EUR-Lex Access to European Union law

Back to EUR-Lex homepage

This document is an excerpt from the EUR-Lex website

Document 32021R1228

Kommissionens gennemførelsesforordning (EU) 2021/1228 af 16. juli 2021 om ændring af gennemførelsesforordning (EU) 2016/799 for så vidt angår kravene til konstruktion, afprøvning, installering, drift og reparation af intelligente takografer og deres komponenter (EØS-relevant tekst)

C/2021/5125

OJ L 273, 30.7.2021, p. 1–140 (BG, ES, CS, DA, DE, ET, EL, EN, FR, GA, HR, IT, LV, LT, HU, MT, NL, PL, PT, RO, SK, SL, FI, SV)

Legal status of the document In force: This act has been changed. Current consolidated version: 21/08/2023

ELI: http://data.europa.eu/eli/reg_impl/2021/1228/oj

30.7.2021   

DA

Den Europæiske Unions Tidende

L 273/1


KOMMISSIONENS GENNEMFØRELSESFORORDNING (EU) 2021/1228

af 16. juli 2021

om ændring af gennemførelsesforordning (EU) 2016/799 for så vidt angår kravene til konstruktion, afprøvning, installering, drift og reparation af intelligente takografer og deres komponenter

(EØS-relevant tekst)

EUROPA-KOMMISSIONEN HAR —

under henvisning til traktaten om Den Europæiske Unions funktionsmåde,

under henvisning til Europa-Parlamentets og Rådets forordning (EU) nr. 165/2014 af 4. februar 2014 om takografer inden for vejtransport (1), særlig artikel 11, og

ud fra følgende betragtninger:

(1)

Ved forordning (EU) nr. 165/2014 er der indført intelligente takografer, som har forbindelse med det globale satellitnavigationssystem (»GNSS«), kommunikationsudstyr til tidlig fjernafsløring og et interface med intelligente transportsystemer.

(2)

De tekniske forskrifter for konstruktion, afprøvning, installering, drift og reparation af takografer og deres komponenter er fastsat ved Kommissionens gennemførelsesforordning (EU) 2016/799 (2).

(3)

Forordning (EU) nr. 165/2014 og Europa-Parlamentets og Rådets forordning (EF) nr. 561/2006 (3) er blevet ændret ved Europa-Parlamentets og Rådets forordning (EU) 2020/1054 (4). I henhold til forordning (EU) 2020/1054 skal der indføres yderligere funktioner i den intelligente takograf. Derfor må en ny version af den intelligente takograf fastsættes med en ændring af gennemførelsesforordning (EU) 2016/799.

(4)

I overensstemmelse med artikel 8, stk. 1, i forordning (EU) nr. 165/2014 bør køretøjets position registreres automatisk, hver gang køretøjet krydser en medlemsstats grænse, og hver gang der i forbindelse med køretøjet foretages læsnings- eller aflæsningsaktiviteter.

(5)

Interfacet med intelligente transportsystemer, som er valgfrit i den version af den intelligente takograf, der blev indført pr. 15. juni 2019, bør være obligatorisk for den nye version af den intelligente takograf.

(6)

Den nye version af den intelligente takograf bør være forberedt til at kunne autentificere Galileo-satellitsignalet, så snart Galileo-systemet bliver operationelt.

(7)

For at undgå en fysisk udskiftning af kontrolapparatet, hver gang takografens tekniske specifikationer ændres, bør det sikres, at fremtidige takograffunktioner kan implementeres og forbedres via softwareopdateringer.

(8)

Gennemførelsesforordning (EU) 2016/799 giver mulighed for at installere en adapter mellem bevægelsessensoren og takografen for køretøjer, der, selv om de har en vægt på under 3,5 ton, lejlighedsvis kan overskride denne tærskel, f.eks. ved at trække et påhængskøretøj. Efter ændringen af forordning (EF) nr. 561/2006 er forpligtelsen til at montere en takograf blevet udvidet til at omfatte køretøjer over 2,5 ton. Den obligatoriske montering af den intelligente takograf i lette erhvervskøretøjer gør det nødvendigt at øge det sikkerhedsniveau, som tilvejebringes med adapteren, ved at montere en intern sensor i takografen, som fungerer uafhængigt af bevægelsessensorens signal.

(9)

Foranstaltningerne i denne forordning er i overensstemmelse med udtalelse fra det udvalg, der er nedsat ved artikel 42, stk. 1, i forordning (EU) nr. 165/2014 —

VEDTAGET DENNE FORORDNING:

Artikel 1

Bilag I C til gennemførelsesforordning (EU) 2016/799 ændres som anført i bilaget til nærværende forordning.

Artikel 2

Ikrafttræden

Denne forordning træder i kraft på tyvendedagen efter offentliggørelsen i Den Europæiske Unions Tidende.

Den anvendes fra den 21. august 2023.

Denne forordning er bindende i alle enkeltheder og gælder umiddelbart i hver medlemsstat.

Udfærdiget i Bruxelles, den 16. juli 2021.

På Kommissionens vegne

Ursula VON DER LEYEN

Formand


(1)  EUT L 60 af 28.2.2014, s. 1.

(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 (EUT L 139 af 26.5.2016, s. 1).

(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 (EUT L 102 af 11.4.2006, s. 1).

(4)  Europa-Parlamentets og Rådets forordning (EU) 2020/1054 af 15. juli 2020 om ændring af forordning (EF) nr. 561/2006, for så vidt angår minimumskravene for maksimal daglig og ugentlig køretid, minimumspauser samt daglig og ugentlig hviletid, og forordning (EU) nr. 165/2014, for så vidt angår lokalisering ved hjælp af takografer (EUT L 249 af 31.7.2020, s. 1).


BILAG

I bilag I C til gennemførelsesforordning (EU) 2016/799 foretages følgende ændringer:

(1)

I indholdsfortegnelsen foretages følgende ændringer:

(a)

Følgende indsættes som punkt 3.6.4:

"3.6.4

Indlæsning af laste-/losseoperation"

(b)

Følgende indsættes som punkt 3.9.18:

"3.9.18

Hændelsen "GNSS-anomali""

(c)

Følgende indsættes som punkt 3.12.17, 3.12.18 og 3.12.19:

"3.12.17

Grænsepassager

3.12.18

Laste-/losseoperationer

3.12.19

Digitalt kort"

(d)

Punkt 3.20 affattes således:

"3.20

Dataudveksling med yderligere eksterne enheder"

(e)

Følgende indsættes som punkt 3.27 og 3.28:

"3.27

Overvågning af grænsepassager

3.28

Softwareopdatering"

(f)

Følgende indsættes som punkt 4.5.3.2.1.1:

"4.5.3.2.1.1

Yderligere identifikation af applikation (anvendes ikke af version 1 af køretøjsenheder af anden generation)"

(g)

Følgende indsættes som punkt 4.5.3.2.17-4.5.3.2.22:

"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øjsenheder af anden generation)

4.5.3.2.19

Grænsepassager (anvendes ikke af version 1 af køretøjsenheder af anden generation)

4.5.3.2.20

Laste-/losseoperationer (anvendes ikke af version 1 af køretøjsenheder af anden generation)

4.5.3.2.21

Indlæsninger af lasttype (anvendes ikke af version 1 af køretøjsenheder 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)"

(h)

Følgende indsættes som punkt 4.5.4.2.1.1:

"4.5.4.2.1.1

Yderligere identifikation af applikation (anvendes ikke af version 1 af køretøjsenheder af anden generation)"

(i)

Følgende indsættes som punkt 4.5.4.2.16-4.5.4.2.22:

"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øjsenheder 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øjsenheder af anden generation)

4.5.4.2.20

Indlæsninger af lasttype (anvendes ikke af version 1 af køretøjsenheder af anden generation)

4.5.4.2.21

Yderligere kalibreringsdata (anvendes ikke af version 1 af køretøjsenheder 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)"

(j)

Følgende indsættes som punkt 4.5.5.2.1.1 efter punkt 4.5.5.2.1:

"4.5.5.2.1.1

Yderligere identifikation af applikation (anvendes ikke af version 1 af køretøjsenheder af anden generation)"

(k)

Følgende indsættes som punkt 4.5.5.2.6:

"4.5.5.2.6

Konfiguration af køretøjsenhed (anvendes ikke af version 1 af køretøjsenheder af anden generation)"

(l)

Følgende indsættes som punkt 4.5.6.2.1.1 efter punkt 4.5.6.2.1:

"4.5.6.2.1.1

Yderligere identifikation af applikation (anvendes ikke af version 1 af køretøjsenheder af anden generation)"

(m)

Følgende indsættes som punkt 4.5.6.2.6:

"4.5.6.2.6

Konfiguration af køretøjsenhed (anvendes ikke af version 1 af køretøjsenheder af anden generation)".

(2)

Indledningen før listen over tillæg affattes således:

"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 takografkort 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 takografsystemer 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 kapacitet til 56 dages føreraktiviteter indføres der ved denne forordning desuden tekniske krav til anden version af anden generation af kontrolapparat og takografkort."

(3)

I afsnit 1 foretages følgende ændringer:

(a)

Litra f) affattes således:

"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øjsidentifikation (VIN, VRN og den registrerende medlemsstat) samt køretøjskarakteristika (w, k, l, dækstørrelse, hastighedsbegrænserens indstilling (hvis relevant), aktuel UTC-tid, aktuel kilometerstand, standardindstillet lasttype). Ved kalibrering af et kontrolapparat skal type og ID for alle monterede plomber, der relevante for typegodkendelsen, også registreres i datalageret.

En opdatering eller bekræftelse, som udelukkende omfatter UTC-tid, betragtes som en tidsjustering og ikke som en kalibrering, 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"

(b)

Litra g) affattes således:

"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 kortfornyelsesindeks.

Et kort er således entydigt identificeret ved den udstedende medlemsstats kode og kortnummeret"

(c)

Litra i) og j) affattes således:

"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"

(d)

Litra ee) affattes således:

"ee)

"ugyldigt kort":

et kort, der enten findes defekt, som ikke har bestået ægthedskontrollen, 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 identifikation af ejer sammen med fortløbende indeks, og et højere fornyelsesindeks allerede blevet indsat i køretøjsenheden, eller

hvis et kort med samme kortudstedende medlemsstat, samme identifikation, dvs. identifikation af fører eller identifikation af ejer sammen med fortløbende indeks, men med et højere erstatningsindeks allerede blevet indsat i køretøjsenheden"

(e)

Litra ll) affattes således:

"ll)

"udstyr til fjernkommunikation", "modul til fjernkommunikation" eller "udstyr til tidlig fjernafsløring":

det udstyr i køretøjsenheden, som anvendes til at udføre målrettede vejsidekontroller".

(f)

litra nn) affattes således:

"nn)

"kortfornyelse":

udstedelse af et nyt takografkort, når et eksisterende kort enten udløber, fejlfungerer eller er blevet returneret til den udstedende myndighed"

(g)

litra pp) affattes således:

"pp)

"korterstatning":

udstedelse af et nyt takografkort som erstatning for et eksisterende kort, som er erklæret tabt, stjålet eller defekt og ikke er returneret til den udstedende myndighed"

(h)

litra tt) affattes således:

"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"

(i)

i litra yy) affattes første led således:

"—

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 (1)"

(j)

litra aaa) affattes således:

"aaa)

forbeholdt fremtidig brug"

(k)

litra ccc) affattes således:

"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."

(4)

I punkt 2.1 foretages følgende ændringer:

(a)

Nr. 5) affattes således:

"5)

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)

Nr. 7), sidste afsnit, affattes således:

"Dette foregår i overensstemmelse med gældende EU-lovgivning om databeskyttelse og i overensstemmelse med artikel 7 i forordning (EU) nr. 165/2014."

(5)

I punkt 2.2 foretages følgende ændringer:

(a)

Sjette led affattes således:

"—

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)

Følgende led tilføjes

"—

overvågning af grænsepassager

softwareopdatering."

(6)

I punkt 2.3 foretages følgende ændringer:

(a)

I nr. 12) affattes femte led således:

"—

Dataoverførselsfunktionen er ikke tilgængelig i driftstilstand, 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)

I nr. 13) foretages følgende ændringer:

i)

Andet led affattes således:

"—

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."

ii)

Fjerde led affattes således:

"—

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."

(7)

I punkt 2.4, nr. 14), affattes fjerde led således:

"—

eksternt GNSS-udstyr (denne profil kræves og gælder kun for den eksterne variant af GNSS-udstyr)."

(8)

I punkt 3.1 foretages følgende ændringer:

(a)

Nr. 16) affattes således:

"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 kontrolapparatet anvende de takografkortdata, der er gemt i dets datalager, som fastsat i krav 133."

(b)

Nr. 20) affattes således:

"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."

(9)

I punkt 3.2 foretages følgende ændringer:

(a)

Nr. 26) og 27) affattes således:

"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 muliggøre registrering af:

positioner, hvor føreren og/eller medchaufføren påbegynder 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)

I punkt 3.2.1 tilføjes følgende punktum i nr. 30):

"Tolerancerne må ikke anvendes til forsætligt at ændre den målte afstand."

(c)

I punkt 3.2.2 affattes nr. 33) således:

"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."

(d)

I punkt 3.2.3 affattes nr. 37) således:

"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."

(10)

I punkt 3.3 foretages følgende ændringer:

(a)

Nr. 41) affattes således:

"41)

Tidspunktdriften skal være ± 1 sekund pr, dag eller derunder under temperaturforhold i overensstemmelse med krav 213 og uden tidsjustering."

(b)

Som nr. 41a), 41b) og 41c) indsættes:

"41a)

Tidsnøjagtigheden, når tiden justeres af værksteder i overensstemmelse 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 tidsjustering i overensstemmelse med punkt 3.23. Den maksimale 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 tidsjustering af kontrolapparatet i overensstemmelse med punkt 3.23. Dette omfatter:

automatiske tidsjusteringer

tidsjusteringer udført i kalibreringstilstand."

(11)

I punkt 3.6 foretages følgende ændringer:

(a)

I punkt 3.6.1 foretages følgende ændringer:

i)

Nr. 57)-59) affattes således:

"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. overskrives ikke mere) en midlertidig indlæsning ved sidste udtag af kortet:

der indlæses et sted, hvor den aktuelle daglige arbejdsperiode begynder, under den manuelle indlæsning i henhold til krav 61)

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 sluttede, under den manuelle indlæsning i henhold til krav 61).

Under de følgende omstændigheder overskrives en midlertidig 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)."

ii)

I nr. 60) indsættes følgende afsnit:

"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)

I punkt 3.6.2 affattes nr. 61) således:

"61)

Kontrolapparatet skal efter isætning af fører- eller værkstedskortet, og først på det tidspunkt, tillade manuel indlæsning af aktiviteter. Manuel indlæsning af aktiviteter foretages med lokal tid og dato i den tidszone (UTC-forskydning), som køretøjsenheden aktuelt er indstillet til.

Ved isætning af fører- eller værkstedskort skal kortindehaveren 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.

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ødvendige for at indstille en aktivitetstype og et start- og et sluttidspunkt for hver aktivitet. For enhver del af tidsperioden mellem den sidste kortudtagning og den aktuelle kortisætning skal kortindehaveren have mulighed for ikke at registrere nogen aktivitet.

Under de manuelle indlæsninger i forbindelse med kortisæ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 kortudtagning, 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 arbejdstiden begynder eller slutter, under de manuelle indlæsninger i forbindelse med kortisætningen, anses dette for en angivelse 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, overskriver så den midlertidige indlæsning, der blev foretaget ved den sidste kortudtagning.

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æsninger bliver afbrudt, skal kontrolapparatet godkende alle komplette indlæsninger af steder og aktiviteter (med enten entydigt sted og tid eller aktivitetstype og start- og sluttidspunkt), 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 aktiviteter for et tidligere isat kort, skal de manuelle indlæsninger 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ækkefø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ærksteder 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."

(c)

I punkt 3.6.3 affattes nr. 62) således:

"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).

"OVERFART MED FÆRGE/TOG" må ikke finde sted, når betingelsen "UDEN FOR GYLDIGHEDSOMRÅDE" er åbnet. Hvis betingelsen "UDEN FOR GYLDIGHEDSOMRÅ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 kalenderminut i overensstemmelse med punkt 3.4.

Hvis flere specifikke betingelser af den samme type indlæses inden for et kalenderminut, registreres kun den sidste."

(d)

Følgende tilføjes som punkt 3.6.4:

"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øretøjet forlader det sted, hvor laste-/losseoperation udføres."

(12)

I punkt 3.9 foretages følgende ændringer:

(a)

I punkt 3.9.12 affattes nr. 83) således:

"83)

Denne hændelse skal udløses uden for kalibreringstilstand ved afbrydelse af den normale dataudveksling mellem bevægelsessensor og køretøjsenhed og/eller ved fejl i dataintegritet eller -ægthedskontrol under dataudveksling 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)

I punkt 3.9.13 affattes nr. 84) således:

"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."

(c)

I punkt 3.9.15 affattes nr. 86) således:

"86)

Denne hændelse skal udløses uden for kalibreringstilstand, hvis køretøjsenheden registrerer en forskel mellem tiden i køretøjsenhedens tidsmålingsfunktion og tidsangivelsen 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 "tidskonflikt", umiddelbart inden køretøjsenheden automatisk justerer køretøjsenhedens interne ur, i overensstemmelse med krav 211."

(d)

I punkt 3.9.17 affattes ottende led således:

"—

Fejl ved ITS-grænseflade."

(e)

Følgende punkt tilføjes:

"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."

(13)

I punkt 3.10 affattes den sidste række i tabellen således:

"ITS-grænseflade

Korrekt funktion"

 

(14)

I punkt 3.12 foretages følgende ændringer:

(a)

Første afsnit affattes således:

"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

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)

I punkt 3.12.1.1 foretages følgende ændringer:

i)

I nr. 93) tilføjes følgende led:

"—

identifikator af version af digitalt kort (krav 133l)."

ii)

Nr. 94) affattes således:

"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."

(c)

I punkt 3.12.1.2 affattes første afsnit i nr. 97) således:

"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):"

(d)

I punkt 3.12.1.3 affattes første afsnit i nr. 100) således:

"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ældende dag)"

(e)

I punkt 3.12.5 foretages følgende ændringer:

i)

I nr. 110) foretages følgende ændringer:

1)

Første led affattes således:

"—

kortnummer for fører og/eller medchauffør samt kortudstedende medlemsstat"

2)

Følgende led tilføjes:

"—

et flag, der viser, om positionen er blevet ægthedsbekræftet."

ii)

Følgende indsættes som nr. 110a):

"110a)

For steder, hvor den daglige arbejdstid begynder eller slutter, som er indlæst under den manuelle indlæsningsprocedure ved isætning af kortet i overensstemmelse med krav 61, gemmes køretøjets aktuelle kilometerstand og position."

(f)

I punkt 3.12.8 foretages følgende ændringer i nr. 117):

i)

femte række affattes således:

"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.":

ii)

Følgende række tilføjes:

"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ældende dag."

(g)

I punkt 3.12.10 tilføjes følgende led i nr. 120):

"—

serienumrene på bevægelsessensoren, eventuelt eksternt GNSS-udstyr og eventuelt eksternt fjernkommunikationsudstyr

den lasttype, der som standard er knyttet til køretøjet (last af gods eller passagerer)

det land, hvor kalibreringen er foretaget, og den dato og det klokkeslæt, hvor GNSS-modtageren leverede positionen til bestemmelse af dette land."

(h)

Følgende punkter indsættes:

"3.12.17   Grænsepassager

133a)

Kontrolapparatet skal registrere og lagre følgende oplysninger 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 kortudstedende medlemsstat

kortgeneration

den tilhørende GNSS-nøjagtighed, dato og tid

et flag, der viser, om positionen er blevet ægthedsbekræftet

køretøjets kilometerstand på tidspunktet for registrering af grænsepassage.

133c)

Datalageret skal kunne opbevare disse data om grænsepassage 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 oplysninger om køretøjets laste- og losseoperationer i sit datalager:

operationstypen (lastning, losning eller samtidig lastning/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 kontrolapparatet bruge den seneste tilgængelige position og den tilhørende dato og tid.

133g)

Sammen med operationstypen og positionen skal kontrolapparatet registrere 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 ægthedsbekræ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 overvå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 versionsidentifikator 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 softwareopdateringsmekanismer, 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.

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."

(15)

I punkt 3.13 foretages følgende ændringer:

(a)

I nr. 134) affattes tredje led således:

"—

til beregning af førerens sammenhængende køretid, akkumulerede pausetid og akkumulerede køretider for den foregående og den aktuelle uge".

(b)

Følgende indsættes som nr. 135a):

"135a)

Strukturen i applikationen "TACHO_G2" afhænger af versionen. Version 2-kort indeholder yderligere elementærfiler i forhold til version 1-kort, herunder:

i fører- og værkstedskort:

Elementærfilen Places_Authentication skal indeholde status for ægthedsbekræftelse for de køretøjspositioner, 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øretø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.

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 indeholde supplerende kalibreringsdata ud over dem, der er lagret i elementærfilen Calibration. Den gamle dato- og klokkeslætværdi og køretøjets identifikationsnummer 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æftelse i elementærfilen Places_Authentication eller elementærfilen GNSS_Places_Authentication, hvis der ikke findes en køretøjsposition med samme tidsstempel i elementærfilen Places eller elementærfilen GNSS_Places.

Køretøjsenheden skal ignorere elementærfilen VU_Configuration 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."

(16)

I punkt 3.14 foretages følgende ændringer:

(a)

I punkt 3.14.1 foretages følgende ændringer:

i)

Nr. 140) affattes således:

"140)

Hændelser og fejl, der ikke er defineret for kontrolapparater af første generation, skal ikke lagres på fører- og værkstedskortene."

ii)

Nr. 143) affattes således:

"143)

Før et fører- eller værkstedskort frigives, og efter at alle relevante data er gemt på kortet, skal kontrolapparatet tilbagestille "kortsessionsdata"."

(b)

I punkt 3.14.2 foretages følgende ændringer:

i)

I nr. 144) tilføjes følgende afsnit:

"Strukturen i applikationen "TACHO_G2" afhænger af versionen. Version 2-kort indeholder yderligere elementærfiler i forhold til version 1-kort."

ii)

Følgende indsættes som nr. 147a) og 147b):

"147a)

Ved isætning af et fører- eller værkstedskort skal kontrolapparatet 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 midlertidigt som anført i krav 59. Hvis dette sted ligger i et andet land end det, hvor køretøjet befinder sig, skal kontrolapparatet 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øretøjet aktuelt befinder sig i

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."

iii)

Følgende indsættes som nr. 150a):

"150a)

Køretøjsenheden skal ignorere elementærfilen VU_Configuration 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."

(17)

I punkt 3.15.4 foretages følgende ændringer i nr. 167):

(a)

Andet led affattes således:

"—

indholdet af de udskrifter, der er anført i krav 169, i samme format som selve udskrifterne"

(b)

Femte og sjette led affattes således:

"—

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"

(c)

Ottende, niende og tiende led affattes således:

"—

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."

(18)

I punkt 3.18 foretages følgende ændringer:

(a)

Nr. 193) affattes således:

"193)

Som en ikke obligatorisk facilitet kan kontrolapparatet desuden i enhver funktionstilstand overføre data til en virksomhed, hvis identitet er bekræftet gennem denne kanal, via en anden grænseflade. I så fald skal der for denne dataoverførsel gælde samme adgangsret til data som i virksomhedstilstand."

(b)

Følgende indsættes som nr. 196a) og 196b):

"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."

(19)

I punkt 3.19 tilføjes følgende led i nr. 199):

"—

køretøjets position

en angivelse, hvis føreren på nuværende tidspunkt muligvis overtræder køretiderne."

(20)

I punkt 3.20 foretages følgende ændringer:

(a)

Overskriften affattes således:

"3.20

Dataudveksling med yderligere eksterne enheder"

(b)

Nr. 200) affattes således:

"200)

Kontrolapparatet skal også være udstyret med en ITS-grænseflade 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 kalibreringstilstand. 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"

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 tilstedeværelse forstyrre eller påvirke køretøjsenhedens funktionstilstand og sikkerhed.

Der kan samtidig anvendes yderligere køretøjsenhedsgrænseflader, forudsat at de fuldt ud overholder minimumskravene i tillæg 13 med hensyn til førerens samtykke. Kontrolapparatet 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 takograffabrikantens 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 overensstemmelse 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ænseflader."

(c)

Nr. 201) affattes således:

"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 klassificeret som en del af køretøjets net i overensstemmelse med krav 200."

(21)

I punkt 3.21 foretages følgende ændringer:

(a)

I nr. 202) foretages følgende ændringer:

i)

Niende led affattes således:

"—

at opdatere eller bekræfte andre parametre, som kontrolapparatet har kendskab til: køretøjsidentifikation, w, l, dækstørrelse, hastighedsbegrænserens indstilling (hvis relevant) og standardlasttype"

ii)

Følgende led tilføjes:

"—

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)

Nr. 205) affattes således:

"205)

Sammenkobling af det eksterne GNSS-udstyr til køretøjsenheden skal som minimum bestå af:

opdatering af det eksterne GNSS-udstyrs monteringsdata, 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."

(22)

I punkt 3.22 tilføjes følgende afsnit i nr. 209):

"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."

(23)

I punkt 3.23 foretages følgende ændringer:

(a)

Nr. 211) affattes således:

"211

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ø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ø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 ægthedsbekræftede positionsmeddelelser som fastsat i tillæg 12. Referencetidspunktet for den automatiske indstilling af køretøjsenhedens interne ur skal være klokkeslættet i den ægthedsbekræftede positionsmeddelelse."

(b)

Nr. 212) affattes således:

"212)

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 ægthedsbekræftede positionsmeddelelser som fastsat i tillæg 12. I sidstnævnte tilfælde anvendes tjenesten RoutineControl i overensstemmelse med afsnit 8 i tillæg 8."

(24)

Følgende indsættes som punkt 3.27 og 3.28:

"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 implementering 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 typegodkendende myndigheder giver deres tilladelse til softwareopdateringerne baseret på den eksisterende typegodkendte køretøjsenhed, i overensstemmelse med artikel 12, stk. 5, i forordning (EU) nr. 165/2014.

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 oplysninger 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ødvendige for at gennemføre krav 226e, og ledige hardwareressourcer til mindst 65 % af opdateringen af det digitale kort baseret på de hardwareressourcer, der kræves til version 2021 af NUTS 0-kortet."

(25)

I punkt 4.1, efter nr. 235), erstattes bagsiden af kontrolkortet på billedet "Takografkort i henhold til fællesskabsmodellen" af følgende:

"

Image 1

"

(26)

I punkt 4.5 foretages følgende ændringer:

(a)

Nr. 246) affattes således:

"246)

Yderligere data kan lagres på takografkort, såfremt lagring af disse data er i overensstemmelse med den gældende lovgivning om databeskyttelse."

(b)

I nr. 247) indsættes følgende bemærkning efter andet led:

"Bemærk: version 2 af kort af anden generation indeholder yderligere elementære filer i den dedikerede fil Tachograph_G2."

(c)

I punkt 4.5.3.2 foretages følgende ændringer:

i)

Overskriften affattes således:

"4.5.3.2

Takografapplikation af anden generation (ikke tilgængelig for køretøjsenheder af første generation, tilgængelig for version 1 og version 2 af køretøjsenheder af anden generation)"

ii)

Følgende indsættes som punkt 4.5.3.2.1.1 efter punkt 4.5.3.2.1:

"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 applikationsidentifikationsdata, der kun gælder for version 2."

iii)

I punkt 4.5.3.2.7 affattes nr. 287) således:

"287)

Førerkortet skal kunne lagre data for de 12 seneste hændelser af hver type (dvs. 132 hændelser)."

iv)

I punkt 4.5.3.2.8 affattes nr. 290) således:

"290)

Førerkortet skal kunne lagre data for de 24 seneste fejl af hver type (dvs. 48 fejl)."

v)

I punkt 4.5.3.2.9 affattes nr. 292) således:

"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)."

vi)

I punkt 4.5.3.2.10 affattes nr. 295) således:

"295)

Førerkortet skal kunne lagre 200 sådanne poster."

vii)

I punkt 4.5.3.2.11 affattes nr. 297) således:

"297)

Førerkortets hukommelse skal kunne lagre mindst 112 sådanne poster."

viii)

I punkt 4.5.3.2.14 affattes nr. 302) således:

"302)

Førerkortet skal kunne lagre 112 sådanne poster."

ix)

I punkt 4.5.3.2.15 affattes nr. 304) således:

"304)

Førerkortet skal kunne lagre 200 sådanne poster."

x)

I punkt 4.5.3.2.16 affattes nr. 306) således:

"306)

Førerkortet skal kunne lagre 336 sådanne poster."

xi)

Følgende indsættes som punkt 4.5.3.2.17-4.5.3.2.22:

"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 Tachograph_G2

et flag, der viser, om positionen er blevet ægthedsbekræftet.

306b)

Førerkortets hukommelse skal kunne lagre 112 sådanne poster.

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øjsenheder 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ærfilen GNSS_Places under den dedikerede fil Tachograph_G2

et flag, der viser, om positionen er blevet ægthedsbekræ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 ægthedsbekræ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øjsenheder af anden generation)

306g)

Førerkortet skal kunne lagre følgende data vedrørende laste-/losseoperationer:

operationstypen (lastning, losning eller samtidig lastning/losning)

dato og klokkeslæt for laste-/losseoperationen

køretøjets position

GNSS-nøjagtigheden, dato og klokkeslæt for registrering af positionen.

et flag, der viser, om positionen er blevet ægthedsbekræ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øjsenheder af anden generation)

306i)

Førerkortet skal kunne lagre følgende data vedrørende lasttype, 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øretøjsenheder af anden generation)

306k)

Førerkortet skal kunne lagre kortindehaverens specifikke takografindstillinger.

306l)

Førerkortets kapacitet til lagring af kortindehaverens specifikke takografindstillinger skal være på 3 072 byte."

(d)

I punkt 4.5.4.2 foretages følgende ændringer:

i)

Overskriften affattes således:

"4.5.4.2

Takografapplikation af anden generation (ikke tilgængelig for køretøjsenheder af første generation, tilgængelig for version 1 og version 2 af køretøjsenheder af anden generation)"

ii)

Følgende indsættes som punkt 4.5.4.2.1.1 efter punkt 4.5.4.2.1:

"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 applikationsidentifikationsdata, der kun gælder for version 2."

iii)

I punkt 4.5.4.2.6 affattes nr. 338) således:

"338)

Værkstedskortet skal kunne lagre 255 sådanne poster."

iv)

I punkt 4.5.4.2.8 affattes nr. 344) således:

"344)

Værkstedskortet skal kunne lagre data om førerens aktivitet i mindst 1 dag med 240 aktivitetsskift."

v)

I punkt 4.5.4.2.9 affattes nr. 346) således:

"346)

Værkstedskortet skal kunne lagre 8 sådanne poster."

vi)

Punkt 4.5.4.2.10 affattes således:

"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."

vii)

I punkt 4.5.4.2.13 affattes nr. 352) således:

"352)

Værkstedskortet skal kunne lagre 8 sådanne poster."

viii)

I punkt 4.5.4.2.14 affattes nr. 354) således:

"354)

Værkstedskortet skal kunne lagre 24 sådanne poster."

ix)

I punkt 4.5.4.2.15 affattes nr. 356) således:

"356)

Værkstedskortet skal kunne lagre 4 sådanne poster."

x)

Følgende tilføjes som punkt 4.5.4.2.16-4.5.4.2.22:

"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.

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øjsenheder 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øjsenheder 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øjsenheder 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øjsenheder af anden generation)

356k)

Værkstedskortet skal kunne lagre supplerende kalibreringsdata, der kun gælder for version 2:

Den gamle dato- og klokkeslætværdi og køretøjets identifikationsnummer, som skal være præcist de samme værdier som dem, der er lagret i elementærfilen Calibration under den dedikerede fil Tachograph_G2

den standardlasttype, der er indlæst under denne kalibrering

det land, hvor kalibreringen er foretaget, og det tidspunkt, hvor GNSS-modtageren leverede positionen til bestemmelse af dette land.

356l)

Værkstedskortet skal kunne lagre 255 sådanne poster.

4.5.4.2.22

Konfiguration af køretøjsenhed (anvendes ikke af version 1 af køretøjsenheder af anden generation)

356 m)

Værkstedskortet skal kunne lagre kortindehaverens specifikke takografindstillinger.

356n)

Værkstedskortets kapacitet til lagring af kortindehaverens specifikke takografindstillinger skal være på 3 072 byte."

(e)

I punkt 4.5.5 foretages følgende ændringer:

i)

I punkt 4.5.5.1.5 affattes andet led således:

"—

kontrollens art (visning og/eller udskrivning og/eller dataoverførsel på køretøjsenhed og/eller dataoverførsel på kort)"

ii)

Følgende indsættes som punkt 4.5.5.2.1.1 efter punkt 4.5.5.2.1:

"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 applikationsidentifikationsdata, der kun gælder for version 2."

iii)

Følgende indsættes efter punkt 4.5.5.2.5:

"4.5.5.2.6

Konfiguration af køretøjsenhed (anvendes ikke af version 1 af køretø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."

(f)

I punkt 4.5.6.2 foretages følgende ændringer:

i)

Følgende indsættes efter punkt 4.5.6.2.1:

"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 applikationsidentifikationsdata, der kun gælder for version 2."

ii)

Følgende indsættes som punkt 4.5.6.2.6:

"4.5.6.2.6

Konfiguration af køretøjsenhed (anvendes ikke af version 1 af køretø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."

(27)

I punkt 5 foretages følgende ændringer:

(a)

I punkt 5.1 foretages følgende ændringer:

i)

Nr. 383) affattes således:

"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."

ii)

Nr. 392) affattes således:

"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 kalibreringen, 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øretø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)

I punkt 5.2 foretages følgende ændringer:

i)

I nr. 395) affattes første afsnit således:

"Når apparatet er blevet kontrolleret efter monteringen, anbringes en installationsplade med permanent indgravering eller tryk klart synligt og lettilgængeligt på kontrolapparatet. Hvis dette ikke er muligt, skal pladen fastgøres til køretøjets "B"-søjle, så den er klart synlig. I køretø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."

ii)

I nr. 396) foretages følgende ændringer:

1)

Tiende led affattes således:

"—

serienummeret på udstyret til fjernkommunikation, hvis relevant"

2)

følgende sekstende led tilføjes:

"—

den lasttype, der som standard er knyttet til køretøjet."

(28)

I punkt 6.4 foretages følgende ændringer:

(a)

Nr. 409) affattes således:

"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ækperiferi, 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)

I nr. 410) tilføjes følgende niende led:

"—

at versionsidentifikatoren for det lagrede digitale kort er den seneste."

(c)

Følgende indsættes som nr. 410a):

"410a)

Hvis de kompetente nationale myndigheder konstaterer et tilfælde af manipulation, kan køretøjet sendes til et autoriseret værksted med henblik på rekalibrering af kontrolapparatet."

(29)

I punkt 8 foretages følgende ændringer:

(a)

I punkt 8.1 affattes nr. 429) og 430) således:

"429)

Procedurer til opdatering af software i et allerede monteret kontrolapparat skal være godkendt af den myndighed, som meddelte typegodkendelse af kontrolapparatet. Softwareopdateringer 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)

I punkt 8.4 foretages følgende ændringer:

i)

Nr. 443) affattes således:

"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."

ii)

Nr. 447) affattes således:

"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."

(30)

I tillæg 1 foretages følgende ændringer:

(a)

I indholdsfortegnelsen foretages følgende ændringer:

i)

Følgende indsættes som punkt 2.11a og 2.11b:

"2.11a.

CardBorderCrossing

2.11b.

CardBorderCrossingRecord"

ii)

Følgende indsættes som punkt 2.24a, 2.24b, 2.24c og 2.24d:

"2.24a.

CardLoadTypeEntries

2.24b.

CardLoadTypeEntryRecord

2.24c.

CardLoadUnloadOperations

2.24d.

CardLoadUnloadRecord"

iii)

Følgende indsættes som punkt 2.26a:

"2.26a.

CardPlaceAuthDailyWorkPeriod"

iv)

Følgende indsættes som punkt 2.48a:

"2.48a.

CompanyCardApplicationIdentificationV2"

v)

Følgende indsættes som punkt 2.50a:

"2.50a.

ControlCardApplicationIdentificationV2"

vi)

Følgende indsættes som punkt 2.60a:

"2.60a.

DownloadInterfaceVersion"

vii)

Følgende indsættes som punkt 2.61a:

"2.61a.

DriverCardApplicationIdentificationV2"

viii)

Følgende indsættes som punkt 2.79a, 2.79b og 2.79c:

"2.79a.

GNSSAuthAccumulatedDriving

2.79b.

GNSSAuthStatusADRecord

2.79c.

GNSSPlaceAuthRecord"

ix)

Punkt 2.84 affattes således:

"2.84.

Forbeholdt fremtidig brug"

x)

Følgende indsættes som punkt 2.89a:

"2.89a.

LengthOfFollowingData"

xi)

Følgende indsættes som punkt 2.90a:

"2.90a.

LoadType"

xii)

Følgende indsættes som punkt 2.101a:

"2.101a.

NoOfBorderCrossingRecords"

xiii)

Følgende indsættes som punkt 2.111a:

"2.111a.

NoOfLoadUnloadRecords"

xiv)

Følgende indsættes som punkt 2.112a:

"2.112a.

NoOfLoadTypeEntryRecords"

xv)

Følgende indsættes som punkt 2.114a:

"2.114a.

OperationType"

xvi)

Følgende indsættes som punkt 2.116a og 2.116b:

"2.116a.

PlaceAuthRecord

2.116b.

PlaceAuthStatusRecord"

xvii)

Følgende indsættes som punkt 2.117a:

"2.117a.

PositionAuthenticationStatus"

xviii)

Følgende indsættes som punkt 2.158a:

"2.158a.

TachographCardsGen1Suppression"

xix)

Følgende indsættes som punkt 2.166a:

"2.166a.

VehicleRegistrationIdentificationRecordArray"

xx)

Følgende indsættes som punkt 2.185a:

"2.185a.

VuConfigurationLengthRange"

xxi)

Følgende indsættes som punkt 2.192a:

"2.192a.

VuDigitalMapVersion"

xxii)

Følgende indsættes som punkt 2.203a og 2.203b:

"2.203a.

VuBorderCrossingRecord

2.203b.

VuBorderCrossingRecordArray"

xxiii)

Følgende indsættes som punkt 2.204a:

"2.204a.

VuGnssMaximalTimeDifference"

xxiv)

Følgende indsættes som punkt 2.208a og 2.208b:

"2.208a.

VuLoadUnloadRecord

2.208b.

VuLoadUnloadRecordArray"

xxv)

Følgende indsættes som punkt 2.222a:

"2.222a.

VuRtcTime"

xxvi)

Følgende indsættes som punkt 2.234a, 2.234b og 2.234c:

"2.234a.

WorkshopCardApplicationIdentificationV2

2.234b.

WorkshopCardCalibrationAddData

2.234c.

WorkshopCardCalibrationAddDataRecord"

(b)

I punkt 2 affattes teksten før punkt 2.1 således:

"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 generation 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."

(c)

Følgende indsættes som punkt 2.11a og 2.11b:

"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).

Image 2

borderCrossingPointerNewestRecord er indekset for den senest opdaterede 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ænsepassageposten på kortet i strukturen.

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).

Image 3

countryLeft er det land, som køretøjet har forladt, eller "ingen tilgængelige 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ø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."

(d)

Følgende indsættes som punkt 2.24a, 2.24b, 2.24c og 2.24d:

"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).

Image 4

loadTypeEntryPointerNewestRecord er indekset for den senest opdaterede 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.

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).

Image 5

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).

Image 6

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 oplysninger om den udførte operationstype (lastning, losning eller samtidig lastning/losning), dato og klokkeslæt for indlæsning af laste-/losseoperationen, 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).

Image 7

timeStamp er dato og klokkeslæt ved begyndelsen af laste-/losseoperationen.

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."

(e)

Følgende indsættes som punkt 2.26a:

"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).

Image 8

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 forekomst af disse poster i strukturen.

placeAuthStatusRecords er mængden af poster, der indeholder status for ægthedsbekræftelse for indlæste steder."

(f)

I punkt 2.36 affattes teksten om den tilordnede værdi "bbH" således:

 

""bb"H Indeks for ændringer vedrørende brug af de dataelementer, 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 generation

 

"01"H for version 2 af applikationer af anden generation"

(g)

I punkt 2.40 affattes afsnittet mellem overskriften og koden således:

"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)."

(h)

Følgende indsættes som punkt 2.48a:

"2.48a.

CompanyCardApplicationIdentificationV2

Anden generation, version 2:

Oplysninger, der er gemt på et virksomhedskort, vedrørende identifikation af kortets applikation (bilag I C, krav 375a).

Image 9

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."

(i)

Følgende indsættes som punkt 2.50a:

"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).

Image 10

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."

(j)

Følgende indsættes som punkt 2.60a:

"2.60a.

DownloadInterfaceVersion

Anden generation, version 2:

Kode, der angiver versionen af en køretøjsenheds overførselsgrænseflade.

Image 11

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."

(k)

Følgende indsættes som punkt 2.61a:

"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).

Image 12

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."

(l)

Punkt 2.63 affattes således:

"2.63.

DSRCSecurityData

Anden generation:

En definition af denne datatype findes i tillæg 11."

(m)

I punkt 2.66 affattes teksten om anden generation således:

"Anden generation

Image 13

Tilordnet værdi: i henhold til ISO/IEC8824-1."

(n)

I punkt 2.70 foretages følgende ændringer:

i)

Overskriften svarende til anden generation affattes således:

"Anden generation, version 1:"

ii)

Følgende tekst tilføjes:

 

"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 fjernkommunikation

"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

"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."

(o)

Punkt 2.71 affattes således:

"2.71.

ExtendedSealIdentifier

Anden generation:

Det udvidede datanavn for en plombe identificerer entydigt plomben (bilag I C, krav 401).

Image 14

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]."

(p)

I punkt 2.76 affattes afsnittet mellem overskriften og koden således:

"Anden generation:

Geo-koordinaterne kodes som heltal. Disse heltal er multipla af kodningen ± DDMM.M for breddegrad og ± DDDMM.M for længdegrad. 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)."

(q)

Følgende indsættes som punkt 2.79a, 2.79b og 2.79c:

"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).

Image 15

gnssAuthADPointerNewestRecord er indekset for den senest opdaterede 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 GNSSAccumulatedDrivingRecord).

Image 16

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-positionen, når den akkumulerede køretid når op på et multiplum af tre timer.

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).

Image 17

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-positionen, da den blev fastlagt."

(r)

Punkt 2.84 affattes således:

"2.84.

Forbeholdt fremtidig brug"

(s)

Følgende indsættes som punkt 2.89a:

"2.89a.

LengthOfFollowingData

Anden generation, version 2:

Længdeindikator for poster, der kan udvides.

Image 18

Tilordnet værdi: Se tillæg 2."

(t)

Følgende indsættes som punkt 2.90a:

"2.90a.

LoadType

Anden generation, version 2:

Kode, der identificerer en indlæst lasttype.

Image 19

Tilordnet værdi:

"00"H

Udefineret lasttype

"01"H

Gods

"02"H

Passagerer

"03"H .. "FF"H

RFU."

(u)

Følgende indsættes som punkt 2.101a:

"2.101a.

NoOfBorderCrossingRecords

Anden generation, version 2:

Antal grænsepassageposter, der kan lagres på et fører- eller værkstedskort.

Image 20

Tilordnet værdi: se tillæg 2."

(v)

Følgende indsættes som punkt 2.111a:

"2.111a.

NoOfLoadUnloadRecords

Anden generation, version 2:

Antal laste-/losseposter, der kan lagres på et kort.

Image 21

Tilordnet værdi: se tillæg 2."

(w)

Følgende indsættes som punkt 2.112a:

"2.112a.

NoOfLoadTypeEntryRecords

Anden generation, version 2:

Antal lasttypeposter, der kan lagres på et fører- eller værkstedskort.

Image 22

Tilordnet værdi: se tillæg 2."

(x)

Følgende indsættes som punkt 2.114a:

"2.114a.

OperationType

Anden generation, version 2:

Kode, der identificerer en indlæst operationstype.

Image 23

Tilordnet værdi:

"00"H

RFU,

"01"H

Lasteoperation

"02"H

Losseoperation

"03"H

Samtidig laste-/losseoperation

"04"H .. "FF"H

RFU."

(y)

Følgende indsættes som punkt 2.116a og 2.116b:

"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:

Image 24

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æsning 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).

Image 25

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."

(z)

Følgende indsættes som punkt 2.117a:

"2.117a.

PositionAuthenticationStatus

Anden generation, version 2:

Image 26

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."

(aa)

I punkt 2.120 affattes de tilordnede værdier "22"H til "7F"H således:

""22"H

VuBorderCrossingRecord

"23"H

VuLoadUnloadRecord

"24"H

VehicleRegistrationIdentification,

"25"H til "7F"H

RFU."

(bb)

Følgende indsættes som punkt 2.158a:

"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).

Image 27 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."

(cc)

Følgende indsættes som punkt 2.166a:

"2.166a.

VehicleRegistrationIdentificationRecordArray

Anden generation, version 2:

Køretøjets indregistreringsnummer plus metadata som anvendt i overførselsprotokollen.

Image 28

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."

(dd)

I punkt 2.168 affattes første linje efter overskriften således:

"Anden generation, version 1:".

(ee)

I punkt 2.174 foretages følgende ændringer:

i)

Overskriften svarende til anden generation affattes således:

"Anden generation, version 1:".

ii)

Følgende tekst tilføjes:

"Anden generation, version 2:

Image 29

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 kalibreringen

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."

(ff)

Følgende indsættes som punkt 2.185a:

"2.185a.

VuConfigurationLengthRange

Anden generation, version 2:

Antal byte i et takografkort, der er tilgængeligt til lagring af køretøjsenhedens konfigurationer.

Image 30

Tilordnet værdi: se tillæg 2."

(gg)

Følgende indsættes som punkt 2.192a:

"2.192a.

VuDigitalMapVersion

Anden generation, version 2:

Version af det digitale kort, der er lagret i køretøjsenheden (bilag I C, krav 133j).

Image 31

Tilordnet værdi: som anført på det dedikerede sikre websted, der stilles til rådighed af Kommissionen (bilag I C, krav 133k)."

(hh)

I punkt 2.203 foretages følgende ændringer:

i)

Overskriften svarende til anden generation affattes således:

"Anden generation, version 1:".

ii)

Følgende tekst tilføjes:

"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).

Image 32

I anden generation, version 2, er gnssPlaceRecord blevet erstattet af gnssPlaceAuthRecord, som også indeholder status for ægthedsbekræftelse af GNSS."

(ii)

Følgende indsættes som punkt 2.203a og 2.203b:

"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).

Image 33

cardNumberAndGenDriverSlot identificerer det kort, der sidder i førerens 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æftelse.

vehicleOdometerValue er køretøjets kilometerstand, når køretøjsenheden 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).

Image 34

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."

(jj)

Følgende indsættes som punkt 2.204a:

"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.

Image 35 "

(kk)

I punkt 2.205 affattes teksten om anden generation således:

"Anden generation:

Image 36

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 understø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)."

(ll)

Følgende indsættes som punkt 2.208a og 2.208b:

"2.208a.

VuLoadUnloadRecord

Anden generation, version 2:

Oplysninger, der er gemt på en køretøjsenhed, vedrørende en indlæst laste-/losseoperation (bilag I C, krav 133e, 133f og 133g).

Image 37

timeStamp er dato og klokkeslæt for indlæsning af laste-/losseoperationen.

operationType er den indlæste operationstype (lastning, losning eller samtidig lastning/losning)

cardNumberAndGenDriverSlot identificerer det kort, der sidder i førerens 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).

Image 38

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."

(mm)

I punkt 2.219 foretages følgende ændringer:

i)

Overskriften svarende til anden generation affattes således:

"Anden generation, version 1:".

ii)

Følgende tekst tilføjes:

"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).

Image 39

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 tidspunkt for bestemmelse af position."

(nn)

Følgende indsættes efter punkt 2.222:

"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.

Image 40 "

(oo)

Følgende indsættes som punkt 2.234a, 2.234b og 2.234c:

"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).

Image 41

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).

Image 42

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 kalibrering 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 identifikationsnummer og køretøjets standartlasttype.

2.234c.

WorkshopCardCalibrationAddDataRecord

Anden generation, version 2:

Oplysninger, der er gemt på et værkstedskort, vedrørende standardlasttypen, der er indlæst under en kalibrering (bilag I C, krav 356k).

Image 43

oldTimeValue er den gamle værdi for dato og klokkeslæt i den tilsvarende 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."

(31)

I tillæg 2 foretages følgende ændringer:

(a)

I punkt 2.5 affattes andet afsnit i krav TCS_09 således:

"i driftstilstand, mens det udfører kommandoer eller er koblet til køretøjsenheden"

(b)

I punkt 3 foretages følgende ændringer:

i)

I punkt 3.2.1 udgår fjerde led i krav TCS_16.

ii)

I punkt 3.5.7.2 foretages følgende ændringer:

1)

Krav TCS_86 affattes således:

"TCS_86

Kommandoen kan udføres i hovedfilen, den dedikerede fil Tachograph og den dedikerede fil Tachograph_G2. Se også TCS_34."

2)

Krav TCS_88 og TCS_89 affattes således:

"TCS_88

For APDU'er med kort længde gælder følgende bestemmelser: 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 bestemmelser: 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."

iii)

I punkt 3.5.10 affattes den sidste række i tabellen i krav TCS_101 således:

"Le

1

"00h"

Som foreskrevet i ISO/IEC 7816-4"

iv)

I punkt 3.5.16 affattes den sidste række i tabellen i krav TCS_138 således:

"Le

1

"00h"

Som foreskrevet i ISO/IEC 7816-4"

(c)

I punkt 4 foretages følgende ændringer:

i)

I krav TCS_141 affattes andet afsnit således:

"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 applikationer af første generation understøtte det maksimale antal poster, der er anført i TCS_150 og TCS_158."

ii)

I punkt 4.2.1 foretages følgende ændringer i tabellen i krav TCS_150:

1)

Rækken svarende til cardIssuingAuthorityName affattes således:

"

Image 44

"

2)

Rækken svarende til LastCardDownload affattes således:

"

Image 45

"

iii)

I punkt 4.2.2 foretages følgende ændringer:

1)

Krav TCS_152 affattes således:

"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 decimaltal. F.eks. svarer værdien 30 til 11110 som binært tal.

Elementærfilen Application_Identification_V2, elementærfilen Places_Authentication, elementærfilen GNSS_Places_Authentication, elementærfilen Border_Crossings, 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 Application_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.

Image 46

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"

2)

Krav TCS_154 affattes således:

"TCS_154

Førerkortapplikationen af anden generation skal have følgende datastruktur:

Image 47

Image 48

Image 49

"

3)

I krav TCS_155 affattes tabellen således:

"

 

 

 

 

 

 

Min

Max

n1

NoOfEventsPerType

12

12

n2

NoOfFaultsPerType

24

24

n3

NoOfCardVehicleRecords

200

200

n4

NoOfCardPlaceRecords

112

112

n6

CardActivityLengthRange

13776 bytes

(56 døgn med 117 aktivitetsskift)

13776 bytes

(56 døgn med 117 aktivitetsskift)

n7

NoOfCardVehicleUnitRecords

200

200

n8

NoOfGNSSADRecords

336

336

n9

NoOfSpecificConditionRecords

112

112

n10

NoOfBorderCrossingRecords

1120

1120

n11

NoOfLoadUnloadRecords

1624

1624

n12

NoOfLoadTypeEntryRecords

336

336

n13

VuConfigurationLengthRange

3072 bytes

3072 bytes

"

iv)

I punkt 4.3.2 foretages følgende ændringer:

1)

Krav TCS_160 affattes således:

"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 decimaltal. F.eks. svarer værdien 30 til 11110 som binært tal.

Elementærfilen Application_Identification_V2, elementærfilen Places_Authentication, elementærfilen GNSS_Places_Authentication, elementærfilen Border_Crossings, elementærfilen Load_Unload_Operations, elementærfilen Load_Type_Entries, elementærfilen VU_Configuration og elementærfilen Calibration_Add_Datafindes kun i version 2 af værkstedskortet af anden generation.

cardStructureVersion i elementærfilen Application_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.

Image 50

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"

2)

I krav TCS_162 affattes tabellen således:

"

Image 51

Image 52

Image 53

Image 54

"

3)

I krav TCS_163 affattes tabellen således:

"

 

 

 

 

 

 

Min

Max

n1

NoOfEventsPerType

3

3

n2

NoOfFaultsPerType

6

6

n3

NoOfCardVehicleRecords

8

8

n4

NoOfCardPlaceRecords

8

8

n5

NoOfCalibrationRecords

255

255

n6

CardActivityLengthRange

492 byte (1 dag * 240 aktivitetsskift)

492 byte (1 dag

med 240 aktivitetsskift)

n7

NoOfCardVehicleUnitRecords

8

8

n8

NoOfGNSSADRecords

24

24

n9

NoOfSpecificConditionRecords

4

4

n10

NoOfBorderCrossingRecords

4

4

n11

NoOfLoadUnloadRecords

8

8

n12

NoOfLoadTypeEntryRecords

4

4

n13

VuConfigurationLengthRange

3072 byte

3072 byte

";

v)

I punkt 4.4.2 foretages følgende ændringer:

1)

Krav TCS_168 affattes således:

"TCS_168

Efter at kontrolkortapplikationen 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 decimaltal. 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 Application_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.

Image 55

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"

2)

I krav TCS_170 affattes tabellen således:

"

Image 56

Image 57

"

3)

I krav TCS_171 affattes tabellen således:

"

 

 

 

 

 

 

Min

Max

n7

NoOfControlActivityRecords

230

520

n13

VuConfigurationLengthRange

3072 byte

3072 byte

"

vi)

I punkt 4.5.2 foretages følgende ændringer:

1)

Krav TCS_176 affattes således:

"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 decimaltal. 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 Application_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.

Image 58

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"

2)

I krav TCS_178 affattes tabellen således:

"

Image 59

".

3)

I krav TCS_179 affattes tabellen således:

"

 

 

 

 

 

 

Min

Max

n8

NoOfCompanyActivityRecords

230

520

n13

VuConfigurationLengthRange

3072 byte

3072 byte

".

(32)

I tillæg 3 foretages følgende ændringer:

(a)

I punkt 1 foretages følgende ændringer:

i)

Afsnittet om særlige omstændigheder affattes således:

"Særlige omstændigheder, manuel indlæsning

Image 60

Uden for gyldighedsområde

Image 61

Overfart med færge/tog

Image 62

Lasteoperation

Image 63

Losseoperation

Image 64

Samtidig laste-/losseoperation

Image 65

Lasttype: passagerer

Image 66

Lasttype: gods

Image 67

Lasttype: udefineret lasttype"

ii)

Piktogrammerne for diverse ændres som følger:

1)

Sikkerhedspiktogrammet ændres således:

" Image 68

Sikkerhed/bekræftede data/plomber"

2)

Følgende piktogram tilføjes:

" Image 69

Digitalt kort/grænsepassage"

(b)

I punkt 2 foretages følgende ændringer:

i)

Følgende piktogramkombinationer føjes til piktogrammerne for diverse:

 

"

Image 70

Position, hvor køretøjet har passeret grænsen mellem to lande

Image 71

Position, hvor en lasteoperation har fundet sted

Image 72

Position, hvor en losseoperation har fundet sted

Image 73

Position, hvor en samtidig laste-/losseoperation har fundet sted"

ii)

Følgende piktogramkombination føjes til piktogrammerne for udskrifter:

" Image 74

Udskrift af historik for isatte kort"

iii)

Følgende piktogramkombination føjes til piktogrammerne for hændelser:

" Image 75

GNSS-anomali"

(33)

I tillæg 4 foretages følgende ændringer:

(a)

I punkt 1 affattes krav PRT_005 således:

"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)

I punkt 2 foretages følgende ændringer:

i)

Følgende led tilføjes efter tabellen og før krav PRT_007:

"—

I en datagruppe henviser teksten efter "pi=" til det tilsvarende piktogram 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, Image 76 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."

ii)

Datagruppe 2 og 3 affattes således:

"

Image 77

Image 78

Er kortet ikke et personligt kort og ikke påført kortindehaverens efternavn, skal der i stedet herfor udskrives virksomhedens, værkstedets eller kontrolorganets navn."

iii)

Før datagruppe 4 slettes den sætning, der indledes med en asterisk.

iv)

Følgende datagruppe indsættes efter datagruppe 4:

"

Image 79

".

v)

Datagruppe 5 affattes således:

"

Image 80

".

vi)

Før datagruppe 6 slettes den sætning, der indledes med en asterisk.

vii)

Følgende datagruppe indsættes efter datagruppe 8a:

"

Image 81

".

viii)

Datagruppe 8.2 affattes således:

"

Image 82

".

ix)

Datagruppe 10.2 affattes således:

"

Image 83

".

x)

Før datagruppe 11 slettes den sætning, der indledes med en asterisk.

xi)

Datagruppe 11.4 og 11.5 affattes således:

"

Image 84

Image 85

Image 86

Image 87

".

xii)

Datagruppe 14 affattes således:

"

Image 88

".

xiii)

Datagruppe 15.1 affattes således:

"

Image 89

".

xiv)

Datagruppe 16 og 16,1 affattes således:

"

16

GNSS-identifikation*

Image 90

Image 91

Image 92

Image 93

".

xv)

Datagruppe 17.1 affattes således:

"

Image 94

Kalibreringens formål (p) er en numerisk kode, som forklarer, hvorfor de pågældende kalibreringsparametre blev registreret, og som er kodet i henhold til dataelementet CalibrationPurpose."

xvi)

Datagruppe 23 affattes således:

"

Image 95 :";

(c)

I punkt 3 foretages følgende ændringer:

i)

I punkt 3.1 affattes krav PRT_008 således:

"PRT_008

Daglig udskrift af føreraktivitet fra kort skal overholde følgende format:

Image 96 ";

ii)

I punkt 3.2 affattes krav PRT_009 således:

"PRT_009

Daglig udskrift af føreraktivitet fra køretøjsenhed skal overholde følgende format:

Image 97 ";

iii)

I punkt 3.5 affattes krav PRT_012 således:

"PRT_012

Udskrift af tekniske data skal overholde følgende format:

Image 98 ";

iv)

I punkt 3.7 affattes krav PRT_014 således:

"PRT_014

Udskriften af historikken over isatte kort skal overholde følgende format:

Image 99 ".

(34)

I tillæg 7 foretages følgende ændringer:

(a)

I indholdsfortegnelsen foretages følgende ændringer:

i)

Punkt 2.2.6.1 til 2.2.6.5 affattes således:

"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 Dataoverførsel, Oversigt)

2.2.6.3

Positive Response Transfer Data Activities (Positivt Svar Dataoverførsel, Aktiviteter)

2.2.6.4

Positive Response Transfer Data Events and Faults (Positivt Svar Dataoverførsel, Hændelser og Fejl)

2.2.6.5

Positive Response Transfer Data Detailed Speed(Positivt Svar Dataoverførsel, Præcis Hastighedsangivelse)"

ii)

Følgende punkt tilføjes:

"2.2.6.6

Positive Response Transfer Data Technical Data (Positivt Svar Dataoverførsel, Tekniske Data)".

(b)

I punkt 2 foretages følgende ændringer:

i)

I punkt 2.2.2 affattes tabellen over meddelelsesstrukturen og bemærkningerne efter tabellen således:

"

Message Structure

Max 4 Bytes

Max 255 Bytes

1 Byte

 

 

Header

Data

CheckSum

IDE ->

<- VU

FMT

TGT

SRC

LEN

SID

DS_ / TRTP

DATA

CS

Start Communication Request

81

EE

F0

 

81

 

 

E0

Positive Response Start Communication

80

F0

EE

03

C1

 

EA, 8F

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

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 Communication

80

F0

EE

01

C2

 

 

21

Acknowledge sub message

80

EE

F0

Len

83

 

Data

CS

Negative responses

 

 

 

 

 

 

 

 

General reject

80

F0

EE

03

7F

Sid Req

10

CS

Service not supported

80

F0

EE

03

7F

Sid Req

11

CS

Sub function not supported

80

F0

EE

03

7F

Sid Req

12

CS

Incorrect Message Length

80

F0

EE

03

7F

Sid Req

13

CS

Conditions not correct or Request sequence error

80

F0

EE

03

7F

Sid Req

22

CS

Request out of range

80

F0

EE

03

7F

Sid Req

31

CS

Upload not accepted

80

F0

EE

03

7F

Sid Req

50

CS

Response pending

80

F0

EE

03

7F

Sid Req

78

CS

Data not available

80

F0

EE

03

7F

Sid Req

FA

CS

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 kompatibilitet 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 kortplads) 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.

TRTP 24 anvendes til anmodninger om overførsel af køretøjsenhedsdata af anden generation, version 1 og version 2.

TRTP 00, 31, 32, 33 og 35 anvendes til anmodninger om overfø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øretøjsenhedsdata af første generation. De accepteres eventuelt af køretø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ørselsanmodninger."

ii)

I punkt 2.2.2.9 foretages følgende ændringer:

1)

I krav DDP_011 affattes første afsnit og den første tabel således:

"Der er syv typer af dataoverførsel. For overførsel af køretø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

".

2)

Krav DDP_054 affattes således:

"DDP_054

IDE-enheden skal obligatorisk anmode om oversigt over dataoverførsel (TRTP 01, 21 eller 31) under en dataoverfø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 overføres."

iii)

I punkt 2.2.2.10 affattes teksten før leddene i krav DDP_055 således:

"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 indeholder følgende oplysninger:"

iv)

I punkt 2.2.5.2 affattes figur 2:

" Image 100 ".

v)

Punkt 2.2.6.1 til 2.2.6.5 affattes således:

"2.2.6.1

Positive Response Transfer Data Download Interface Version (Positivt Svar Dataoverførsel, Version af Download-Interface)

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:

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

Positive Response Transfer Data Overview (Positivt Svar Dataoverførsel, Oversigt)

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

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

Positive Response Transfer Data Activities (Positivt Svar Dataoverførsel, Aktiviteter)

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:

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 overførte dag. Hvis feltet står tomt, sendes kun noOfPlaceRecords = 0.

 

 

VuSpecificConditionData

 

Data vedrørende særlige omstændigheder, der er registreret 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 overfø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 registreret 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 overfø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 registreret 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.

 

 

 

2.2.6.4

Positive Response Transfer Data Events and Faults (Positivt Svar Dataoverførsel, Hændelser og Fejl)

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øjsenheden.

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øjsenheden.

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 noOfVuOverSpeedingEvents = 0.

VuTimeAdjustmentData

 

Alle tidsjusteringshændelser, der er gemt i køretøjsenheden (uden for rammerne af en komplet kalibrering).

Hvis feltet står tomt, sendes kun noOfVuTimeAdjRecords = 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øjsenheden.

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øjsenheden.

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øjsenheden (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øjsenheden.

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øjsenheden.

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øjsenheden (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

Positive Response Transfer Data Detailed Speed

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øjsenheden (é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.

 

 

 

Datastruktur, anden generation (TREP 24 Hex)

Dataelement

 

Bemærkning

VuDetailedSpeedBlockRecordArray

 

Alle detaljerede hastighedsdata, der er gemt i køretøjsenheden (é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.

 

 

 

".

vi)

Følgende punkt tilføjes:

"2.2.6.6

Positive Response Transfer Data Technical Data

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øjsenheden

VuSensorExternalGNSSCoupledRecordArray

 

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øjsenheden.

VuITSConsentRecordArray

 

 

VuPowerSupplyInterruptionRecordArray

 

 

SignatureRecordArray

 

ECC-underskrift for alle foregående data.

 

 

 

Datastruktur, anden generation, version 2 (TREP 35 Hex)

Dataelement

 

Bemærkning

VuIdentificationRecordArray

 

 

VuSensorPairedRecordArray

 

Alle bevægelsessensorparringer, der er gemt i køretøjsenheden

VuSensorExternalGNSSCoupledRecordArray

 

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øjsenheden.

VuITSConsentRecordArray

 

 

VuPowerSupplyInterruptionRecordArray

 

 

SignatureRecordArray

 

ECC-underskrift for alle foregående data.

 

 

 

".

(c)

I punkt 3.3 affattes krav DDP_035 således:

"DDP_035

Overførsel af et takografkort omfatter følgende trin:

Overførsel af kortets fælles oplysninger i elementærfilerne 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ærfiler (i den dedikerede fil Tachograph) undtagen elementærfilen Card_Download. Disse oplysninger sikres med en digital underskrift i henhold til tillæg 11 Fælles sikkerhedsmekanismer, 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øretø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 Tachograph_G2:

Overførsel af elementærfilerne CardSignCertificate, CA_Certificate og Link_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ærfiler (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 sikkerhedsmekanismer, del B.

Ved hver overførselssession er det obligatorisk som minimum at overføre elementærfilerne Application_Identification, Application_Identification_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 kalibreringstæ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 elementærfilen Sensor_Installation_Data i den dedikerede fil Tachograph og den dedikerede fil Tachograph_G2, hvis det er relevant, ikke overføres."

(35)

I tillæg 8 foretages følgende ændringer:

(a)

I indholdsfortegnelsen foretages følgende ændringer:

i)

Punkt 8, 8.1 og 8.2 affattes således:

"8.

ROUTINECONTROL SERVICE (TIDSJUSTERING)

8.1.

Beskrivelse af meddelelser

8.2.

Meddelelsesformat"

ii)

Følgende tilføjes som punkt 9, 9.1 og 9.2:

"9.

FORMATER TIL DATARECORDS

9.1.

Værdiområder for overførte parametre

9.2.

Formater til dataRecords"

(b)

I punkt 3.1 føjes følgende række til tabel 1:

"

 

Diagnostic Sessions

RoutineControl

8

31

 

Image 101

Image 102

".

(c)

I punkt 6.1.3 affattes krav CPR_053 således:

"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 dataelement i tillæg 1, som recordDataIdentifier er baseret på (omkodning kan være nødvendig).

Tredje kolonne (Beskrivelse) indeholder navnet på den tilsvarende recordDataIdentifier.

Fjerde kolonne (Adgangsrettigheder) angiver adgangsrettighederne 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)

Adgangsrettigheder

(Read/Write)

Huskeværdi

F90B

CurrentDateTime

TimeDate

R/W

RDI_TD

F912

HighResOdometer

HighResolutionTotalVehicleDistance

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

RemoteCommunicationModuleSerialNumber

RemoteCommunicationFacilitySerialNumber

R

RDI_RCSN

F9D2

SensorGNSSSerialNumber

ExternalGNSSFacilitySerialNumber

R

RDI_GSSN

F9D3

SealDataVu

SmartTachographSealsSerialNumber

R/W

RDI_SDV

F9D4

VuSerialNumber

VuSerialNumber

R

RDI_VSN

F9D5

ByDefaultLoadType

ByDefaultLoadType

R/W

RDI_BDLT

F9D6

TachographCardsGen1Suppression

TachographCardsGen1Suppression

R/W

RDI_TCG1S

F9D7

VehiclePosition

VehiclePosition

R

RDI_VP

F9D8

LastCalibrationCountry

CalibrationCountry

R

RDI_CC

".

(d)

Punkt 8 affattes således:

"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. Diagnosetesteren 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

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

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

".

(e)

Følgende tilføjes som punkt 9:

"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 datatransmissionsservicer, der er beskrevet i punkt 6.

CPR_067

Alle angivne parametre skal være understøttet af køretøjsenheden.

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 parameterværdier.

CPR_071

Værdierne i området "forefindes ikke" giver køretøjsenheden mulighed for at overføre en meddelelse, som indeholder 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 parametre, 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 indikatorbit

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 "*" reserveres som skilletegn.

9.2.

Formater til dataRecords

Tabel 39 til Tabel 42 nedenfor angiver de formater, som skal anvendes via servicerne ReadDataByIdentifier og WriteDataByIdentifier.

CPR_074

Tabel 39 angiver længde, opløsning og arbejdsområde for hver parameter, som er identificeret ved sin recordDataIdentifier:

Tabel 39

Format af dataRecords

Parameternavn

Datalængde (byte)

Opløsning

Arbejdsområde

TimeDate

8

Se nærmere i Tabel 40

HighResolutionTotalVehicleDistance

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

RemoteCommunicationModuleSerialNumber

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

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 parameteren 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ærdierne 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.

CPR_078

Tabel 42 angiver formaterne for de forskellige byte i parameteren 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 parameteren 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 parameteren 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 parametrene VuSerialNumber, SensorSerialNumber, SensorGNSSSerialNumber og RemoteCommunicationModuleSerialNumber:

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 RemoteCommunicationModuleSerialNumber:

 

Format ExtendedSerialNumber som fastlagt i tillæg 1.

ikke relevant

ExtendedSerialNumber

CPR_093

Tabel 46 angiver formaterne for de forskellige byte i parameteren TachographCardsGen1Suppression:

Tabel 46

Detaljeret format af TachographCardsGen1Suppression (recordDataIdentifier-værdi # F9D6)

Længde

Parameterdefinition

Opløsning

Arbejdsområde

1 — 2

TachographCardsGen1Suppression. Format TachographCardsGen1Suppression som fastlagt i tillæg 1.

ikke relevant

"0000"H, "A5E3"H

CPR_094

Tabel 47 angiver formaterne for de forskellige byte i parameteren 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 opdateringen af nuværende land og region blive forsinket."

(36)

I tillæg 9 foretages følgende ændringer:

(a)

I indholdsfortegnelsen indsættes følgende som punkt 9:

"9.

OSNMA-PRØVER"

(b)

I punkt 1 foretages følgende ændringer:

i)

I punkt 1.1 indsættes følgende afsnit:

"Medlemsstatens myndighed med ansvar for funktionsprøverne for køretø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."

ii)

I punkt 1.2 tilføjes følgende reference:

"RGODP

JRC Technical Report — Receiver guidelines for OSNMA data processing (Retningslinjer for modtagere med henblik på OSNMA-databehandlingen)"

(c)

I punkt 2 affattes række 3.1-3.41 således:

"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*

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".

(d)

Følgende tilføjes som punkt 9:

"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 typegodkendelsesmyndighederne med nærmere oplysninger om udviklingen og resultaterne af de prøvninger, der udføres under GNSS-modtagerfabrikantens 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øvebetingelser.

Kriterierne kan revideres i forbindelse med Galileo-erklæringen om OSNMA-tjenesten og under hensyntagen til de tilknyttede præstationsforpligtelser.

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 Guidelines 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 (Digitalsignaturmeddelelse KROOT)

GNSS

Global Navigation Satellite System (Globalt satellitnavigationssystem)

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)

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, ephemeris 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 Operational 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).

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 tidssynkronisering er opfyldt for hver prøvningsbetingelse, dvs. nominel synkronisering 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-navigationsdata 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 hukommelse 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-navigationsdata 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 tidsinitialisering, 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.

 

Før prøvningen påbegyndes, slettes ephemeris- og KROOT-oplysningerne fra GNSS-modtagerens hukommelse 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-navigationsdata 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.

Tillæg 12

GNS_3b

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-navigationsdata 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 behandlingen 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

".

(37)

I tillæg 12 foretages følgende ændringer:

(a)

I indholdsfortegnelsen foretages følgende ændringer:

i)

Efter punkt 1.1 indsættes følgende som punkt 1.1.1:

"1.1.1

Referencer"

ii)

Punkt 2 affattes således:

"2.

GNSS-MODTAGERENS GRUNDLÆGGENDE EGENSKABER"

iii)

Punkt 3 affattes således:

"3.

SÆTNINGER FRA GNSS-MODTAGEREN"

iv)

Følgende indsættes som punkt 4.2.4 og 4.2.5:

"4.2.4

WriteRecord-kommandoens struktur

4.2.5

Andre kommandoer"

v)

Punkt 5.2 affattes således:

"5.2.

Overførsel af oplysninger fra GNSS-modtageren til køretøjsenheden"

vi)

Punkt 5.2.1. udgår.

vii)

Følgende indsættes som punkt 5.3, 5.4 og 5.4.1:

"5.3.

Overførsel af oplysninger fra køretøjsenheden til GNSS-modtageren

5.4.

Fejlhåndtering

5.4.1

Manglende positionsoplysninger fra GNSS-modtager"

viii)

Punkt 6 og 7 affattes således:

"6.

KØRETØJSENHEDENS BEHANDLING OG REGISTRERING AF POSITIONSDATA

7.

GNSS-TIDSKONFLIKT".

ix)

Følgende tilføjes som punkt 8:

"8.

KØRETØJSBEVÆGELSESKONFLIKT".

(b)

I punkt 1 foretages følgende ændringer:

i)

Teksten før figur 1 affattes således:

"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:"

ii)

Efter punkt 1.1 indsættes følgende som punkt 1.1.1:

"1.1.1

Henvisninger

Følgende henvisninger benyttes i denne del af dette tillæg.

NMEA

NMEA (National Marine Electronics Association) 0183 Interface Standard, V4.11"

iii)

I punkt 1.2 tilføjes følgende akronymer:

"OSNMA

Galileo Open Service Navigation Messages Authentication (Ægthedsbekræftelse af navigationsmeddelelser via åben Galileo-tjeneste)

RTC

Real Time Clock (Realtidsur)

".

(c)

I punkt 2 foretages følgende ændringer:

i)

Overskriften affattes således:

"2.

GNSS-MODTAGERENS GRUNDLÆGGENDE EGENSKABER"

ii)

Krav GNS_3 affattes således:

"GNS_3

GNSS-modtageren skal kunne understøtte Navigation Messages Authentication on the Open Service of Galileo (OSNMA)."

iii)

Følgende indsættes som krav GNS_3a til GNS_3g:

"GNS_3a

GNSS-modtageren foretager en række overensstemmelseskontroller 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 kombineret 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ålingerne

RAIM-teknikker (receiver autonomous integrity monitoring), 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 tidsspring 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-oplysninger, 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 standardpositionsmeddelelser, der er udarbejdet ved brug af de synlige satellitter, uanset om de er ægthedsbekræftede eller ej.

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."

(d)

Punkt 3 affattes således:

"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 konfigurationen 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-standarden):

Image 103

$--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.

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 (breddegrad 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-standarden, bortset fra værdi nr. 2):

Image 104

$--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 satellitter, 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

Navigationsstatus er valgfri og indgår muligvis ikke i AMC-sætningen.

Status viser, om der findes en ægthedsbekræftet GNSS-position, 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 GeoCoordinates.

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).

Image 105

$--GSA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*hh

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.

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 defineret i NMEA V4.11-standarden.

Image 106

$--ASA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*hh

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 postnummer "02" til "06", og ASA-sætningen lagres med postnummer "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ørrelsen af kommandoen Read record, er 85 byte (se tabel 1)."

(e)

I punkt 4 foretages følgende ændringer:

i)

I punkt 4.1.1 foretages følgende ændringer i krav GNS_9:

1)

Teksten før litra b) affattes således:

"GNS_9

Det eksterne GNSS-udstyr består af følgende komponenter (se figur 6):

a)

En kommerciel GNSS-modtager, der leverer positionsdata via GNSS-datainterfacet. GNSS-datainterfacet kan f.eks. følge NMEA-standard V4.11, hvor GNSS-modtageren 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."

2)

Litra c) affattes således:

"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 beskyttelsesprofilen for den intelligente takograf."

ii)

I punkt 4.2.1 foretages følgende ændringer:

1)

Krav GNS_14 affattes således:

"GNS_14

Kommunikationsprotokollen mellem det eksterne GNSS-udstyr og køretøjsenheden skal understøtte følgende funktioner:

1.

indsamling og distribution af GNSS-data (f.eks., position, tidspunkt, hastighed)

2.

indsamling af konfigurationsdata for det eksterne GNSS-udstyr

3.

administrationsprotokollen, der understøtter sammenkoblingen, gensidig ægthedskontrol og kontrol af sessionsnøgleoverensstemmelse mellem det eksterne GNSS-udstyr og køretøjsenheden

4.

overførslen til det eksterne GNSS-udstyr af køretøjsenhedens RTC-tid og af den maksimale forskel mellem sand tid og køretøjsenhedens RTC-tid."

2)

Følgende indsættes efter krav GNS_18:

"GNS_18a

Med hensyn til funktion 4) (overførslen til det eksterne GNSS-udstyr af køretøjsenhedens RTC-tid og af den maksimale forskel mellem sand tid og køretøjsenhedens RTC-tid) skal den sikre GNSS-sender/modtager anvende en elementærfil (elementærfilen VU) i den samme dedikerede fil med en filidentifikator svarende til "2F30" som beskrevet i tabel 1."

3)

Følgende indsættes efter krav GNS_19:

"GNS_19a

Den sikre GNSS-sender/modtager gemmer data fra køretøjsenheden i elementærfilen VU. Dette er en lineær registerfil af fast længde med en identifikator lig med "2F30" i hexadecimalformat."

4)

I krav GNS_20 affattes første afsnit således:

"GNS_20

Den sikre GNSS-sender/modtager skal anvende en hukommelse 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."

5)

I GNS_21 affattes tabel 1 således:

"

Tabel 1

Filstruktur

 

 

Adgangsbetingelser

Fil

Fil-ID

Læs

Update

Krypteret

MF

3F00

 

 

 

EF.ICC

0002

ALW

NEV

(efter køretøjsenhed)

Nr.

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øjsenhed)

Nr.

EF VU

2F30

SM-MAC

SM-MAC

Nr.


Fil/dataelement

Post nr.

Størrelse (bytes)

Standardværdier

 

 

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

 

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 SensorExternalGNSSApprovalNumber.

"09"

16

16

 

Identifikator for sikkerhedskomponenten for det eksterne GNSS-udstyr defineret i tillæg 1 som SensorExternalGNSSSCIdentifier

"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}

".

iii)

I punkt 4.2.2 foretages følgende ændringer:

1)

I krav GNS_22 affattes første afsnit således:

"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:"

2)

Krav GNS_23 affattes således:

"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æcisionsopløsning (fra GSA- og ASA-sætningen). Køretøjsenhedens 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ærfilen 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øretøjsenhedens sikre sender/modtager ved hjælp af APDU-svarmeddelelsen i tilstanden "Kun ægthedskontrol" 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øjsenhedens 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å oplysningerne (f.eks. breddegrad, længdegrad, tidspunkt) af AMC-sætningen. AMC-sætningen medtager oplysningerne, 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ætningerne og beregner mindsteværdien af de tilgængelige satellitsystemer (dvs. når den modtager et signal).

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 ægthedskontrol" 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."

iv)

I punkt 4.2.3 foretages følgende ændringer:

1)

I krav GNS_26 affattes fjerde og femte led således:

"—

Hvis posten ikke findes, tilbagemelder den sikre GNSS-sender/modtager "6A83".

Hvis det eksterne GNSS-udstyr har konstateret manipulation, tilbagemelder det statusordene "6690"."

2)

Krav GNS_27 udgår.

v)

Følgende indsættes som punkt 4.2.4 og 4.2.5:

"4.2.4

WriteRecord-kommandoens struktur

Dette afsnit indeholder en detaljeret beskrivelse af Write Record-kommandoens 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 meddelelsesoverfø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, tilbagemelder 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 manipulation, 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 specificeres 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 certifikat)

Tillæg 2, kapitel 3.5.7

External Authenticate (Ekstern ægthedskontrol)

Tillæg 2, kapitel 3.5.9

General Authenticate (Almen ægthedskontrol)

Tillæg 2, kapitel 3.5.10

MSE:SET

Tillæg 2, kapitel 3.5.11.

".

vi)

I punkt 4.4.1 affattes krav GNS_28 således:

"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."

vii)

I punkt 4.4.2 affattes krav GNS_29 således:

"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 registrerer 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 meddelelsesoverførsel og med status "6A88"."

viii)

I punkt 4.4.3 affattes krav GNS_30 således:

"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-kommandoen med et RECORD-nummer lig med "01" med et datafelt på 12 byte, som alle er sat til 0xFF. Efter modtagelsen af svarmeddelelsen med denne værdi i datafeltet, genererer og registrerer køretøjsenheden hændelsen "Manglende positionsoplysninger fra GNSS-modtager" som defineret i krav 81 i bilag I C og tillæg 1 (EventFaultType)."

ix)

I punkt 4.4.4 foretages følgende ændringer:

1)

Krav GNS_31 affattes således:

"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øjsenheden anvender stadig de modtagne GNSS-positionsdata."

2)

Overskriften på figur 4 affattes således:

"Figur 6

Skema over det eksterne GNSS-udstyr"

(f)

I punkt 5 foretages følgende ændringer:

i)

I punkt 5.1 affattes krav GNS_32 således:

"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."

ii)

Punkt 5.2 affattes således:

"5.2.

Overførsel af oplysninger fra GNSS-modtageren til køretøjsenheden

GNS_34

Køretøjsenhedens processor kontrollerer de modtagne data ved at udtrække oplysningerne (f.eks. breddegrad, længdegrad, 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 positionsdataene 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øretø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 overensstemmelse 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.

5.3.

Overførsel af oplysninger fra køretøjsenheden til GNSS-modtageren

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 (EventFaultType)."

(g)

Punkt 6 og 7 affattes således:

"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 standardpositionen er gyldige og overensstemmende, registreres standardpositionen og dens nøjagtighed i køretøjsenheden, og flaget indstilles til "ægthedsbekræftet".

b)

Hvis både den ægthedsbekræftede position og standardpositionen er gyldige, men ikke overensstemmende, lagrer køretøjsenheden den ægthedsbekræftede position og dens nøjagtighed, og flaget indstilles til "ægthedsbekræftet".

c)

Hvis den ægthedsbekræftede position er gyldig, og standardpositionen ikke er gyldig, registrerer køretøjsenheden den ægthedsbekræftede position og dens nøjagtighed, og flaget indstilles til "ægthedsbekræftet".

d)

Hvis standardpositionen er gyldig, og den ægthedsbekræftede position ikke er gyldig, registrerer køretøjsenheden 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 indikator, 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ålapplikationen, herunder bymiljøer. Der anvendes en konstant værdi på σUERE = 10 meter.

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.

Image 107

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 tidskonflikt som defineret i krav 86 i bilag I C og tillæg 1 (EventFaultType)."

(h)

Følgende tilføjes som punkt 8:

"8.

KØRETØJSBEVÆGELSESKONFLIKT

GNS_42

Køretøjsenheden udløser og registrerer hændelsen køretøjsbevæ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:

 

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ægelsesfø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 gennemsnittet 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 afvigende 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øretøjets hastighedsværdier estimeret ud fra bevægelsessensoren 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 × OdometerToleranceFactor + Minimum(SlipDistanceUpperlimit;(OdometerDifference × SlipFactor)) + GnssTolerance + FerryTrainDistance]

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 positionsmeddelelser, uden hensyntagen til højden

OdometerDifference er forskellen mellem den aktuelle kilometerstand og kilometertællerens værdi svarende til den tidligere gyldige ægthedsbekræftede positionsmeddelelse

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-tolerance)

Minimum (SlipDistanceUpperLimit; (OdometerDifference * SlipFactor)) er minimumsværdien mellem:

SlipDistanceUpperLimit, som er lig med 10 km den øvre grænse for slipafstand forårsaget af udslipseffekter under bremsning)

og OdometerDifference * SlipFactor, hvor SlipFactor 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ægelsesføleren ikke detekterer nogen bevægelse, og den uafhængige 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."

(38)

Tillæg 13 affattes således:

"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-INTERFACET, OG KLASSIFICERING SOM PERSONLIG/IKKE PERSONLIG

1.   INDLEDNING

1.1.   Anvendelsesområde

ITS_01

I dette tillæg specificeres de grundlæggende elementer i kommunikationen gennem takografinterfacet med intelligente transportsystemer (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 applikationerne på den eksterne anordning

ITS-sikkerhedsspecifikationen ud over Bluetooth®

Bluetooth®-protokollerne, som ITS-interfacet benytter.

1.2.   Akronymer og definitioner

Følgende akronymer og definitioner anvendes i dette tillæg:

GNSS

Global Navigation Satellite System (Globalt satellitnavigationssystem)

ITS

Intelligent Transport System (Intelligent transportsystem)

OSI

Open Systems Interconnection (Åbne systemers sammenkobling)

VU

Vehicle Unit (Køretøjsenhed)

ITS-enhed

En ekstern enhed eller applikation, der anvender køretøjsenhedens 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 bestemmelserne 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 etableres, når en Bluetooth®-parring er udført.

ITS_07

Der etableres en sikker og krypteret kommunikation mellem køretøjsenheden og ITS-enheden i overensstemmelse med Bluetooth®-specifikationsmekanismerne. Dette tillæg omhandler ikke kryptering eller andre sikkerhedsmekanismer ud over det, som Bluetooth® 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.

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.

Image 108

ITS_10

Når downloadinterfacet anvendes via det forreste stik, leverer køretø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.

Tabel 1

ITS-interfacet tilgængelighed afhængigt af den type kort, der er isat i takografen

Tilgængelighed af ITS-interfacet

Førerkortplads

 

Intet kort

Førerkort

Kontrolkort

Værkstedskort

Virksomhedskort

Kortplads for medchauffør

Intet kort

Ikke til rådighed

Til rådighed

Til rådighed

Til rådighed

Til rådighed

Førerkort

Til rådighed

Til rådighed

Til rådighed

Til rådighed

Til rådighed

Kontrolkort

Til rådighed

Til rådighed

Til rådighed

Ikke til rådighed

Ikke til rådighed

Værkstedskort

Til rådighed

Til rådighed

Ikke til rådighed

Til rådighed

Ikke til rådighed

Virksomhedskort

Til rådighed

Til rådighed

Ikke til rådighed

Ikke til rådighed

Til rådighed

ITS_14

Efter en vellykket ITS Bluetooth®-parring tildeler køretøjsenheden ITS Bluetooth®-forbindelsen til det specifikke isatte 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

Kortplads for medchauffør

Intet kort

Ikke til rådighed

Førerkort

Kontrolkort

Værkstedskort

Virksomhedskort

Førerkort

Førerkort

Førerkort  (*2)

Kontrolkort

Værkstedskort

Virksomhedskort

Kontrolkort

Kontrolkort

Kontrolkort

Kontrolkort  (*1)

Ikke til rådighed

Ikke til rådighed

Værkstedskort

Værkstedskort

Værkstedskort

Ikke til rådighed

Værkstedskort  (*1)

Ikke til rådighed

Virksomhedskort

Virksomhedskort

Virksomhedskort

Ikke til rådighed

Ikke til rådighed

Virksomhedskort  (*1)

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.

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 obligatoriske 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 overensstemmelse 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 kalibreringstilstand, forvaltes adgangsrettighederne via ITS-interfacet i overensstemmelse 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-INTERFACET, OG KLASSIFICERING SOM PERSONLIG/IKKE PERSONLIG

Databetegnelse

Dataformat

Kilde

Dataklassificering (personlig/ ikke personlig)

Samtykke til oplysningernes tilgængelighed

Tilgængelighed

fører

medchauffør

VehicleIdentificationNumber

Tillæg 8

Køretøjsenhed

ikke personlig

ikke personlig

intet behov for samtykke

obligatorisk

CalibrationDate

ISO 16844-7

Køretøjsenhed

ikke personlig

ikke personlig

intet behov for samtykke

obligatorisk

TachographVehicleSpeed

ISO 16844-7

Køretøjsenhed

personlig

Ikke relevant

førerens samtykke

obligatorisk

Driver1WorkingState

ISO 16844-7

Køretøjsenhed

personlig

Ikke relevant

førerens samtykke

obligatorisk

Driver2WorkingState

ISO 16844-7

Køretøjsenhed

Ikke relevant

personlig

medchaufførens samtykke

obligatorisk

DriveRecognize

ISO 16844-7

Køretøjsenhed

ikke personlig

ikke personlig

intet behov for samtykke

obligatorisk

Driver1TimeRelatedStates

ISO 16844-7

Køretøjsenhed

personlig

Ikke relevant

førerens samtykke

obligatorisk

Driver2TimeRelatedStates

ISO 16844-7

Køretøjsenhed

Ikke relevant

personlig

medchaufførens samtykke

obligatorisk

DriverCardDriver1

ISO 16844-7

Køretøjsenhed

personlig

Ikke relevant

førerens samtykke

obligatorisk

DriverCardDriver2

ISO 16844-7

Køretøjsenhed

Ikke relevant

personlig

medchaufførens samtykke

obligatorisk

OverSpeed

ISO 16844-7

Køretøjsenhed

personlig

Ikke relevant

førerens samtykke

obligatorisk

TimeDate

Tillæg 8

Køretøjsenhed

ikke personlig

ikke personlig

intet behov for samtykke

obligatorisk

HighResolutionTotalVehicleDistance

ISO 16844-7

Køretøjsenhed

ikke personlig

ikke personlig

intet behov for samtykke

obligatorisk

HighResolutionTripDistance

ISO 16844-7

Køretøjsenhed

ikke personlig

ikke personlig

intet behov for samtykke

obligatorisk

ServiceComponentIdentification

ISO 16844-7

Køretøjsenhed

ikke personlig

ikke personlig

intet behov for samtykke

obligatorisk

ServiceDelayCalendarTimeBased

ISO 16844-7

Køretøjsenhed

ikke personlig

ikke personlig

intet behov for samtykke

obligatorisk

Driver1Identification

ISO 16844-7

Førerkort

personlig

Ikke relevant

førerens samtykke

obligatorisk

Driver2Identification

ISO 16844-7

Førerkort

Ikke relevant

personlig

medchaufførens samtykke

obligatorisk

NextCalibrationDate

Tillæg 8

Køretøjsenhed

ikke personlig

ikke personlig

intet behov for samtykke

obligatorisk

Driver1ContinuousDrivingTime

ISO 16844-7

Køretøjsenhed

personlig

Ikke relevant

førerens samtykke

obligatorisk

Driver2ContinuousDrivingTime

ISO 16844-7

Køretøjsenhed

Ikke relevant

personlig

medchaufførens samtykke

obligatorisk

Driver1CumulativeBreakTime

ISO 16844-7

Køretøjsenhed

personlig

Ikke relevant

førerens samtykke

obligatorisk

Driver2CumulativeBreakTime

ISO 16844-7

Køretøjsenhed

Ikke relevant

personlig

medchaufførens samtykke

obligatorisk

Driver1CurrentDurationOfSelectedActivity

ISO 16844-7

Køretøjsenhed

personlig

Ikke relevant

førerens samtykke

obligatorisk

Driver2CurrentDurationOfSelectedActivity

ISO 16844-7

Køretøjsenhed

Ikke relevant

personlig

medchaufførens samtykke

obligatorisk

SpeedAuthorised

Tillæg 8

Køretøjsenhed

ikke personlig

ikke personlig

intet behov for samtykke

obligatorisk

TachographCardSlot1

ISO 16844-7

Køretøjsenhed

ikke personlig

Ikke relevant

intet behov for samtykke

obligatorisk

TachographCardSlot2

ISO 16844-7

Køretøjsenhed

Ikke relevant

ikke personlig

intet behov for samtykke

obligatorisk

Driver1Name

ISO 16844-7

Førerkort

personlig

Ikke relevant

førerens samtykke

obligatorisk

Driver2Name

ISO 16844-7

Førerkort

Ikke relevant

personlig

medchaufførens samtykke

obligatorisk

OutOfScopeCondition

ISO 16844-7

Køretøjsenhed

ikke personlig

ikke personlig

intet behov for samtykke

obligatorisk

ModeOfOperation

ISO 16844-7

Køretøjsenhed

ikke personlig

ikke personlig

intet behov for samtykke

obligatorisk

Driver1CumulatedDrivingTimePreviousAndCurrentWeek

ISO 16844-7

Køretøjsenhed

personlig

Ikke relevant

førerens samtykke

obligatorisk

Driver2CumulatedDrivingTimePreviousAndCurrentWeek

ISO 16844-7

Køretøjsenhed

Ikke relevant

personlig

medchaufførens samtykke

obligatorisk

EngineSpeed

ISO 16844-7

Køretøjsenhed

personlig

Ikke relevant

førerens samtykke

valgfrit

RegisteringMemberState

Tillæg 8

Køretøjsenhed

ikke personlig

ikke personlig

intet behov for samtykke

obligatorisk

VehicleRegistrationNumber

Tillæg 8

Køretøjsenhed

ikke personlig

ikke personlig

intet behov for samtykke

obligatorisk

Driver1EndOfLastDailyRestPeriod

ISO 16844-7

Køretøjsenhed

personlig

Ikke relevant

førerens samtykke

valgfrit

Driver2EndOfLastDailyRestPeriod

ISO 16844-7

Køretøjsenhed

Ikke relevant

personlig

medchaufførens samtykke

valgfrit

Driver1EndOfLastWeeklyRestPeriod

ISO 16844-7

Køretøjsenhed

personlig

Ikke relevant

førerens samtykke

valgfrit

Driver2EndOfLastWeeklyRestPeriod

ISO 16844-7

Køretøjsenhed

Ikke relevant

personlig

medchaufførens samtykke

valgfrit

Driver1EndOfSecondLastWeeklyRestPeriod

ISO 16844-7

Køretøjsenhed

personlig

Ikke relevant

førerens samtykke

valgfrit

Driver2EndOfSecondLastWeeklyRestPeriod

ISO 16844-7

Køretøjsenhed

Ikke relevant

Personlige

medchaufførens samtykke

valgfrit

Driver1TimeLastLoadUnloadOperation

ISO 16844-7

Køretøjsenhed

personlig

Ikke relevant

førerens samtykke

valgfrit

Driver2TimeLastLoadUnloadOperation

ISO 16844-7

Køretøjsenhed

Ikke relevant

personlig

medchaufførens samtykke

valgfrit

Driver1CurrentDailyDrivingTime

ISO 16844-7

Køretøjsenhed

personlig

Ikke relevant

førerens samtykke

valgfrit

Driver2CurrentDailyDrivingTime

ISO 16844-7

Køretøjsenhed

Ikke relevant

personlig

medchaufførens samtykke

valgfrit

Driver1CurrentWeeklyDrivingTime

ISO 16844-7

Køretøjsenhed

personlig

Ikke relevant

førerens samtykke

valgfrit

Driver2CurrentWeeklyDrivingTime

ISO 16844-7

Køretøjsenhed

Ikke relevant

personlig

medchaufførens samtykke

valgfrit

Driver1TimeLeftUntilNewDailyRestPeriod

ISO 16844-7

Køretøjsenhed

personlig

Ikke relevant

førerens samtykke

valgfrit

Driver2TimeLeftUntilNewDailyRestPeriod

ISO 16844-7

Køretøjsenhed

Ikke relevant

personlig

medchaufførens samtykke

valgfrit

Driver1CardExpiryDate

ISO 16844-7

Førerkort

personlig

Ikke relevant

førerens samtykke

valgfrit

Driver2CardExpiryDate

ISO 16844-7

Førerkort

Ikke relevant

personlig

medchaufførens samtykke

valgfrit

Driver1CardNextMandatoryDownloadDate

ISO 16844-7

Køretøjsenhed

personlig

Ikke relevant

førerens samtykke

valgfrit

Driver2CardNextMandatoryDownloadDate

ISO 16844-7

Køretøjsenhed

Ikke relevant

personlig

medchaufførens samtykke

valgfrit

TachographNextMandatoryDownloadDate

ISO 16844-7

Køretøjsenhed

ikke personlig

ikke personlig

intet behov for samtykke

valgfrit

Driver1TimeLeftUntilNewWeeklyRestPeriod

ISO 16844-7

Køretøjsenhed

personlig

Ikke relevant

førerens samtykke

valgfrit

Driver2TimeLeftUntilNewWeeklyRestPeriod

ISO 16844-7

Køretøjsenhed

Ikke relevant

personlig

medchaufførens samtykke

valgfrit

Driver1NumberOfTimes9hDailyDrivingTimesExceeded

ISO 16844-7

Køretøjsenhed

personlig

Ikke relevant

førerens samtykke

valgfrit

Driver2NumberOfTimes9hDailyDrivingTimesExceeded

ISO 16844-7

Køretøjsenhed

Ikke relevant

personlig

medchaufførens samtykke

valgfrit

Driver1CumulativeUninterruptedRestTime

ISO 16844-7

Køretøjsenhed

personlig

Ikke relevant

førerens samtykke

valgfrit

Driver2CumulativeUninterruptedRestTime

ISO 16844-7

Køretøjsenhed

Ikke relevant

personlig

medchaufførens samtykke

valgfrit

Driver1MinimumDailyRest

ISO 16844-7

Køretøjsenhed

personlig

Ikke relevant

førerens samtykke

valgfrit

Driver2MinimumDailyRest

ISO 16844-7

Køretøjsenhed

Ikke relevant

personlig

medchaufførens samtykke

valgfrit

Driver1MinimumWeeklyRest

ISO 16844-7

Køretøjsenhed

personlig

Ikke relevant

førerens samtykke

valgfrit

Driver2MinimumWeeklyRest

ISO 16844-7

Køretøjsenhed

Ikke relevant

personlig

medchaufførens samtykke

valgfrit

Driver1MaximumDailyPeriod

ISO 16844-7

Køretøjsenhed

personlig

Ikke relevant

førerens samtykke

valgfrit

Driver2MaximumDailyPeriod

ISO 16844-7

Køretøjsenhed

Ikke relevant

personlig

medchaufførens samtykke

valgfrit

Driver1MaximumDailyDrivingTime

ISO 16844-7

Køretøjsenhed

personlig

Ikke relevant

førerens samtykke

valgfrit

Driver2MaximumDailyDrivingTime

ISO 16844-7

Køretøjsenhed

Ikke relevant

personlig

medchaufførens samtykke

valgfrit

Driver1NumberOfUsedReducedDailyRestPeriods

ISO 16844-7

Køretøjsenhed

personlig

Ikke relevant

førerens samtykke

valgfrit

Driver2NumberOfUsedReducedDailyRestPeriods

ISO 16844-7

Køretøjsenhed

Ikke relevant

personlig

medchaufførens samtykke

valgfrit

Driver1RemainingCurrentDrivingTime

ISO 16844-7

Køretøjsenhed

personlig

Ikke relevant

førerens samtykke

valgfrit

Driver2RemainingCurrentDrivingTime

ISO 16844-7

Køretøjsenhed

Ikke relevant

personlig

medchaufførens samtykke

valgfrit

VehiclePosition

Tillæg 8

Køretøjsenhed

personlig

personlig

førerens og medchaufførens samtykke

obligatorisk

ByDefaultLoadType

Tillæg 8

Køretøjsenhed

personlig

personlig

førerens og medchaufførens samtykke

obligatorisk

".

(39)

I tillæg 14 foretages følgende ændringer:

(a)

I indholdsfortegnelsen indsættes følgende punkt efter punkt 5.4.8:

"5.5

Forbeholdt fremtidig brug".

(b)

I punkt 4.1.1.5 affattes krav DCS_17 således:

"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 sikkerhedsmekanismer, 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."

(c)

I punkt 5 foretages følgende ændringer:

i)

I punkt 5.4.4 affattes sekvensen TachographPayload i moduldefinitionen ASN.1 for DSRC-dataene i RTM-applikationen således:

"

Image 109

".

ii)

I punkt 5.4.5 affattes tabel 14.3 således:

"

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 tp15638VehicleRegistrationPlate RTM1 ud fra den værdi, der er registreret for datatypen

VehicleRegistrationIdentification som fastlagt i tillæg 1 VehicleRegistrationIdentification

Køretøjets nummerplade udtrykt som en streng af tegn

tp15638VehicleRegistrationPlate LPN,

--Køretøjets nummerplade ud fra datastrukturen i ISO 14906, men med følgende begrænsning 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 tp15638SpeedingEvent på grundlag af det antal hændelser med overskridelse af tilladt hastighed, der er registreret i køretøjsenheden 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,

RTM3

Kørsel uden

gyldigt kort

Køretøjsenheden genererer en boolsk

værdi for dataelementet RTM3

tp15638DrivingWithoutValidCard.

Køretøjsenheden tildeler værdien TRUE til variablen tp15638DrivingWithoutValidCard, hvis mindst én hændelse med kørsel uden behørigt kort 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ørsel uden behørigt kort sluttede inden for de sidste ti dage eller stadig er i gang

0 (FALSE): i alle andre tilfælde.

tp15638DrivingWithoutValidCard

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øretøjsenheden

0 (FALSE): hvis der er et gyldigt førerkort i førerkortpladsen i køretø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øjsenheden 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,

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 tp15638VehicleMotionConflict, hvis mindst én hændelse med køretøjsbevægelseskonflikt 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ægelseskonflikt 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øretø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øjsenheden værdien af RTM9 til TRUE.

1 (TRUE): anden aktivitet

valgt

0 (FALSE): kørsel valgt

tp15638CurrentActivityDriving

BOOLEAN

RTM10

Seneste session afsluttet

Køretøjsenheden genererer en boolsk værdi for dataelementet 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

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 tp15638PowerSupplyInterruption svarende til det antal registrerede hændelser med afbrydelse af strømforsyning, der er lagret i køretøjsenheden 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øjsenheden inden for de sidste ti dage, indstilles værdien for RTM11 til 0.

Antal registrerede hændelser med afbrydelse af strømforsyning inden for de sidste ti dage.

tp15638PowerSupplyInterruption

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-kommunikationsfejl 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-kommunikationsfejl blev afsluttet inden for de sidste 10 dage eller er stadig i gang.

6, hvis både GNSS-modtagerfejl og ekstern GNSS-kommunikationsfejl 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.

--følerfejl en oktet i henhold til dataordlisten

tp15638SensorFault INTEGER (0..255),

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 tidsværdi, hvor den seneste hændelse med tidsjusteringsdata 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),

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 defineret 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 kalibreringsposten 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 kalibreringspostens 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 kalibrering af køretøjsenheden i det aktuelle køretøj.

Køretøjsenheden henter disse data fra VuCalibrationData (tillæg 1) fra vuCalibrationRecords med CalibrationPurpose 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 kalibrering af køretøjsenheden i det aktuelle køretøj.

tp15638DateTachoConnected

INTEGER(0..4294967295),

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 aktuelle 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 tidspunktet for den seneste ajourføring af RtmData.

Tidsstempel for aktuel

TachographPayload-post

tp15638Timestamp

INTEGER(0..4294967295),

RTM20

Tidspunkt, hvor den senest ægthedsbekræftede 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øjsposition 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æftede køretøjsposition

tp15638LatestAuthenticatedPosition

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ørerens sammenhængende køretid.

Førerens sammenhængende 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.

tp15638ContinuousDrivingTime INTEGER(0..255),

RTM22

Længste daglige køretid for igangværende og tidligere RTM-skift beregnet i overensstemmelse med addendummet 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 igangværende eller det tidligere RTM-skift.

Førerens daglige køretid kodet som en heltalsvæ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 overensstemmelse med addendummet til tillæg 14

Køretøjsenheden genererer en heltalsværdi for dataelementet RTM23.

Køretøjsenheden indstiller værdien for RTM23 til førerens 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 heltalsvæ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.

tp15638DailyDrivingTimeWeek INTEGER(0..255),

RTM24

Ugentlig køretid beregnet i overensstemmelse med addendummet til tillæg 14

Køretøjsenheden genererer en heltalsværdi for dataelementet RTM24.

Køretøjsenheden indstiller værdien for RTM24 til førerens 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),

RTM25

Køretid over to uger beregnet i overensstemmelse med addendummet til tillæg 14

Køretøjsenheden genererer en heltalsværdi for dataelementet RTM25.

Køretøjsenheden indstiller værdien for RTM25 til førerens 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.

tp15638FortnightlyDrivingTime INTEGER(0..255),

Bemærk: RTM22, RTM23, RTM24 og RTM25 beregnes i overensstemmelse med addendummet til dette tillæg"

iii)

I punkt 5.4.7 affattes tabel 14.9 således:

"Tabel 14.9

Initialisering — Eksempel på VST-rammeindhold

Oktet nr.

Attribut/Felt

Bit i oktet

Beskrivelse

1

MARKØR

0111 1110

Startmarkør

2

Privat LID

xxxx xxxx

Linkadresse på den specifikke 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. Eksempelprofil 0

Ingen udvidelse, 1 applikation

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 applikationsforekomsten.

14

Parameter Container {

0000 0010

Ingen udvidelse, Containervalg = 02,

Oktetstreng

15

 

0000 0110

Ingen udvidelse, længde af RTM-kontekstmarkering = 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-/hardwareversionen for DSRC-interfacet

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

".

iv)

Følgende indsættes som punkt 5.5:

"5.5

Forbeholdt fremtidig brug".

v)

I punkt 5.7 affattes krav DSC_77 og DSC_78 således:

"DSC_77

Dataene skal leveres af VUSM-funktionen til DSRC-køretøjsenheden 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øjsenheden til DSRC-køretøjsenhedens hukommelse skal registreres 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."

(d)

Følgende addendum tilføjes:

"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øretiden 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øretøjsenheden.

Køretiderne beregnes ikke, når der ikke er isat et førerkort (eller værkstedskort).

UKENDTE perioder i den periode, der skal bruges til beregningerne, sidestilles 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 GYLDIGHEDSOMRÅ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 afslutningen 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ØRSELsaktiviteter i en periode, som ikke er UDEN FOR GYLDIGHEDSOMRÅ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

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 regulære daglige hviletid undtagelsesvis afbrydes højst to gange af andre aktiviteter 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 afbrydelser, 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.

Image 110

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 akkumuleret 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

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 akkumulerede 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.

Image 111

Når en opdelt daglig hviletid er blevet afbrudt, skal køretøjsenheden:

ikke medregne den kørselsaktivitet, der er udført under disse afbrydelser, 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 betingelser er opfyldt:

afbrydelsen bevirker, at den samlede varighed af de 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 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ængende hviletid umiddelbart forud for afbrydelsen til den akkumulerede hviletid.

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 OVERFART 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øjsenheden 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øretø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 afbrydelsen 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.

Image 112

Image 113

Image 114

Image 115

Image 116

Image 117

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.

"

(40)

I tillæg 15 foretages følgende ændringer:

(a)

Overskriften affattes således:

"Tillæg 15

MIGRATION: FORVALTNING AF SAMEKSISTENSEN AF UDSTYRSGENERATIONER OG -VERSIONER

"

(b)

I indholdsfortegnelsen foretages følgende ændringer:

i)

Punkt 2.2 affattes således:

"2.2.

Interoperabilitet mellem køretøjsenhed og kort"

ii)

Følgende tilføjes som punkt 5:

"5.

REGISTRERING AF GRÆNSEPASSAGER I TAKOGRAFER AF FØRSTE GENERATION OG TAKOGRAFER AF FØRSTE VERSION AF ANDEN GENERATION"

(c)

Punkt 2-4 affattes således:

"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.

Ud over bestemmelserne i denne indledning fremhæves følgende oplysninger:

bevægelsesfølere af første generation er ikke interoperable med køretø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 generationer 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øjsenheder 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øjsenheder, 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øjsenheder 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.

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 generationer 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 sikkerhedsmekanismerne 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ærkstedskort) 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 dedikerede fil Tachograph), som overførselsprotokollen for kort af første generation forespørger. Disse oplysninger skal sikres med en digital underskrift i henhold til sikkerhedsmekanismerne 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 generation (applikationsdatas elementærfiler inden for den dedikerede 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 generation, og de overførte data skal overholde formatet, der er defineret for kort af første generation.

2.4.3

Overførsel fra køretøjsenhed

MIG_014

Uden for rammerne af førerkontrol udført af kontrolmyndigheder 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 generation. 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ældende generations eller versions kalibreringsprotokol. Kalibreringsudstyr 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 fabrikanter 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 fabrikanterne anmoder herom, senest 15 måneder før indførelsesdatoen.

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ærkstedskort af anden generation senest en måned før indførelsesdatoen.

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.

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."

(d)

Følgende tilføjes som punkt 5:

"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 forordning (EU) nr. 165/2014 og krav 50 i bilag I B til forordning (EØF) nr. 3821/85."

(41)

I tillæg 16 affattes krav ADA_012 således:

"ADA_012

Adapterens indgangssignaltilkobling skal om nødvendigt kunne multiplicere eller dividere frekvensimpulserne fra de indkommende 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ærksted, som installerer adapteren."


(1)  Europa-Parlamentets og Rådets forordning (EU) 2018/858 af 30. maj 2018 om godkendelse 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).

(*1)  ITS Bluetooth®-forbindelsen tildeles takografkortet i køretøjsenhedens førerkortplads.

(*2)  Brugeren skal vælge det kort, som ITS Bluetooth®-forbindelsen skal tildeles (isat i førerkortpladsen eller i medchaufførens kortplads).


Top