Nutzen Sie Anführungszeichen für die Suche nach einem Begriff „mit exakter Übereinstimmung“. Hängen Sie ein Sternchen (*) für die Suche nach Varianten an (Umsetzung*, 32019R*). Verwenden Sie ein Fragezeichen (?) anstelle eines einzelnen Zeichens in Ihrem Suchbegriff, um Varianten zu finden („Fa?l“ findet „Fall“ und „Fell“).
Commission Implementing Regulation (EU) 2021/1228 of 16 July 2021 amending Implementing Regulation (EU) 2016/799 as regards the requirements for the construction, testing, installation, operation and repair of smart tachographs and their components (Text with EEA relevance)
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)
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
EUT L 273 af 30.7.2021, S. 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)
In Kraft: Dieser Rechtsakt wurde geändert. Aktuelle konsolidierte Fassung: 21/08/2023
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.
(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:
"
"
(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).
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).
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).
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).
timeStamp er den dato og det klokkeslæt, hvor lasttypen blev indlæst.
loadTypeEntered er den indlæste lasttype.
2.24c.
CardLoadUnloadOperations
Anden generation, version 2:
Oplysninger, der er gemt på et fører- eller værkstedskort, vedrørende køretøjets laste-/losseoperationer (bilag I C, krav 306h og 356h).
loadUnloadPointerNewestRecord er indekset for den senest opdaterede post om laste-/losseoperationer.
Tilordnet værdi: er tallet svarende til tælleren i posten om laste-/losseoperationer på kortet, begyndende med "0" for den første forekomst af posten om laste-/losseoperationer på kortet i strukturen.
cardLoadUnloadRecords er den mængde poster, der indeholder 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).
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).
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).
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).
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.
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).
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
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).
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).
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).
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).
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.
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.
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.
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.
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.
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.
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:
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).
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:
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).
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.
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:
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.
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).
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).
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).
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).
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.
"
(kk)
I punkt 2.205 affattes teksten om anden generation således:
"Anden generation:
Ud over dataelementerne for første generation anvendes følgende dataelementer:
vuGeneration angiver køretøjsenhedens generation.
vuAbility rummer oplysninger om, hvorvidt køretøjsenheden 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).
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).
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).
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.
"
(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).
lengthOfFollowingData er antallet af byte i posten.
noOfBorderCrossingRecords er det antal grænsepassageposter, der kan lagres på værkstedskortet.
noOfLoadUnloadRecords er det antal laste-/losseposter, der kan lagres på værkstedskortet.
noOfLoadTypeEntryRecords er det antal lasttypeposter, der kan lagres på værkstedskortet.
vuConfigurationLengthRange er antallet af byte i et takografkort, der er tilgængeligt til lagring af køretøjsenhedens konfigurationer.
2.234b.
WorkshopCardCalibrationAddData
Anden generation, version 2:
Oplysninger, der er gemt på et værkstedskort, vedrørende yderligere data (dvs. standardlasttypen), der er indlæst under en kalibrering (bilag I C, krav 356l).
calibrationPointerNewestRecord er indekset for den senest opdaterede post vedrørende kalibrering af yderligere data.
Tilordnet værdi er tallet svarende til tælleren i posten vedrørende 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).
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:
"
"
2)
Rækken svarende til LastCardDownload affattes således:
"
"
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.
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:
"
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.
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:
"
"
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.
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:
"
"
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.
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:
"
".
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
Uden for gyldighedsområde
Overfart med færge/tog
Lasteoperation
Losseoperation
Samtidig laste-/losseoperation
Lasttype: passagerer
Lasttype: gods
Lasttype: udefineret lasttype"
ii)
Piktogrammerne for diverse ændres som følger:
1)
Sikkerhedspiktogrammet ændres således:
"
Sikkerhed/bekræftede data/plomber"
2)
Følgende piktogram tilføjes:
"
Digitalt kort/grænsepassage"
(b)
I punkt 2 foretages følgende ændringer:
i)
Følgende piktogramkombinationer føjes til piktogrammerne for diverse:
"
Position, hvor køretøjet har passeret grænsen mellem to lande
Position, hvor en lasteoperation har fundet sted
Position, hvor en losseoperation har fundet sted
Position, hvor en samtidig laste-/losseoperation har fundet sted"
ii)
Følgende piktogramkombination føjes til piktogrammerne for udskrifter:
"
Udskrift af historik for isatte kort"
iii)
Følgende piktogramkombination føjes til piktogrammerne for hændelser:
"
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, 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:
"
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:
"
".
v)
Datagruppe 5 affattes således:
"
".
vi)
Før datagruppe 6 slettes den sætning, der indledes med en asterisk.
vii)
Følgende datagruppe indsættes efter datagruppe 8a:
"
".
viii)
Datagruppe 8.2 affattes således:
"
".
ix)
Datagruppe 10.2 affattes således:
"
".
x)
Før datagruppe 11 slettes den sætning, der indledes med en asterisk.
xi)
Datagruppe 11.4 og 11.5 affattes således:
"
".
xii)
Datagruppe 14 affattes således:
"
".
xiii)
Datagruppe 15.1 affattes således:
"
".
xiv)
Datagruppe 16 og 16,1 affattes således:
"
16
GNSS-identifikation*
".
xv)
Datagruppe 17.1 affattes således:
"
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:
"
:";
(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:
";
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:
";
iii)
I punkt 3.5 affattes krav PRT_012 således:
"PRT_012
Udskrift af tekniske data skal overholde følgende format:
";
iv)
I punkt 3.7 affattes krav PRT_014 således:
"PRT_014
Udskriften af historikken over isatte kort skal overholde følgende format:
".
(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:
"
Figur 2 Håndtering af fejl ved køretøjsenhed
".
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
".
(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.
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
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)
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.
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):
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):
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).
Figur 4 GSA-sætningens struktur (standardpositioner)
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.
Figur 5 ASA-sætningens struktur (ægthedsbekræftede positioner)
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.
Figur 7 Overensstemmende ægthedsbekræftede positioner og ikke-ægthedsbekræftede standardpositioner
GNS_40
Når værdien af status i en modtaget AMC-sætning er sat til "J" eller "O" eller "F" i overensstemmelse med krav GNS_4a, skal køretøjsenheden generere og registrere en GNSS-anomali som defineret i krav 88a i bilag I C og tillæg 1 (EventFaultType). Køretøjsenheden kan foretage yderligere kontrol, inden den lagrer en GNSS-anomali efter modtagelse af en "J"- eller "O"-værdi.
7.
GNSS-TIDSKONFLIKT
GNS_41
Hvis køretøjsenheden registrerer en forskel mellem tiden i køretøjsenhedens tidsmålingsfunktion og tidsangivelsen fra GNSS-signalerne, genererer og registrerer den en 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 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.
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
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:
"
".
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.
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.
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.
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).