# Den Europæiske Unions L 85/2018

| | ISSN 1977-0634 |
| --- | --- |
| Den Europæiske Unions
  Tidende | L 85 |
| | |
| Dansk udgave | Retsforskrifter | 61. årgang28. marts 2018 |

ISSN 1977-0634

Den Europæiske Unions

Tidende

L 85

Dansk udgave

Retsforskrifter

61. årgang28. marts 2018

---

| Indhold | | II   Ikke-lovgivningsmæssige retsakter | Side |
| --- | --- | --- | --- |
| | | FORORDNINGER |
| | * | Kommissionens gennemførelsesforordning (EU) 2018/502 af 28. februar 2018 om ændring af gennemførelsesforordning (EU) 2016/799 om fastsættelse af forskrifter for konstruktion, afprøvning, installering, brug og reparation af takografer og deres komponenter (
  1
  ) | 1 |

Indhold

II   Ikke-lovgivningsmæssige retsakter

Side

FORORDNINGER

*

Kommissionens gennemførelsesforordning (EU) 2018/502 af 28. februar 2018 om ændring af gennemførelsesforordning (EU) 2016/799 om fastsættelse af forskrifter for konstruktion, afprøvning, installering, brug og reparation af takografer og deres komponenter (
  1
  )

1

1

| | |
| --- | --- |
| | (1)   EØS-relevant tekst |

---

(1)   EØS-relevant tekst

1

| DA | De akter, hvis titel er trykt med magre typer, er løbende retsakter inden for rammerne af landbrugspolitikken og har normalt en begrænset gyldighedsperiode.
  Titlen på alle øvrige akter er trykt med fede typer efter en asterisk. |
| --- | --- |

DA

De akter, hvis titel er trykt med magre typer, er løbende retsakter inden for rammerne af landbrugspolitikken og har normalt en begrænset gyldighedsperiode.

Titlen på alle øvrige akter er trykt med fede typer efter en asterisk.

---

II Ikke-lovgivningsmæssige retsakter

FORORDNINGER

| 28.3.2018 | DA | Den Europæiske Unions Tidende | L 85/1 |
| --- | --- | --- | --- |

28.3.2018

DA

Den Europæiske Unions Tidende

L 85/1

---

KOMMISSIONENS GENNEMFØRELSESFORORDNING (EU) 2018/502

af 28. februar 2018

om ændring af gennemførelsesforordning (EU) 2016/799 om fastsættelse af forskrifter for konstruktion, afprøvning, installering, brug og reparation af 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 artikel 12, stk. 7, og

ud fra følgende betragtninger:

| (1) | Ved forordning (EU) nr. 165/2014 indførtes digitale takografer af anden generation, kaldet intelligente takografer, som omfatter en forbindelse til det globale satellitnavigationssystem (»GNSS«), kommunikationsudstyr til tidlig fjernafsløring og en fakultativ grænseflade til intelligente transportsystemer. |
| --- | --- |

(1)

Ved forordning (EU) nr. 165/2014 indførtes digitale takografer af anden generation, kaldet intelligente takografer, som omfatter en forbindelse til det globale satellitnavigationssystem (»GNSS«), kommunikationsudstyr til tidlig fjernafsløring og en fakultativ grænseflade til intelligente transportsystemer.

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

(2)

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

| (3) | Ifølge artikel 8, 9 og 10 i forordning (EU) nr. 165/2014 skal takografer, som installeres i køretøjer, der registreres første gang den 15. juni 2019 eller derefter, være intelligente takografer. Gennemførelsesforordning (EU) 2016/799 bør derfor ændres, så de tekniske forskrifter indeholdt deri anvendes fra denne dato. |
| --- | --- |

(3)

Ifølge artikel 8, 9 og 10 i forordning (EU) nr. 165/2014 skal takografer, som installeres i køretøjer, der registreres første gang den 15. juni 2019 eller derefter, være intelligente takografer. Gennemførelsesforordning (EU) 2016/799 bør derfor ændres, så de tekniske forskrifter indeholdt deri anvendes fra denne dato.

| (4) | For at kunne overholde artikel 8 i forordning (EU) nr. 165/2014, som fastlægger, at køretøjets position skal registreres hver tredje times kumulerede køretid, bør gennemførelsesforordning (EU) 2016/799 ændres, så det bliver muligt at lagre oplysninger om køretøjets position hver tredje time under anvendelse af en måleparameter, som ikke kan nulstilles, og for at undgå forveksling med »sammenhængende køretid«, som er en måleparameter med en anden funktion. |
| --- | --- |

(4)

For at kunne overholde artikel 8 i forordning (EU) nr. 165/2014, som fastlægger, at køretøjets position skal registreres hver tredje times kumulerede køretid, bør gennemførelsesforordning (EU) 2016/799 ændres, så det bliver muligt at lagre oplysninger om køretøjets position hver tredje time under anvendelse af en måleparameter, som ikke kan nulstilles, og for at undgå forveksling med »sammenhængende køretid«, som er en måleparameter med en anden funktion.

| (5) | Køretøjsenheden kan enten være en enkelt enhed eller flere enheder, som er fordelt i køretøjet. Udstyret til GNSS og Dedicated Short Range Communication (»DSRC«) kan derfor være internt eller eksternt i forhold til køretøjsenhedens hoveddel. Hvis udstyret er eksternt, bør det være muligt, at begge udstyrsdele og køretøjsenhedens hoveddel kan typegodkendes som komponenter med henblik på at tilpasse processen til typegodkendelse af intelligente takografer til markedets behov. |
| --- | --- |

(5)

Køretøjsenheden kan enten være en enkelt enhed eller flere enheder, som er fordelt i køretøjet. Udstyret til GNSS og Dedicated Short Range Communication (»DSRC«) kan derfor være internt eller eksternt i forhold til køretøjsenhedens hoveddel. Hvis udstyret er eksternt, bør det være muligt, at begge udstyrsdele og køretøjsenhedens hoveddel kan typegodkendes som komponenter med henblik på at tilpasse processen til typegodkendelse af intelligente takografer til markedets behov.

| (6) | Reglerne om lagring af tidskonflikthændelser og tidsjusteringer må ændres for at skelne mellem automatiske tidsjusteringer, som udløses efter en eventuel manipulation eller svigt af takografen, og de tidsjusteringer, der skyldes andre årsager såsom vedligeholdelse. |
| --- | --- |

(6)

Reglerne om lagring af tidskonflikthændelser og tidsjusteringer må ændres for at skelne mellem automatiske tidsjusteringer, som udløses efter en eventuel manipulation eller svigt af takografen, og de tidsjusteringer, der skyldes andre årsager såsom vedligeholdelse.

| (7) | Dataidentifikatorerne bør være i stand til at skelne mellem data, der overføres fra en intelligent takograf, og data, der overføres fra en takograf af en tidligere generation. |
| --- | --- |

(7)

Dataidentifikatorerne bør være i stand til at skelne mellem data, der overføres fra en intelligent takograf, og data, der overføres fra en takograf af en tidligere generation.

| (8) | Gyldighedsperioden for virksomhedskortet bør forlænges fra to til fem år for at bringe den i overensstemmelse med gyldighedsperioden for førerkortet. |
| --- | --- |

(8)

Gyldighedsperioden for virksomhedskortet bør forlænges fra to til fem år for at bringe den i overensstemmelse med gyldighedsperioden for førerkortet.

| (9) | Beskrivelsen af visse fejl og hændelser, valideringen af registreringerne af de steder, hvor den daglige arbejdsperiode begynder og/eller slutter, brugen af førers samtykke til intelligente transportsystemer (ITS-grænseflade) for så vidt angår data, der sendes af køretøjsenheden via køretøjets net, og andre tekniske spørgsmål bør defineres bedre. |
| --- | --- |

(9)

Beskrivelsen af visse fejl og hændelser, valideringen af registreringerne af de steder, hvor den daglige arbejdsperiode begynder og/eller slutter, brugen af førers samtykke til intelligente transportsystemer (ITS-grænseflade) for så vidt angår data, der sendes af køretøjsenheden via køretøjets net, og andre tekniske spørgsmål bør defineres bedre.

| (10) | For at sikre, at certificeringen af takografplomberinger er på den seneste stand, bør de tilpasses til den nye sikkerhedsstandard for mekaniske plomberinger til takografer. |
| --- | --- |

(10)

For at sikre, at certificeringen af takografplomberinger er på den seneste stand, bør de tilpasses til den nye sikkerhedsstandard for mekaniske plomberinger til takografer.

| (11) | Denne forordning vedrører konstruktion, afprøvning, installering og brug af systemer, som også består af radioudstyr, der er reguleret ved Europa-Parlamentets og Rådets direktiv 2014/53/EU (3). Direktivet regulerer tilgængeliggørelse på markedet og ibrugtagning af elektronisk og elektrisk udstyr, der anvender radiobølger til kommunikation og/eller radiostedbestemmelse på horisontalt plan, navnlig for så vidt angår elektrisk sikkerhed, kompatibilitet med andre systemer, adgang til frekvensressourcer, adgang til nødtjenester og/eller eventuelle supplerende delegerede bestemmelser. For at garantere en effektiv udnyttelse af frekvensressourcer, undgå skadelig radiointerferens, tage hensyn til sikkerheden og den elektromagnetiske kompatibilitet af radioudstyret samt for at imødekomme eventuelle andre specifikke delegerede krav bør denne forordning ikke være til hinder for nævnte direktiv. |
| --- | --- |

(11)

Denne forordning vedrører konstruktion, afprøvning, installering og brug af systemer, som også består af radioudstyr, der er reguleret ved Europa-Parlamentets og Rådets direktiv 2014/53/EU (3). Direktivet regulerer tilgængeliggørelse på markedet og ibrugtagning af elektronisk og elektrisk udstyr, der anvender radiobølger til kommunikation og/eller radiostedbestemmelse på horisontalt plan, navnlig for så vidt angår elektrisk sikkerhed, kompatibilitet med andre systemer, adgang til frekvensressourcer, adgang til nødtjenester og/eller eventuelle supplerende delegerede bestemmelser. For at garantere en effektiv udnyttelse af frekvensressourcer, undgå skadelig radiointerferens, tage hensyn til sikkerheden og den elektromagnetiske kompatibilitet af radioudstyret samt for at imødekomme eventuelle andre specifikke delegerede krav bør denne forordning ikke være til hinder for nævnte direktiv.

| (12) | Gennemførelsesforordning (EU) 2016/799 bør derfor ændres. |
| --- | --- |

(12)

Gennemførelsesforordning (EU) 2016/799 bør derfor ændres.

| (13) | Foranstaltningerne i denne forordning er i overensstemmelse med udtalelsen fra det udvalg, der er nævnt i artikel 42, stk. 3, i forordning (EU) nr. 165/2014 — |
| --- | --- |

(13)

Foranstaltningerne i denne forordning er i overensstemmelse med udtalelsen fra det udvalg, der er nævnt i artikel 42, stk. 3, i forordning (EU) nr. 165/2014 —

VEDTAGET DENNE FORORDNING:

Artikel 1

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

| 1) | I artikel 1 foretages følgende ændringer:


  a) | Stk. 2 og 3 affattes således:

  »2.   Konstruktion, afprøvning, installering, eftersyn, brug og reparation af intelligente takografer og deres komponenter skal ske i henhold til de tekniske krav i bilag I C til denne forordning.


  3.   Andre takografer end intelligente takografer skal, for så vidt angår konstruktion, afprøvning, installering, eftersyn, brug og reparation, fortsat overholde kravene i enten bilag I til forordning (EU) nr. 165/2014 eller bilag I B til Rådets forordning (EØF) nr. 3821/85 (*1), alt efter hvad der er relevant.


  (*1)  Rådets forordning (EØF) nr. 3821/85 af 20. december 1985 om kontrolapparatet inden for vejtransport (EFT L 370 af 31.12.1985, s. 8).«
  " |
| --- | --- | --- |

1)

I artikel 1 foretages følgende ændringer:

a)

Stk. 2 og 3 affattes således:

»2.   Konstruktion, afprøvning, installering, eftersyn, brug og reparation af intelligente takografer og deres komponenter skal ske i henhold til de tekniske krav i bilag I C til denne forordning.

3.   Andre takografer end intelligente takografer skal, for så vidt angår konstruktion, afprøvning, installering, eftersyn, brug og reparation, fortsat overholde kravene i enten bilag I til forordning (EU) nr. 165/2014 eller bilag I B til Rådets forordning (EØF) nr. 3821/85 (*1), alt efter hvad der er relevant.

(*1)  Rådets forordning (EØF) nr. 3821/85 af 20. december 1985 om kontrolapparatet inden for vejtransport (EFT L 370 af 31.12.1985, s. 8).«
  "

*1

| b) | Følgende indsættes som stk. 5:

  »5.   Denne forordning berører ikke Europa-Parlamentets og Rådets direktiv 2014/53/EU (*2).


  (*2)  Europa-Parlamentets og Rådets direktiv 2014/53/EU af 16. april 2014 om harmonisering af medlemsstaternes love om tilgængeliggørelse af radioudstyr på markedet og om ophævelse af direktiv 1999/5/EF (EUT L 153 af 22.5.2014, s. 62).«
  " |
| --- | --- |

b)

Følgende indsættes som stk. 5:

»5.   Denne forordning berører ikke Europa-Parlamentets og Rådets direktiv 2014/53/EU (*2).

(*2)  Europa-Parlamentets og Rådets direktiv 2014/53/EU af 16. april 2014 om harmonisering af medlemsstaternes love om tilgængeliggørelse af radioudstyr på markedet og om ophævelse af direktiv 1999/5/EF (EUT L 153 af 22.5.2014, s. 62).«
  "

*2

| 2) | I artikel 2 foretages følgende ændringer:


  a) | Definition 3) affattes således:


  »3) | »informationsmappe«: hele mappen, i elektronisk form eller papirform, der indeholder alle oplysninger, som fabrikanten eller dennes repræsentant har indgivet til typegodkendelsesmyndigheden med henblik på typegodkendelse af en takograf eller en komponent dertil, inklusive de i artikel 12, stk. 3, i forordning (EU) nr. 165/2014 nævnte certifikater, resultaterne af de prøvninger, der defineres i bilag I C til denne forordning samt tegninger, fotografier og andre relevante dokumenter«. |
| --- | --- | --- | --- |

2)

I artikel 2 foretages følgende ændringer:

a)

Definition 3) affattes således:

»3)

»informationsmappe«: hele mappen, i elektronisk form eller papirform, der indeholder alle oplysninger, som fabrikanten eller dennes repræsentant har indgivet til typegodkendelsesmyndigheden med henblik på typegodkendelse af en takograf eller en komponent dertil, inklusive de i artikel 12, stk. 3, i forordning (EU) nr. 165/2014 nævnte certifikater, resultaterne af de prøvninger, der defineres i bilag I C til denne forordning samt tegninger, fotografier og andre relevante dokumenter«.

| b) | Definition 7) affattes således:


  »7) | »intelligent takograf« eller »takograf af anden generation«: digital takograf, der er i overensstemmelse med artikel 8, 9 og 10 i forordning (EU) nr. 165/2014 samt med bilag I C til nærværende forordning«. |
| --- | --- | --- |

b)

Definition 7) affattes således:

»7)

»intelligent takograf« eller »takograf af anden generation«: digital takograf, der er i overensstemmelse med artikel 8, 9 og 10 i forordning (EU) nr. 165/2014 samt med bilag I C til nærværende forordning«.

| c) | Definition 8) affattes således:


  »8) | »takografkomponent« eller »komponent«: ethvert af følgende elementer: køretøjsenheden, bevægelsessensoren, diagramarket, det eksterne GNSS-udstyr og det eksterne udstyr til tidlig fjernafsløring«. |
| --- | --- | --- |

c)

Definition 8) affattes således:

»8)

»takografkomponent« eller »komponent«: ethvert af følgende elementer: køretøjsenheden, bevægelsessensoren, diagramarket, det eksterne GNSS-udstyr og det eksterne udstyr til tidlig fjernafsløring«.

| d) | Følgende definition 10) indsættes:


  »10) | »køretøjsenhed«: takograf bortset fra bevægelsessensoren og de kabler, hvormed bevægelsessensoren tilsluttes.
  Køretøjsenheden kan enten være en enkelt enhed eller flere enheder, som er fordelt i køretøjet, og omfatter bl.a. en processor, et datalager, en tidsmålefunktion, to intelligente kortlæserenheder til fører og medfører, en printer, en skærm, stik samt faciliteter til indlæsning af brugerens data, en GNSS-modtager og fjernkommunikationsudstyr.
  Køretøjsenheden kan være sammensat af følgende komponenter, der er underlagt typegodkendelse:


  — | en køretøjsenhed, som består af en enkelt komponent (med GNSS-modtager og fjernkommunikationsudstyr) |
| --- | --- | --- | --- |

d)

Følgende definition 10) indsættes:

»10)

»køretøjsenhed«: takograf bortset fra bevægelsessensoren og de kabler, hvormed bevægelsessensoren tilsluttes.

Køretøjsenheden kan enten være en enkelt enhed eller flere enheder, som er fordelt i køretøjet, og omfatter bl.a. en processor, et datalager, en tidsmålefunktion, to intelligente kortlæserenheder til fører og medfører, en printer, en skærm, stik samt faciliteter til indlæsning af brugerens data, en GNSS-modtager og fjernkommunikationsudstyr.

Køretøjsenheden kan være sammensat af følgende komponenter, der er underlagt typegodkendelse:

—

en køretøjsenhed, som består af en enkelt komponent (med GNSS-modtager og fjernkommunikationsudstyr)

| — | en køretøjsenhedshoveddel (med fjernkommunikationsudstyr) og eksternt GNSS-udstyr |
| --- | --- |

—

en køretøjsenhedshoveddel (med fjernkommunikationsudstyr) og eksternt GNSS-udstyr

| — | en køretøjsenhedshoveddel (med GNSS-modtager) og eksternt fjernkommunikationsudstyr |
| --- | --- |

—

en køretøjsenhedshoveddel (med GNSS-modtager) og eksternt fjernkommunikationsudstyr

| — | en køretøjsenhedshoveddel, eksternt GNSS-udstyr og eksternt fjernkommunikationsudstyr. |
| --- | --- |

—

en køretøjsenhedshoveddel, eksternt GNSS-udstyr og eksternt fjernkommunikationsudstyr.

Hvis køretøjsenheden består af flere enheder, som er fordelt i køretøjet, så er køretøjsenhedens hoveddel den enhed, der indeholder processoren, datalageret og tidsmålefunktionen.

»køretøjsenhed (VU)« anvendes for »køretøjsenhed« eller »køretøjsenhedshoveddel«
  «.

| 3) | Artikel 6, stk. 3, affattes således:
  »Bilag I C gælder dog fra den 15. juni 2019 med undtagelse af tillæg 16, der anvendes fra den 2. marts 2016.« |
| --- | --- |

3)

Artikel 6, stk. 3, affattes således:

»Bilag I C gælder dog fra den 15. juni 2019 med undtagelse af tillæg 16, der anvendes fra den 2. marts 2016.«

| 4) | Bilag I C ændres i overensstemmelse med bilag I til denne forordning. |
| --- | --- |

4)

Bilag I C ændres i overensstemmelse med bilag I til denne forordning.

| 5) | Bilag II ændres i overensstemmelse med bilag II til denne forordning. |
| --- | --- |

5)

Bilag II ændres i overensstemmelse med bilag II til denne forordning.

Artikel 2

Ikrafttræden

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

Den Europæiske Unions Tidende

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

Udfærdiget i Bruxelles, den 28. februar 2018.

På Kommissionens vegne

Jean-Claude JUNCKER

Formand

---

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

1

(2)  Kommissionens gennemførelsesforordning (EU) 2016/799 af 18. marts 2016 om gennemførelse af Europa-Parlamentets og Rådets forordning (EU) nr. 165/2014 om fastsættelse af forskrifter for konstruktion, afprøvning, installering, brug og reparation af takografer og deres komponenter (EUT L 139 af 26.5.2016, s. 1).

2

(3)  Europa-Parlamentets og Rådets direktiv 2014/53/EU af 16. april 2014 om harmonisering af medlemsstaternes love om tilgængeliggørelse af radioudstyr på markedet og om ophævelse af direktiv 1999/5/EF (EUT L 153 af 22.5.2014, s. 62).

3

---

BILAG I

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

| 1) | I indholdsfortegnelsen foretages følgende ændringer:


  a) | Afsnit 3.12.5 affattes således:
  »3.12.5.   Steder og positioner, hvor daglige arbejdsperioder påbegyndes, afsluttes og/eller hvor tre timers kumuleret køretid nås«. |
| --- | --- | --- |

1)

I indholdsfortegnelsen foretages følgende ændringer:

a)

Afsnit 3.12.5 affattes således:

»3.12.5.   Steder og positioner, hvor daglige arbejdsperioder påbegyndes, afsluttes og/eller hvor tre timers kumuleret køretid nås«.

| b) | Afsnit 4.5.3.2.16 affattes således:
  »4.5.3.2.16   Data vedrørende den position, hvor tre timers kumuleret køretid nås«. |
| --- | --- |

b)

Afsnit 4.5.3.2.16 affattes således:

»4.5.3.2.16   Data vedrørende den position, hvor tre timers kumuleret køretid nås«.

| c) | Afsnit 4.5.4.2.14 affattes således:
  »4.5.4.2.14   Data vedrørende den position, hvor tre timers kumuleret køretid nås«. |
| --- | --- |

c)

Afsnit 4.5.4.2.14 affattes således:

»4.5.4.2.14   Data vedrørende den position, hvor tre timers kumuleret køretid nås«.

| d) | Afsnit 6.2 affattes således:
  »6.2   Kontrol af nye eller reparerede komponenter«. |
| --- | --- |

d)

Afsnit 6.2 affattes således:

»6.2   Kontrol af nye eller reparerede komponenter«.

| 2) | I afsnit 1 foretages følgende ændringer:


  a) | Definition ll) affattes således:


  »ll) | »udstyr til fjernkommunikation« eller »udstyr til tidlig fjernafsløring«:
  det udstyr i køretøjsenheden, som anvendes til at udføre målrettede vejsidekontroller«. |
| --- | --- | --- | --- |

2)

I afsnit 1 foretages følgende ændringer:

a)

Definition ll) affattes således:

»ll)

»udstyr til fjernkommunikation« eller »udstyr til tidlig fjernafsløring«:

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

| b) | Definition tt) affattes således:


  »tt) | »tidsjustering«:
  en justering af aktuelt klokkeslæt; det kan være en automatisk justering med regelmæssige mellemrum, som anvender GNSS-modtagerens tid som reference, eller en justering foretaget ved kalibrering«. |
| --- | --- | --- |

b)

Definition tt) affattes således:

»tt)

»tidsjustering«:

en justering af aktuelt klokkeslæt; det kan være en automatisk justering med regelmæssige mellemrum, som anvender GNSS-modtagerens tid som reference, eller en justering foretaget ved kalibrering«.

| c) | Definition yy), første led, affattes således:


  »— | alene installeres og anvendes i køretøjer af typerne M1 og N1 (som defineret i bilag II til Europa-Parlamentets og Rådets direktiv 2007/46/EF (*), med senere ændringer)«. |
| --- | --- | --- |

c)

Definition yy), første led, affattes således:

»—

alene installeres og anvendes i køretøjer af typerne M1 og N1 (som defineret i bilag II til Europa-Parlamentets og Rådets direktiv 2007/46/EF (*), med senere ændringer)«.

| d) | Følgende indsættes som ny definition fff):


  »fff) | »kumuleret køretid«:
  en værdi, som repræsenterer det samlede kumulerede antal minutters kørsel med et bestemt køretøj.
  Værdien for kumuleret køretid er en fortløbende tælling af alle minutter, der anses for KØRSEL, gennem overvågning af kontrolapparatets funktionstilstand for kørsel og anvendes kun til at udløse registrering af køretøjets position, hver gang et multiplum af tre timers kumuleret køretid er nået. Kumuleringen starter, når kontrolapparatet aktiveres. Den påvirkes ikke af nogen anden aktivitet som f.eks. uden for gyldighedsområde eller færge/tog.
  Værdien for kumuleret køretid er ikke beregnet til at blive vist, printet eller overført.« |
| --- | --- | --- |

d)

Følgende indsættes som ny definition fff):

»fff)

»kumuleret køretid«:

en værdi, som repræsenterer det samlede kumulerede antal minutters kørsel med et bestemt køretøj.

Værdien for kumuleret køretid er en fortløbende tælling af alle minutter, der anses for KØRSEL, gennem overvågning af kontrolapparatets funktionstilstand for kørsel og anvendes kun til at udløse registrering af køretøjets position, hver gang et multiplum af tre timers kumuleret køretid er nået. Kumuleringen starter, når kontrolapparatet aktiveres. Den påvirkes ikke af nogen anden aktivitet som f.eks. uden for gyldighedsområde eller færge/tog.

Værdien for kumuleret køretid er ikke beregnet til at blive vist, printet eller overført.«

| 3) | Afsnit 2.3, krav 13), sidste led, affattes således:


  »— | Køretøjsenhederne har en gyldighedsperiode for normale operationer på 15 år fra og med den faktiske dato for køretøjsenhedens certifikater, men køretøjsenheder kan anvendes i yderligere tre måneder, dog kun til dataoverførsel.« |
| --- | --- | --- |

3)

Afsnit 2.3, krav 13), sidste led, affattes således:

»—

Køretøjsenhederne har en gyldighedsperiode for normale operationer på 15 år fra og med den faktiske dato for køretøjsenhedens certifikater, men køretøjsenheder kan anvendes i yderligere tre måneder, dog kun til dataoverførsel.«

| 4) | Afsnit 2.4, første afsnit, affattes således:

  »Med sikringen af systemet tilstræbes det at beskytte datahukommelsen på en sådan måde, at uvedkommende ikke kan få adgang til og manipulere med data, og således at forsøg herpå opdages, beskytte integriteten og ægtheden af data, som udveksles mellem bevægelsessensor og køretøjsenhed, beskytte integriteten og ægtheden af data, som udveksles mellem kontrolapparat og takografkort, beskytte integriteten og ægtheden af data, der udveksles mellem køretøjsenhed og eventuelt eksternt GNSS-udstyr, beskytte fortroligheden, integriteten og ægtheden af data, som udveksles gennem udstyret til fjernkommunikation med henblik på tidlig afsløring til kontrolformål, samt verificere integriteten og ægtheden af overførte data.« |
| --- | --- |

4)

Afsnit 2.4, første afsnit, affattes således:

»Med sikringen af systemet tilstræbes det at beskytte datahukommelsen på en sådan måde, at uvedkommende ikke kan få adgang til og manipulere med data, og således at forsøg herpå opdages, beskytte integriteten og ægtheden af data, som udveksles mellem bevægelsessensor og køretøjsenhed, beskytte integriteten og ægtheden af data, som udveksles mellem kontrolapparat og takografkort, beskytte integriteten og ægtheden af data, der udveksles mellem køretøjsenhed og eventuelt eksternt GNSS-udstyr, beskytte fortroligheden, integriteten og ægtheden af data, som udveksles gennem udstyret til fjernkommunikation med henblik på tidlig afsløring til kontrolformål, samt verificere integriteten og ægtheden af overførte data.«

| 5) | Afsnit 3.2, krav 27), andet led, affattes således:


  »— | positioner, hvor den kumulerede køretid når op på et multiplum af tre timer«. |
| --- | --- | --- |

5)

Afsnit 3.2, krav 27), andet led, affattes således:

»—

positioner, hvor den kumulerede køretid når op på et multiplum af tre timer«.

| 6) | Afsnit 3.4, krav 49), affattes således:


  »49) | Det første aktivitetsskift til PAUSE/HVILE eller RÅDIGHED, som finder sted inden for 120 sekunder efter det ved standsning af køretøjet udløste automatiske skift til ARBEJDE, antages at have fundet sted på tidspunktet for køretøjets standsning (således at skiftet til ARBEJDE eventuelt ophæves).« |
| --- | --- | --- |

6)

Afsnit 3.4, krav 49), affattes således:

»49)

| 7) | Afsnit 3.6.1, krav 59), affattes således:


  »59) | Føreren skal derefter indlæse køretøjets aktuelle placering, som anses for at være en midlertidig indlæsning.
  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) |
| --- | --- | --- | --- |

7)

Afsnit 3.6.1, krav 59), affattes således:

»59)

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 arbejdsperiode begynder, hvis kortindehaveren ikke indlæser et sted, hvor arbejdsperioden begynder eller sluttede, under den manuelle indlæsning i henhold til krav 61). |
| --- | --- |

—

den næste indlæsning af et sted, hvor den aktuelle daglige arbejdsperiode begynder, hvis kortindehaveren ikke indlæser et sted, hvor arbejdsperioden 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:

| — | den næste indlæsning af et sted, hvor den aktuelle daglige arbejdsperiode slutter, hvis kortindehaveren ikke indlæser et sted, hvor arbejdsperioden begynder eller sluttede, under den manuelle indlæsning i henhold til krav 61).« |
| --- | --- |

—

den næste indlæsning af et sted, hvor den aktuelle daglige arbejdsperiode slutter, hvis kortindehaveren ikke indlæser et sted, hvor arbejdsperioden begynder eller sluttede, under den manuelle indlæsning i henhold til krav 61).«

| 8) | Afsnit 3.6.2, sjette og syvende led, affattes således:


  »— | 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) |
| --- | --- | --- |

8)

Afsnit 3.6.2, sjette og syvende led, affattes således:

»—

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

—

et sted, hvor den aktuelle daglige arbejdsperiode begynder, og det tilknyttede tidspunkt (hvorved en midlertidig indlæsning, der skete ved den sidste kortudtagning, valideres)«.

| 9) | Afsnit 3.9.15 affattes således:
  »3.9.15   Hændelsen »tidskonflikt«


  86) | Denne hændelse skal udløses uden for kalibreringstilstand, hvis køretøjsenheden registrerer en forskel på mere end 1 minut mellem tiden i køretøjsenhedens tidsmålingsfunktion og tidsangivelsen fra GNSS-modtageren. Denne hændelse registreres sammen med værdien i køretøjsenhedens interne ur og ledsages af en automatisk tidsjustering. Hvis hændelsen »tidskonflikt« er blevet udløst, vil køretøjsenheden ikke generere andre tidskonflikthændelser inden for de næste 12 timer. Denne hændelse vil ikke blive udløst, hvis GNSS-modtageren ikke har detekteret noget gyldigt GNSS-signal de seneste 30 dage eller længere.« |
| --- | --- | --- |

9)

Afsnit 3.9.15 affattes således:

»3.9.15   Hændelsen »tidskonflikt«

86)

| 10) | I afsnit 3.9.17 indsættes følgende nye led:


  »— | ITS-grænsefladefejl (hvis relevant).« |
| --- | --- | --- |

10)

I afsnit 3.9.17 indsættes følgende nye led:

»—

ITS-grænsefladefejl (hvis relevant).«

| 11) | I afsnit 3.10 foretages følgende ændringer:


  i) | Teksten før tabellen i krav 89) affattes således:

  »Kontrolapparatet skal detektere fejl gennem selvtester og indbyggede tester i overensstemmelse med følgende tabel:«. |
| --- | --- | --- |

11)

I afsnit 3.10 foretages følgende ændringer:

i)

Teksten før tabellen i krav 89) affattes således:

»Kontrolapparatet skal detektere fejl gennem selvtester og indbyggede tester i overensstemmelse med følgende tabel:«.

| ii) | Følgende række tilføjes til tabellen:


  »ITS-grænseflade (hvis relevant) | Korrekt funktion« | |
| --- | --- | --- | --- |

ii)

Følgende række tilføjes til tabellen:

»ITS-grænseflade (hvis relevant)

Korrekt funktion«

| 12) | Afsnit 3.12, andet led, affattes således:


  »— | defineres det gennemsnitlige antal positioner pr. dag som mindst 6 positioner, hvor den daglige arbejdsperiode starter, 6 positioner, hvor den kumulerede køretid når op på et multiplum af tre timer, og 6 positioner, hvor den daglige arbejdsperiode slutter, så »365 dage« omfatter mindst 6570 positioner«. |
| --- | --- | --- |

12)

Afsnit 3.12, andet led, affattes således:

»—

defineres det gennemsnitlige antal positioner pr. dag som mindst 6 positioner, hvor den daglige arbejdsperiode starter, 6 positioner, hvor den kumulerede køretid når op på et multiplum af tre timer, og 6 positioner, hvor den daglige arbejdsperiode slutter, så »365 dage« omfatter mindst 6570 positioner«.

| 13) | I afsnit 3.12.5 foretages følgende ændringer:


  a) | Titlen og krav 108) affattes således:
  »3.12.5.   Steder og positioner, hvor daglige arbejdsperioder starter, slutter og/eller hvor tre timers kumuleret køretid nås


  108) | Kontrolapparatet skal registrere og i sit datalager gemme:


  — | steder og positioner, hvor føreren og/eller medchaufføren påbegynder sin daglige arbejdsperiode |
| --- | --- | --- | --- | --- |

13)

I afsnit 3.12.5 foretages følgende ændringer:

a)

Titlen og krav 108) affattes således:

»3.12.5.   Steder og positioner, hvor daglige arbejdsperioder starter, slutter og/eller hvor tre timers kumuleret køretid nås

108)

—

steder og 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 den kumulerede køretid når op på et multiplum af tre timer

| — | steder og positioner, hvor føreren og/eller medchaufføren slutter sin daglige arbejdsperiode.« |
| --- | --- |

—

steder og positioner, hvor føreren og/eller medchaufføren slutter sin daglige arbejdsperiode.«

| b) | Krav 110), fjerde led, affattes således:


  »— | indlæsningens art (begyndelse, slutning eller tre timers kumuleret køretid)«. |
| --- | --- | --- |

b)

Krav 110), fjerde led, affattes således:

»—

indlæsningens art (begyndelse, slutning eller tre timers kumuleret køretid)«.

| c) | Krav 111) affattes således:


  »111) | Datalageret skal kunne rumme steder og positioner, hvor daglige arbejdsperioder starter og slutter, og/eller hvor tre timers kumuleret køretid nås, for mindst 365 dage.« |
| --- | --- | --- |

c)

Krav 111) affattes således:

»111)

| 14) | Afsnit 3.12.7, krav 116), affattes således:


  »116) | Kontrolapparatet skal registrere og i sit datalager gemme køretøjets øjeblikkelige hastighed med tilhørende dato og klokkeslæt i hvert sekund for mindst de seneste 24 timer, køretøjet har bevæget sig.« |
| --- | --- | --- |

14)

Afsnit 3.12.7, krav 116), affattes således:

»116)

| 15) | I afsnit 3.12.8 foretages følgende ændringer i skemaet:


  a) | Følgende post indsættes mellem posterne »Manglende positionsoplysninger fra GNSS-modtageren« og »Fejl ved køredata«:


  »Fejl ved kommunikation med det eksterne GNSS-udstyr | — | den længstvarende hændelse for hver af de 10 seneste dage, den er forekommet |
| --- | --- | --- | --- | --- |

15)

I afsnit 3.12.8 foretages følgende ændringer i skemaet:

a)

Følgende post indsættes mellem posterne »Manglende positionsoplysninger fra GNSS-modtageren« og »Fejl ved køredata«:

»Fejl ved kommunikation med det eksterne GNSS-udstyr

—

den længstvarende hændelse for hver af de 10 seneste dage, den er forekommet

| — | de 5 længstvarende hændelser inden for de seneste 365 dage |
| --- | --- |

—

de 5 længstvarende hændelser inden for de seneste 365 dage

| — | hændelsens startdato og -klokkeslæt |
| --- | --- |

—

hændelsens startdato og -klokkeslæt

| — | hændelsens slutdato 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 |
| --- | --- |

—

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

—

antal tilsvarende hændelser den pågældende dag«

| b) | Posten »Tidskonflikt« affattes således:


  »Tidskonflikt | — | den alvorligste hændelse for hver af de 10 seneste dage, den er forekommet (dvs. med den største forskel mellem kontrolapparatdato og -tid og GNSS-dato og -tid) |
| --- | --- | --- | --- |

b)

Posten »Tidskonflikt« affattes således:

»Tidskonflikt

—

den alvorligste hændelse for hver af de 10 seneste dage, den er forekommet (dvs. med den største forskel mellem kontrolapparatdato og -tid og GNSS-dato og -tid)

| — | de 5 alvorligste hændelser inden for de seneste 365 dage |
| --- | --- |

—

de 5 alvorligste hændelser inden for de seneste 365 dage

| — | kontrolapparat, dato og klokkeslæt |
| --- | --- |

—

kontrolapparat, dato og klokkeslæt

| — | GNSS, dato og klokkeslæt |
| --- | --- |

—

GNSS, dato og klokkeslæt

| — | korttype, kortnummer, udstedende medlemsstat og generation af kort, der er isat ved starten og/eller slutningen af hændelsen |
| --- | --- |

—

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

—

antal tilsvarende hændelser den pågældende dag«

| 16) | Afsnit 3.20, krav 200), affattes således:


  »200) | Kontrolapparatet kan også udrustes med standardiserede grænseflader, som muliggør brug af de data, der registreres eller frembringes af takografen, i eksternt udstyr i drifts- eller kalibreringstilstand.
  I tillæg 13 præsenteres en standardiseret fakultativ ITS-grænseflade. Der kan samtidig anvendes andre køretøjsenhedsgrænseflader, forudsat at de fuldt ud overholder minimumskravene i tillæg 13 med hensyn til data, sikkerhed og førerens samtykke.
  Førerens samtykke finder ikke anvendelse på data, som sendes fra kontrolapparatet til køretøjets net. Hvis personoplysninger, der er indlæst i køretøjets net, viderebehandles uden for køretøjets net, er det køretøjsfabrikantens ansvar, at personoplysningerne behandles i overensstemmelse med forordning (EU) 2016/679 (»den generelle forordning om databeskyttelse«).
  Førerens samtykke finder heller ikke anvendelse på takografdata, som overføres til en fjerntilsluttet virksomhed (krav 193), idet dette scenarie overvåges via virksomhedskortets adgangsrettighed.
  Følgende krav gælder for ITS-data, der tilvejebringes via den pågældende grænseflade:


  — | Der er tale om udvalgte eksisterende data fra takografens dataordliste (tillæg 1). |
| --- | --- | --- | --- |

16)

Afsnit 3.20, krav 200), affattes således:

»200)

I tillæg 13 præsenteres en standardiseret fakultativ ITS-grænseflade. Der kan samtidig anvendes andre køretøjsenhedsgrænseflader, forudsat at de fuldt ud overholder minimumskravene i tillæg 13 med hensyn til data, sikkerhed og førerens samtykke.

Førerens samtykke finder ikke anvendelse på data, som sendes fra kontrolapparatet til køretøjets net. Hvis personoplysninger, der er indlæst i køretøjets net, viderebehandles uden for køretøjets net, er det køretøjsfabrikantens ansvar, at personoplysningerne behandles i overensstemmelse med forordning (EU) 2016/679 (»den generelle forordning om databeskyttelse«).

Førerens samtykke finder heller ikke anvendelse på takografdata, som overføres til en fjerntilsluttet virksomhed (krav 193), idet dette scenarie overvåges via virksomhedskortets adgangsrettighed.

Følgende krav gælder for ITS-data, der tilvejebringes via den pågældende grænseflade:

—

Der er tale om udvalgte eksisterende data fra takografens dataordliste (tillæg 1).

| — | En delmængde af disse udvalgte data er markeret som »personoplysninger«. |
| --- | --- |

—

En delmængde af disse udvalgte data er markeret som »personoplysninger«.

| — | »Personoplysningerne« er kun tilgængelige, hvis der indhentes verificerbart samtykke fra føreren om, at vedkommendes personoplysninger må hentes ud af køretøjets net. |
| --- | --- |

—

»Personoplysningerne« er kun tilgængelige, hvis der indhentes verificerbart samtykke fra føreren om, at vedkommendes personoplysninger må hentes ud af køretøjets net.

| — | Dette samtykke kan til enhver tid gives eller trækkes tilbage ved hjælp af kommandoer i menuen, forudsat at førerkortet er isat. |
| --- | --- |

—

Dette samtykke kan til enhver tid gives eller trækkes tilbage ved hjælp af kommandoer i menuen, forudsat at førerkortet er isat.

| — | Både de samlede data og delmængder heraf udsendes via trådløs protokol (Bluetooth) inden for førerhusets radius med en opdateringsfrekvens på 1 minut. |
| --- | --- |

—

Både de samlede data og delmængder heraf udsendes via trådløs protokol (Bluetooth) inden for førerhusets radius med en opdateringsfrekvens på 1 minut.

| — | Parringen af den eksterne enhed med ITS-grænsefladen vil være beskyttet af en særlig tilfældig pinkode på mindst 4 cifre, der registreres i hver enkelt køretøjsenhed og er tilgængelig via dennes skærm. |
| --- | --- |

—

Parringen af den eksterne enhed med ITS-grænsefladen vil være beskyttet af en særlig tilfældig pinkode på mindst 4 cifre, der registreres i hver enkelt køretøjsenhed og er tilgængelig via dennes skærm.

| — | Under ingen omstændigheder må ITS-grænsefladens tilstedeværelse forstyrre eller påvirke køretøjsenhedens funktionstilstand og sikkerhed. |
| --- | --- |

—

Under ingen omstændigheder må ITS-grænsefladens tilstedeværelse forstyrre eller påvirke køretøjsenhedens funktionstilstand og sikkerhed.

Ud over de udvalgte eksisterende data, der betragtes som et minimum, kan andre data også udlæses, forudsat at de ikke kan betragtes som personoplysninger.

Kontrolapparatet skal kunne kommunikere førerens samtykkestatus til andre platforme i køretøjets net.

Når køretøjet er sat i tænding, skal disse data udsendes permanent.«

| 17) | Afsnit 3.23, krav 211), affattes således:


  »211) | Køretøjsenhedens interne urs tidsindstilling skal automatisk tilpasses hver 12. time. Hvis denne tilpasning ikke er mulig, fordi der ikke er noget GNSS-signal, skal tidsindstillingen foretages, så snart køretøjsenheden kan få adgang til en gyldig tidsværdi fra GNSS-modtageren, afhængigt af køretøjets tændingstilstand. Referencetidspunktet for den automatiske indstilling af køretøjsenhedens interne ur skal hentes fra GNSS-modtageren.« |
| --- | --- | --- |

17)

Afsnit 3.23, krav 211), affattes således:

»211)

| 18) | Afsnit 3.26, krav 225) og 226), affattes således:


  »225) | På hver af kontrolapparatets separate komponenter skal være fastgjort et skilt med følgende oplysninger:


  — | fabrikantens navn og adresse |
| --- | --- | --- | --- |

18)

Afsnit 3.26, krav 225) og 226), affattes således:

»225)

—

fabrikantens navn og adresse

| — | fabrikantens reservedelsnummer og fremstillingsår |
| --- | --- |

—

fabrikantens reservedelsnummer og fremstillingsår

| — | komponentens serienummer |
| --- | --- |

—

komponentens serienummer

| — | typegodkendelsesmærke. |
| --- | --- |

—

typegodkendelsesmærke.

| 226) | Hvis der ikke er tilstrækkelig plads til at angive alle ovennævnte oplysninger, skal skiltet i det mindste angive: fabrikantens navn eller mærke, og komponentens reservedelsnummer.« |
| --- | --- |

226)

| 19) | I afsnit 4.1 erstattes figuren af for- og bagsiden af førerkortet af følgende:
  »


  Tekst af billedet

  »
  «

  « |
| --- | --- |

19)

I afsnit 4.1 erstattes figuren af for- og bagsiden af førerkortet af følgende:

»

«

| 20) | Afsnit 4.5.3.1.8, krav 263), første led, affattes således:


  »— | kortfejl (når kortet er genstand for fejlen)«. |
| --- | --- | --- |

20)

Afsnit 4.5.3.1.8, krav 263), første led, affattes således:

»—

kortfejl (når kortet er genstand for fejlen)«.

| 21) | Afsnit 4.5.3.2.8, krav 288), første led, affattes således:


  »— | kortfejl (når kortet er genstand for fejlen)«. |
| --- | --- | --- |

21)

Afsnit 4.5.3.2.8, krav 288), første led, affattes således:

»—

kortfejl (når kortet er genstand for fejlen)«.

| 22) | Afsnit 4.5.3.2.16 affattes således:
  »4.5.3.2.16   Data vedrørende den position, hvor tre timers kumuleret køretid nås


  305) | Førerkortet skal kunne opbevare følgende data vedrørende køretøjets position, hvis den kumulerede køretid når op på et multiplum af tre timer:


  — | dato og klokkeslæt, hvor den kumulerede køretid når op på et multiplum af tre timer |
| --- | --- | --- | --- |

22)

Afsnit 4.5.3.2.16 affattes således:

»4.5.3.2.16   Data vedrørende den position, hvor tre timers kumuleret køretid nås

305)

Førerkortet skal kunne opbevare følgende data vedrørende køretøjets position, hvis den kumulerede køretid når op på et multiplum af tre timer:

—

dato og klokkeslæt, hvor den kumulerede køretid når op på et multiplum af tre timer

| — | køretøjets position |
| --- | --- |

—

køretøjets position

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

—

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

| — | køretøjets kilometerstand. |
| --- | --- |

—

køretøjets kilometerstand.

| 306) | Førerkortet skal kunne lagre mindst 252 sådanne poster.« |
| --- | --- |

306)

Førerkortet skal kunne lagre mindst 252 sådanne poster.«

| 23) | Afsnit 4.5.4.2.14 affattes således:
  »4.5.4.2.14   Data vedrørende den position, hvor tre timers kumuleret køretid nås


  353) | Værkstedskortet skal kunne opbevare følgende data vedrørende køretøjets position, hvis den kumulerede køretid når op på et multiplum af tre timer:


  — | dato og klokkeslæt, hvor den kumulerede køretid når op på et multiplum af tre timer |
| --- | --- | --- | --- |

23)

Afsnit 4.5.4.2.14 affattes således:

»4.5.4.2.14   Data vedrørende den position, hvor tre timers kumuleret køretid nås

353)

Værkstedskortet skal kunne opbevare følgende data vedrørende køretøjets position, hvis den kumulerede køretid når op på et multiplum af tre timer:

—

dato og klokkeslæt, hvor den kumulerede køretid når op på et multiplum af tre timer

| — | køretøjets position |
| --- | --- |

—

køretøjets position

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

—

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

| — | køretøjets kilometerstand. |
| --- | --- |

—

køretøjets kilometerstand.

| 354) | Værkstedskortet skal kunne lagre mindst 18 sådanne poster.« |
| --- | --- |

354)

Værkstedskortet skal kunne lagre mindst 18 sådanne poster.«

| 24) | Afsnit 5.2, krav 396), affattes således:


  »396) | Pladen skal være forsynet med mindst følgende oplysninger:


  — | den autoriserede installatørs eller det autoriserede værksteds navn og adresse eller firmanavn |
| --- | --- | --- | --- |

24)

Afsnit 5.2, krav 396), affattes således:

»396)

Pladen skal være forsynet med mindst følgende oplysninger:

—

den autoriserede installatørs eller det autoriserede værksteds navn og adresse eller firmanavn

| — | køretøjets vejdrejetal efter formlen »w = ... imp/km« |
| --- | --- |

—

køretøjets vejdrejetal efter formlen »w = ... imp/km«

| — | kontrolapparatets konstant, angivet ved »k = ... imp/km« |
| --- | --- |

—

kontrolapparatets konstant, angivet ved »k = ... imp/km«

| — | effektiv dækperiferi i formen »l = ... mm« |
| --- | --- |

—

effektiv dækperiferi i formen »l = ... mm«

| — | dækstørrelse |
| --- | --- |

—

dækstørrelse

| — | datoen for måling af køretøjets vejdrejetal og dets effektive dækperiferi |
| --- | --- |

—

datoen for måling af køretøjets vejdrejetal og dets effektive dækperiferi

| — | køretøjets identifikationsnummer |
| --- | --- |

—

køretøjets identifikationsnummer

| — | om der forefindes eksternt GNSS-udstyr |
| --- | --- |

—

om der forefindes eksternt GNSS-udstyr

| — | serienummeret på det eksterne GNSS-udstyr, hvis relevant |
| --- | --- |

—

serienummeret på det eksterne GNSS-udstyr, hvis relevant

| — | serienummeret på enheden til fjernkommunikation, hvis relevant |
| --- | --- |

—

serienummeret på enheden til fjernkommunikation, hvis relevant

| — | serienummeret på alle monterede plomber |
| --- | --- |

—

serienummeret på alle monterede plomber

| — | den del af køretøjet, hvor adapteren i givet fald er installeret |
| --- | --- |

—

den del af køretøjet, hvor adapteren i givet fald er installeret

| — | den del af køretøjet, hvor bevægelsessensoren er installeret, hvis den ikke er sluttet til gearkassen, eller der ikke anvendes en adapter |
| --- | --- |

—

den del af køretøjet, hvor bevægelsessensoren er installeret, hvis den ikke er sluttet til gearkassen, eller der ikke anvendes en adapter

| — | en angivelse af farven på kablet mellem adapteren og den del af køretøjet, der forsyner denne med impulser |
| --- | --- |

—

en angivelse af farven på kablet mellem adapteren og den del af køretøjet, der forsyner denne med impulser

| — | serienummeret på adapterens indlejrede bevægelsessensor.« |
| --- | --- |

—

serienummeret på adapterens indlejrede bevægelsessensor.«

| 25) | I afsnit 5.3 foretages følgende ændringer:


  a) | Efter krav 398) indsættes følgende nye krav 398a):


  »398a) | De nævnte plomber skal være certificeret i henhold til standard EN 16882:2016«. |
| --- | --- | --- | --- |

25)

I afsnit 5.3 foretages følgende ændringer:

a)

Efter krav 398) indsættes følgende nye krav 398a):

»398a)

De nævnte plomber skal være certificeret i henhold til standard EN 16882:2016«.

| b) | Krav 401), andet underafsnit, affattes således:

  »Det unikke identifikationsnummer anføres som en markering i formatet MMNNNNNNNN, som ikke kan fjernes, hvor MM er et unikt fabrikant-ID (databaseregistrering forvaltes af Europa-Kommissionen), og NNNNNNNN er plombens alfanumeriske nummer, som er unik i fabrikantens regi.« |
| --- | --- |

b)

Krav 401), andet underafsnit, affattes således:

»Det unikke identifikationsnummer anføres som en markering i formatet MMNNNNNNNN, som ikke kan fjernes, hvor MM er et unikt fabrikant-ID (databaseregistrering forvaltes af Europa-Kommissionen), og NNNNNNNN er plombens alfanumeriske nummer, som er unik i fabrikantens regi.«

| c) | Krav 403) affattes således:


  »403) | Plombefabrikanterne skal registreres i en særlig database, når de får en plombemodel certificeret i henhold til EN 16882:2016, og offentliggøre numrene på deres identifikationsplomber ved at følge en procedure, der skal fastlægges af Europa-Kommissionen.« |
| --- | --- | --- |

c)

Krav 403) affattes således:

»403)

Plombefabrikanterne skal registreres i en særlig database, når de får en plombemodel certificeret i henhold til EN 16882:2016, og offentliggøre numrene på deres identifikationsplomber ved at følge en procedure, der skal fastlægges af Europa-Kommissionen.«

| d) | Krav 404) affattes således:


  »404) | Godkendte værksteder og køretøjsfabrikanter må i henhold til forordning (EU) nr. 165/2014 kun bruge plomber certificeret i henhold til EN 16882:2016 fra de plombefabrikanter, der står opført i ovennævnte database.« |
| --- | --- | --- |

d)

Krav 404) affattes således:

»404)

Godkendte værksteder og køretøjsfabrikanter må i henhold til forordning (EU) nr. 165/2014 kun bruge plomber certificeret i henhold til EN 16882:2016 fra de plombefabrikanter, der står opført i ovennævnte database.«

| 26) | Afsnit 6.2 affattes således:
  »6.2   Kontrol af nye eller reparerede komponenter


  407) | For hver enkelt ny eller repareret anordning kontrolleres den korrekte funktion og nøjagtigheden af angivelser og optegnelser inden for de i afsnit 3.2.1, 3.2.2, 3.2.3 og 3.3 fastlagte grænser.« |
| --- | --- | --- |

26)

Afsnit 6.2 affattes således:

»6.2   Kontrol af nye eller reparerede komponenter

407)

For hver enkelt ny eller repareret anordning kontrolleres den korrekte funktion og nøjagtigheden af angivelser og optegnelser inden for de i afsnit 3.2.1, 3.2.2, 3.2.3 og 3.3 fastlagte grænser.«

| 27) | Afsnit 6.3, krav 408), affattes således:


  »408) | Ved monteringen i et køretøj skal apparatet og hele installationen opfylde bestemmelserne i afsnit 3.2.1, 3.2.2, 3.2.3 og 3.3 vedrørende maksimale tolerancer. Hele monteringen plomberes i henhold til afsnit 5.3 og kalibreres.« |
| --- | --- | --- |

27)

Afsnit 6.3, krav 408), affattes således:

»408)

Ved monteringen i et køretøj skal apparatet og hele installationen opfylde bestemmelserne i afsnit 3.2.1, 3.2.2, 3.2.3 og 3.3 vedrørende maksimale tolerancer. Hele monteringen plomberes i henhold til afsnit 5.3 og kalibreres.«

| 28) | I afsnit 8.1 foretages følgende ændringer:


  a) | Afsnit 8.1, den indledende tekst før krav 425), affattes således:

  »I dette afsnit forstås ved »kontrolapparat«
  »kontrolapparatet eller dets komponenter«. Der kræves ingen typegodkendelse af det/de kabler, som forbinder bevægelsessensoren med køretøjsenheden, det eksterne GNSS-udstyr med køretøjsenheden eller det eksterne udstyr til fjernkommunikation med køretøjsenheden. Det papir, som skal anvendes af kontrolapparatet, anses for at være en komponent i kontrolapparatet.
  Enhver fabrikant kan anmode om typegodkendelse af kontrolapparatkomponenter sammen med enhver anden kontrolapparatkomponent, forudsat at den enkelte komponent er i overensstemmelse med kravene i dette bilag. Alternativt kan fabrikanter anmode om typegodkendelse af kontrolapparater.
  Som beskrevet i definitionen i denne forordnings artikel 2, nr. 10), kan køretøjsenheder have varianter i komponentsammensætningen. Uanset køretøjsenhedens komponentsammensætning er den eksterne antenne og (eventuelt) antennesplitteren, der er forbundet med GNSS-modtageren eller udstyret til fjernkommunikation, ikke en del af køretøjsenhedens typegodkendelse.
  Dog skal fabrikanter, som har opnået typegodkendelse af kontrolapparatet, føre en offentligt tilgængelig liste over kompatible antenner og splittere for hver typegodkendt køretøjsenhed, eksternt GNSS-udstyr og eksternt udstyr til fjernkommunikation.« |
| --- | --- | --- |

28)

I afsnit 8.1 foretages følgende ændringer:

a)

Afsnit 8.1, den indledende tekst før krav 425), affattes således:

»I dette afsnit forstås ved »kontrolapparat«
  »kontrolapparatet eller dets komponenter«. Der kræves ingen typegodkendelse af det/de kabler, som forbinder bevægelsessensoren med køretøjsenheden, det eksterne GNSS-udstyr med køretøjsenheden eller det eksterne udstyr til fjernkommunikation med køretøjsenheden. Det papir, som skal anvendes af kontrolapparatet, anses for at være en komponent i kontrolapparatet.

Enhver fabrikant kan anmode om typegodkendelse af kontrolapparatkomponenter sammen med enhver anden kontrolapparatkomponent, forudsat at den enkelte komponent er i overensstemmelse med kravene i dette bilag. Alternativt kan fabrikanter anmode om typegodkendelse af kontrolapparater.

Som beskrevet i definitionen i denne forordnings artikel 2, nr. 10), kan køretøjsenheder have varianter i komponentsammensætningen. Uanset køretøjsenhedens komponentsammensætning er den eksterne antenne og (eventuelt) antennesplitteren, der er forbundet med GNSS-modtageren eller udstyret til fjernkommunikation, ikke en del af køretøjsenhedens typegodkendelse.

Dog skal fabrikanter, som har opnået typegodkendelse af kontrolapparatet, føre en offentligt tilgængelig liste over kompatible antenner og splittere for hver typegodkendt køretøjsenhed, eksternt GNSS-udstyr og eksternt udstyr til fjernkommunikation.«

| b) | Krav 427) affattes således:


  »427) | Medlemsstaternes typegodkendelsesmyndigheder udsteder ikke en typegodkendelsesattest, før de er i besiddelse af:


  — | en sikkerhedsattest (hvis krævet i dette bilag) |
| --- | --- | --- | --- |

b)

Krav 427) affattes således:

»427)

Medlemsstaternes typegodkendelsesmyndigheder udsteder ikke en typegodkendelsesattest, før de er i besiddelse af:

—

en sikkerhedsattest (hvis krævet i dette bilag)

| — | en funktionsattest |
| --- | --- |

—

en funktionsattest

| — | en interoperabilitetsattest (hvis krævet i dette bilag) |
| --- | --- |

—

en interoperabilitetsattest (hvis krævet i dette bilag)

for det kontrolapparat eller det takografkort, som typegodkendelsesansøgningen omfatter.«

| 29) | I tillæg 1 foretages følgende ændringer:


  a) | I indholdsfortegnelsen foretages følgende ændringer:


  i) | Afsnit 2.63 affattes således:
  »2.63.   Forbeholdt fremtidig brug«. |
| --- | --- | --- | --- |

29)

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

a)

I indholdsfortegnelsen foretages følgende ændringer:

i)

Afsnit 2.63 affattes således:

»2.63.   Forbeholdt fremtidig brug«.

| ii) | Afsnit 2.78 affattes således:
  »2.78.   GNSSAccumulatedDriving«. |
| --- | --- |

ii)

Afsnit 2.78 affattes således:

»2.78.   GNSSAccumulatedDriving«.

| iii) | Afsnit 2.79 affattes således:
  »2.79.   GNSSAccumulatedDrivingRecord«. |
| --- | --- |

iii)

Afsnit 2.79 affattes således:

»2.79.   GNSSAccumulatedDrivingRecord«.

| iv) | Afsnit 2.111 affattes således:
  »2.111.   NoOfGNSSADRecords«. |
| --- | --- |

iv)

Afsnit 2.111 affattes således:

»2.111.   NoOfGNSSADRecords«.

| v) | Afsnit 2.160 affattes således:
  »2.160.   Forbeholdt fremtidig brug«. |
| --- | --- |

v)

Afsnit 2.160 affattes således:

»2.160.   Forbeholdt fremtidig brug«.

| vi) | Afsnit 2.203 affattes således:
  »2.203.   VuGNSSADRecord«. |
| --- | --- |

vi)

Afsnit 2.203 affattes således:

»2.203.   VuGNSSADRecord«.

| vii) | Afsnit 2.204 affattes således:
  »2.204.   VuGNSSADRecordArray«. |
| --- | --- |

vii)

Afsnit 2.204 affattes således:

»2.204.   VuGNSSADRecordArray«.

| viii) | Afsnit 2.230 affattes således:
  »2.230.   Forbeholdt fremtidig brug«. |
| --- | --- |

viii)

Afsnit 2.230 affattes således:

»2.230.   Forbeholdt fremtidig brug«.

| ix) | Afsnit 2.231 affattes således:
  »2.231.   Forbeholdt fremtidig brug«. |
| --- | --- |

ix)

Afsnit 2.231 affattes således:

»2.231.   Forbeholdt fremtidig brug«.

| b) | Følgende tekst indsættes i afsnit 2 før afsnit 2.1:

  »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.« |
| --- | --- |

b)

Følgende tekst indsættes i afsnit 2 før afsnit 2.1:

»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.«

| c) | Afsnit 2.19 affattes således:
  »2.19.   CardEventData

  Første generation:
  Oplysninger gemt på et fører- eller værkstedskort vedrørende hændelser knyttet til kortindehaveren (bilag I C, krav 260 og 318).


  Tekst af billedet

  CardEventData ::= SEQUENCE SIZE(6) OF {
  cardEventRecords SET SIZE(NoOfEventsPerType) OF
  CardEventRecord
  }


  CardEventData er en sekvens af cardEventRecords, ordnet efter stigende EventFaultType (bortset fra poster vedrørende forsøg på sikkerhedsbrud, som er samlet i sidste del af sekvensen).

  cardEventRecords er et sæt hændelsesposter af en given hændelsestype (eller kategori ved hændelser bestående i forsøg på sikkerhedsbrud).
  Anden generation:
  Oplysninger gemt på et fører- eller værkstedskort vedrørende hændelser knyttet til kortindehaveren (bilag I C, krav 285 og 341).


  Tekst af billedet

  CardEventData ::= SEQUENCE SIZE(11) OF {
  cardEventRecords SET SIZE(NoOfEventsPerType) OF
  CardEventRecord
  }


  CardEventData er en sekvens af cardEventRecords, ordnet efter stigende EventFaultType (bortset fra poster vedrørende forsøg på sikkerhedsbrud, som er samlet i sidste del af sekvensen).

  cardEventRecords er et sæt hændelsesposter af en given hændelsestype (eller kategori ved hændelser bestående i forsøg på sikkerhedsbrud).« |
| --- | --- |

c)

Afsnit 2.19 affattes således:

»2.19.   CardEventData

CardEventData

Første generation:

Oplysninger gemt på et fører- eller værkstedskort vedrørende hændelser knyttet til kortindehaveren (bilag I C, krav 260 og 318).

CardEventData ::= SEQUENCE SIZE(6) OF {

cardEventRecords SET SIZE(NoOfEventsPerType) OF

CardEventRecord

}

CardEventData er en sekvens af cardEventRecords, ordnet efter stigende EventFaultType (bortset fra poster vedrørende forsøg på sikkerhedsbrud, som er samlet i sidste del af sekvensen).

CardEventData

cardEventRecords er et sæt hændelsesposter af en given hændelsestype (eller kategori ved hændelser bestående i forsøg på sikkerhedsbrud).

cardEventRecords

Anden generation:

Oplysninger gemt på et fører- eller værkstedskort vedrørende hændelser knyttet til kortindehaveren (bilag I C, krav 285 og 341).

CardEventData ::= SEQUENCE SIZE(11) OF {

cardEventRecords SET SIZE(NoOfEventsPerType) OF

CardEventRecord

}

CardEventData er en sekvens af cardEventRecords, ordnet efter stigende EventFaultType (bortset fra poster vedrørende forsøg på sikkerhedsbrud, som er samlet i sidste del af sekvensen).

CardEventData

cardEventRecords er et sæt hændelsesposter af en given hændelsestype (eller kategori ved hændelser bestående i forsøg på sikkerhedsbrud).«

cardEventRecords

| d) | Afsnit 2.30 affattes således:
  »2.30.   CardRenewalIndex

  Et kortfornyelsesindeks (definition i)).


  Tekst af billedet

  CardRenewalIndex::= IA5String(SIZE(1))


  Tilordnet værdi: (se kapitel 7 i dette bilag).


  »0« | Første udstedelse. |
| --- | --- | --- |

d)

Afsnit 2.30 affattes således:

»2.30.   CardRenewalIndex

CardRenewalIndex

Et kortfornyelsesindeks (definition i)).

CardRenewalIndex::= IA5String(SIZE(1))

Tilordnet værdi: (se kapitel 7 i dette bilag).

Tilordnet værdi

»0«

Første udstedelse.

Rækkefølge af forøgelse: »0, ..., 9, A, ..., Z«
  «.

| e) | Afsnit 2.61, teksten efter overskriften »Anden generation:«, affattes således:
  »


  Tekst af billedet

  »DriverCardApplicationIdentification ::= SEQUENCE {
  typeOfTachographCardId
  EquipmentType,
  cardStructureVersion
  CardStructureVersion,
  noOfEventsPerType
  NoOfEventsPerType,
  noOfFaultsPerType
  NoOfFaultsPerType,
  activityStructureLength
  CardActivityLengthRange,
  noOfCardVehicleRecords
  NoOfCardVehicleRecords,
  noOfCardPlaceRecords
  NoOfCardPlaceRecords,
  noOfGNSSADRecords
  NoOfGNSSADRecords,
  noOfSpecificConditionRecords
  NoOfSpecificConditionRecords
  noOfCardVehicleUnitRecords
  NoOfCardVehicleUnitRecords
  }

  Ud over dataelementerne for første generation anvendes følgende dataelementer:

  noOfGNSSADRecords er det antal GNSS-poster for kumuleret køretid, som kan gemmes på kortet.

  noOfSpecificConditionRecords er det antal poster vedrørende særlige omstændigheder, som kan gemmes på kortet.

  noOfCardVehicleUnitRecords er det antal poster om anvendte køretøjsenheder, som kan gemmes på kortet.« |
| --- | --- |

e)

Afsnit 2.61, teksten efter overskriften »Anden generation:«, affattes således:

»DriverCardApplicationIdentification ::= SEQUENCE {

typeOfTachographCardId

EquipmentType,

cardStructureVersion

CardStructureVersion,

noOfEventsPerType

NoOfEventsPerType,

noOfFaultsPerType

NoOfFaultsPerType,

activityStructureLength

CardActivityLengthRange,

noOfCardVehicleRecords

NoOfCardVehicleRecords,

noOfCardPlaceRecords

NoOfCardPlaceRecords,

noOfGNSSADRecords

NoOfGNSSADRecords,

noOfSpecificConditionRecords

NoOfSpecificConditionRecords

noOfCardVehicleUnitRecords

NoOfCardVehicleUnitRecords

}

Ud over dataelementerne for første generation anvendes følgende dataelementer:

noOfGNSSADRecords er det antal GNSS-poster for kumuleret køretid, som kan gemmes på kortet.

noOfGNSSADRecords

noOfSpecificConditionRecords er det antal poster vedrørende særlige omstændigheder, som kan gemmes på kortet.

noOfSpecificConditionRecords

noOfCardVehicleUnitRecords er det antal poster om anvendte køretøjsenheder, som kan gemmes på kortet.«

noOfCardVehicleUnitRecords

| f) | Afsnit 2.63 affattes således:
  »2.63.   Forbeholdt fremtidig brug« |
| --- | --- |

f)

Afsnit 2.63 affattes således:

»2.63.   Forbeholdt fremtidig brug«

Forbeholdt fremtidig brug

| g) | Afsnit 2.67, teksten efter overskriften »Anden generation:«, affattes således:

  »De samme værdier som for første generation anvendes med følgende tilføjelser:


  Tekst af billedet

  –GNSS Facility
  (8),
  –Remote Communication Module
  (9),
  –ITS interface module
  (10),
  –Plaque
  (11),–may be used in SealRecord
  –M1/N1 Adapter
  (12),–may be used in SealRecord
  –European Root CA (ERCA)
  (13),
  –Member State CA (MSCA)
  (14),
  –External GNSS connection
  (15),–may be used in SealRecord
  –Unused
  (16),–used in SealDataVu
  –Driver Card (Sign)
  (17),–only to be used in the CHA field of a signing certificate
  –Workshop Card (Sign)
  (18), –only to be used in the CHA field of a signing certificate
  –Vehicle Unit (Sign)
  (19), –only to be used in the CHA field of a signing certificate
  –RFU
  (20..255)


  Note 1: | Værdierne for anden generation for pladen, adapteren og den eksterne GNSS-forbindelse samt værdierne for første generation af køretøjsenheden og bevægelsessensoren kan anvendes i SealRecord, hvis det er relevant. |
| --- | --- | --- |

g)

Afsnit 2.67, teksten efter overskriften »Anden generation:«, affattes således:

»De samme værdier som for første generation anvendes med følgende tilføjelser:

–GNSS Facility

(8),

–Remote Communication Module

(9),

–ITS interface module

(10),

–Plaque

(11),–may be used in SealRecord

–M1/N1 Adapter

(12),–may be used in SealRecord

–European Root CA (ERCA)

(13),

–Member State CA (MSCA)

(14),

–External GNSS connection

(15),–may be used in SealRecord

–Unused

(16),–used in SealDataVu

–Driver Card (Sign)

(17),–only to be used in the CHA field of a signing certificate

–Workshop Card (Sign)

(18), –only to be used in the CHA field of a signing certificate

–Vehicle Unit (Sign)

(19), –only to be used in the CHA field of a signing certificate

–RFU

(20..255)

Note 1:

Note 1:

Værdierne for anden generation for pladen, adapteren og den eksterne GNSS-forbindelse samt værdierne for første generation af køretøjsenheden og bevægelsessensoren kan anvendes i SealRecord, hvis det er relevant.

| Note 2: | I feltet CardHolderAuthorisation (CHA) på et certifikat for anden generation skal værdierne 1), 2), og 6) fortolkes som angivende et certifikat for gensidig ægthedskontrol for den pågældende udstyrstype. For at angive det respektive certifikat for at generere en digital underskrift skal værdierne 17), 18) eller 19) anvendes.« |
| --- | --- |

Note 2:

Note 2:

I feltet CardHolderAuthorisation (CHA) på et certifikat for anden generation skal værdierne 1), 2), og 6) fortolkes som angivende et certifikat for gensidig ægthedskontrol for den pågældende udstyrstype. For at angive det respektive certifikat for at generere en digital underskrift skal værdierne 17), 18) eller 19) anvendes.«

| h) | Afsnit 2.70, teksten efter overskriften »Anden generation:«, affattes således:

  »Anden generation: | Generelle hændelser
  Ingen yderligere detaljer
  Isætning af ugyldigt kort
  Kortkonflikt
  Tidsoverlapning
  Kørsel uden behørigt kort
  Isætning af kort under kørslen
  Seneste kortsession ikke korrekt afsluttet
  Overskridelse af tilladt hastighed
  Afbrydelse i strømforsyningen
  Fejl ved køredata
  Køretøjsbevægelseskonflikt
  Tidskonflikt (GNSS kontra køretøjsenhedens interne ur)
  Fejl ved kommunikation med udstyr til fjernkommunikation
  Manglende positionsoplysninger fra GNSS-modtager
  Fejl ved kommunikation med det eksterne GNSS-udstyr
  RFU |
| --- | --- | --- |
| | Hændelser, som er knyttet til køretøjsenheden og består i forsøg på sikkerhedsbrud
  Ingen yderligere detaljer
  Ægthedsbekræftelse for bevægelsessensor lykkedes ikke
  Ægthedsbekræftelse for takografkort lykkedes ikke
  Ubeføjet ændring af bevægelsessensor
  Integritetsfejl på indlæste kortdata
  Integritetsfejl på lagrede brugerdata
  Fejl ved intern dataoverførsel
  Ubehørig åbning af hus
  Hardware-sabotage
  Registrering af manipulation af GNSS
  Ægthedsbekræftelse for eksternt GNSS-udstyr lykkedes ikke
  Certifikat for eksternt GNSS-udstyr udløbet
  til ‘1F’H RFU |
| | Hændelser, som knyttet til føleren og består i forsøg på sikkerhedsbrud
  Ingen yderligere detaljer
  Ægthedskontrol lykkedes ikke
  Integritetsfejl på lagrede data
  Fejl ved intern dataoverførsel
  Ubehørig åbning af hus
  Hardware-sabotage
  RFU |
| | Fejl ved kontrolapparat
  Ingen yderligere detaljer
  Intern fejl i køretøjsenhed
  Printerfejl
  Displayfejl
  Dataoverførselsfejl
  Følerfejl
  Intern GNSS-modtager
  Eksternt GNSS-udstyr
  Udstyr til fjernkommunikation
  ITS-grænseflade
  RFU |
| | Kortfejl
  Ingen yderligere detaljer
  RFU |
| | RFU |
| | Fabrikantspecifik.« |

h)

Afsnit 2.70, teksten efter overskriften »Anden generation:«, affattes således:

»Anden generation:

Image 7

Generelle hændelser

Ingen yderligere detaljer

Isætning af ugyldigt kort

Kortkonflikt

Tidsoverlapning

Kørsel uden behørigt kort

Isætning af kort under kørslen

Seneste kortsession ikke korrekt afsluttet

Overskridelse af tilladt hastighed

Afbrydelse i strømforsyningen

Fejl ved køredata

Køretøjsbevægelseskonflikt

Tidskonflikt (GNSS kontra køretøjsenhedens interne ur)

Fejl ved kommunikation med udstyr til fjernkommunikation

Manglende positionsoplysninger fra GNSS-modtager

Fejl ved kommunikation med det eksterne GNSS-udstyr

RFU

Image 8

Hændelser, som er knyttet til køretøjsenheden og består i forsøg på sikkerhedsbrud

Ingen yderligere detaljer

Ægthedsbekræftelse for bevægelsessensor lykkedes ikke

Ægthedsbekræftelse for takografkort lykkedes ikke

Ubeføjet ændring af bevægelsessensor

Integritetsfejl på indlæste kortdata

Integritetsfejl på lagrede brugerdata

Fejl ved intern dataoverførsel

Ubehørig åbning af hus

Hardware-sabotage

Registrering af manipulation af GNSS

Ægthedsbekræftelse for eksternt GNSS-udstyr lykkedes ikke

Certifikat for eksternt GNSS-udstyr udløbet

til ‘1F’H RFU

Image 9

Hændelser, som knyttet til føleren og består i forsøg på sikkerhedsbrud

Ingen yderligere detaljer

Ægthedskontrol lykkedes ikke

Integritetsfejl på lagrede data

Fejl ved intern dataoverførsel

Ubehørig åbning af hus

Hardware-sabotage

RFU

Image 10

Fejl ved kontrolapparat

Ingen yderligere detaljer

Intern fejl i køretøjsenhed

Printerfejl

Displayfejl

Dataoverførselsfejl

Følerfejl

Intern GNSS-modtager

Eksternt GNSS-udstyr

Udstyr til fjernkommunikation

ITS-grænseflade

RFU

Image 11

Kortfejl

Ingen yderligere detaljer

RFU

Image 12

RFU

Image 13

Fabrikantspecifik.«

| i) | Afsnit 2.71 affattes således:
  »2.71.   ExtendedSealIdentifier

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


  Tekst af billedet

  ExtendedSealIdentifier ::= SEQUENCE{
  manufacturerCode OCTET STRING (SIZE(2)),
  sealIdentifier OCTET STRING (SIZE(8))
  }


  manufacturerCode er en kode for fabrikanten af plomben.

  sealIdentifier er et datanavn for plomben, som er unikt for fabrikanten.« |
| --- | --- |

i)

Afsnit 2.71 affattes således:

»2.71.   ExtendedSealIdentifier

ExtendedSealIdentifier

Anden generation:

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

ExtendedSealIdentifier ::= SEQUENCE{

manufacturerCode OCTET STRING (SIZE(2)),

sealIdentifier OCTET STRING (SIZE(8))

}

manufacturerCode er en kode for fabrikanten af plomben.

manufacturerCode

sealIdentifier er et datanavn for plomben, som er unikt for fabrikanten.«

sealIdentifier

| j) | Afsnit 2.78 og 2.79 affattes således:
  »2.78.   GNSSAccumulatedDriving

  Anden generation:
  Oplysninger gemt på et fører- eller værkstedskort vedrørende køretøjets GNSS-position, hvis den kumulerede køretid når op på et multiplum af tre timer (bilag I C, krav 306 og 354).


  Tekst af billedet

  GNSSAccumulatedDriving := SEQUENCE {
  gnssADPointerNewestRecord INTEGER(0..NoOfGNSSADRecords -1),
  gnssAccumulatedDrivingRecords SET SIZE(NoOfGNSSADRecords) OF
  GNSSAccumulatedDrivingRecord
  }


  gnssADPointerNewestRecord er indekset på den senest opdaterede GNSS-post for kumuleret køretid.

  Tilordnet værdi: Tal svarende til tælleren i GNSS-posten for kumuleret køretid, begyndende med »0« for den første forekomst af GNSS-posten for kumuleret køretid i strukturen.

  gnssAccumulatedDrivingRecords er mængden af poster, der indeholder dato og klokkeslæt, hvor den kumulerede køretid når op på et multiplum af tre timer, og oplysninger om køretøjets position.
  2.79.   GNSSAccumulatedDrivingRecord

  Anden generation:
  Oplysninger gemt på et fører- eller værkstedskort vedrørende køretøjets GNSS-position, hvis den kumulerede køretid når op på et multiplum af tre timer (bilag I C, krav 305 og 353).


  Tekst af billedet

  GNSSAccumulatedDrivingRecord ::= SEQUENCE {
  timeStamp TimeReal,
  gnssPlaceRecord GNSSPlaceRecord,
  vehicleOdometerValue OdometerShort
  }


  timeStamp er den dato og det klokkeslæt, hvor den kumulerede køretid når op på et multiplum af tre timer.

  gnssPlaceRecord indeholder oplysninger om køretøjets position.

  vehicleOdometerValue er kilometerstanden, når den kumulerede køretid når op på et multiplum af tre timer.« |
| --- | --- |

j)

Afsnit 2.78 og 2.79 affattes således:

»2.78.   GNSSAccumulatedDriving

GNSSAccumulatedDriving

Anden generation:

Oplysninger gemt på et fører- eller værkstedskort vedrørende køretøjets GNSS-position, hvis den kumulerede køretid når op på et multiplum af tre timer (bilag I C, krav 306 og 354).

GNSSAccumulatedDriving := SEQUENCE {

gnssADPointerNewestRecord INTEGER(0..NoOfGNSSADRecords -1),

gnssAccumulatedDrivingRecords SET SIZE(NoOfGNSSADRecords) OF

GNSSAccumulatedDrivingRecord

}

gnssADPointerNewestRecord er indekset på den senest opdaterede GNSS-post for kumuleret køretid.

gnssADPointerNewestRecord

Tilordnet værdi: Tal svarende til tælleren i GNSS-posten for kumuleret køretid, begyndende med »0« for den første forekomst af GNSS-posten for kumuleret køretid i strukturen.

Tilordnet værdi:

gnssAccumulatedDrivingRecords er mængden af poster, der indeholder dato og klokkeslæt, hvor den kumulerede køretid når op på et multiplum af tre timer, og oplysninger om køretøjets position.

gnssAccumulatedDrivingRecords

2.79.   GNSSAccumulatedDrivingRecord

GNSSAccumulatedDrivingRecord

Anden generation:

Oplysninger gemt på et fører- eller værkstedskort vedrørende køretøjets GNSS-position, hvis den kumulerede køretid når op på et multiplum af tre timer (bilag I C, krav 305 og 353).

GNSSAccumulatedDrivingRecord ::= SEQUENCE {

timeStamp TimeReal,

gnssPlaceRecord GNSSPlaceRecord,

vehicleOdometerValue OdometerShort

}

timeStamp er den dato og det klokkeslæt, hvor den kumulerede køretid når op på et multiplum af tre timer.

timeStamp

gnssPlaceRecord indeholder oplysninger om køretøjets position.

gnssPlaceRecord

vehicleOdometerValue er kilometerstanden, når den kumulerede køretid når op på et multiplum af tre timer.«

vehicleOdometerValue

| k) | Afsnit 2.86 affattes således:
  »2.86.   KeyIdentifier

  Et entydigt datanavn for en offentlig nøgle. Benyttes til at henvise til og vælge nøgle. Den identificerer desuden indehaveren af nøglen.


  Tekst af billedet

  KeyIdentifier ::= CHOICE {
  extendedSerialNumber ExtendedSerialNumber,
  certificateRequestID CertificateRequestID,
  certificationAuthorityKID CertificationAuthorityKID
  }

  Det første valg er egnet til henvisning til den offentlige nøgle for en køretøjsenhed, et takografkort eller et eksternt GNSS-udstyr.
  Det andet valg er egnet til henvisning til den offentlige nøgle for en køretøjsenhed (når køretøjsenhedens serienummer ikke kan oplyses på tidspunktet for udfærdigelse af certifikatet).
  Det tredje valg er egnet til henvisning til den offentlige nøgle for en medlemsstat.« |
| --- | --- |

k)

Afsnit 2.86 affattes således:

»2.86.   KeyIdentifier

KeyIdentifier

Et entydigt datanavn for en offentlig nøgle. Benyttes til at henvise til og vælge nøgle. Den identificerer desuden indehaveren af nøglen.

KeyIdentifier ::= CHOICE {

extendedSerialNumber ExtendedSerialNumber,

certificateRequestID CertificateRequestID,

certificationAuthorityKID CertificationAuthorityKID

}

Det første valg er egnet til henvisning til den offentlige nøgle for en køretøjsenhed, et takografkort eller et eksternt GNSS-udstyr.

Det andet valg er egnet til henvisning til den offentlige nøgle for en køretøjsenhed (når køretøjsenhedens serienummer ikke kan oplyses på tidspunktet for udfærdigelse af certifikatet).

Det tredje valg er egnet til henvisning til den offentlige nøgle for en medlemsstat.«

| l) | Afsnit 2.92 affattes således:
  »2.92.   MAC

  Anden generation:
  En kryptografisk kontrolsum af 8, 12 eller 16 bytes længde svarende til de krypteringsprogrammer, der er angivet i tillæg 11.


  Tekst af billedet

  MAC ::= CHOICE {
  Mac8 OCTET STRING (SIZE(8)),
  Mac12 OCTET STRING (SIZE(12)),
  Mac16 OCTET STRING (SIZE(16)),
  }«;

  « |
| --- | --- |

l)

Afsnit 2.92 affattes således:

»2.92.   MAC

MAC

Anden generation:

En kryptografisk kontrolsum af 8, 12 eller 16 bytes længde svarende til de krypteringsprogrammer, der er angivet i tillæg 11.

MAC ::= CHOICE {

Mac8 OCTET STRING (SIZE(8)),

Mac12 OCTET STRING (SIZE(12)),

Mac16 OCTET STRING (SIZE(16)),

}«;

| m) | Afsnit 2.111 affattes således:
  »2.111.   NoOfGNSSADRecords

  Anden generation:
  Antal GNSS-poster for kumuleret køretid, som kan gemmes på et kort.


  Tekst af billedet

  NoOfGNSSADRecords ::= INTEGER (0..216-1)


  Tilordnet værdi: se tillæg 2.« |
| --- | --- |

m)

Afsnit 2.111 affattes således:

»2.111.   NoOfGNSSADRecords

NoOfGNSSADRecords

Anden generation:

Antal GNSS-poster for kumuleret køretid, som kan gemmes på et kort.

NoOfGNSSADRecords ::= INTEGER (0..216-1)

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

Tilordnet værdi:

| n) | Afsnit 2.120, den tilordnede værdi ‘16’H, affattes således:
  »


  Tekst af billedet

  ’16’HVuGNSSADRecord

  «. |
| --- | --- |

n)

Afsnit 2.120, den tilordnede værdi ‘16’H, affattes således:

’16’HVuGNSSADRecord

| o) | Afsnit 2.160 affattes således:
  »2.160.   Forbeholdt fremtidig brug«. |
| --- | --- |

o)

Afsnit 2.160 affattes således:

»2.160.   Forbeholdt fremtidig brug«.

Forbeholdt fremtidig brug

| p) | Afsnit 2.162 affattes således:
  »2.162.   TimeReal

  Kode for et kombineret dato- og klokkeslætfelt, hvor dato og klokkeslæt er angivet som sekunder siden 00h.00m.00s. den 1. januar 1970 UTC.


  Tekst af billedet

  TimeReal {INTEGER:TimeRealRange} ::= INTEGER (0..TimeRealRange)


  Tilordnet værdi — Oktet udsluttet: Antal sekunder siden midnat den 1. januar 1970 UTC.
  Den maksimale værdi af dato/klokkeslæt er året 2106.« |
| --- | --- |

p)

Afsnit 2.162 affattes således:

»2.162.   TimeReal

TimeReal

Kode for et kombineret dato- og klokkeslætfelt, hvor dato og klokkeslæt er angivet som sekunder siden 00h.00m.00s. den 1. januar 1970 UTC.

TimeReal {INTEGER:TimeRealRange} ::= INTEGER (0..TimeRealRange)

Tilordnet værdi — Oktet udsluttet: Antal sekunder siden midnat den 1. januar 1970 UTC.

Tilordnet værdi

Oktet udsluttet

Den maksimale værdi af dato/klokkeslæt er året 2106.«

| q) | Afsnit 2.179 affattes således:
  »2.179.   VuCardRecord

  Anden generation:
  Oplysninger gemt på en køretøjsenhed vedrørende et anvendt takografkort (bilag I C, krav 132).


  Tekst af billedet

  VuCardRecord ::= SEQUENCE {
  cardNumberAndGenerationInformation FullCardNumberAndGeneration,
  cardExtendedSerialNumber ExtendedSerialNumber,
  cardStructureVersion CardStructureVersion,
  cardNumber CardNumber
  }


  cardNumberAndGenerationInformation er det fuldstændige kortnummer og det anvendte korts generation (datatype 2.74).

  cardExtendedSerialNumber, aflæst fra filen EF_ICC under kortets hovedfil.

  cardStructureVersion, aflæst fra filen EF_Application_Identification under DF_Tachograph_G2.

  cardNumber, aflæst fra filen EF_Identification under DF_Tachograph_G2.«. |
| --- | --- |

q)

Afsnit 2.179 affattes således:

»2.179.   VuCardRecord

VuCardRecord

Anden generation:

Oplysninger gemt på en køretøjsenhed vedrørende et anvendt takografkort (bilag I C, krav 132).

VuCardRecord ::= SEQUENCE {

cardNumberAndGenerationInformation FullCardNumberAndGeneration,

cardExtendedSerialNumber ExtendedSerialNumber,

cardStructureVersion CardStructureVersion,

cardNumber CardNumber

}

cardNumberAndGenerationInformation er det fuldstændige kortnummer og det anvendte korts generation (datatype 2.74).

cardNumberAndGenerationInformation

cardExtendedSerialNumber, aflæst fra filen EF_ICC under kortets hovedfil.

cardExtendedSerialNumber

cardStructureVersion, aflæst fra filen EF_Application_Identification under DF_Tachograph_G2.

cardStructureVersion

cardNumber, aflæst fra filen EF_Identification under DF_Tachograph_G2.«.

cardNumber

| r) | Afsnit 2.203 og 2.204 affattes således:
  »2.203.   VuGNSSADRecord

  Anden generation:
  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).


  Tekst af billedet

  VuGNSSADRecord ::= SEQUENCE {
  timeStamp TimeReal,
  cardNumberAndGenDriverSlot FullCardNumberAndGeneration,
  cardNumberAndGenCodriverSlot FullCardNumberAndGeneration,
  gnssPlaceRecord GNSSPlaceRecord,
  vehicleOdometerValue OdometerShort
  }


  timeStamp er den dato og det klokkeslæt, hvor den kumulerede køretid når op på et multiplum af tre timer.

  cardNumberAndGenDriverSlot identificerer det kort, der sidder i førerens kortplads, og kortets generation.

  cardNumberAndGenCodriverSlot identificerer det kort, der sidder i medchaufførens kortplads, og kortets generation.

  gnssPlaceRecord indeholder oplysninger om køretøjets position.

  vehicleOdometerValue er kilometerstanden, når den kumulerede køretid når op på et multiplum af tre timer.
  2.204.   VuGNSSADRecordArray

  Anden generation:
  Oplysninger gemt på en køretøjsenhed vedrørende køretøjets GNSS-position, når den kumulerede køretid når op på et multiplum af tre timer (bilag I C, krav 108 og 110).


  Tekst af billedet

  VuGNSSADRecordArray ::= SEQUENCE {
  recordType RecordType,
  recordSize INTEGER(1..65535),
  noOfRecords INTEGER(0..65535),
  records SET SIZE(noOfRecords) OF VuGNSSADRecord
  }


  recordType er postens type (VuGNSSADRecord).

  Tilordnet værdi: Se postens type.

  recordSize er størrelsen af VuGNSSADRecord i bytes.

  noOfRecords er antallet af poster i mængden af poster.

  records er mængden af GNSS-poster for kumuleret køretid.« |
| --- | --- |

r)

Afsnit 2.203 og 2.204 affattes således:

»2.203.   VuGNSSADRecord

VuGNSSADRecord

Anden generation:

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

VuGNSSADRecord ::= SEQUENCE {

timeStamp TimeReal,

cardNumberAndGenDriverSlot FullCardNumberAndGeneration,

cardNumberAndGenCodriverSlot FullCardNumberAndGeneration,

gnssPlaceRecord GNSSPlaceRecord,

vehicleOdometerValue OdometerShort

}

timeStamp er den dato og det klokkeslæt, hvor den kumulerede køretid når op på et multiplum af tre timer.

timeStamp

cardNumberAndGenDriverSlot identificerer det kort, der sidder i førerens kortplads, og kortets generation.

cardNumberAndGenDriverSlot

cardNumberAndGenCodriverSlot identificerer det kort, der sidder i medchaufførens kortplads, og kortets generation.

cardNumberAndGenCodriverSlot

gnssPlaceRecord indeholder oplysninger om køretøjets position.

gnssPlaceRecord

vehicleOdometerValue er kilometerstanden, når den kumulerede køretid når op på et multiplum af tre timer.

vehicleOdometerValue

2.204.   VuGNSSADRecordArray

VuGNSSADRecordArray

Anden generation:

Oplysninger gemt på en køretøjsenhed vedrørende køretøjets GNSS-position, når den kumulerede køretid når op på et multiplum af tre timer (bilag I C, krav 108 og 110).

VuGNSSADRecordArray ::= SEQUENCE {

recordType RecordType,

recordSize INTEGER(1..65535),

noOfRecords INTEGER(0..65535),

records SET SIZE(noOfRecords) OF VuGNSSADRecord

}

recordType er postens type (VuGNSSADRecord).

recordType

Tilordnet værdi: Se postens type.

Tilordnet værdi

recordSize er størrelsen af VuGNSSADRecord i bytes.

recordSize

noOfRecords er antallet af poster i mængden af poster.

noOfRecords

records er mængden af GNSS-poster for kumuleret køretid.«

records

| s) | Afsnit 2.230 og 2.231 affattes således:
  »2.230.   Forbeholdt fremtidig brug

  2.231.   Forbeholdt fremtidig brug«. |
| --- | --- |

s)

Afsnit 2.230 og 2.231 affattes således:

»2.230.   Forbeholdt fremtidig brug

Forbeholdt fremtidig brug

2.231.   Forbeholdt fremtidig brug«.

Forbeholdt fremtidig brug

| t) | Afsnit 2.234, teksten efter overskriften »Anden generation:«, affattes således:
  »


  Tekst af billedet

  »WorkshopCardApplicationIdentification ::= SEQUENCE {
  typeOfTachographCardId EquipmentType,
  cardStructureVersion CardStructureVersion,
  noOfEventsPerType NoOfEventsPerType,
  noOfFaultsPerType NoOfFaultsPerType,
  activityStructureLength CardActivityLengthRange,
  noOfCardVehicleRecords NoOfCardVehicleRecords,
  noOfCardPlaceRecords NoOfCardPlaceRecords,
  noOfCalibrationRecords NoOfCalibrationRecords,
  noOfGNSSADRecords NoOfGNSSADRecords,
  noOfSpecificConditionRecords NoOfSpecificConditionRecords,
  noOfCardVehicleUnitRecords NoOfCardVehicleUnitRecords
  }

  Ud over dataelementerne for første generation anvendes følgende dataelementer:

  noOfGNSSADRecords er det antal GNSS-poster for kumuleret køretid, som kan gemmes på kortet.

  noOfSpecificConditionRecords er det antal poster vedrørende særlige omstændigheder, som kan gemmes på kortet.

  noOfCardVehicleUnitRecords er det antal poster om anvendte køretøjsenheder, som kan gemmes på kortet.« |
| --- | --- |

t)

Afsnit 2.234, teksten efter overskriften »Anden generation:«, affattes således:

»WorkshopCardApplicationIdentification ::= SEQUENCE {

typeOfTachographCardId EquipmentType,

cardStructureVersion CardStructureVersion,

noOfEventsPerType NoOfEventsPerType,

noOfFaultsPerType NoOfFaultsPerType,

activityStructureLength CardActivityLengthRange,

noOfCardVehicleRecords NoOfCardVehicleRecords,

noOfCardPlaceRecords NoOfCardPlaceRecords,

noOfCalibrationRecords NoOfCalibrationRecords,

noOfGNSSADRecords NoOfGNSSADRecords,

noOfSpecificConditionRecords NoOfSpecificConditionRecords,

noOfCardVehicleUnitRecords NoOfCardVehicleUnitRecords

}

Ud over dataelementerne for første generation anvendes følgende dataelementer:

noOfGNSSADRecords er det antal GNSS-poster for kumuleret køretid, som kan gemmes på kortet.

noOfGNSSADRecords

noOfSpecificConditionRecords er det antal poster vedrørende særlige omstændigheder, som kan gemmes på kortet.

noOfSpecificConditionRecords

noOfCardVehicleUnitRecords er det antal poster om anvendte køretøjsenheder, som kan gemmes på kortet.«

noOfCardVehicleUnitRecords

| 30) | I tillæg 2 foretages følgende ændringer:


  a) | I punkt 1.1 indsættes følgende forkortelser:


  »CHA | Certifikatindehavers autorisation (Certificate Holder Authorisation) |
| --- | --- | --- | --- |
| DO | Dataobjekt«. |

30)

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

a)

I punkt 1.1 indsættes følgende forkortelser:

»CHA

Certifikatindehavers autorisation (Certificate Holder Authorisation)

DO

Dataobjekt«.

| b) | I afsnit 3.3 foretages følgende ændringer:


  i) | Krav TCS_24 affattes således:


  »TCS_24 | Disse sikkerhedsbetingelser kan kædes sammen på følgende måder:

  AND: Alle sikkerhedsbetingelser skal være opfyldt

  OR: Mindst én sikkerhedsbetingelse skal være opfyldt
  Adgangsreglerne for filsystemet, dvs. kommandoerne SELECT, READ BINARY og UPDATE BINARY, er nærmere beskrevet i afsnit 4. Adgangsreglerne for de resterende kommandoer er nærmere beskrevet i følgende tabeller. Udtrykket »ikke relevant« anvendes, hvis der ikke findes noget krav til støtte for kommandoen. I så tilfælde kan kommandoen være støttet, men adgangsreglerne er uden for gyldighedsområdet.« |
| --- | --- | --- | --- |

b)

I afsnit 3.3 foretages følgende ændringer:

i)

Krav TCS_24 affattes således:

»TCS_24

Disse sikkerhedsbetingelser kan kædes sammen på følgende måder:

AND: Alle sikkerhedsbetingelser skal være opfyldt

AND

OR: Mindst én sikkerhedsbetingelse skal være opfyldt

OR

Adgangsreglerne for filsystemet, dvs. kommandoerne SELECT, READ BINARY og UPDATE BINARY, er nærmere beskrevet i afsnit 4. Adgangsreglerne for de resterende kommandoer er nærmere beskrevet i følgende tabeller. Udtrykket »ikke relevant« anvendes, hvis der ikke findes noget krav til støtte for kommandoen. I så tilfælde kan kommandoen være støttet, men adgangsreglerne er uden for gyldighedsområdet.«

| ii) | I krav TCS_25 affattes tabellen således:


  »Kommando | Førerkort | Værkstedskort | Kontrolkort | Virksomhedskort |
| --- | --- | --- | --- | --- | --- |
| External Authenticate | | | | |
| — | For ægthedsbekræftelse (første generation) |

ii)

I krav TCS_25 affattes tabellen således:

»Kommando

Førerkort

Værkstedskort

Kontrolkort

Virksomhedskort

External Authenticate

—

For ægthedsbekræftelse (første generation)

ALW

ALW

ALW

ALW

| — | For ægthedsbekræftelse (anden generation) |
| --- | --- |

—

For ægthedsbekræftelse (anden generation)

ALW

PWD

ALW

ALW

Internal Authenticate

ALW

PWD

ALW

ALW

General Authenticate

ALW

ALW

ALW

ALW

Get Challenge

ALW

ALW

ALW

ALW

MSE:SET AT

ALW

ALW

ALW

ALW

MSE:SET DST

ALW

ALW

ALW

ALW

Process DSRC Message

Ikke relevant

Ikke relevant

Ikke relevant

Ikke relevant

PSO: Compute Digital Signature

ALW OR

SM-MAC-G2

ALW OR

SM-MAC-G2

Ikke relevant

Ikke relevant

PSO: Hash

Ikke relevant

Ikke relevant

ALW

Ikke relevant

PERFORM HASH OF FILE

ALW OR

SM-MAC-G2

ALW OR

SM-MAC-G2

Ikke relevant

Ikke relevant

PSO: Verify Certificate

ALW

ALW

ALW

ALW

PSO: Verify Digital Signature

Ikke relevant

Ikke relevant

ALW

Ikke relevant

Verify

Ikke relevant

ALW

Ikke relevant

Ikke relevant«

| iii) | I krav TCS_26 affattes tabellen således:


  »Kommando | Førerkort | Værkstedskort | Kontrolkort | Virksomhedskort |
| --- | --- | --- | --- | --- | --- |
| External Authenticate | | | | |
| — | For ægthedsbekræftelse (første generation) |

iii)

I krav TCS_26 affattes tabellen således:

»Kommando

Førerkort

Værkstedskort

Kontrolkort

Virksomhedskort

External Authenticate

—

For ægthedsbekræftelse (første generation)

Ikke relevant

Ikke relevant

Ikke relevant

Ikke relevant

| — | For ægthedsbekræftelse (anden generation) |
| --- | --- |

—

For ægthedsbekræftelse (anden generation)

ALW

PWD

ALW

ALW

Internal Authenticate

Ikke relevant

Ikke relevant

Ikke relevant

Ikke relevant

General Authenticate

ALW

ALW

ALW

ALW

Get Challenge

ALW

ALW

ALW

ALW

MSE:SET AT

ALW

ALW

ALW

ALW

MSE:SET DST

ALW

ALW

ALW

ALW

Process DSRC Message

Ikke relevant

ALW

ALW

Ikke relevant

PSO: Compute Digital Signature

ALW OR

SM-MAC-G2

ALW OR

SM-MAC-G2

Ikke relevant

Ikke relevant

PSO: Hash

Ikke relevant

Ikke relevant

ALW

Ikke relevant

PERFORM HASH OF FILE

ALW OR

SM-MAC-G2

ALW OR

SM-MAC-G2

Ikke relevant

Ikke relevant

PSO: Verify Certificate

ALW

ALW

ALW

ALW

PSO: Verify Digital Signature

Ikke relevant

Ikke relevant

ALW

Ikke relevant

Verify

Ikke relevant

ALW

Ikke relevant

Ikke relevant«

| iv) | I krav TCS_27 affattes tabellen således:


  »Kommando | Førerkort | Værkstedskort | Kontrolkort | Virksomhedskort |
| --- | --- | --- | --- | --- | --- |
| External Authenticate | | | | |
| — | For første generation ægthedskontrol |

iv)

I krav TCS_27 affattes tabellen således:

»Kommando

Førerkort

Værkstedskort

Kontrolkort

Virksomhedskort

External Authenticate

—

For første generation ægthedskontrol

Ikke relevant

Ikke relevant

Ikke relevant

Ikke relevant

| — | For anden generation ægthedskontrol |
| --- | --- |

—

For anden generation ægthedskontrol

ALW

PWD

ALW

ALW

Internal Authenticate

Ikke relevant

Ikke relevant

Ikke relevant

Ikke relevant

General Authenticate

ALW

ALW

ALW

ALW

Get Challenge

ALW

ALW

ALW

ALW

MSE:SET AT

ALW

ALW

ALW

ALW

MSE:SET DST

ALW

ALW

ALW

ALW

Process DSRC Message

Ikke relevant

Ikke relevant

Ikke relevant

Ikke relevant

PSO: Compute Digital Signature

Ikke relevant

Ikke relevant

Ikke relevant

Ikke relevant

PSO: Hash

Ikke relevant

Ikke relevant

Ikke relevant

Ikke relevant

PERFORM HASH OF FILE

Ikke relevant

Ikke relevant

Ikke relevant

Ikke relevant

PSO: Verify Certificate

ALW

ALW

ALW

ALW

PSO: Verify Digital Signature

Ikke relevant

Ikke relevant

Ikke relevant

Ikke relevant

Verify

Ikke relevant

ALW

Ikke relevant

Ikke relevant«

| c) | Afsnit 3.4, krav TCS_29, affattes således:


  »TCS_29 | Statusordene SW1 SW2 tilbagemeldes sammen med enhver svarmeddelelse og angiver behandlingsstatus for kommandoen.


  SW1 | SW2 | Betydning |
| --- | --- | --- | --- | --- |
| 90 | 00 | Normal behandling af data. |
| 61 | XX | Normal behandling af data. XX = antal svarbytes til rådighed |
| 62 | 81 | Advarselsbehandling. En del af svardata kan være beskadiget |
| 63 | 00 | Ægthedsbekræftelse mislykkedes (advarsel) |
| 63 | CX | Forkert CHV (kortindehaververifikation, PIN). Indholdet i tæller for resterende forsøg tilbagemeldes med »X« |
| 64 | 00 | Kørselsfejl — Status for ikke-flygtigt lager uændret. Integritetsfejl. |
| 65 | 00 | Kørselsfejl — Status for ikke-flygtigt lager ændret. |
| 65 | 81 | Kørselsfejl — Status for ikke-flygtigt lager ændret. Hukommelsesfejl |
| 66 | 88 | Sikkerhedsfejl | : | forkert kryptografisk kontrolsum (ved sikker meddelelsesoverførsel) eller
  forkert certifikat (ved verifikation af certifikat) eller
  forkert kryptogram (ved ekstern ægthedsbekræftelse) eller
  forkert underskrift (ved verifikation af underskrift) |

c)

Afsnit 3.4, krav TCS_29, affattes således:

»TCS_29

Statusordene SW1 SW2 tilbagemeldes sammen med enhver svarmeddelelse og angiver behandlingsstatus for kommandoen.

SW1

SW2

Betydning

90

00

Normal behandling af data.

61

XX

Normal behandling af data. XX = antal svarbytes til rådighed

62

81

Advarselsbehandling. En del af svardata kan være beskadiget

63

00

Ægthedsbekræftelse mislykkedes (advarsel)

63

CX

Forkert CHV (kortindehaververifikation, PIN). Indholdet i tæller for resterende forsøg tilbagemeldes med »X«

64

00

Kørselsfejl — Status for ikke-flygtigt lager uændret. Integritetsfejl.

65

00

Kørselsfejl — Status for ikke-flygtigt lager ændret.

65

81

Kørselsfejl — Status for ikke-flygtigt lager ændret. Hukommelsesfejl

66

88

Sikkerhedsfejl

:

forkert kryptografisk kontrolsum (ved sikker meddelelsesoverførsel) eller

forkert certifikat (ved verifikation af certifikat) eller

forkert kryptogram (ved ekstern ægthedsbekræftelse) eller

forkert underskrift (ved verifikation af underskrift)

67

00

Forkert længde (forkert Lc eller Le)

68

83

Sidste kommando i den forventede kæde

69

00

Forbudt kommando (intet svar foreligger i T = 0)

69

82

Sikkerhedsstatus ikke tilfredsstillet

69

83

Ægthedsbekræftelse blokeret

69

85

Betingelser for anvendelse ikke opfyldt

69

86

Kommando ikke tilladt (ingen aktuel elementærfil)

69

87

Forventede dataobjekter for sikker meddelelsesoverførsel mangler

69

88

Ukorrekte dataobjekter for sikker meddelelsesoverførsel

6A

80

Ukorrekte parametre i datafelt

6A

82

Filer ikke fundet

6A

86

Forkerte parametre P1-P2

6A

88

De adresserede data kunne ikke findes

6B

00

Forkerte parametre (adressetillæg uden for elementærfil)

6C

XX

Forkert længde, SW2 angiver eksakt længde. Intet datafelt tilbagemeldes

6D

00

Operationskode ikke understøttet eller ugyldig

6E

00

Klasse ikke understøttet

6F

00

| — | Andre kontrolfejl |
| --- | --- |

—

Andre kontrolfejl

Der kan tilbagemeldes yderligere statusord som defineret i ISO/IEC 7816-4, hvis deres funktion ikke er udtrykkeligt nævnt i dette tillæg.

F.eks. kan følgende statusord eventuelt tilbagemeldes:

6881: Logisk kanal ikke understøttet

6882: Sikker meddelelsesoverførsel ikke understøttet«.

| d) | Afsnit 3.5.1.1, krav TCS_38, sidste led, affattes således:


  »— | Hvis den valgte applikation anses for beskadiget (der er fundet integritetsfejl i filattributterne), tilbagemeldes behandlingsstatus »6400« eller »6500«.« |
| --- | --- | --- |

d)

Afsnit 3.5.1.1, krav TCS_38, sidste led, affattes således:

»—

Hvis den valgte applikation anses for beskadiget (der er fundet integritetsfejl i filattributterne), tilbagemeldes behandlingsstatus »6400« eller »6500«.«

6400

6500

| e) | Afsnit 3.5.1.2, krav TCS_41, sidste led, affattes således:


  »— | Hvis den valgte fil anses for beskadiget (der er fundet integritetsfejl i filattributterne), tilbagemeldes behandlingsstatus »6400« eller »6500«.«. |
| --- | --- | --- |

e)

Afsnit 3.5.1.2, krav TCS_41, sidste led, affattes således:

»—

Hvis den valgte fil anses for beskadiget (der er fundet integritetsfejl i filattributterne), tilbagemeldes behandlingsstatus »6400« eller »6500«.«.

6400

6500

| f) | Afsnit 3.5.2.1, krav TCS_43, sjette led, affattes således:


  »— | Konstateres der en integritetsfejl i filattributterne, skal kortet anse filen for uoprettelig beskadiget, og der tilbagemeldes behandlingsstatus »6400« eller »6500«.« |
| --- | --- | --- |

f)

Afsnit 3.5.2.1, krav TCS_43, sjette led, affattes således:

»—

Konstateres der en integritetsfejl i filattributterne, skal kortet anse filen for uoprettelig beskadiget, og der tilbagemeldes behandlingsstatus »6400« eller »6500«.«

6400

6500

| g) | I afsnit 3.5.2.1.1 foretages følgende ændringer:


  i) | I krav TCS_45 affattes tabellen således:


  »Byte | Længde | Værdi | Beskrivelse |
| --- | --- | --- | --- | --- | --- |
| #1 | 1 | »81h« | TPV: Etiket for data med ordinær værdi |
| #2 | L | »NNh« eller
  »81 NNh« | LPV: længde af tilbagemeldte data (= original Le).
  L er 2 bytes, hvis LPV >127 bytes. |
| #(2+L) - #(1+L+NN) | NN | »XX..XXh« | Ordinær dataværdi |
| #(2+L+NN) | 1 | »99h« | Etiket til behandlingsstatus (SW1-SW2) — valgfri for sikker meddelelsesoverførsel (første generation) |
| #(3+L+NN) | 1 | »02h« | Længde af behandlingsstatus — valgfri for sikker meddelelsesoverførsel (første generation) |
| #(4+L+NN) - #(5+L+NN) | 2 | »XX XXh« | Behandlingsstatus for det ubeskyttede APDU-svar — valgfri for sikker meddelelsesoverførsel (første generation) |
| #(6+L+NN) | 1 | »8Eh« | TCC: Etiket for kryptografisk kontrolsum |
| #(7+L+NN) | 1 | »XXh« | LCC: Længde af efterfølgende kryptografiske kontrolsum | »04h« for sikker meddelelsesoverførsel (første generation) (se tillæg 11, del A) |

g)

I afsnit 3.5.2.1.1 foretages følgende ændringer:

i)

I krav TCS_45 affattes tabellen således:

»Byte

Længde

Værdi

Beskrivelse

# 1

1

»81h«

TPV: Etiket for data med ordinær værdi

PV

# 2

L

»NNh« eller

»81 NNh«

LPV: længde af tilbagemeldte data (= original Le).

PV

L er 2 bytes, hvis LPV >127 bytes.

PV

# (2+L) - #(1+L+NN)

NN

»XX..XXh«

Ordinær dataværdi

# (2+L+NN)

1

»99h«

Etiket til behandlingsstatus (SW1-SW2) — valgfri for sikker meddelelsesoverførsel (første generation)

# (3+L+NN)

1

»02h«

Længde af behandlingsstatus — valgfri for sikker meddelelsesoverførsel (første generation)

# (4+L+NN) - #(5+L+NN)

2

»XX XXh«

Behandlingsstatus for det ubeskyttede APDU-svar — valgfri for sikker meddelelsesoverførsel (første generation)

# (6+L+NN)

1

»8Eh«

TCC: Etiket for kryptografisk kontrolsum

# (7+L+NN)

1

»XXh«

LCC: Længde af efterfølgende kryptografiske kontrolsum

»04h« for sikker meddelelsesoverførsel (første generation) (se tillæg 11, del A)

| | »08h«, »0Ch« eller »10h« afhængigt af AES-nøglelængden for sikker meddelelsesoverførsel (anden generation) (se tillæg 11, del B) |
| --- | --- |

»08h«, »0Ch« eller »10h« afhængigt af AES-nøglelængden for sikker meddelelsesoverførsel (anden generation) (se tillæg 11, del B)

# (8+L+NN)-#(7+M+L+NN)

M

»XX..XXh«

Kryptografisk kontrolsum

SW

2

»XXXXh«

Statusord (SW1, SW2)«

| ii) | I krav TCS_46 affattes tabellen således:


  »Byte | Længde | Værdi | Beskrivelse |
| --- | --- | --- | --- | --- |
| #1 | 1 | »87h« | TPI CG: Etiket for krypterede data (kryptogram) |
| #2 | L | »MMh« eller
  »81 MMh« | LPI CG: Længde af tilbagemeldte krypterede data (afviger pga. udfyldning fra kommandoens oprindelige længde Le).
  L er 2 bytes, hvis LPI CG >127 bytes. |
| #(2+L)-#(1+L+MM) | MM | »01XX..XXh« | Krypterede data: Udfyldningsindikator og kryptogram |
| #(2+L+MM) | 1 | »99h« | Etiket til behandlingsstatus (SW1-SW2) — valgfri for sikker meddelelsesoverførsel (første generation) |
| #(3+L+MM) | 1 | »02h« | Længde af behandlingsstatus — valgfri for sikker meddelelsesoverførsel (første generation) |
| #(4+L+MM) - #(5+L+MM) | 2 | »XX XXh« | Behandlingsstatus for det ubeskyttede APDU-svar — valgfri for sikker meddelelsesoverførsel (første generation) |
| #(6+L+MM) | 1 | »8Eh« | TCC: Etiket for kryptografisk kontrolsum |
| #(7+L+MM) | 1 | »XXh« | LCC: Længde af efterfølgende kryptografiske kontrolsum | »04h« for sikker meddelelsesoverførsel (første generation) (se tillæg 11, del A) |

ii)

I krav TCS_46 affattes tabellen således:

»Byte

Længde

Værdi

Beskrivelse

# 1

1

»87h«

TPI CG: Etiket for krypterede data (kryptogram)

PI CG

# 2

L

»MMh« eller

»81 MMh«

LPI CG: Længde af tilbagemeldte krypterede data (afviger pga. udfyldning fra kommandoens oprindelige længde Le).

PI CG

L er 2 bytes, hvis LPI CG >127 bytes.

# (2+L)-#(1+L+MM)

MM

»01XX..XXh«

Krypterede data: Udfyldningsindikator og kryptogram

# (2+L+MM)

1

»99h«

Etiket til behandlingsstatus (SW1-SW2) — valgfri for sikker meddelelsesoverførsel (første generation)

# (3+L+MM)

1

»02h«

Længde af behandlingsstatus — valgfri for sikker meddelelsesoverførsel (første generation)

# (4+L+MM) - #(5+L+MM)

2

»XX XXh«

Behandlingsstatus for det ubeskyttede APDU-svar — valgfri for sikker meddelelsesoverførsel (første generation)

# (6+L+MM)

1

»8Eh«

TCC: Etiket for kryptografisk kontrolsum

# (7+L+MM)

1

»XXh«

LCC: Længde af efterfølgende kryptografiske kontrolsum

»04h« for sikker meddelelsesoverførsel (første generation) (se tillæg 11, del A)

| | »08h«, »0Ch« eller »10h« afhængigt af AES-nøglelængden for sikker meddelelsesoverførsel (anden generation) (se tillæg 11, del B) |
| --- | --- |

»08h«, »0Ch« eller »10h« afhængigt af AES-nøglelængden for sikker meddelelsesoverførsel (anden generation) (se tillæg 11, del B)

# (8+L+MM)-#(7+N+L+MM)

N

»XX..XXh«

Kryptografisk kontrolsum

SW

2

»XXXXh«

Statusord (SW1, SW2)«

| h) | Afsnit 3.5.2.2, krav TCS_50), sjette led, affattes således:


  »— | Konstateres der en integritetsfejl i filattributterne, skal kortet anse filen for uoprettelig beskadiget, og der tilbagemeldes behandlingsstatus »6400« eller »6500«.« |
| --- | --- | --- |

h)

Afsnit 3.5.2.2, krav TCS_50), sjette led, affattes således:

»—

Konstateres der en integritetsfejl i filattributterne, skal kortet anse filen for uoprettelig beskadiget, og der tilbagemeldes behandlingsstatus »6400« eller »6500«.«

6400

6500

| i) | I afsnit 3.5.2.3, krav TCS_52, foretages følgende ændringer:


  i) | Den sidste række i tabellen affattes således:


  »Le | 1 | »XXh« | Som foreskrevet i ISO/IEC 7816-4« |
| --- | --- | --- | --- | --- | --- |

i)

I afsnit 3.5.2.3, krav TCS_52, foretages følgende ændringer:

i)

Den sidste række i tabellen affattes således:

»Le

1

»XXh«

Som foreskrevet i ISO/IEC 7816-4«

| ii) | Der tilføjes følgende:

  »Hvis T = 0, antager kortet værdien Le = »00h«, hvis der ikke anvendes sikker meddelelsesoverførsel.
  Hvis T = 1, tilbagemeldes behandlingsstatus »6700«, hvis Le=»01h«.« |
| --- | --- |

ii)

Der tilføjes følgende:

»Hvis T = 0, antager kortet værdien Le = »00h«, hvis der ikke anvendes sikker meddelelsesoverførsel.

Hvis T = 1, tilbagemeldes behandlingsstatus »6700«, hvis Le=»01h«.«

| j) | Afsnit 3.5.2.3, krav TCS_53), sjette led, affattes således:


  »— | Konstateres der en integritetsfejl i filattributterne, skal kortet anse filen for uoprettelig beskadiget, og der tilbagemeldes behandlingsstatus »6400« eller »6500«.« |
| --- | --- | --- |

j)

Afsnit 3.5.2.3, krav TCS_53), sjette led, affattes således:

»—

Konstateres der en integritetsfejl i filattributterne, skal kortet anse filen for uoprettelig beskadiget, og der tilbagemeldes behandlingsstatus »6400« eller »6500«.«

6400

6500

| k) | Afsnit 3.5.3.2, krav TCS_63), sjette led, affattes således:


  »— | Konstateres der en integritetsfejl i filattributterne, skal kortet anse filen for uoprettelig beskadiget, og der tilbagemeldes behandlingsstatus »6400« eller »6500«.« |
| --- | --- | --- |

k)

Afsnit 3.5.3.2, krav TCS_63), sjette led, affattes således:

»—

Konstateres der en integritetsfejl i filattributterne, skal kortet anse filen for uoprettelig beskadiget, og der tilbagemeldes behandlingsstatus »6400« eller »6500«.«

6400

6500

| l) | Afsnit 3.5.5, krav TCS_72, affattes således:


  »TCS_72 | Den PIN, der er indlæst af brugeren, skal af kortlæseren være ASCII-kodet og udfyldt mod højre med »FFh«-bytes til en længde af 8 bytes. Se også datatypen WorkshopCardPIN i tillæg 1.« |
| --- | --- | --- |

l)

Afsnit 3.5.5, krav TCS_72, affattes således:

»TCS_72

Den PIN, der er indlæst af brugeren, skal af kortlæseren være ASCII-kodet og udfyldt mod højre med »FFh«-bytes til en længde af 8 bytes. Se også datatypen WorkshopCardPIN i tillæg 1.«

| m) | Afsnit 3.5.8, krav TCS_95, affattes således:


  »TCS_95 | Hvis INTERNAL AUTHENTICATE-kommandoen giver resultat, slettes den eventuelle aktuelle nøgle af første generation for sessionen, og er ikke længere til rådighed. For at man kan få adgang til en ny sessionsnøgle for første generation, skal kommandoen EXTERNAL AUTHENTICATE for mekanismen til ægthedsbekræftelse for første generation gennemføres med resultat.


  Bemærk: | For sessionsnøgler af anden generation henvises til tillæg 11, krav CSM_193 og CSM_195. Hvis der oprettes sessionsnøgler for anden generation, og takografkortet modtager den ordinære INTERNAL AUTHENTICATE-kommando APDU, afbryder det den sikre meddelelsesoverførsel for anden generation og destruerer sessionsnøglerne for anden generation.« |
| --- | --- | --- | --- |

m)

Afsnit 3.5.8, krav TCS_95, affattes således:

»TCS_95

Hvis INTERNAL AUTHENTICATE-kommandoen giver resultat, slettes den eventuelle aktuelle nøgle af første generation for sessionen, og er ikke længere til rådighed. For at man kan få adgang til en ny sessionsnøgle for første generation, skal kommandoen EXTERNAL AUTHENTICATE for mekanismen til ægthedsbekræftelse for første generation gennemføres med resultat.

Bemærk:

Bemærk:

For sessionsnøgler af anden generation henvises til tillæg 11, krav CSM_193 og CSM_195. Hvis der oprettes sessionsnøgler for anden generation, og takografkortet modtager den ordinære INTERNAL AUTHENTICATE-kommando APDU, afbryder det den sikre meddelelsesoverførsel for anden generation og destruerer sessionsnøglerne for anden generation.«

| n) | Afsnit 3.5.9, krav TCS_97, affattes således:


  »TCS_97 | Kommandovarianten for gensidig ægthedsbekræftelse for anden generation på køretøjsenhedens kort kan udføres i hovedfilen, DF Tachograph og DF Tachograph_G2. Se også TCS_34. Hvis INTERNAL AUTHENTICATE-kommandoen for anden generation giver resultat, slettes den eventuelle aktuelle nøgle af første generation for sessionen, og er ikke længere til rådighed.


  Bemærk: | For sessionsnøgler af anden generation henvises til tillæg 11, krav CSM_193 og CSM_195. Hvis der oprettes sessionsnøgler for anden generation, og takografkortet modtager den ordinære EXTERNAL AUTHENTICATE-kommando APDU, afbryder det den sikre meddelelsesoverførsel for anden generation og destruerer sessionsnøglerne for anden generation.« |
| --- | --- | --- | --- |

n)

Afsnit 3.5.9, krav TCS_97, affattes således:

»TCS_97

Kommandovarianten for gensidig ægthedsbekræftelse for anden generation på køretøjsenhedens kort kan udføres i hovedfilen, DF Tachograph og DF Tachograph_G2. Se også TCS_34. Hvis INTERNAL AUTHENTICATE-kommandoen for anden generation giver resultat, slettes den eventuelle aktuelle nøgle af første generation for sessionen, og er ikke længere til rådighed.

Bemærk:

Bemærk:

For sessionsnøgler af anden generation henvises til tillæg 11, krav CSM_193 og CSM_195. Hvis der oprettes sessionsnøgler for anden generation, og takografkortet modtager den ordinære EXTERNAL AUTHENTICATE-kommando APDU, afbryder det den sikre meddelelsesoverførsel for anden generation og destruerer sessionsnøglerne for anden generation.«

| o) | I afsnit 3.5.10 tilføjes følgende række til tabellen i krav TCS_101:


  »5 + L + 1 | 1 | »00h« | Som foreskrevet i ISO/IEC 7816-4« |
| --- | --- | --- | --- | --- |

o)

I afsnit 3.5.10 tilføjes følgende række til tabellen i krav TCS_101:

»5 + L + 1

1

»00h«

Som foreskrevet i ISO/IEC 7816-4«

| p) | I afsnit 3.5.11.2.3 tilføjes følgende i krav TCS_114:


  »— | Hvis kortets currentAuthenticatedTime ligger senere end udløbsdatoen for den valgte offentlige nøgle, tilbagemeldes behandlingsstatus
  »6A88«
  . |
| --- | --- | --- |

p)

I afsnit 3.5.11.2.3 tilføjes følgende i krav TCS_114:

»—

Hvis kortets currentAuthenticatedTime ligger senere end udløbsdatoen for den valgte offentlige nøgle, tilbagemeldes behandlingsstatus
  »6A88«
  .

»6A88«

| Bemærk: | For kommandoen MSE: SET AT til ægthedsbekræftelse af køretøjsenheden er den nøgle, der henvises til, en offentlig VU_MA-nøgle. Kortet indstiller den offentlige VU_MA-nøgle, der skal anvendes, hvis den findes i hukommelsen, og som modsvarer den henvisning til certifikatindehaveren (Certificate Holder Reference - CHR), der er givet i kommandoens datafelt (kortet kan identificere offentlige VU_MA-nøgler ved hjælp af certifikatets CHA-felt). Kortet skal tilbagemelde »6A 88« på denne kommando, hvis kun den offentlige VU_Sign-nøgle eller ingen offentlig nøgle for køretøjsenheden er til rådighed. Se definitionen af CHA-feltet i tillæg 11 og af datatypen Equipment Type i tillæg 1. |
| --- | --- |

Bemærk:

Bemærk:

For kommandoen MSE: SET AT til ægthedsbekræftelse af køretøjsenheden er den nøgle, der henvises til, en offentlig VU_MA-nøgle. Kortet indstiller den offentlige VU_MA-nøgle, der skal anvendes, hvis den findes i hukommelsen, og som modsvarer den henvisning til certifikatindehaveren (Certificate Holder Reference - CHR), der er givet i kommandoens datafelt (kortet kan identificere offentlige VU_MA-nøgler ved hjælp af certifikatets CHA-felt). Kortet skal tilbagemelde »6A 88« på denne kommando, hvis kun den offentlige VU_Sign-nøgle eller ingen offentlig nøgle for køretøjsenheden er til rådighed. Se definitionen af CHA-feltet i tillæg 11 og af datatypen Equipment Type i tillæg 1.

Ligeledes hvis en MSE: SET DST-kommando, som henviser til et EQT (dvs. en køretøjsenhed eller et kort), sendes til et kontrolkort, jf. krav CSM_234, er den nøgle, der henvises til, altid en EQT_Sign-nøgle, som skal anvendes til verifikation af en digital underskrift. Ifølge Figur 13 i tillæg 11 vil kontrolkortet altid have lagret den relevante offentlige EQT_Sign-nøgle. I visse tilfælde kan kontrolkortet have lagret den modsvarende offentlige EQT_MA-nøgle. Kontrolkortet skal altid indstille den offentlige EQT_Sign-nøgle til anvendelse, når det modtager en MSE: SET DST-kommando.«

| q) | I afsnit 3.5.13 foretages følgende ændringer:


  i) | Krav TCS_121 affattes således:


  »TCS_121 | Den midlertidigt gemte Hash of File-værdi skal slettes, hvis en ny Hash of File-værdi beregnes ved hjælp af kommandoen PERFORM HASH of FILE, hvis en dedikeret fil vælges, og hvis takografkortet nulstilles.« |
| --- | --- | --- | --- |

q)

I afsnit 3.5.13 foretages følgende ændringer:

i)

Krav TCS_121 affattes således:

»TCS_121

Den midlertidigt gemte Hash of File-værdi skal slettes, hvis en ny Hash of File-værdi beregnes ved hjælp af kommandoen PERFORM HASH of FILE, hvis en dedikeret fil vælges, og hvis takografkortet nulstilles.«

| ii) | Krav TCS_123 affattes således:


  »TCS_123 | Takografapplikationer af anden generation skal understøtte SHA-2-algoritmen (dvs. SHA-256, SHA-384 eller SHA-512) angivet ved krypteringsprogrammerne i tillæg 11, del B for kortets underskriftsnøgle Card_Sign.« |
| --- | --- | --- |

ii)

Krav TCS_123 affattes således:

»TCS_123

Takografapplikationer af anden generation skal understøtte SHA-2-algoritmen (dvs. SHA-256, SHA-384 eller SHA-512) angivet ved krypteringsprogrammerne i tillæg 11, del B for kortets underskriftsnøgle Card_Sign.«

| iii) | Tabellen i krav TCS_124 affattes således:


  »Byte | Længde | Værdi | Beskrivelse |
| --- | --- | --- | --- | --- |
| CLA | 1 | »80h« | CLA |
| INS | 1 | »2Ah« | Udfør sikkerhedsoperation |
| P1 | 1 | »90h« | Etiket: Hash |
| P2 | 1 | »00h« | Algoritmen kendes implicit
  For takografapplikationer af første generation: SHA-1
  For takografapplikationer af anden generation: SHA-2-algoritmen (SHA-256, SHA-384 eller SHA-512), angivet ved krypteringsprogrammerne i tillæg 11, del B for kortets underskriftsnøgle Card_Sign.« |

iii)

Tabellen i krav TCS_124 affattes således:

»Byte

Længde

Værdi

Beskrivelse

CLA

1

»80h«

CLA

INS

1

»2Ah«

Udfør sikkerhedsoperation

P1

1

»90h«

Etiket: Hash

P2

1

»00h«

Algoritmen kendes implicit

For takografapplikationer af første generation: SHA-1

For takografapplikationer af anden generation: SHA-2-algoritmen (SHA-256, SHA-384 eller SHA-512), angivet ved krypteringsprogrammerne i tillæg 11, del B for kortets underskriftsnøgle Card_Sign.«

| r) | I afsnit 3.5.14 foretages følgende ændringer:
  Teksten under overskriften og frem til krav TCS_126 affattes således:

  »Denne kommando anvendes til at beregne den digitale underskrift af en tidligere beregnet hashkode (se PERFORM HASH OF FILE, afsnit 3.5.13).
  Kun førerkortet og værkstedskortet kræves for at understøtte denne kommando i DF Tachograph og DF Tachograph_G2.
  Andre slags takografkort kan eventuelt udføre denne kommando. Ved takografapplikationer af anden generation er det kun førerkortet og værkstedskortet, som har en underskriftsnøgle af anden generation, andre kort kan ikke udføre kommandoen med resultat, men skal afsluttes med en passende fejlkode.
  Kommandoen kan eventuelt være tilgængelig i hovedfilen. Hvis kommandoen ikke er tilgængelig i hovedfilen, skal den afsluttes med en passende fejlkode.
  Denne kommando er i overensstemmelse med ISO/IEC 7816-8. Brugen af denne kommando er begrænset med hensyn til den tilknyttede standard.« |
| --- | --- |

r)

I afsnit 3.5.14 foretages følgende ændringer:

Teksten under overskriften og frem til krav TCS_126 affattes således:

»Denne kommando anvendes til at beregne den digitale underskrift af en tidligere beregnet hashkode (se PERFORM HASH OF FILE, afsnit 3.5.13).

Kun førerkortet og værkstedskortet kræves for at understøtte denne kommando i DF Tachograph og DF Tachograph_G2.

Andre slags takografkort kan eventuelt udføre denne kommando. Ved takografapplikationer af anden generation er det kun førerkortet og værkstedskortet, som har en underskriftsnøgle af anden generation, andre kort kan ikke udføre kommandoen med resultat, men skal afsluttes med en passende fejlkode.

Kommandoen kan eventuelt være tilgængelig i hovedfilen. Hvis kommandoen ikke er tilgængelig i hovedfilen, skal den afsluttes med en passende fejlkode.

Denne kommando er i overensstemmelse med ISO/IEC 7816-8. Brugen af denne kommando er begrænset med hensyn til den tilknyttede standard.«

| s) | I afsnit 3.5.15 foretages følgende ændringer:


  i) | Tabellen i krav TCS_133 affattes således:


  »Byte | Længde | Værdi | Beskrivelse |
| --- | --- | --- | --- | --- | --- |
| CLA | 1 | »00h« | CLA |
| INS | 1 | »2Ah« | Udfør sikkerhedsoperation |
| P1 | 1 | »00h« | |
| P2 | 1 | »A8h« | Etiket: Datafeltet indeholder dataobjekter, der er relevante for verifikation |
| Lc | 1 | »XXh« | Længde Lc af det efterfølgende datafelt |
| #6 | 1 | »9Eh« | Etiket for digital underskrift |
| #7 eller
  #7-#8 | L | »NNh« eller
  »81 NNh« | Længde af digital underskrift (L er 2 bytes, hvis den digitale underskrift er længere end 127 bytes): | 128 bytes kodet i overensstemmelse med tillæg 11, del A, for takografapplikationer af første generation |

s)

I afsnit 3.5.15 foretages følgende ændringer:

i)

Tabellen i krav TCS_133 affattes således:

»Byte

Længde

Værdi

Beskrivelse

CLA

1

»00h«

CLA

INS

1

»2Ah«

Udfør sikkerhedsoperation

P1

1

»00h«

P2

1

»A8h«

Etiket: Datafeltet indeholder dataobjekter, der er relevante for verifikation

Lc

1

»XXh«

Længde Lc af det efterfølgende datafelt

# 6

1

»9Eh«

Etiket for digital underskrift

# 7 eller

# 7-#8

L

»NNh« eller

»81 NNh«

Længde af digital underskrift (L er 2 bytes, hvis den digitale underskrift er længere end 127 bytes):

128 bytes kodet i overensstemmelse med tillæg 11, del A, for takografapplikationer af første generation

| | Afhængigt af den valgte kurve for takografapplikationer af anden generation (se tillæg 11, del B). |
| --- | --- |

Afhængigt af den valgte kurve for takografapplikationer af anden generation (se tillæg 11, del B).

# (7+L)-#(6+L+NN)

NN

»XX..XXh«

Indhold af digital underskrift«

| ii) | I krav TCS_134 indsættes følgende led:


  »— | Hvis den valgte offentlige nøgle (som anvendes til at verificere den digitale underskrift) har en CHA.LSB (CertificateHolderAuthorisation.equipmentType), som ikke egner sig til verificering af digital underskrift i overensstemmelse med tillæg 11, tilbagemeldes status
  »6985«
  .« |
| --- | --- | --- |

ii)

I krav TCS_134 indsættes følgende led:

»—

Hvis den valgte offentlige nøgle (som anvendes til at verificere den digitale underskrift) har en CHA.LSB (CertificateHolderAuthorisation.equipmentType), som ikke egner sig til verificering af digital underskrift i overensstemmelse med tillæg 11, tilbagemeldes status
  »6985«
  .«

»6985«

| t) | I afsnit 3.5.16 foretages følgende ændringer:


  i) | I krav TCS_138 tilføjes følgende række til tabellen:


  »5 + L + 1 | 1 | »00h« | Som foreskrevet i ISO/IEC 7816-4« |
| --- | --- | --- | --- | --- | --- |

t)

I afsnit 3.5.16 foretages følgende ændringer:

i)

I krav TCS_138 tilføjes følgende række til tabellen:

»5 + L + 1

1

»00h«

Som foreskrevet i ISO/IEC 7816-4«

| ii) | I krav TCS_139 indsættes følgende led:


  »— | »6985« indikerer, at tidsstemplet på 4 byte, som fremgår af kommandodatafeltet er tidligeree end cardValidityBegin eller senere end cardExpiryDate.« |
| --- | --- | --- |

ii)

I krav TCS_139 indsættes følgende led:

»—

»6985« indikerer, at tidsstemplet på 4 byte, som fremgår af kommandodatafeltet er tidligeree end cardValidityBegin eller senere end cardExpiryDate.«

6985

| u) | I afsnit 4.2.2 foretages følgende ændringer:


  i) | I datastrukturen i krav TCS_154 affattes linjerne fra DF Tachograph G2 til EF CardMA_Certificate og linjerne fra EF GNSS_Places til slutningen af kravet således:
  »


  Tekst af billedet

  Fil/dataelement
  Antal poster
  Størrelse (bytes)
  Standard- værdier
  Min
  Max

  « |
| --- | --- | --- |

u)

I afsnit 4.2.2 foretages følgende ændringer:

i)

I datastrukturen i krav TCS_154 affattes linjerne fra DF Tachograph G2 til EF CardMA_Certificate og linjerne fra EF GNSS_Places til slutningen af kravet således:

Fil/dataelement

Antal poster

Størrelse (bytes)

Standard- værdier

Min

Max

| ii) | I krav TCS_155 affattes posten


  i tabellen således:


  » | | 252 | 336« |
| --- | --- | --- | --- | --- |

ii)

Image 27

Image 28

Image 29

252

336«

| v) | I afsnit 4.3.1, krav TCS_156, affattes teksten til forkortelsen SC4 således:


  »SC4 | For kommandoen READ BINARY med lige INS-byte:
  (SM-C-MAC-G1 AND SM-R-ENC-MAC-G1) OR
  (SM-C-MAC-G2 AND SM-R-ENC-MAC-G2)
  For kommandoen READ BINARY med ulige INS-byte (hvis den understøttes): NEV« |
| --- | --- | --- |

v)

I afsnit 4.3.1, krav TCS_156, affattes teksten til forkortelsen SC4 således:

»SC4

SC4

For kommandoen READ BINARY med lige INS-byte:

(SM-C-MAC-G1 AND SM-R-ENC-MAC-G1) OR

(SM-C-MAC-G2 AND SM-R-ENC-MAC-G2)

For kommandoen READ BINARY med ulige INS-byte (hvis den understøttes): NEV«

| w) | I afsnit 4.3.2 foretages følgende ændringer:


  i) | I datastrukturen i krav TCS_162 affattes linjerne fra DF Tachograph G2 til EF CardMA_Certificate, linjerne fra EF Calibration til extendedSealIdentifier og linjerne fra EF GNSS_Places til vehicleOdometerValue således:
  »


  Tekst af billedet

  Fil/dataelement
  Antal poster
  Størrelse (bytes)
  Standard- værdier
  Min
  Max


  « |
| --- | --- | --- |

w)

I afsnit 4.3.2 foretages følgende ændringer:

i)

I datastrukturen i krav TCS_162 affattes linjerne fra DF Tachograph G2 til EF CardMA_Certificate, linjerne fra EF Calibration til extendedSealIdentifier og linjerne fra EF GNSS_Places til vehicleOdometerValue således:

Fil/dataelement

Antal poster

Størrelse (bytes)

Standard- værdier

Min

Max

| ii) | Posten NoOfGNSSCDRecords i tabellen i krav TCS_163 affattes således:


  » | | 18 | 24« |
| --- | --- | --- | --- | --- |

ii)

Posten NoOfGNSSCDRecords i tabellen i krav TCS_163 affattes således:

Image 32

Image 33

18

24«

| 31) | I tillæg 3, afsnit 2, foretages følgende ændringer:


  a) | Følgende linje indsættes efter linjen med piktogrammerne for »Sted, hvor den daglige arbejdstid begynder« og »Sted, hvor den daglige arbejdstid slutter«:

  »


  Position efter tre timers kumuleret køretid«. |
| --- | --- | --- |

31)

I tillæg 3, afsnit 2, foretages følgende ændringer:

a)

Følgende linje indsættes efter linjen med piktogrammerne for »Sted, hvor den daglige arbejdstid begynder« og »Sted, hvor den daglige arbejdstid slutter«:

»

  Image 34
  Position efter tre timers kumuleret køretid«.

| b) | Piktogramkombinationen for »Justering af klokkeslæt (foretaget af værksted)« erstattes af:

  »


  Tidskonflikt eller justering af klokkeslæt (foretaget af værksted)«. |
| --- | --- |

b)

Piktogramkombinationen for »Justering af klokkeslæt (foretaget af værksted)« erstattes af:

»

  Image 35
  Tidskonflikt eller justering af klokkeslæt (foretaget af værksted)«.

| c) | Følgende piktogramkombinationer tilføjes til listen over begivenheder:

  »


  Manglende positionsoplysninger fra GNSS-modtager eller Fejl ved kommunikation med det eksterne GNSS-udstyr


  Fejl ved kommunikation med udstyr til fjernkommunikation«. |
| --- | --- |

c)

Følgende piktogramkombinationer tilføjes til listen over begivenheder:

»

  Image 36
  Manglende positionsoplysninger fra GNSS-modtager eller Fejl ved kommunikation med det eksterne GNSS-udstyr

Image 37
  Fejl ved kommunikation med udstyr til fjernkommunikation«.

| 32) | I tillæg 4 foretages følgende ændringer:


  a) | I afsnit 2 foretages følgende ændringer:


  i) | Blok 11.4 affattes således:


  »11.4 | Indlæsning af sted, hvor daglig arbejdstid begynder og/eller slutter |
| --- | --- | --- | --- | --- |
| pi = piktogram for sted begynder/slutter, tidspunkt, land, region
  længdegrad for registreret position
  breddegrad for registreret position
  tidsstempel for bestemmelse af position
  Kilometertæller | pihh:mm Cou Reg
  lon ±DDDoMM.M’
  lat ± DDoMM.M’
  hh:mm
  x xxx xxx km« |

32)

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

a)

I afsnit 2 foretages følgende ændringer:

i)

Blok 11.4 affattes således:

»11.4

Indlæsning af sted, hvor daglig arbejdstid begynder og/eller slutter

Indlæsning af sted, hvor daglig arbejdstid begynder og/eller slutter

pi = piktogram for sted begynder/slutter, tidspunkt, land, region

længdegrad for registreret position

breddegrad for registreret position

tidsstempel for bestemmelse af position

Kilometertæller

pihh:mm Cou Reg

lon ±DDDoMM.M’

o

lat ± DDoMM.M’

o

hh:mm

x xxx xxx km«

km

| ii) | Blok 11.5 affattes således:


  »11.5 | Position efter tre timers kumuleret køretid

  Position efter tre timers kumuleret køretid |
| --- | --- | --- |
| tidspunkt
  længdegrad for registreret position
  breddegrad for registreret position
  tidsstempel for bestemmelse af position
  Kilometertæller | « |

ii)

Blok 11.5 affattes således:

»11.5

Position efter tre timers kumuleret køretid

Position efter tre timers kumuleret køretid

Position efter tre timers kumuleret køretid

tidspunkt

længdegrad for registreret position

breddegrad for registreret position

tidsstempel for bestemmelse af position

Kilometertæller

Image 38

| b) | Afsnit 3.1, nr. 11.5 i den daglige udskrift, affattes således:


  »11.5 | Position efter tre timers kumuleret køretid i kronologisk rækkefølge«. |
| --- | --- | --- |

b)

Afsnit 3.1, nr. 11.5 i den daglige udskrift, affattes således:

»11.5

Position efter tre timers kumuleret køretid i kronologisk rækkefølge«.

| c) | Afsnit 3.2, den daglige udskrift, affattes således:


  »1 | Dato og tidspunkt for udskrivning af dokumentet |
| --- | --- | --- |
| 2 | Udskriftens art |
| 3 | Identifikation af kortindehaver (for alle kort isat i køretøjsenhed + GEN) |
| 4 | Identifikation af køretøj (det køretøj, hvorfra udskriften tages) |
| 5 | Identifikation af køretøjsenhed (den køretøjsenhed, hvorfra udskriften tages + GEN) |
| 6 | Seneste kalibrering af denne køretøjsenhed |
| 7 | Seneste kontrol på denne takograf |
| 9 | Skilletegn for føreraktiviteter |
| 10 | Skilletegn for førerkortplads (kortplads 1) |
| 10a | Betingelsen »uden for gyldighedsområde« ved den aktuelle dags begyndelse |
| 10.1 / 10.2 / 10.3 / 10.3a / 10.4 | Aktiviteter i kronologisk rækkefølge (førerkortplads) |
| 10 | Skilletegn for medchaufførens kortplads (kortplads 2) |
| 10a | Betingelsen »uden for gyldighedsområde« ved den aktuelle dags begyndelse |
| 10.1 / 10.2 / 10.3 / 10.3a / 10.4 | Aktiviteter i kronologisk rækkefølge (medchaufførens kortplads) |
| 11 | Skilletegn for døgnoversigt |
| 11.1 | Oversigt over perioder uden kort i førerens kortplads |
| 11.4 | Indlæste steder i kronologisk rækkefølge |
| 11.5 | Position efter tre timers kumuleret køretid i kronologisk rækkefølge |
| 11.7 | Aktiviteter, i alt |
| 11.2 | Oversigt over perioder uden kort i medchaufførens kortplads |
| 11.4 | Indlæste steder i kronologisk rækkefølge |
| 11.5 | Position efter tre timers kumuleret køretid i kronologisk rækkefølge |
| 11.8 | Aktiviteter, i alt |
| 11.3 | Oversigt over føreraktiviteter, begge kortpladser medregnet |
| | 11.4 | | Steder indlæst af denne fører i kronologisk rækkefølge |
| | 11.5 | | Position efter tre timers kumuleret køretid i kronologisk rækkefølge |
| 11.9 | Aktiviteter i alt for denne fører |
| 13.1 | Skilletegn for hændelser/fejl |
| 13.4 | Poster med hændelser/fejl (seneste fem hændelser eller fejl, som er gemt eller igangværende på køretøjsenheden) |
| 22.1 | Kontrolsted |
| 22.2 | Den tilsynsførendes underskrift |
| 22.3 | Fra tidspunkt (plads til rådighed for en fører uden kort til angivelse af de relevante perioder) |
| 22.4 | Til tidspunkt |
| 22.5 | Førerens underskrift« |

c)

Afsnit 3.2, den daglige udskrift, affattes således:

»1

Dato og tidspunkt for udskrivning af dokumentet

2

Udskriftens art

3

Identifikation af kortindehaver (for alle kort isat i køretøjsenhed + GEN)

4

Identifikation af køretøj (det køretøj, hvorfra udskriften tages)

5

Identifikation af køretøjsenhed (den køretøjsenhed, hvorfra udskriften tages + GEN)

6

Seneste kalibrering af denne køretøjsenhed

7

Seneste kontrol på denne takograf

9

Skilletegn for føreraktiviteter

10

Skilletegn for førerkortplads (kortplads 1)

10a

Betingelsen »uden for gyldighedsområde« ved den aktuelle dags begyndelse

10.1 / 10.2 / 10.3 / 10.3a / 10.4

Aktiviteter i kronologisk rækkefølge (førerkortplads)

10

Skilletegn for medchaufførens kortplads (kortplads 2)

10a

Betingelsen »uden for gyldighedsområde« ved den aktuelle dags begyndelse

10.1 / 10.2 / 10.3 / 10.3a / 10.4

Aktiviteter i kronologisk rækkefølge (medchaufførens kortplads)

11

Skilletegn for døgnoversigt

11.1

Oversigt over perioder uden kort i førerens kortplads

11.4

Indlæste steder i kronologisk rækkefølge

11.5

Position efter tre timers kumuleret køretid i kronologisk rækkefølge

11.7

Aktiviteter, i alt

11.2

Oversigt over perioder uden kort i medchaufførens kortplads

11.4

Indlæste steder i kronologisk rækkefølge

11.5

Position efter tre timers kumuleret køretid i kronologisk rækkefølge

11.8

Aktiviteter, i alt

11.3

Oversigt over føreraktiviteter, begge kortpladser medregnet

11.4

Steder indlæst af denne fører i kronologisk rækkefølge

11.5

Position efter tre timers kumuleret køretid i kronologisk rækkefølge

11.9

Aktiviteter i alt for denne fører

13.1

Skilletegn for hændelser/fejl

13.4

Poster med hændelser/fejl (seneste fem hændelser eller fejl, som er gemt eller igangværende på køretøjsenheden)

22.1

Kontrolsted

22.2

Den tilsynsførendes underskrift

22.3

Fra tidspunkt (plads til rådighed for en fører uden kort til angivelse af de relevante perioder)

22.4

Til tidspunkt

22.5

Førerens underskrift«

| d) | Afsnit 3.7, krav PRT_014, affattes således:


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


  1 | Dato og tidspunkt for udskrivning af dokumentet |
| --- | --- | --- | --- |
| 2 | Udskriftens art |
| 3 | Identifikation af kortindehaver (for alle kort isat i køretøjsenheden) |
| 23 | Seneste kort, som er isat køretøjsenheden |
| 23.1 | Isatte kort (op til 88 poster) |
| 12.3 | Skilletegn for fejl« |

d)

Afsnit 3.7, krav PRT_014, affattes således:

»PRT_014

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

1

Dato og tidspunkt for udskrivning af dokumentet

2

Udskriftens art

3

Identifikation af kortindehaver (for alle kort isat i køretøjsenheden)

23

Seneste kort, som er isat køretøjsenheden

23.1

Isatte kort (op til 88 poster)

12.3

Skilletegn for fejl«

| 33) | I tillæg 7 foretages følgende ændringer:


  a) | Afsnit 1.1 affattes således:
  »1.1.   Anvendelsesområde

  Der kan overføres data til et eksternt lagermedium:


  — | fra en køretøjsenhed med en intelligent dedikeret enhed (IDE) tilsluttet køretøjsenheden |
| --- | --- | --- | --- |

33)

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

a)

Afsnit 1.1 affattes således:

»1.1.   Anvendelsesområde

Anvendelsesområde

Der kan overføres data til et eksternt lagermedium:

—

fra en køretøjsenhed med en intelligent dedikeret enhed (IDE) tilsluttet køretøjsenheden

| — | fra et takografkort med en IDE-enhed med kortlæser (IFD) |
| --- | --- |

—

fra et takografkort med en IDE-enhed med kortlæser (IFD)

| — | fra et takografkort via en køretøjsenhed ved hjælp af en IDE-enhed tilsluttet køretøjsenheden. |
| --- | --- |

—

fra et takografkort via en køretøjsenhed ved hjælp af en IDE-enhed tilsluttet køretøjsenheden.

For at man skal kunne fastslå ægthed og integritet af overførte data, som er gemt på et eksternt lagermedium, bliver der ved dataoverførsel vedhæftet en underskrift i overensstemmelse med tillæg 11 (fælles sikkerhedsmekanismer). Kildeenhedens (køretøjsenhed eller kort) identifikation og sikkerhedsattester (fra medlemsstaten og for udstyret) bliver ligeledes overført. Den, der kontrollerer data, skal uafhængigt være indehaver af en betroet europæisk offentlig nøgle.

Data, der overføres fra en køretøjsenhed, underskrives i henhold til tillæg 11 Fælles sikkerhedsmekanismer, del B (takografsystemer af anden generation), undtagen når førerkontrollen udføres af en kontrolmyndighed uden for EU under anvendelse af et kontrolkort af første generation, idet data så underskrives i henhold til tillæg 11 Fælles sikkerhedsmekanismer, del A (takografsystemer af første generation), jf. tillæg 15 Migration, krav MIG_15.

I dette tillæg beskrives derfor to typer data, der kan overføres fra køretøjsenheden:

| — | Overførsel af køretøjsenhedsdata af anden generation med datastruktur af anden generation, som underskrives i henhold til tillæg 11 Fælles sikkerhedsmekanismer, del B |
| --- | --- |

—

Overførsel af køretøjsenhedsdata af anden generation med datastruktur af anden generation, som underskrives i henhold til tillæg 11 Fælles sikkerhedsmekanismer, del B

| — | Overførsel af køretøjsenhedsdata af første generation med datastruktur af første generation, som underskrives i henhold til tillæg 11 Fælles sikkerhedsmekanismer, del A. |
| --- | --- |

—

Overførsel af køretøjsenhedsdata af første generation med datastruktur af første generation, som underskrives i henhold til tillæg 11 Fælles sikkerhedsmekanismer, del A.

Ligeledes er der to typer dataoverførsel fra førerkort af anden generation, der er isat en køretøjsenhed, jf. dette tillægs afsnit 3 og 4.«

| b) | I afsnit 2.2.2 foretages følgende ændringer:


  i) | Tabellen affattes således:


  »Meddelelsesstruktur | Maks. 4 bytes Hoved | Maks. 255 bytes Data | 1 byte Kontrolsum |
| --- | --- | --- | --- | --- | --- |
| 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 | |
| Overview | 80 | EE | F0 | 02 | 36 | 01 eller 21 | | 97 |
| Activities | 80 | EE | F0 | 06 | 36 | 02 eller 22 | Date | CS |
| Events & Faults | 80 | EE | F0 | 02 | 36 | 03 eller 23 | Date | 99 |
| Detailed Speed | 80 | EE | F0 | 02 | 36 | 04 eller 24 | Date | 9 A |
| Technical Data | 80 | EE | F0 | 02 | 36 | 05 eller 25 | Date | 9 B |
| Card download | 80 | EE | F0 | 02 | 36 | 06 | Slot | CS |
| Positive Response Transfer Data | 80 | F0 | EE | Len | 76 | TREP | Data | CS |
| Request Transfer Exit | 80 | EE | F0 | 01 | 37 | | | 96 |
| Positive Response Request Transfer Exit | 80 | F0 | EE | 01 | 77 | | | D6 |
| Stop Communication Request | 80 | EE | F0 | 01 | 82 | | | E1 |
| Positive Response Stop Communication | 80 | F0 | EE | 01 | C2 | | | 21 |
| Acknowledge sub message | 80 | EE | F0 | Len | 83 | | Data | CS |
| Negative responses | |
| General reject | 80 | F0 | EE | 03 | 7F | Sid Req | 10 | CS |
| Service not supported | 80 | F0 | EE | 03 | 7F | Sid Req | 11 | CS |
| Sub function not supported | 80 | F0 | EE | 03 | 7F | Sid Req | 12 | CS |
| Incorrect Message Length | 80 | F0 | EE | 03 | 7F | Sid Req | 13 | CS |
| Conditions not correct or Request sequence error | 80 | F0 | EE | 03 | 7F | Sid Req | 22 | CS |
| Request out of range | 80 | F0 | EE | 03 | 7F | Sid Req | 31 | CS |
| Upload not accepted | 80 | F0 | EE | 03 | 7F | Sid Req | 50 | CS |
| Response pending | 80 | F0 | EE | 03 | 7F | Sid Req | 78 | CS |
| Data not available | 80 | F0 | EE | 03 | 7F | Sid Req | FA | CS« |

b)

I afsnit 2.2.2 foretages følgende ændringer:

i)

Tabellen affattes således:

»Meddelelsesstruktur

Maks. 4 bytes Hoved

Maks. 255 bytes Data

1 byte Kontrolsum

IDE ->

IDE ->

<- VU

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

Overview

80

EE

F0

02

36

01 eller 21

97

Activities

80

EE

F0

06

36

02 eller 22

Date

CS

Events & Faults

80

EE

F0

02

36

03 eller 23

Date

99

Detailed Speed

80

EE

F0

02

36

04 eller 24

Date

9 A

Technical Data

80

EE

F0

02

36

05 eller 25

Date

9 B

Card download

80

EE

F0

02

36

06

Slot

CS

Positive Response Transfer Data

80

F0

EE

Len

76

TREP

Data

CS

Request Transfer Exit

80

EE

F0

01

37

96

Positive Response Request Transfer Exit

80

F0

EE

01

77

D6

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«

| ii) | Følgende led tilføjes til bemærkningerne efter tabellen:


  »— | TRTP 21 til 25 anvendes til anmodninger om overførsel af køretøjsenhedsdata af anden generation, TRTP 01 til 05 anvendes til anmodninger om overførsel af køretøjsenhedsdata af første generation, som kun kan accepteres af køretøjsenheden i forbindelse med førerkontrol, som udføres af en kontrolmyndighed uden for EU under anvendelse af et kontrolkort af første generation |
| --- | --- | --- |

ii)

Følgende led tilføjes til bemærkningerne efter tabellen:

»—

TRTP 21 til 25 anvendes til anmodninger om overførsel af køretøjsenhedsdata af anden generation, TRTP 01 til 05 anvendes til anmodninger om overførsel af køretøjsenhedsdata af første generation, som kun kan accepteres af køretøjsenheden i forbindelse med førerkontrol, som udføres af en kontrolmyndighed uden for EU under anvendelse af et kontrolkort af første generation

| — | TRTP 11 til 19 og 31 til 39 er reserveret til fabrikantspecifikke overførselsanmodninger.« |
| --- | --- |

—

TRTP 11 til 19 og 31 til 39 er reserveret til fabrikantspecifikke overførselsanmodninger.«

| c) | I afsnit 2.2.2.9 foretages følgende ændringer:


  i) | Krav DDP_011 affattes således:


  »DDP_011 | Transfer Data Request sendes af IDE-enheden for over for køretøjsenheden at specificere den type data, som skal overføres. Overførslens type angives af en parameter for anmodning om dataoverførsel (TRTP) på én byte.
  Der er seks typer 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 |
| --- | --- | --- | --- | --- | --- |
| Oversigt | 01 | 21 |
| Aktiviteter på en nærmere angivet dato | 02 | 22 |
| Hændelser og fejl | 03 | 23 |
| Detaljeret hastighed | 04 | 24 |
| Tekniske data | 05 | 25 |

c)

I afsnit 2.2.2.9 foretages følgende ændringer:

i)

Krav DDP_011 affattes således:

»DDP_011

Transfer Data Request sendes af IDE-enheden for over for køretøjsenheden at specificere den type data, som skal overføres. Overførslens type angives af en parameter for anmodning om dataoverførsel (TRTP) på én byte.

Der er seks typer 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

Oversigt

01

21

Aktiviteter på en nærmere angivet dato

02

22

Hændelser og fejl

03

23

Detaljeret hastighed

04

24

Tekniske data

05

25

| Dataoverførselstype | TRTP-værdi |
| --- | --- |
| Overførsel af data fra kort | 06« |

Dataoverførselstype

TRTP-værdi

Overførsel af data fra kort

06«

| ii) | Krav DDP_054 affattes således:


  »DDP_054 | IDE-enheden skal obligatorisk anmode om oversigt over dataoverførsel (TRTP 01 eller 21) 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 andet tilfælde (TRTP 02 eller 22) er det i meddelelsen overfør data angivet, hvilken kalenderdag (


-format) der skal overføres.« |
| --- | --- | --- |

ii)

Krav DDP_054 affattes således:

»DDP_054

IDE-enheden skal obligatorisk anmode om oversigt over dataoverførsel (TRTP 01 eller 21) 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 andet tilfælde (TRTP 02 eller 22) er det i meddelelsen overfør data angivet, hvilken kalenderdag (

  Image 39

-format) der skal overføres.«

| d) | Afsnit 2.2.2.10, krav DDP_055, affattes således:


  »DDP_055 | I første tilfælde (TREP 01 eller 21) 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:


  — | sikkerhedscertifikater |
| --- | --- | --- | --- |

d)

Afsnit 2.2.2.10, krav DDP_055, affattes således:

»DDP_055

I første tilfælde (TREP 01 eller 21) 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:

—

sikkerhedscertifikater

| — | identifikation af køretøjer |
| --- | --- |

—

identifikation af køretøjer

| — | køretøjsenhedens aktuelle dato og klokkeslæt |
| --- | --- |

—

køretøjsenhedens aktuelle dato og klokkeslæt

| — | mindste og største dato, som kan overføres (data fra køretøjsenhed) |
| --- | --- |

—

mindste og største dato, som kan overføres (data fra køretøjsenhed)

| — | angivelse af kort, som er isat i køretøjsenheden |
| --- | --- |

—

angivelse af kort, som er isat i køretøjsenheden

| — | tidligere dataoverførsler til en virksomhed |
| --- | --- |

—

tidligere dataoverførsler til en virksomhed

| — | virksomhedslåse |
| --- | --- |

—

virksomhedslåse

| — | tidligere kontroller.« |
| --- | --- |

—

tidligere kontroller.«

| e) | Afsnit 2.2.2.16, krav DDP_018, sidste led, affattes således:


  »— | FA-data foreligger ikke
  Dataobjektet for en anmodning om dataoverførsel findes ikke i køretøjsenheden (f.eks. hvis der ikke er isat noget kort, eller der er anmodet om overførsel af køretøjsenhedsdata af første generation, uden for rammerne af en førerkontrol udført af en kontrolmyndighed uden for EU).« |
| --- | --- | --- |

e)

Afsnit 2.2.2.16, krav DDP_018, sidste led, affattes således:

»—

FA-data foreligger ikke

Dataobjektet for en anmodning om dataoverførsel findes ikke i køretøjsenheden (f.eks. hvis der ikke er isat noget kort, eller der er anmodet om overførsel af køretøjsenhedsdata af første generation, uden for rammerne af en førerkontrol udført af en kontrolmyndighed uden for EU).«

| f) | I afsnit 2.2.6.1 foretages følgende ændringer:


  i) | Det første afsnit i krav DDP_029 affattes således:

  »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 eller 21 Hex og med passende opdeling i delmeddelelser og behørig tælling:«. |
| --- | --- | --- |

f)

I afsnit 2.2.6.1 foretages følgende ændringer:

i)

Det første afsnit i krav DDP_029 affattes således:

»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 eller 21 Hex og med passende opdeling i delmeddelelser og behørig tælling:«.

| ii) | Titlen »Datastruktur, første generation« erstattes af følgende titel:

  »Datastruktur, første generation (TREP 01 Hex)«. |
| --- | --- |

ii)

Titlen »Datastruktur, første generation« erstattes af følgende titel:

»Datastruktur, første generation (TREP 01 Hex)«.

| iii) | Titlen »Datastruktur, anden generation« erstattes af følgende titel:

  »Datastruktur, anden generation (TREP 21 Hex)«. |
| --- | --- |

iii)

Titlen »Datastruktur, anden generation« erstattes af følgende titel:

»Datastruktur, anden generation (TREP 21 Hex)«.

| g) | I afsnit 2.2.6.2 foretages følgende ændringer:


  i) | Det første afsnit i krav DDP_030 affattes således:

  »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 eller 22 Hex og med passende opdeling i delmeddelelser og behørig tælling:«. |
| --- | --- | --- |

g)

I afsnit 2.2.6.2 foretages følgende ændringer:

i)

Det første afsnit i krav DDP_030 affattes således:

»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 eller 22 Hex og med passende opdeling i delmeddelelser og behørig tælling:«.

| ii) | Titlen »Datastruktur, første generation« erstattes af følgende titel:

  »Datastruktur, første generation (TREP 02 Hex)«. |
| --- | --- |

ii)

Titlen »Datastruktur, første generation« erstattes af følgende titel:

»Datastruktur, første generation (TREP 02 Hex)«.

| iii) | Titlen »Datastruktur, anden generation« erstattes af følgende titel:

  »Datastruktur, anden generation (TREP 22 Hex)«. |
| --- | --- |

iii)

Titlen »Datastruktur, anden generation« erstattes af følgende titel:

»Datastruktur, anden generation (TREP 22 Hex)«.

| iv) | Under titlen »Datastruktur, anden generation (TREP 22 Hex)« affattes posten VuGNSSCDRecordArray således:


  » | | 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.« |
| --- | --- | --- | --- |

iv)

Under titlen »Datastruktur, anden generation (TREP 22 Hex)« affattes posten VuGNSSCDRecordArray således:

Image 40

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

| h) | I afsnit 2.2.6.3 foretages følgende ændringer:


  i) | Det første afsnit i krav DDP_031 affattes således:

  »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 eller 23 Hex, med passende opdeling i delmeddelelser og behørig tælling:«. |
| --- | --- | --- |

h)

I afsnit 2.2.6.3 foretages følgende ændringer:

i)

Det første afsnit i krav DDP_031 affattes således:

»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 eller 23 Hex, med passende opdeling i delmeddelelser og behørig tælling:«.

| ii) | Titlen »Datastruktur, første generation« erstattes af følgende titel:

  »Datastruktur, første generation (TREP 03 Hex)«. |
| --- | --- |

ii)

Titlen »Datastruktur, første generation« erstattes af følgende titel:

»Datastruktur, første generation (TREP 03 Hex)«.

| iii) | Titlen »Datastruktur, anden generation« erstattes af følgende titel:

  »Datastruktur, anden generation (TREP 23 Hex)«. |
| --- | --- |

iii)

Titlen »Datastruktur, anden generation« erstattes af følgende titel:

»Datastruktur, anden generation (TREP 23 Hex)«.

| iv) | Under titlen »Datastruktur, anden generation (TREP 23 Hex)« udgår posten VuTimeAdjustmentGNSSRecordArray. |
| --- | --- |

iv)

Under titlen »Datastruktur, anden generation (TREP 23 Hex)« udgår posten VuTimeAdjustmentGNSSRecordArray.

| i) | I afsnit 2.2.6.4 foretages følgende ændringer:


  i) | Det første afsnit i krav DDP_032 affattes således:

  »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:«. |
| --- | --- | --- |

i)

I afsnit 2.2.6.4 foretages følgende ændringer:

i)

Det første afsnit i krav DDP_032 affattes således:

»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:«.

| ii) | Titlen »Datastruktur, første generation« erstattes af følgende titel:

  »Datastruktur, første generation (TREP 04)«. |
| --- | --- |

ii)

Titlen »Datastruktur, første generation« erstattes af følgende titel:

»Datastruktur, første generation (TREP 04)«.

| iii) | Titlen »Datastruktur, anden generation« erstattes af følgende titel:

  »Datastruktur, anden generation (TREP 24)«. |
| --- | --- |

iii)

Titlen »Datastruktur, anden generation« erstattes af følgende titel:

»Datastruktur, anden generation (TREP 24)«.

| j) | I afsnit 2.2.6.5 foretages følgende ændringer:


  i) | Det første afsnit i krav DDP_033 affattes således:

  »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 eller 25 Hex med passende opdeling i delmeddelelser og behørig tælling:«. |
| --- | --- | --- |

j)

I afsnit 2.2.6.5 foretages følgende ændringer:

i)

Det første afsnit i krav DDP_033 affattes således:

»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 eller 25 Hex med passende opdeling i delmeddelelser og behørig tælling:«.

| ii) | Titlen »Datastruktur, første generation« erstattes af følgende titel:

  »Datastruktur, første generation (TREP 05)«. |
| --- | --- |

ii)

Titlen »Datastruktur, første generation« erstattes af følgende titel:

»Datastruktur, første generation (TREP 05)«.

| iii) | Titlen »Datastruktur, anden generation« erstattes af følgende titel:

  »Datastruktur, anden generation (TREP 25)«. |
| --- | --- |

iii)

Titlen »Datastruktur, anden generation« erstattes af følgende titel:

»Datastruktur, anden generation (TREP 25)«.

| k) | Afsnit 3.3, krav DDP_035, affattes således:


  »DDP_035 | Overførsel af et takografkort omfatter følgende trin:


  — | Overførsel af kortets fælles oplysninger i elementærfilerne


  og


  Disse oplysninger er ikke obligatoriske og sikres ikke med digital underskrift. |
| --- | --- | --- | --- |

k)

Afsnit 3.3, krav DDP_035, affattes således:

»DDP_035

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

—

Overførsel af kortets fælles oplysninger i elementærfilerne

  Image 41
  og

  Image 42
  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


:


  — | Overførsel af elementærfilerne


  og


  Disse oplysninger sikres ikke med digital underskrift.
  Det er obligatorisk at overføre disse filer ved hver overførselssession. |
| --- | --- | --- |

—

(for takografkort af første og anden generation) Overførsel af elementærfiler i

  Image 43

:

—

Overførsel af elementærfilerne

  Image 44
  og

  Image 45
  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


) undtagen elementærfilen


  Disse oplysninger sikres med en digital underskrift i henhold til tillæg 11 Fælles sikkerhedsmekanismer, del A. |
| --- | --- |

—

Overførsel af applikationens øvrige elementærfiler (i

  Image 46

) undtagen elementærfilen

  Image 47
  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


  og


. |
| --- | --- |

—

Ved hver overførselssession er det obligatorisk som minimum at overføre elementærfilerne

  Image 48
  og

  Image 49

.

| — | Ved overførsel af et førerkort er det desuden obligatorisk at overføre følgende elementærfiler:


  Tekst af billedet

  Events_Data,
  Faults_Data,


  Tekst af billedet

  Driver_Activity_Data,
  Vehicles_Used,
  Places,
  Control_Activity_Data,
  Specific_Conditions, |
| --- | --- |

—

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


:


  — | Overfør elementærfilerne CardSignCertificate, CA_Certificate og Link_Certificate (hvis til stede). Disse oplysninger sikres ikke med digital underskrift.
  Det er obligatorisk at overføre disse filer ved hver overførselssession. |
| --- | --- | --- |

—

(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

  Image 52

:

—

Overfør elementærfilerne CardSignCertificate, CA_Certificate og Link_Certificate (hvis til stede). 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


) undtagen elementærfilen


  Disse oplysninger sikres med en digital underskrift i henhold til tillæg 11 Fælles sikkerhedsmekanismer, del B. |
| --- | --- |

—

Overførsel af applikationens øvrige elementærfiler (i

  Image 53

) undtagen elementærfilen

  Image 54
  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 og Identification. |
| --- | --- |

—

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:


  Tekst af billedet

  Events_Data,
  Faults_Data,
  Driver_Activity_Data,
  Vehicles_Used,
  Places,
  Control_Activity_Data,
  Specific_Conditions,
  VehicleUnits_Used,
  GNSS Places. |
| --- | --- |

—

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.

| — | Ved overførsel af et førerkort opdateres


-datoen i elementærfilen


, og i de dedikerede filer Tachograph og, hvis relevant,


. |
| --- | --- |

—

Ved overførsel af et førerkort opdateres

  Image 56

-datoen i elementærfilen

  Image 57

, og i de dedikerede filer Tachograph og, hvis relevant,

  Image 58

.

| — | Ved overførsel af et værkstedskort nulstilles kalibreringstælleren i elementærfilen


-datoen, og i de dedikerede filer


  og, hvis relevant,


. |
| --- | --- |

—

Ved overførsel af et værkstedskort nulstilles kalibreringstælleren i elementærfilen

  Image 59

-datoen, og i de dedikerede filer

  Image 60
  og, hvis relevant,

  Image 61

.

| — | Ved dataoverførsel fra et værkstedskort skal elementærfilen


  i de dedikerede filer


  og, hvis relevant,


  ikke overføres.« |
| --- | --- |

—

Ved dataoverførsel fra et værkstedskort skal elementærfilen

  Image 62
  i de dedikerede filer

  Image 63
  og, hvis relevant,

  Image 64
  ikke overføres.«

| l) | Punkt 3.3.2, krav DDP_037, første afsnit, affattes således:

  »Følgende sekvens anvendes til overførsel af elementærfilerne ICC, IC, Card_Certificate (eller CardSignCertificate for den dedikerede fil Tachograph_G2), CA_Certificate og Link_Certificate (kun for den dedikerede fil Tachograph_G2):«. |
| --- | --- |

l)

Punkt 3.3.2, krav DDP_037, første afsnit, affattes således:

»Følgende sekvens anvendes til overførsel af elementærfilerne ICC, IC, Card_Certificate (eller CardSignCertificate for den dedikerede fil Tachograph_G2), CA_Certificate og Link_Certificate (kun for den dedikerede fil Tachograph_G2):«.

| m) | I punkt 3.3.3 affattes tabellen således:


  »Kort | Retn. | IDE-enhed/kortlæser | Betydning/bemærkninger |
| --- | --- | --- | --- | --- |
| | | Select File | |
| OK | | | |
| | | Perform Hash of File | — | Beregner hash-værdien af den valgte fils dataindhold ved hjælp af den foreskrevne hash-algoritme i overensstemmelse med tillæg 11, del A eller B. Denne kommando er ikke en ISO-kommando. |

m)

I punkt 3.3.3 affattes tabellen således:

»Kort

Retn.

IDE-enhed/kortlæser

Betydning/bemærkninger

Image 65

Select File

Select File

OK

OK

Image 66

Image 67

Perform Hash of File

Perform Hash of File

—

Beregner hash-værdien af den valgte fils dataindhold ved hjælp af den foreskrevne hash-algoritme i overensstemmelse med tillæg 11, del A eller B. Denne kommando er ikke en ISO-kommando.

Beregn hashværdi af fil, og gem hashværdi midlertidigt

OK

OK

Image 68

Image 69

Read Binary

Read Binary

Indeholder filen flere data end svarende til bufferstørrelsen af kortlæser eller kort, må kommandoen gentages, indtil hele filen er læst.

File Data

File Data

OK

OK

Image 70

Gem de modtagne data på eksternt lagermedium

i henhold til 3.4 Data storage format

3.4

Image 71

PSO: Compute Digital Signature

PSO: Compute Digital Signature

Udfør sikkerhedsoperationen »Compute Digital Signature« med anvendelse af den midlertidigt gemte hashværdi

Signature

Signature

OK

OK

Image 72

Tilføj data til de data, som i forvejen er gemt på det eksterne lagermedium

i henhold til 3.4 Data storage format«

3.4

| n) | Afsnit 3.4.2, krav DDP_046, affattes således:


  »DDP_046 | En underskrift skal gemmes som næste TLV-objekt direkte efter det TLV-objekt, som indeholder filens data.


  Definition | Betydning | Længde |
| --- | --- | --- | --- | --- |
| FID (2 bytes) »00« | Etiket for elementærfil (FID) i den dedikerede fil


  eller for kortets fælles oplysninger | 3 bytes |
| FID (2 bytes) »01« | Etiket for underskrift af elementærfilen (FID) i den dedikerede fil | 3 bytes |
| FID (2 bytes) »02« | Etiket for elementærfil (FID) i den dedikerede fil | 3 bytes |
| FID (2 bytes) »03« | Etiket for underskrift af elementærfilen (FID) i den dedikerede fil | 3 bytes |
| xx xx | Længde af feltet Værdi | 2 bytes |

n)

Afsnit 3.4.2, krav DDP_046, affattes således:

»DDP_046

En underskrift skal gemmes som næste TLV-objekt direkte efter det TLV-objekt, som indeholder filens data.

Definition

Betydning

Længde

FID (2 bytes) »00«

Image 73

3 bytes

FID (2 bytes) »01«

Image 74

3 bytes

FID (2 bytes) »02«

Image 75

3 bytes

FID (2 bytes) »03«

Image 76

3 bytes

xx xx

Længde af feltet Værdi

2 bytes

Eksempel på data i en fil overført til eksternt lagermedium:

| Etiket | Længde | Værdi |
| --- | --- | --- |
| | | — | Data i elementærfilen ICC |

Etiket

Længde

Værdi

Image 77

Image 78

—

Data i elementærfilen ICC

Image 79

Image 80

| — | Data i elementærfilen Card_Certificate |
| --- | --- |

—

Data i elementærfilen Card_Certificate

| — | ... |
| --- | --- |

—

...

Image 81

Image 82

Image 83

Image 84

Image 85

Image 86

Image 87

Image 88

Image 89

Image 90

Image 91

Image 92

Image 93

Image 94

Image 95

Image 96

| o) | Afsnit 4, krav DDP_049, affattes således:


  »DDP_049 | Førerkort af første generation: Data skal overføres ved hjælp af dataoverførselsprotokollen for første generation, og overførte data skal have samme format som data, der overføres fra en køretøjsenhed af første generation.
  Førerkort af anden generation: Køretøjsenheden skal derefter overføre hele kortet fil for fil i overensstemmelse med protokollen for overførsel af kort som fastlagt i punkt 3 og skal fremsende alle data, som er modtaget fra kortet, til IDE-enheden i det korrekte TLV-filformat (se 3.4.2) og indkapslet i en »Positive Response Transfer Data«-meddelelse.« |
| --- | --- | --- |

o)

Afsnit 4, krav DDP_049, affattes således:

»DDP_049

Førerkort af første generation: Data skal overføres ved hjælp af dataoverførselsprotokollen for første generation, og overførte data skal have samme format som data, der overføres fra en køretøjsenhed af første generation.

Førerkort af anden generation: Køretøjsenheden skal derefter overføre hele kortet fil for fil i overensstemmelse med protokollen for overførsel af kort som fastlagt i punkt 3 og skal fremsende alle data, som er modtaget fra kortet, til IDE-enheden i det korrekte TLV-filformat (se 3.4.2) og indkapslet i en »Positive Response Transfer Data«-meddelelse.«

| 34) | Tillæg 8, afsnit 2, teksten efter overskriften »Henvisninger«, affattes således:

  »ISO 14230-2: Road Vehicles — Diagnostic Systems — Keyword Protocol 2000 — Part 2: Data Link Layer.
  First edition: 1999.« |
| --- | --- |

34)

Tillæg 8, afsnit 2, teksten efter overskriften »Henvisninger«, affattes således:

»ISO 14230-2: Road Vehicles — Diagnostic Systems — Keyword Protocol 2000 — Part 2: Data Link Layer.

First edition: 1999.«

| 35) | I tillæg 9 foretages følgende ændringer:


  a) | Indholdsfortegnelsen, afsnit 6, affattes således:


  »6 | PRØVNING AF EKSTERNT UDSTYR TIL FJERNKOMMUNIKATION«. |
| --- | --- | --- | --- |

35)

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

a)

Indholdsfortegnelsen, afsnit 6, affattes således:

»6

PRØVNING AF EKSTERNT UDSTYR TIL FJERNKOMMUNIKATION«.

| b) | Afsnit 1.1, første led, affattes således:


  »— | en sikkerhedsattestering baseret på fælles kriterier efter et sikkerhedsmål, som er i fuld overensstemmelse med tillæg 10 til dette bilag«. |
| --- | --- | --- |

b)

Afsnit 1.1, første led, affattes således:

»—

en sikkerhedsattestering baseret på fælles kriterier efter et sikkerhedsmål, som er i fuld overensstemmelse med tillæg 10 til dette bilag«.

sikkerhedsattestering

| c) | I punkt 2 affattes tabellen om funktionsprøver for køretøjsenheder således:


  »Nr. | Prøve | Beskrivelse | Tilknyttede krav |
| --- | --- | --- | --- | --- |
| 1 | Administrativ undersøgelse |
| 1.1 | Dokumentation | Dokumentationens korrekthed | |
| 1.2 | Fabrikantens prøvningsresultater | Resultater af fabrikantens prøvning, udført med kombination.
  Eftervisning på papir | 88, 89,91 |
| 2 | Eftersyn |
| 2.1 | Overensstemmelse med dokumentationen | |
| 2.2 | Identifikation/mærkning | 224 til 226 |
| 2.3 | Materialer | 219 til 223 |
| 2.4 | Plombering | 398, 401 til 405 |
| 2.5 | Eksterne grænseflader | |
| 3 | Funktionsprøver |
| 3.1 | Ydede funktioner | 02, 03, 04, 05, 07, 382 |
| 3.2 | Funktionsmåder | 09 to 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 og tilbagelagt afstand | 21 til 31 |
| 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, 134 |
| 3.9 | Manuel indlæsning | 56 til 62 |
| 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 88, 134 |
| 3.13 | Identifikationsdata for apparat | 93*, 94*, 97, 100 |
| 3.14 | Data vedrørende isætning og udtagning af førerkort | 102* til 104* |
| 3.15 | Føreraktivitetsdata | 105* til 107* |
| 3.16 | Data om steder og positioner | 108* til 112* |
| 3.17 | Kilometertællerdata | 113* til 115* |
| 3.18 | Detaljerede hastighedsdata | 116* |
| 3.19 | Data vedrørende hændelser | 117* |
| 3.20 | Data vedrørende fejl | 118* |
| 3.21 | Kalibreringsdata | 119* til 121* |
| 3.22 | Tidsjusteringsdata | 124*, 125* |
| 3.23 | Kontrolaktivitetsdata | 126*, 127* |
| 3.24 | Data vedrørende virksomhedslåse | 128* |
| 3.25 | Data vedrørende dataoverførselsaktivitet | 129* |
| 3.26 | Data vedrørende særlige omstændigheder | 130*, 131* |
| 3.27 | Registrering og lagring på takografkort | 136, 137, 138*, 139*, 141*, 142, 143
  144, 145, 146*, 147*, 148*, 149, 150 |
| 3.28 | Visning på skærm | 90, 134,
  151 til 168,
  PIC_001, DIS_001 |
| 3.29 | Trykning | 90, 134,
  169 to 181, PIC_001, PRT_001 to PRT_014 |
| 3.30 | Advarsel | 134, 182 til 191,
  PIC_001 |
| 3.31 | Dataoverførsel til eksterne medier | 90, 134, 192 til 196 |
| 3.32 | Fjernkommunikation i forbindelse med målrettede vejsidekontroller | 197 til 199 |
| 3.33 | Udlæsning af data til supplerende eksterne enheder | 200, 201 |
| 3.34 | Kalibrering | 202 til 206*, 383, 384, 386 til 391 |
| 3.35 | Kalibreringskontrol ved vejsiden | 207 til 209 |
| 3.36 | Tidsjustering | 210 til 212* |
| 3.37 | Fravær af forstyrrelse af ekstra funktioner | 06, 425 |
| 3.38 | Grænseflade til bevægelsesføler | 02, 122 |
| 3.39 | Eksternt GNSS-udstyr | 03, 123 |
| 3.40 | 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.41 | Krypteringsprogram og standardiserede domæneparametre | CSM_48, CSM_50 |
| 4 | Miljøprøver |
| 4.1 | Temperatur | Funktionaliteten eftervises gennem: | Prøvning i overensstemmelse med ISO 16750-4, kapitel 5.1.1.2: Funktionsprøve ved lav temperatur (72 timer ved – 20 °C) |

c)

I punkt 2 affattes tabellen om funktionsprøver for køretøjsenheder således:

»Nr.

Prøve

Beskrivelse

Tilknyttede krav

1

1

Administrativ undersøgelse

Administrativ undersøgelse

1.1

Dokumentation

Dokumentationens korrekthed

1.2

Fabrikantens prøvningsresultater

Resultater af fabrikantens prøvning, udført med kombination.

Eftervisning på papir

88, 89,91

2

2

Eftersyn

Eftersyn

2.1

Overensstemmelse med dokumentationen

2.2

Identifikation/mærkning

224 til 226

2.3

Materialer

219 til 223

2.4

Plombering

398, 401 til 405

2.5

Eksterne grænseflader

3

3

Funktionsprøver

Funktionsprøver

3.1

Ydede funktioner

02, 03, 04, 05, 07, 382

3.2

Funktionsmåder

09 to 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 og tilbagelagt afstand

21 til 31

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, 134

3.9

Manuel indlæsning

56 til 62

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 88, 134

3.13

Identifikationsdata for apparat

93*, 94*, 97, 100

3.14

Data vedrørende isætning og udtagning af førerkort

102* til 104*

3.15

Føreraktivitetsdata

105* til 107*

3.16

Data om steder og positioner

108* til 112*

3.17

Kilometertællerdata

113* til 115*

3.18

Detaljerede hastighedsdata

116*

3.19

Data vedrørende hændelser

117*

3.20

Data vedrørende fejl

118*

3.21

Kalibreringsdata

119* til 121*

3.22

Tidsjusteringsdata

124*, 125*

3.23

Kontrolaktivitetsdata

126*, 127*

3.24

Data vedrørende virksomhedslåse

128*

3.25

Data vedrørende dataoverførselsaktivitet

129*

3.26

Data vedrørende særlige omstændigheder

130*, 131*

3.27

Registrering og lagring på takografkort

136, 137, 138*, 139*, 141*, 142, 143

144, 145, 146*, 147*, 148*, 149, 150

3.28

Visning på skærm

90, 134,

151 til 168,

PIC_001, DIS_001

3.29

Trykning

90, 134,

169 to 181, PIC_001, PRT_001 to PRT_014

3.30

Advarsel

134, 182 til 191,

PIC_001

3.31

Dataoverførsel til eksterne medier

90, 134, 192 til 196

3.32

Fjernkommunikation i forbindelse med målrettede vejsidekontroller

197 til 199

3.33

Udlæsning af data til supplerende eksterne enheder

200, 201

3.34

Kalibrering

202 til 206*, 383, 384, 386 til 391

3.35

Kalibreringskontrol ved vejsiden

207 til 209

3.36

Tidsjustering

210 til 212*

3.37

Fravær af forstyrrelse af ekstra funktioner

06, 425

3.38

Grænseflade til bevægelsesføler

02, 122

3.39

Eksternt GNSS-udstyr

03, 123

3.40

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

Krypteringsprogram og standardiserede domæneparametre

CSM_48, CSM_50

4

4

Miljøprøver

Miljøprøver

4.1

Temperatur

Funktionaliteten eftervises gennem:

Prøvning i overensstemmelse med ISO 16750-4, kapitel 5.1.1.2: Funktionsprøve ved lav temperatur (72 timer ved – 20 °C)

| | For denne prøve henvises til IEC 60068-2-1: Environmental testing — Part 2-1: Tests — Test A: Cold |
| --- | --- |

For denne prøve henvises til IEC 60068-2-1: Environmental testing — Part 2-1: Tests — Test A: Cold

| | Test i overensstemmelse med ISO 16750-4: kapitel 5.1.2.2: High temperature operation test (72 timer ved 70 °C) |
| --- | --- |

Test i overensstemmelse med ISO 16750-4: kapitel 5.1.2.2: High temperature operation test (72 timer ved 70 °C)

| | For denne prøve henvises til IEC 60068-2-2: Basic environmental testing procedures; part 2: tests; tests B: dry heat |
| --- | --- |

For denne prøve henvises til IEC 60068-2-2: Basic environmental testing procedures; part 2: tests; tests B: dry heat

| | Test i overensstemmelse med ISO 16750-4: kapitel 5.3.2: Rapid change of temperature with specified transition duration (– 20°C/70 °C, 20 cycles, dwell time 2h at each temperature)
  Et reduceret sæt prøvninger (af dem, som foreskrives i denne tabels punkt 3) kan udføres ved den lave temperatur, den høje temperatur og med gennemgang af temperaturcyklusserne |
| --- | --- |

Test i overensstemmelse med ISO 16750-4: kapitel 5.3.2: Rapid change of temperature with specified transition duration (– 20°C/70 °C, 20 cycles, dwell time 2h at each temperature)

Et reduceret sæt prøvninger (af dem, som foreskrives i denne tabels punkt 3) kan udføres ved den lave temperatur, den høje temperatur og med gennemgang af temperaturcyklusserne

213

4.2

Fugtighed

Det eftervises, at køretøjsenheden kan modstå en cyklisk fugtighedsprøve (varmeprøve) ved gennemgang af IEC 60068-2-30, prøve Db, seks 24 timers cyklusser, hvor hver temperatur varierer fra + 25 °C til + 55 °C, og hvor den relative fugtighed er 97 % ved + 25 °C og 93 % ved + 55 °C

214

4.3

Mekanisk masse

| 1. | Sinusvibrationer.
  Det kontrolleres, at køretøjsenheden kan modstå sinusvibrationer med følgende egenskaber: | Konstant skift mellem 5 og 11 Hz: Topværdi 10 mm |
| --- | --- | --- |

1.

Sinusvibrationer.

Det kontrolleres, at køretøjsenheden kan modstå sinusvibrationer med følgende egenskaber:

Konstant skift mellem 5 og 11 Hz: Topværdi 10 mm

| | konstant acceleration mellem 11 og 300 Hz: 5 g |
| --- | --- |

konstant acceleration mellem 11 og 300 Hz: 5 g

| | Prøvning for dette krav sker med IEC 60068-2-6, prøve Fc, med en mindste prøvningsvarighed på 3 × 12 timer (12 timer for hver akse) |
| --- | --- |

Prøvning for dette krav sker med IEC 60068-2-6, prøve Fc, med en mindste prøvningsvarighed på 3 × 12 timer (12 timer for hver akse)

| | ISO 16750-3 kræver ikke en sinusvibrationsprøvning for enheder, der sidder i afkoblede førerhuse. |
| --- | --- |

ISO 16750-3 kræver ikke en sinusvibrationsprøvning for enheder, der sidder i afkoblede førerhuse.

| 2. | Tilfældige vibrationer:
  Test i overensstemmelse med ISO 16750-3: kapitel 4.1.2.8: Test VIII: Commercial vehicle, decoupled vehicle cab
  Prøvning for tilfældige vibrationer, 10...2 000 Hz, kvadratisk middel, lodret: 21,3 m/s2, kvadratisk middel, langsgående: 11,8 m/s2, kvadratisk middel, tværgående: 13,1 m/s2, 3 akser, 32 timer pr. akse, herunder temperaturcyklus: – 20...70 °C.
  For denne prøve henvises til IEC 60068-2-64: Environmental testing - Part 2-64: Tests - Test Fh: Vibration, broadband random and guidance - |
| --- | --- |

2.

Tilfældige vibrationer:

Test i overensstemmelse med ISO 16750-3: kapitel 4.1.2.8: Test VIII: Commercial vehicle, decoupled vehicle cab

Prøvning for tilfældige vibrationer, 10...2 000 Hz, kvadratisk middel, lodret: 21,3 m/s2, kvadratisk middel, langsgående: 11,8 m/s2, kvadratisk middel, tværgående: 13,1 m/s2, 3 akser, 32 timer pr. akse, herunder temperaturcyklus: – 20...70 °C.

2

2

2

For denne prøve henvises til IEC 60068-2-64: Environmental testing - Part 2-64: Tests - Test Fh: Vibration, broadband random and guidance -

| 3. | Stød:
  mekanisk stød med 3 g halv-sinus i overensstemmelse med ISO 16750. |
| --- | --- |

3.

Stød:

mekanisk stød med 3 g halv-sinus i overensstemmelse med ISO 16750.

De ovenfor beskrevne prøvninger udføres på forskellige prøveeksemplarer af den afprøvede apparattype.

219

4.4

Beskyttelse mod vand og fremmedlegemer

Prøvning i overensstemmelse med ISO 20653: Road vehicles — Degree of protection (IP code) — Protection of electrical equipment against foreign objects, water and access (No change in parameters); Minimum value IP 40

220, 221

4.5

Overspændingsbeskyttelse

Det kontrolleres, at køretøjsenheden kan modstå en strømforsyning på:

| 24 V-udførelse | : | 34 V ved + 40 °C 1 time |
| --- | --- | --- |
| 12 V-udførelse | : | 17 V ved + 40 °C 1 time |

24 V-udførelse

:

34 V ved + 40 °C 1 time

12 V-udførelse

:

17 V ved + 40 °C 1 time

(ISO 16750-2)

216

4.6

Beskyttelse mod omvendt polaritet

Det kontrolleres, at køretøjsenheden kan modstå polvending af strømforsyningen

(ISO 16750-2)

216

4.7

Kortslutningsbeskyttelse

Det kontrolleres, at ind- og udgangssignaler er beskyttet mod kortslutning til strømforsyningen og til stel

(ISO 16750-2)

216

5

5

Prøver for elektromagnetisk kompatibilitet

Prøver for elektromagnetisk kompatibilitet

5.1

Strålingsemission og følsomhed

Overensstemmelse med ECE-regulativ R10

218

5.2

Elektrostatisk udladning

Overensstemmelse med ISO 10605:2008 +

Technical Corrigendum:2010 +

AMD1: 2014: +/– 4 kV for kontakt og +/– 8 kV for udladning i luften

218

5.3

Transient nedre ledningsoverførsel for strømforsyning

For 24 V-udførelse: overensstemmelse med ISO 7637-2 og ECE-regulativ nr. 10, rev. 3:

| | impuls 1a: Vs = – 450 V, Ri = 50 ohm |
| --- | --- |

impuls 1a: Vs = – 450 V, Ri = 50 ohm

| | impuls 2 a: Vs = + 37 V, Ri = 2 ohm |
| --- | --- |

impuls 2 a: Vs = + 37 V, Ri = 2 ohm

| | impuls 2b: Vs = + 20 V, Ri = 0,05 ohm |
| --- | --- |

impuls 2b: Vs = + 20 V, Ri = 0,05 ohm

| | impuls 3 a: Vs = – 150 V, Ri = 50 ohm |
| --- | --- |

impuls 3 a: Vs = – 150 V, Ri = 50 ohm

| | impuls 3b: Vs = + 150 V, Ri = 50 ohm |
| --- | --- |

impuls 3b: Vs = + 150 V, Ri = 50 ohm

| | impuls 4: Vs = – 16 V Va = – 12 V t6 = 100 ms |
| --- | --- |

impuls 4: Vs = – 16 V Va = – 12 V t6 = 100 ms

| | impuls 5: Vs = + 120 V Ri = 2,2 ohm td = 250 ms |
| --- | --- |

impuls 5: Vs = + 120 V Ri = 2,2 ohm td = 250 ms

For 12 V-udførelse: overensstemmelse med ISO 7637-1 og ECE-regulativ nr. 10, rev. 3:

| | impuls 1: Vs = – 75 V, Ri = 10 ohm |
| --- | --- |

impuls 1: Vs = – 75 V, Ri = 10 ohm

| | impuls 2a: Vs = + 37 V, Ri = 2 ohm |
| --- | --- |

impuls 2a: Vs = + 37 V, Ri = 2 ohm

| | impuls 2b: Vs = + 10 V, Ri = 0,05 ohm |
| --- | --- |

impuls 2b: Vs = + 10 V, Ri = 0,05 ohm

| | impuls 3a: Vs = – 112 V, Ri = 50 ohm |
| --- | --- |

impuls 3a: Vs = – 112 V, Ri = 50 ohm

| | impuls 3b: Vs = + 75 V, Ri = 50 ohm |
| --- | --- |

impuls 3b: Vs = + 75 V, Ri = 50 ohm

| | impuls 4: Vs = – 6 V Va = – 5 V t6 = 15 ms |
| --- | --- |

impuls 4: Vs = – 6 V Va = – 5 V t6 = 15 ms

| | impuls 5: Vs = + 65 V, Ri = 3 ohm td = 100 ms |
| --- | --- |

impuls 5: Vs = + 65 V, Ri = 3 ohm td = 100 ms

| | Impuls 5 skal kun afprøves for køretøjsenheder bestemt til montering i køretøjer uden ekstern fælles overbelastningsbeskyttelse |
| --- | --- |

Impuls 5 skal kun afprøves for køretøjsenheder bestemt til montering i køretøjer uden ekstern fælles overbelastningsbeskyttelse

For så vidt angår overbelastningsbeskyttelse henvises til ISO 16750-2, 4. udgave, kapitel 4.6.4.

218«

| d) | Afsnit 6 affattes således:
  »6   PRØVNING AF EKSTERNT UDSTYR TIL FJERNKOMMUNIKATION


  Nr. | Prøve | Beskrivelse | Tilknyttede krav |
| --- | --- | --- | --- | --- |
| 1. | Administrativ undersøgelse |
| 1.1 | Dokumentation | Dokumentationens korrekthed | |
| 2. | Eftersyn |
| 2.1. | Overensstemmelse med dokumentationen | |
| 2.2. | Identifikation/mærkning | 225, 226 |
| 2.3 | Materialer | 219 til 223 |
| 3. | Funktionsprøver |
| 3.1 | Fjernkommunikation i forbindelse med målrettede vejsidekontroller | 4, 197 til 199 |
| 3.2 | Registrering og lagring i datalager | 91 |
| 3.3 | Kommunikation med køretøjsenhed | Tillæg 14, krav DSC_66 til DSC_70, DSC_71 til DSC_76 |
| 4. | Miljøprøver |
| 4.1 | Temperatur | Funktionaliteten eftervises gennem: | Prøvning i overensstemmelse med ISO 16750-4, kapitel 5.1.1.2: Funktionsprøve ved lav temperatur (72 timer ved – 20 °C)
  For denne prøve henvises til IEC 60068-2-1: Environmental testing — Part 2-1: Tests — Test A: Cold |

d)

Afsnit 6 affattes således:

»6   PRØVNING AF EKSTERNT UDSTYR TIL FJERNKOMMUNIKATION

Nr.

Prøve

Beskrivelse

Tilknyttede krav

1.

Administrativ undersøgelse

Administrativ undersøgelse

1.1

Dokumentation

Dokumentationens korrekthed

2.

Eftersyn

Eftersyn

2.1.

Overensstemmelse med dokumentationen

2.2.

Identifikation/mærkning

225, 226

2.3

Materialer

219 til 223

3.

3.

Funktionsprøver

Funktionsprøver

3.1

Fjernkommunikation i forbindelse med målrettede vejsidekontroller

4, 197 til 199

3.2

Registrering og lagring i datalager

91

3.3

Kommunikation med køretøjsenhed

Tillæg 14, krav DSC_66 til DSC_70, DSC_71 til DSC_76

4.

Miljøprøver

Miljøprøver

4.1

Temperatur

Funktionaliteten eftervises gennem:

Prøvning i overensstemmelse med ISO 16750-4, kapitel 5.1.1.2: Funktionsprøve ved lav temperatur (72 timer ved – 20 °C)

For denne prøve henvises til IEC 60068-2-1: Environmental testing — Part 2-1: Tests — Test A: Cold

| | Test i overensstemmelse med ISO 16750-4: kapitel 5.1.2.2: High temperature operation test (72 timer ved 70 °C)
  For denne prøve henvises til IEC 60068-2-2: Basic environmental testing procedures; part 2: tests; tests B: dry heat |
| --- | --- |

Test i overensstemmelse med ISO 16750-4: kapitel 5.1.2.2: High temperature operation test (72 timer ved 70 °C)

For denne prøve henvises til IEC 60068-2-2: Basic environmental testing procedures; part 2: tests; tests B: dry heat

| | Test i overensstemmelse med ISO 16750-4: kapitel 5.3.2: Rapid change of temperature with specified transition duration (– 20 °C/70 °C, 20 cyklusser, holdetid 1 time ved hver temperatur)
  Et reduceret sæt prøvninger (af dem, som foreskrives i denne tabels punkt 3) kan udføres ved den lave temperatur, den høje temperatur og med gennemgang af temperaturcyklusserne |
| --- | --- |

Test i overensstemmelse med ISO 16750-4: kapitel 5.3.2: Rapid change of temperature with specified transition duration (– 20 °C/70 °C, 20 cyklusser, holdetid 1 time ved hver temperatur)

Et reduceret sæt prøvninger (af dem, som foreskrives i denne tabels punkt 3) kan udføres ved den lave temperatur, den høje temperatur og med gennemgang af temperaturcyklusserne

213

4.2

Beskyttelse mod vand og fremmedlegemer

Prøvning i overensstemmelse med ISO 20653: Road vehicles — Degree of protection (IP code) — Protection of electrical equipment against foreign objects, water and access (targeted value IP40)

220, 221

5

5

Prøver for elektromagnetisk kompatibilitet

Prøver for elektromagnetisk kompatibilitet

5.1

Strålingsemission og følsomhed

Overensstemmelse med ECE-regulativ R10

218

5.2

Elektrostatisk udladning

Overensstemmelse med ISO 10605:2008 + Technical Corrigendum:2010 + AMD1: 2014: +/– 4 kV for kontakt og +/– 8 kV for udladning i luften

218

5.3

Transient nedre ledningsoverførsel for strømforsyning

For 24 V-udførelse: overensstemmelse med ISO 7637-2 og ECE-regulativ nr. 10, rev. 3:

| | impuls 1a: Vs = – 450 V, Ri = 50 ohm |
| --- | --- |

impuls 1a: Vs = – 450 V, Ri = 50 ohm

| | impuls 2 a: Vs = + 37 V, Ri = 2 ohm |
| --- | --- |

impuls 2 a: Vs = + 37 V, Ri = 2 ohm

| | impuls 2b: Vs = + 20 V, Ri = 0,05 ohm |
| --- | --- |

impuls 2b: Vs = + 20 V, Ri = 0,05 ohm

| | impuls 3 a: Vs = – 150 V, Ri = 50 ohm |
| --- | --- |

impuls 3 a: Vs = – 150 V, Ri = 50 ohm

| | impuls 3b: Vs = + 150 V, Ri = 50 ohm |
| --- | --- |

impuls 3b: Vs = + 150 V, Ri = 50 ohm

| | impuls 4: Vs = – 16 V Va = – 12 V t6 = 100 ms |
| --- | --- |

impuls 4: Vs = – 16 V Va = – 12 V t6 = 100 ms

| | impuls 5: Vs = + 120 V Ri = 2,2 ohm td = 250 ms |
| --- | --- |

impuls 5: Vs = + 120 V Ri = 2,2 ohm td = 250 ms

For 12 V-udførelse: overensstemmelse med ISO 7637-1 og ECE-regulativ nr. 10, rev. 3:

| | impuls 1: Vs = – 75 V, Ri = 10 ohm |
| --- | --- |

impuls 1: Vs = – 75 V, Ri = 10 ohm

| | impuls 2 a: Vs = + 37 V, Ri = 2 ohm |
| --- | --- |

impuls 2 a: Vs = + 37 V, Ri = 2 ohm

| | impuls 2b: Vs = + 10 V, Ri = 0,05 ohm |
| --- | --- |

impuls 2b: Vs = + 10 V, Ri = 0,05 ohm

| | impuls 3 a: Vs = – 112 V, Ri = 50 ohm |
| --- | --- |

impuls 3 a: Vs = – 112 V, Ri = 50 ohm

| | impuls 3b: Vs = + 75 V, Ri = 50 ohm |
| --- | --- |

impuls 3b: Vs = + 75 V, Ri = 50 ohm

| | impuls 4: Vs = – 6 V Va = – 5 V t6 = 15 ms |
| --- | --- |

impuls 4: Vs = – 6 V Va = – 5 V t6 = 15 ms

| | impuls 5: Vs = + 65 V, Ri = 3 ohm td = 100 ms |
| --- | --- |

impuls 5: Vs = + 65 V, Ri = 3 ohm td = 100 ms

| | Impuls 5 skal kun afprøves for køretøjsenheder bestemt til montering i køretøjer uden ekstern fælles overbelastningsbeskyttelse |
| --- | --- |

Impuls 5 skal kun afprøves for køretøjsenheder bestemt til montering i køretøjer uden ekstern fælles overbelastningsbeskyttelse

For så vidt angår overbelastningsbeskyttelse henvises til ISO 16750-2, 4. udgave, kapitel 4.6.4.

218«

| e) | Afsnit 8, tabellen om interoperabilitetsprøver, affattes således:


  »Nr. | Prøve | Beskrivelse |
| --- | --- | --- | --- |
| 8.1   Interoperabilitetsprøver mellem køretøjsenheder og takografkort |
| 1 | Gensidig ægthedsbekræftelse | Kontroller, at den gensidige ægthedsbekræftelse mellem køretøjsenheden og takografkortet afvikles normalt |
| 2 | Skrive-/læseprøver | Gennemfør et typisk aktivitetsscenario på køretøjsenheden. Scenariet skal være tilpasset den afprøvede korttype og skal indebære skrivning på så mange af kortets elementærfiler som muligt
  Gennem dataoverførsel til køretøjsenheden kontrolleres det, at alle de tilsvarende registreringer er udført korrekt
  Gennem dataoverførsel fra kortet kontrolleres det, at alle de tilsvarende registreringer er udført korrekt
  Gennem daglige udskrifter kontrolleres det, at alle de tilsvarende registreringer kan læses korrekt. |
| 8.2   Interoperabilitetsprøver mellem køretøjsenheder og bevægelsesfølere |
| 1 | Parring | Kontrollér, at parringen mellem køretøjsenheden og bevægelsesføleren afvikles normalt. |
| 2 | Aktivitetsprøvninger | Gennemfør et typisk aktivitetsscenario på bevægelsesføleren. Scenariet skal omfatte en normal aktivitet og frembringe så mange hændelser eller fejl som muligt.
  Gennem dataoverførsel til køretøjsenheden kontrolleres det, at alle de tilsvarende registreringer er udført korrekt
  Gennem dataoverførsel fra kortet kontrolleres det, at alle de tilsvarende registreringer er udført korrekt
  Gennem daglige udskrifter kontrolleres det, at alle de tilsvarende registreringer kan læses korrekt. |
| 8.3   Interoperabilitetsprøver mellem køretøjsenheder og eksternt GNSS-udstyr (hvor det er relevant) |
| 1 | Gensidig ægthedsbekræftelse | Kontrollér, at den gensidige ægthedsbekræftelse mellem køretøjsenheden og det eksterne GNSS-modul afvikles normalt. |
| 2 | Aktivitetsprøvninger | Gennemfør et typisk aktivitetsscenario på det eksterne GNSS-udstyr. Scenariet skal omfatte en normal aktivitet og frembringe så mange hændelser eller fejl som muligt.
  Gennem dataoverførsel til køretøjsenheden kontrolleres det, at alle de tilsvarende registreringer er udført korrekt
  Gennem dataoverførsel fra kortet kontrolleres det, at alle de tilsvarende registreringer er udført korrekt
  Gennem daglige udskrifter kontrolleres det, at alle de tilsvarende registreringer kan læses korrekt.« |

e)

Afsnit 8, tabellen om interoperabilitetsprøver, affattes således:

»Nr.

Prøve

Beskrivelse

Interoperabilitetsprøver mellem køretøjsenheder og takografkort

1

Gensidig ægthedsbekræftelse

Kontroller, at den gensidige ægthedsbekræftelse mellem køretøjsenheden og takografkortet afvikles normalt

2

Skrive-/læseprøver

Gennemfør et typisk aktivitetsscenario på køretøjsenheden. Scenariet skal være tilpasset den afprøvede korttype og skal indebære skrivning på så mange af kortets elementærfiler som muligt

Gennem dataoverførsel til køretøjsenheden kontrolleres det, at alle de tilsvarende registreringer er udført korrekt

Gennem dataoverførsel fra kortet kontrolleres det, at alle de tilsvarende registreringer er udført korrekt

Gennem daglige udskrifter kontrolleres det, at alle de tilsvarende registreringer kan læses korrekt.

Interoperabilitetsprøver mellem køretøjsenheder og bevægelsesfølere

1

Parring

Kontrollér, at parringen mellem køretøjsenheden og bevægelsesføleren afvikles normalt.

2

Aktivitetsprøvninger

Gennemfør et typisk aktivitetsscenario på bevægelsesføleren. Scenariet skal omfatte en normal aktivitet og frembringe så mange hændelser eller fejl som muligt.

Gennem dataoverførsel til køretøjsenheden kontrolleres det, at alle de tilsvarende registreringer er udført korrekt

Gennem dataoverførsel fra kortet kontrolleres det, at alle de tilsvarende registreringer er udført korrekt

Gennem daglige udskrifter kontrolleres det, at alle de tilsvarende registreringer kan læses korrekt.

Interoperabilitetsprøver mellem køretøjsenheder og eksternt GNSS-udstyr (hvor det er relevant)

1

Gensidig ægthedsbekræftelse

Kontrollér, at den gensidige ægthedsbekræftelse mellem køretøjsenheden og det eksterne GNSS-modul afvikles normalt.

2

Aktivitetsprøvninger

Gennemfør et typisk aktivitetsscenario på det eksterne GNSS-udstyr. Scenariet skal omfatte en normal aktivitet og frembringe så mange hændelser eller fejl som muligt.

Gennem dataoverførsel til køretøjsenheden kontrolleres det, at alle de tilsvarende registreringer er udført korrekt

Gennem dataoverførsel fra kortet kontrolleres det, at alle de tilsvarende registreringer er udført korrekt

Gennem daglige udskrifter kontrolleres det, at alle de tilsvarende registreringer kan læses korrekt.«

| 36) | I tillæg 11 foretages følgende ændringer:


  a) | Afsnit 8.2.3, krav CSM_49, affattes således:


  »CSM_49 | Køretøjsenheder, takografkort og eksternt GNSS-udstyr skal understøtte SHA-256-, SHA-384- og SHA-512-algoritmerne som specificeret i [SHS].« |
| --- | --- | --- | --- |

36)

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

a)

Afsnit 8.2.3, krav CSM_49, affattes således:

»CSM_49

Køretøjsenheder, takografkort og eksternt GNSS-udstyr skal understøtte SHA-256-, SHA-384- og SHA-512-algoritmerne som specificeret i [SHS].«

| b) | Punkt 9.1.2, krav CSM_58, første afsnit, affattes således:


  »CSM_58 | Hver gang ERCA'en genererer et nyt europæisk rodnøglepar, opretter den et forbindelsescertifikat til den nye europæiske offentlige nøgle og underskriver det med den hidtidige europæiske private nøgle. Gyldighedsperioden af et forbindelsescertifikat er 17 år plus 3 måneder. Dette fremgår ligeledes af Figur 1 i afsnit 9.1.7.« |
| --- | --- | --- |

b)

Punkt 9.1.2, krav CSM_58, første afsnit, affattes således:

»CSM_58

Hver gang ERCA'en genererer et nyt europæisk rodnøglepar, opretter den et forbindelsescertifikat til den nye europæiske offentlige nøgle og underskriver det med den hidtidige europæiske private nøgle. Gyldighedsperioden af et forbindelsescertifikat er 17 år plus 3 måneder. Dette fremgår ligeledes af Figur 1 i afsnit 9.1.7.«

| c) | Afsnit 9.1.4, krav CSM_72, affattes således:


  »CSM_72 | Der skal genereres to entydige ECC-nøglepar for hver køretøjsenhed, som betegnes VU_MA og VU_Sign. Denne opgave varetages af køretøjsenhedsfabrikanterne. Når der genereres et køretøjsenhedsnøglepar, sender den part, der genererer nøglen den offentlige nøgle til sin MSCA for at få et tilhørende køretøjsenhedscertifikat underskrevet af MSCA'en. Den private nøgle må kun benyttes af køretøjsenheden.« |
| --- | --- | --- |

c)

Afsnit 9.1.4, krav CSM_72, affattes således:

»CSM_72

Der skal genereres to entydige ECC-nøglepar for hver køretøjsenhed, som betegnes VU_MA og VU_Sign. Denne opgave varetages af køretøjsenhedsfabrikanterne. Når der genereres et køretøjsenhedsnøglepar, sender den part, der genererer nøglen den offentlige nøgle til sin MSCA for at få et tilhørende køretøjsenhedscertifikat underskrevet af MSCA'en. Den private nøgle må kun benyttes af køretøjsenheden.«

| d) | I afsnit 9.1.5 foretages følgende ændringer:


  i) | Krav CSM_83 affattes således:


  »CSM_83 | Der genereres et entydigt ECC- nøglepar, som betegnes Card_MA, for hvert takografkort. Der genereres desuden endnu et entydigt ECC-nøglepar, som betegnes Card_Sign, for hvert førerkort og hvert værkstedskort. Denne opgave kan udføres af kortfabrikanter eller leverandører af individuelle tilpasninger af kort. Når der genereres et kortnøglepar, sender den part, der genererer nøglen den offentlige nøgle til sin MSCA for at få et tilhørende kortcertifikat underskrevet af MSCA'en. Den private nøgle må kun benyttes af takografkortet.« |
| --- | --- | --- | --- |

d)

I afsnit 9.1.5 foretages følgende ændringer:

i)

Krav CSM_83 affattes således:

»CSM_83

Der genereres et entydigt ECC- nøglepar, som betegnes Card_MA, for hvert takografkort. Der genereres desuden endnu et entydigt ECC-nøglepar, som betegnes Card_Sign, for hvert førerkort og hvert værkstedskort. Denne opgave kan udføres af kortfabrikanter eller leverandører af individuelle tilpasninger af kort. Når der genereres et kortnøglepar, sender den part, der genererer nøglen den offentlige nøgle til sin MSCA for at få et tilhørende kortcertifikat underskrevet af MSCA'en. Den private nøgle må kun benyttes af takografkortet.«

| ii) | Krav CSM_88 affattes således:


  »CSM_88 | Et Card_MA-certifikat har følgende gyldighedsperiode:


  — | for førerkort: 5 år |
| --- | --- | --- | --- |

ii)

Krav CSM_88 affattes således:

»CSM_88

Et Card_MA-certifikat har følgende gyldighedsperiode:

—

for førerkort: 5 år

| — | for virksomhedskort: 5 år |
| --- | --- |

—

for virksomhedskort: 5 år

| — | for kontrolkort: 2 år |
| --- | --- |

—

for kontrolkort: 2 år

| — | for værkstedskort: 1 år.« |
| --- | --- |

—

for værkstedskort: 1 år.«

| iii) | I krav CSM_91 indsættes følgende tekst:


  »— | Udelukkende for kontrolkort, virksomhedskort og værkstedskort gælder desuden, at hvis sådanne kort udstedes i løbet af de første tre måneder af gyldighedsperioden for et nyt EUR-certifikat: det EUR-certifikat, som er to generationer ældre, hvis dette findes.

  Bemærkning til sidste led: F.eks. i de første tre måneder af ERCA(3)-certifikatet (jf. Figur 1), skal de nævnte kort indeholde ERCA(1)-certifikatet. Det er nødvendigt, så disse kort kan anvendes til at udføre dataoverførsel fra ERCA(1)-køretøjsenheder, hvis normale dataoverførselslevetid på 15 år plus 3 måneder udløber i disse måneder; se det sidste led i krav 13) i bilag I C.« |
| --- | --- | --- |

iii)

I krav CSM_91 indsættes følgende tekst:

»—

Udelukkende for kontrolkort, virksomhedskort og værkstedskort gælder desuden, at hvis sådanne kort udstedes i løbet af de første tre måneder af gyldighedsperioden for et nyt EUR-certifikat: det EUR-certifikat, som er to generationer ældre, hvis dette findes.

Bemærkning til sidste led: F.eks. i de første tre måneder af ERCA(3)-certifikatet (jf. Figur 1), skal de nævnte kort indeholde ERCA(1)-certifikatet. Det er nødvendigt, så disse kort kan anvendes til at udføre dataoverførsel fra ERCA(1)-køretøjsenheder, hvis normale dataoverførselslevetid på 15 år plus 3 måneder udløber i disse måneder; se det sidste led i krav 13) i bilag I C.«

Bemærkning til sidste led

| e) | I afsnit 9.1.6 foretages følgende ændringer:


  i) | Krav CSM_93 affattes således:


  »CSM_93 | Der genereres et entydigt ECC-nøglepar for hvert eksternt GNSS-udstyr, som betegnes EGF_MA. Denne opgave varetages af fabrikanter af eksternt GNSS-udstyr. Når der genereres et EGF_MA-nøglepar, sender den part, der genererer nøglen den offentlige nøgle til sin MSCA for at få et tilhørende EGF_MA-certifikat underskrevet af MSCA'en. Den private nøgle må kun benyttes af det eksterne GNSS-udstyr.« |
| --- | --- | --- | --- |

e)

I afsnit 9.1.6 foretages følgende ændringer:

i)

Krav CSM_93 affattes således:

»CSM_93

Der genereres et entydigt ECC-nøglepar for hvert eksternt GNSS-udstyr, som betegnes EGF_MA. Denne opgave varetages af fabrikanter af eksternt GNSS-udstyr. Når der genereres et EGF_MA-nøglepar, sender den part, der genererer nøglen den offentlige nøgle til sin MSCA for at få et tilhørende EGF_MA-certifikat underskrevet af MSCA'en. Den private nøgle må kun benyttes af det eksterne GNSS-udstyr.«

| ii) | Krav CSM_95 affattes således:


  »CSM_95 | Eksternt GNSS-udstyr må udelukkende bruge sit EGF_MA-nøglepar, som består af den private nøgle EGF_MA.SK og den offentlige nøgle EGF_MA.PK til at foretage gensidig ægthedskontrol og kontrol af en sessionsnøgles overensstemmelse med køretøjsenheder som specificeret i afsnit 11.4 i dette tillæg.« |
| --- | --- | --- |

ii)

Krav CSM_95 affattes således:

»CSM_95

Eksternt GNSS-udstyr må udelukkende bruge sit EGF_MA-nøglepar, som består af den private nøgle EGF_MA.SK og den offentlige nøgle EGF_MA.PK til at foretage gensidig ægthedskontrol og kontrol af en sessionsnøgles overensstemmelse med køretøjsenheder som specificeret i afsnit 11.4 i dette tillæg.«

| f) | I afsnit 9.1.7 foretages følgende ændringer:


  i) | Figur 1 erstattes af følgende figur:

  »
  Figur 1


  Udstedelse og brug af forskellige generationer af ERCA-rodcertifikater, ERCA-forbindelsescertifikater, MSCA-certifikater og udstyrscertifikater


  Tekst af billedet

  Tegnforklaring
  Brugsperiode privatnøgle / Resterende certifikatgyldighed
  ERCA-certifikat af andan generation og certifikater baseret herpå
  ERCA-certifikat af terdje generation og certifikater baseret herpå
  ERCA-certifikat af første generation og certifikater baseret herpå
  år
  år
  år

  « |
| --- | --- | --- |

f)

I afsnit 9.1.7 foretages følgende ændringer:

i)

Figur 1 erstattes af følgende figur:

»
  Figur 1

Figur 1

Udstedelse og brug af forskellige generationer af ERCA-rodcertifikater, ERCA-forbindelsescertifikater, MSCA-certifikater og udstyrscertifikater

Udstedelse og brug af forskellige generationer af ERCA-rodcertifikater, ERCA-forbindelsescertifikater, MSCA-certifikater og udstyrscertifikater

Tegnforklaring

Brugsperiode privatnøgle / Resterende certifikatgyldighed

ERCA-certifikat af andan generation og certifikater baseret herpå

ERCA-certifikat af terdje generation og certifikater baseret herpå

ERCA-certifikat af første generation og certifikater baseret herpå

år

år

år

| ii) | Nr. 6 i bemærkningerne til figur 1 affattes således:


  »6 | Af pladshensyn vises forskellen i gyldighedsperiode mellem Card_MA- og Card_Sign-certifikaterne kun for første generation.« |
| --- | --- | --- |

ii)

Nr. 6 i bemærkningerne til figur 1 affattes således:

»6

Af pladshensyn vises forskellen i gyldighedsperiode mellem Card_MA- og Card_Sign-certifikaterne kun for første generation.«

| g) | I afsnit 9.2.1.1 foretages følgende ændringer:


  i) | Krav CSM_106, første led, affattes således:


  »— | For 128-bit hovednøgler til bevægelsessensorer: CV = »B6 44 2C 45 0E F8 D3 62 0B 7A 8A 97 91 E4 5D 83««. |
| --- | --- | --- | --- |

g)

I afsnit 9.2.1.1 foretages følgende ændringer:

i)

Krav CSM_106, første led, affattes således:

»—

For 128-bit hovednøgler til bevægelsessensorer: CV = »B6 44 2C 45 0E F8 D3 62 0B 7A 8A 97 91 E4 5D 83««.

| ii) | Krav CSM_107, første afsnit, affattes således:

  »Hver fabrikant af bevægelsessensorer genererer en tilfældig og entydig parringsnøgle KP til hver bevægelsessensor og sender hver enkelt parringsnøgle til sin medlemsstats certificeringsmyndighed. MSCA'en krypterer hver parringsnøgle separat med bevægelsessensorens hovednøgle KM og returnerer den krypterede nøgle til fabrikanten af bevægelsessensoren. For hver krypteret nøgle meddeler MSCA'en fabrikanten af bevægelsessensoren versionsnummeret for den tilhørende KM.« |
| --- | --- |

ii)

Krav CSM_107, første afsnit, affattes således:

»Hver fabrikant af bevægelsessensorer genererer en tilfældig og entydig parringsnøgle KP til hver bevægelsessensor og sender hver enkelt parringsnøgle til sin medlemsstats certificeringsmyndighed. MSCA'en krypterer hver parringsnøgle separat med bevægelsessensorens hovednøgle KM og returnerer den krypterede nøgle til fabrikanten af bevægelsessensoren. For hver krypteret nøgle meddeler MSCA'en fabrikanten af bevægelsessensoren versionsnummeret for den tilhørende KM.«

P

M

M

| iii) | Krav CSM_108 affattes således:


  »CSM_108 | Hver fabrikant af bevægelsessensorer genererer et entydigt serienummer til hver bevægelsessensor og sender alle serienumre til sin medlemsstats certificeringsmyndighed. MSCA'en krypterer hvert serienummer separat med identifikationsnøglen KID og returnerer det krypterede serienummer til fabrikanten af bevægelsessensoren. For hvert krypteret serienummer meddeler MSCA'en fabrikanten af bevægelsessensoren versionsnummeret for den tilhørende KID.« |
| --- | --- | --- |

iii)

Krav CSM_108 affattes således:

»CSM_108

Hver fabrikant af bevægelsessensorer genererer et entydigt serienummer til hver bevægelsessensor og sender alle serienumre til sin medlemsstats certificeringsmyndighed. MSCA'en krypterer hvert serienummer separat med identifikationsnøglen KID

ID

| h) | I afsnit 9.2.2.1 foretages følgende ændringer:


  i) | Krav CSM_123 affattes således:


  »CSM_123 | For hver køretøjsenhed skal fabrikanten af køretøjsenheden oprette et entydigt serienummer for køretøjsenheden og sende dette nummer til sin medlemsstats certificeringsmyndighed med en anmodning om at få et sæt bestående af to køretøjsenhedsspecifikke DSRC-nøgler. Køretøjsenhedens serienummer skal have datatypen


.

  Bemærk:


  — | Køretøjsenhedens serienummer skal være identisk med vuSerialNumber-elementet af VuIdentification, se tillæg 1, og henvisningen til certifikatindehaveren i køretøjsenhedens certifikater. |
| --- | --- | --- | --- | --- |

h)

I afsnit 9.2.2.1 foretages følgende ændringer:

i)

Krav CSM_123 affattes således:

»CSM_123

For hver køretøjsenhed skal fabrikanten af køretøjsenheden oprette et entydigt serienummer for køretøjsenheden og sende dette nummer til sin medlemsstats certificeringsmyndighed med en anmodning om at få et sæt bestående af to køretøjsenhedsspecifikke DSRC-nøgler. Køretøjsenhedens serienummer skal have datatypen

  Image 98

.

Bemærk:

Bemærk:

—

Køretøjsenhedens serienummer skal være identisk med vuSerialNumber-elementet af VuIdentification, se tillæg 1, og henvisningen til certifikatindehaveren i køretøjsenhedens certifikater.

| — | Køretøjsenhedens serienummer er måske ikke kendt på det tidspunkt, hvor en fabrikant af køretøjsenheder anmoder om de køretøjsenhedsspecifikke DSRC-nøgler. I dette tilfælde skal fabrikanten af køretøjsenheden i stedet sende den unikke ID for certifikatanmodningen, som fabrikanten anvendte i forbindelse med anmodningen om køretøjsenhedens certifikater; se CSM_153. Denne ID for certifikatanmodningen skal derfor svare til henvisningen til certifikatindehaveren i køretøjsenhedens certifikater.« |
| --- | --- |

—

Køretøjsenhedens serienummer er måske ikke kendt på det tidspunkt, hvor en fabrikant af køretøjsenheder anmoder om de køretøjsenhedsspecifikke DSRC-nøgler. I dette tilfælde skal fabrikanten af køretøjsenheden i stedet sende den unikke ID for certifikatanmodningen, som fabrikanten anvendte i forbindelse med anmodningen om køretøjsenhedens certifikater; se CSM_153. Denne ID for certifikatanmodningen skal derfor svare til henvisningen til certifikatindehaveren i køretøjsenhedens certifikater.«

| ii) | Krav CSM_124, kravet info i trin 2, affattes således:

  »info = køretøjsenhedens serienummer eller certifikatanmodningens ID som specificeret i krav CSM_123«. |
| --- | --- |

ii)

Krav CSM_124, kravet info i trin 2, affattes således:

info

»info = køretøjsenhedens serienummer eller certifikatanmodningens ID som specificeret i krav CSM_123«.

| iii) | Krav CSM_128 affattes således:


  »CSM_128 | MSCA'en fører registre over alle køretøjsenhedsspecifikke DSRC-nøgler, som den har genereret, deres versionsnummer og serienummer eller certifikatanmodningens ID for den køretøjsenhed, der anvendes til at generere dem.« |
| --- | --- | --- |

iii)

Krav CSM_128 affattes således:

»CSM_128

MSCA'en fører registre over alle køretøjsenhedsspecifikke DSRC-nøgler, som den har genereret, deres versionsnummer og serienummer eller certifikatanmodningens ID for den køretøjsenhed, der anvendes til at generere dem.«

| i) | Punkt 9.3.1, krav CSM_135, første afsnit, affattes således:

  »Distinguished Encoding Rules (DER) i henhold til [ISO 8825-1] skal anvendes til kodning af dataobjekter i certifikater. Tabel 4 viser den fuldstændige certifikatkodning, herunder alle etiket- og længdebytes.« |
| --- | --- |

i)

Punkt 9.3.1, krav CSM_135, første afsnit, affattes således:

»Distinguished Encoding Rules (DER) i henhold til [ISO 8825-1] skal anvendes til kodning af dataobjekter i certifikater. Tabel 4 viser den fuldstændige certifikatkodning, herunder alle etiket- og længdebytes.«

| j) | Afsnit 9.3.2.3, krav CSM_141, affattes således:


  »CSM_141 | Certifikatindehavers autorisation anvendes til at identificere typen af certifikat. Den består af de seks mest betydende byte i takografens applikations-ID sammenføjet med den type udstyr, som angiver den type udstyr, certifikatet er beregnet til. I tilfælde af et køretøjsenhedscertifikat, et førerkortcertifikat eller et værkstedskortscertifikat anvendes udstyrstypen også til at skelne mellem et certifikat for gensidig ægthedskontrol og et certifikat til at generere digitale underskrifter (se afsnit 9.1 og tillæg 1, datatypen Equipment Type).« |
| --- | --- | --- |

j)

Afsnit 9.3.2.3, krav CSM_141, affattes således:

»CSM_141

Certifikatindehavers autorisation anvendes til at identificere typen af certifikat. Den består af de seks mest betydende byte i takografens applikations-ID sammenføjet med den type udstyr, som angiver den type udstyr, certifikatet er beregnet til. I tilfælde af et køretøjsenhedscertifikat, et førerkortcertifikat eller et værkstedskortscertifikat anvendes udstyrstypen også til at skelne mellem et certifikat for gensidig ægthedskontrol og et certifikat til at generere digitale underskrifter (se afsnit 9.1 og tillæg 1, datatypen Equipment Type).«

| k) | I afsnit 9.3.2.5, krav CSM_146, indsættes følgende afsnit:

  »
  Bemærk: For et kortcertifikat skal værdien af CHR svare til værdien af cardExtendedSerialNumber i EF_ICC; se tillæg 2. For et EGF-certifikat skal værdien af CHR svare til værdien af sensorGNSSSerialNumber i EF_ICC; se tillæg 14. For et køretøjsenhedscertifikat skal værdien af CHR svare til vuSerialNumber-elementet af VuIdentification, se tillæg 1, medmindre fabrikanten ikke kender det fabrikantspecifikke serienummer på det tidspunkt, hvor der anmodes om certifikatet.« |
| --- | --- |

k)

I afsnit 9.3.2.5, krav CSM_146, indsættes følgende afsnit:

»
  Bemærk: For et kortcertifikat skal værdien af CHR svare til værdien af cardExtendedSerialNumber i EF_ICC; se tillæg 2. For et EGF-certifikat skal værdien af CHR svare til værdien af sensorGNSSSerialNumber i EF_ICC; se tillæg 14. For et køretøjsenhedscertifikat skal værdien af CHR svare til vuSerialNumber-elementet af VuIdentification, se tillæg 1, medmindre fabrikanten ikke kender det fabrikantspecifikke serienummer på det tidspunkt, hvor der anmodes om certifikatet.«

Bemærk

| l) | Afsnit 9.3.2.6, krav CSM_148, affattes således:


  »CSM_148 | Certifikatets faktiske gyldighedsdato angiver startdato og -tidspunkt for certifikatets gyldighedsperiode.« |
| --- | --- | --- |

l)

Afsnit 9.3.2.6, krav CSM_148, affattes således:

»CSM_148

Certifikatets faktiske gyldighedsdato angiver startdato og -tidspunkt for certifikatets gyldighedsperiode.«

| m) | I afsnit 9.3.3 foretages følgende ændringer:


  i) | Krav CSM_151, første afsnit, affattes således:

  »Når der anmodes om et certifikat, sender MSCA'en følgende data til ERCA'en:«. |
| --- | --- | --- |

m)

I afsnit 9.3.3 foretages følgende ændringer:

i)

Krav CSM_151, første afsnit, affattes således:

»Når der anmodes om et certifikat, sender MSCA'en følgende data til ERCA'en:«.

| ii) | Krav CSM_153 affattes således:


  »CSM_153 | En udstyrsfabrikant skal sende følgende data til en MSCA i anmodningen om et certifikat, således at MSCA'en får mulighed for at oprette henvisningen til certifikatindehaveren for det nye udstyrscertifikat:


  — | Hvis dette kendes (se CSM_154), et serienummer for udstyret, som er entydigt for fabrikanten, udstyrstypen og produktionsmåneden. Ellers en entydig identifikator for certifikatanmodningen |
| --- | --- | --- | --- |

ii)

Krav CSM_153 affattes således:

»CSM_153

En udstyrsfabrikant skal sende følgende data til en MSCA i anmodningen om et certifikat, således at MSCA'en får mulighed for at oprette henvisningen til certifikatindehaveren for det nye udstyrscertifikat:

—

Hvis dette kendes (se CSM_154), et serienummer for udstyret, som er entydigt for fabrikanten, udstyrstypen og produktionsmåneden. Ellers en entydig identifikator for certifikatanmodningen

| — | Måned og år for produktionen af udstyret eller for anmodningen om certifikatet. |
| --- | --- |

—

Måned og år for produktionen af udstyret eller for anmodningen om certifikatet.

Fabrikanten skal sikre, at disse data er korrekte, og at det certifikat, der sendes tilbage af MSCA'en, sættes i det planlagte udstyr.«

| n) | I afsnit 10.2.1 foretages følgende ændringer:


  i) | Krav CSM_157, teksten før bemærkningerne til figur 4, affattes således:

  »Køretøjsenheder skal anvende den protokol, der beskrives i Figur 4, til at verificere takografkorts certifikatkæde. For hvert certifikat, som den læser fra kortet, skal køretøjsenheden kontrollere, at CHA-feltet (Certificate Holder Authorisation) er korrekt:


  — | Kortcertifikatets CHA-felt skal angive et kortcertifikat til brug for gensidig ægthedskontrol (se tillæg 1, datatypen Equipment Type). |
| --- | --- | --- | --- |

n)

I afsnit 10.2.1 foretages følgende ændringer:

i)

Krav CSM_157, teksten før bemærkningerne til figur 4, affattes således:

»Køretøjsenheder skal anvende den protokol, der beskrives i Figur 4, til at verificere takografkorts certifikatkæde. For hvert certifikat, som den læser fra kortet, skal køretøjsenheden kontrollere, at CHA-feltet (Certificate Holder Authorisation) er korrekt:

—

Kortcertifikatets CHA-felt skal angive et kortcertifikat til brug for gensidig ægthedskontrol (se tillæg 1, datatypen Equipment Type).

| — | CHA'en på Card.CA-certifikatet skal angive en MSCA. |
| --- | --- |

—

CHA'en på Card.CA-certifikatet skal angive en MSCA.

| — | CHA'en på Card.Link-certifikatet skal angive ERCA'en.« |
| --- | --- |

—

CHA'en på Card.Link-certifikatet skal angive ERCA'en.«

| ii) | I krav CSM_159 tilføjes følgende punktum:

  »Det er fakultativt at opbevare alle andre typer certifikater, men det er obligatorisk for en køretøjsenhed at opbevare et nyt forbindelsescertifikat, som præsenteres af et kort.« |
| --- | --- |

ii)

I krav CSM_159 tilføjes følgende punktum:

»Det er fakultativt at opbevare alle andre typer certifikater, men det er obligatorisk for en køretøjsenhed at opbevare et nyt forbindelsescertifikat, som præsenteres af et kort.«

| o) | I afsnit 10.2.2 foretages følgende ændringer:


  i) | Krav CSM_161, teksten før bemærkningerne til figur 5, affattes således:

  »Takografkort skal benytte den protokol, der illustreres i Figur 5 til verifikation af en køretøjsenheds certifikatkæde. For hvert certifikat, som sendes af køretøjsenheden, skal kortet kontrollere, at CHA-feltet (Card Holder Authorisation) er korrekt:


  — | CHA'en på VU.Link-certifikatet skal angive ERCA'en. |
| --- | --- | --- | --- |

o)

I afsnit 10.2.2 foretages følgende ændringer:

i)

Krav CSM_161, teksten før bemærkningerne til figur 5, affattes således:

»Takografkort skal benytte den protokol, der illustreres i Figur 5 til verifikation af en køretøjsenheds certifikatkæde. For hvert certifikat, som sendes af køretøjsenheden, skal kortet kontrollere, at CHA-feltet (Card Holder Authorisation) er korrekt:

—

CHA'en på VU.Link-certifikatet skal angive ERCA'en.

| — | CHA'en på VU.CA-certifikatet skal angive en MSCA. |
| --- | --- |

—

CHA'en på VU.CA-certifikatet skal angive en MSCA.

| — | Køretøjsenhedscertifikatets CHA-felt skal angive et køretøjsenhedscertifikat til brug for gensidig ægthedskontrol (se tillæg 1, datatypen Equipment Type).« |
| --- | --- |

—

Køretøjsenhedscertifikatets CHA-felt skal angive et køretøjsenhedscertifikat til brug for gensidig ægthedskontrol (se tillæg 1, datatypen Equipment Type).«

| ii) | Krav CSM_165 affattes således:


  »CSM_165 | Hvis kommandoen MSE: Set AT giver et positivt resultat, angiver kortet den angivne VU.PK til efterfølgende brug under ægthedskontrol af køretøjet og gemmer Comp(VU.PKeph) midlertidigt. Hvis der sendes to eller flere vellykkede MSE: Set AT-kommandoer, inden overensstemmelseskontrollen af sessionsnøglen gennemføres, gemmer kortet kun den seneste modtagne Comp(VU.PKeph). Kortet skal nulstille Comp(VU.PKeph) efter et positivt resultat af kommandoen GENERAL AUTHENTICATE.« |
| --- | --- | --- |

ii)

Krav CSM_165 affattes således:

»CSM_165

Hvis kommandoen MSE: Set AT giver et positivt resultat, angiver kortet den angivne VU.PK til efterfølgende brug under ægthedskontrol af køretøjet og gemmer Comp(VU.PKeph) midlertidigt. Hvis der sendes to eller flere vellykkede MSE: Set AT-kommandoer, inden overensstemmelseskontrollen af sessionsnøglen gennemføres, gemmer kortet kun den seneste modtagne Comp(VU.PKeph). Kortet skal nulstille Comp(VU.PKeph) efter et positivt resultat af kommandoen GENERAL AUTHENTICATE.«

| p) | I afsnit 10.3 foretages følgende ændringer:


  i) | Krav CSM_170, første afsnit, affattes således:

  »Ud over kortets anmodning skal køretøjsenheden i underskriften medtage henvisningen til certifikatindehaveren hentet fra kortets certifikat.« |
| --- | --- | --- |

p)

I afsnit 10.3 foretages følgende ændringer:

i)

Krav CSM_170, første afsnit, affattes således:

»Ud over kortets anmodning skal køretøjsenheden i underskriften medtage henvisningen til certifikatindehaveren hentet fra kortets certifikat.«

| ii) | I krav CSM_171 erstattes figur 6 af følgende figur:

  »
  Figur 6


  Protokol til ægthedskontrol af køretøjsenhed


  « |
| --- | --- |

ii)

I krav CSM_171 erstattes figur 6 af følgende figur:

»
  Figur 6

Figur 6

Protokol til ægthedskontrol af køretøjsenhed

Protokol til ægthedskontrol af køretøjsenhed

Image 99

  «

| iii) | Krav CSM_174 affattes således:


  »CSM_174 | Efter modtagelsen af køretøjsenhedens underskrift i en EXTERNAL AUTHENTICATE-kommando gør kortet følgende:


  — | Beregner token for ægthedskontrol ved at sammenføre Card.CHR, kortets anmodning rcard og identifikatoren for køretøjsenhedens midlertidige offentlige nøgle Comp(VU.PKeph) |
| --- | --- | --- | --- |

iii)

Krav CSM_174 affattes således:

»CSM_174

Efter modtagelsen af køretøjsenhedens underskrift i en EXTERNAL AUTHENTICATE-kommando gør kortet følgende:

—

Beregner token for ægthedskontrol ved at sammenføre Card.CHR, kortets anmodning rcard og identifikatoren for køretøjsenhedens midlertidige offentlige nøgle Comp(VU.PKeph)

| — | Verificerer køretøjsenhedens underskrift ved at benytte ECDSA-algoritmen ved hjælp af hash-algoritmen, der er sammenkædet med nøglestørrelsen af køretøjsenhedens VU_MA-nøglepar som specificeret i CSM_50, i kombination med VU.PK og den beregnede token for ægthedskontrol.« |
| --- | --- |

—

Verificerer køretøjsenhedens underskrift ved at benytte ECDSA-algoritmen ved hjælp af hash-algoritmen, der er sammenkædet med nøglestørrelsen af køretøjsenhedens VU_MA-nøglepar som specificeret i CSM_50, i kombination med VU.PK og den beregnede token for ægthedskontrol.«

| q) | I afsnit 10.4, krav CSM_176, foretages følgende ændringer:


  i) | Underafsnit 2 affattes således:


  »2 | Køretøjsenheden sender det offentlige punkt VU.PKeph for sit midlertidige nøglepar til kortet. Det offentlige punkt konverteres til en oktetstreng som specificeret i [TR-03111]. Det ukomprimerede kodningsformat skal benyttes. Som forklaret i CSM_164 genererede køretøjsenheden dette midlertidige nøglepar inden verifikationen af køretøjsenhedens certifikatkæde. Køretøjsenheden sendte identifikatoren for den midlertidige offentlige nøgle Comp(VU.PKeph) til kortet, og kortet gemte den.« |
| --- | --- | --- | --- |

q)

I afsnit 10.4, krav CSM_176, foretages følgende ændringer:

i)

Underafsnit 2 affattes således:

»2

Køretøjsenheden sender det offentlige punkt VU.PKeph for sit midlertidige nøglepar til kortet. Det offentlige punkt konverteres til en oktetstreng som specificeret i [TR-03111]. Det ukomprimerede kodningsformat skal benyttes. Som forklaret i CSM_164 genererede køretøjsenheden dette midlertidige nøglepar inden verifikationen af køretøjsenhedens certifikatkæde. Køretøjsenheden sendte identifikatoren for den midlertidige offentlige nøgle Comp(VU.PKeph) til kortet, og kortet gemte den.«

eph

eph

| ii) | Underafsnit 6 affattes således:


  »6 | Ved hjælp af KMAC beregner kortet et token til ægthedskontrol ud fra køretøjsenhedens midlertidige offentlige nøgle: TPICC = CMAC(KMAC, VU.PKeph). Det offentlige punkt skal være i det format, der anvendes af køretøjsenheden (se underafsnit 2). Kortet sender NPICC og TPICC til køretøjsenheden.« |
| --- | --- | --- |

ii)

Underafsnit 6 affattes således:

»6

Ved hjælp af KMAC beregner kortet et token til ægthedskontrol ud fra køretøjsenhedens midlertidige offentlige nøgle: TPICC = CMAC(KMAC, VU.PKeph). Det offentlige punkt skal være i det format, der anvendes af køretøjsenheden (se underafsnit 2). Kortet sender NPICC og TPICC til køretøjsenheden.«

MAC

PICC

MAC

eph

PICC

PICC

| r) | Afsnit 10.5.2, krav CSM_191, affattes således:


  »CSM_191 | Alle dataobjekter, der skal krypteres, udfyldes i henhold til [ISO 7816-4] med udfyldningsindikatoren »01«. Ved beregningen af MAC'en skal dataobjekter i APDU'en udfyldes i henhold til [ISO 7816-4].

  Bemærk: Udfyldning til sikker meddelelsesoverførsel udføres altid af det sikre meddelelseslag, ikke af CMAC- eller CBC-algoritmerne. |
| --- | --- | --- |

r)

Afsnit 10.5.2, krav CSM_191, affattes således:

»CSM_191

Alle dataobjekter, der skal krypteres, udfyldes i henhold til [ISO 7816-4] med udfyldningsindikatoren »01«. Ved beregningen af MAC'en skal dataobjekter i APDU'en udfyldes i henhold til [ISO 7816-4].

Bemærk: Udfyldning til sikker meddelelsesoverførsel udføres altid af det sikre meddelelseslag, ikke af CMAC- eller CBC-algoritmerne.

Bemærk:

Sammenfatning og eksempler

Sammenfatning og eksempler

En kommando-APDU med anvendt sikker meddelelsesoverførsel vil have følgende struktur afhængigt af alternativet for den respektive ikke-sikrede kommando (DO står for dataobjekt):

| Alternativ 1 | : | CLA INS P1 P2 Lc' DO »8E« Le |
| --- | --- | --- |
| Alternativ 2 | : | CLA INS P1 P2 Lc' DO »97« DO»8E« Le |
| Alternativ 3 (lige INS-byte) | : | CLA INS P1 P2 Lc' DO »81« DO»8E« Le |
| Alternativ 3 (ulige INS-byte) | : | CLA INS P1 P2 Lc' DO »B3« DO»8E« Le |
| Alternativ 4 (lige INS-byte) | : | CLA INS P1 P2 Lc' DO »81« DO»97« DO»8E« Le |
| Alternativ 4 (ulige INS-byte) | : | CLA INS P1 P2 Lc' DO »B3« DO»97« DO»8E« Le |

Alternativ 1

:

CLA INS P1 P2 Lc' DO »8E« Le

Alternativ 2

:

CLA INS P1 P2 Lc' DO »97« DO»8E« Le

Alternativ 3 (lige INS-byte)

:

CLA INS P1 P2 Lc' DO »81« DO»8E« Le

Alternativ 3 (ulige INS-byte)

:

CLA INS P1 P2 Lc' DO »B3« DO»8E« Le

Alternativ 4 (lige INS-byte)

:

CLA INS P1 P2 Lc' DO »81« DO»97« DO»8E« Le

Alternativ 4 (ulige INS-byte)

:

CLA INS P1 P2 Lc' DO »B3« DO»97« DO»8E« Le

Hvor Le = »00« eller »00 00« afhængigt af, hvorvidt der benyttes felter med kort længde eller felter med udvidet længde; se [ISO 7816-4].

En svar-APDU med anvendt sikker meddelelsesoverførsel vil have følgende struktur afhængigt af alternativet for det respektive ikke-sikrede svar:

| Alternativ 1 eller 3 | : | DO »99« DO »8E« SW1SW2 |
| --- | --- | --- |
| Alternativ 2 eller 4 (lige INS-byte) uden kryptering | : | DO »81« DO »99« DO »8E« SW1SW2 |
| Alternativ 2 eller 4 (lige INS-byte) med kryptering | : | DO »87« DO »99« DO »8E« SW1SW2 |
| Alternativ 2 eller 4 (ulige INS-byte) uden kryptering | : | DO »B3« DO »99« DO »8E« SW1SW2 |

Alternativ 1 eller 3

:

DO »99« DO »8E« SW1SW2

Alternativ 2 eller 4 (lige INS-byte) uden kryptering

:

DO »81« DO »99« DO »8E« SW1SW2

Alternativ 2 eller 4 (lige INS-byte) med kryptering

:

DO »87« DO »99« DO »8E« SW1SW2

Alternativ 2 eller 4 (ulige INS-byte) uden kryptering

:

DO »B3« DO »99« DO »8E« SW1SW2

Bemærk: Alternativ 2 eller 4 (ulige INS-byte) med kryptering anvendes aldrig i kommunikationen mellem en køretøjsenhed og et kort.

Bemærk:

Herunder gives tre eksempler på APDU-transformationer for kommandoer med lige INS-kode. Figur 8 viser en autentificeret Alternativ 4-kommando-APDU, Figur 9 viser en autentificeret Alternativ 1-/Alternativ 3-svar-APDU, og Figur 10 viser en krypteret og autentificeret Alternativ 2-/Alternativ 4-svar-APDU.

Figur 8

Figur 8

Transformation af en autentificeret Alternativ 4-kommando-APDU

Transformation af en autentificeret Alternativ 4-kommando-APDU

Image 100

Figur 9

Figur 9

Transformation af en autentificeret Alternativ 1-/Alternativ 3-svar-APDU

Transformation af en autentificeret Alternativ 1-/Alternativ 3-svar-APDU

Image 101

Figur 10

Figur 10

Transformation af et krypteret og autentificeret Alternativ 2-/Alternativ 4-svar-APDU

Transformation af et krypteret og autentificeret Alternativ 2-/Alternativ 4-svar-APDU

Image 102

  «

| s) | Afsnit 10.5.3, krav CSM_193, affattes således:


  »CSM_193 | Et takografkort afbryder en igangværende sikker meddelelsesoverførselssession, hvis, og kun hvis et af følgende forhold gør sig gældende:


  — | Det modtager en APDU-kommando i klartekst. |
| --- | --- | --- | --- |

s)

Afsnit 10.5.3, krav CSM_193, affattes således:

»CSM_193

Et takografkort afbryder en igangværende sikker meddelelsesoverførselssession, hvis, og kun hvis et af følgende forhold gør sig gældende:

—

Det modtager en APDU-kommando i klartekst.

| — | Det konstaterer en fejl i den sikre meddelelsesoverførsel i en kommando-APDU:


  — | Et forventet dataobjekt i en sikker meddelelsesoverførsel mangler, rækkefølgen af dataobjekter er forkert, eller der er medtaget et ukendt dataobjekt. |
| --- | --- | --- |

—

Det konstaterer en fejl i den sikre meddelelsesoverførsel i en kommando-APDU:

—

Et forventet dataobjekt i en sikker meddelelsesoverførsel mangler, rækkefølgen af dataobjekter er forkert, eller der er medtaget et ukendt dataobjekt.

| — | Et dataobjekt i en sikker meddelelsesoverførsel er forkert, f.eks. er MAC-værdien forkert, eller TLV-strukturen er forkert. |
| --- | --- |

—

Et dataobjekt i en sikker meddelelsesoverførsel er forkert, f.eks. er MAC-værdien forkert, eller TLV-strukturen er forkert.

| — | Strømmen afbrydes, eller enheden nulstilles. |
| --- | --- |

—

Strømmen afbrydes, eller enheden nulstilles.

| — | Køretøjsenheden indleder processen med ægthedskontrol af køretøjsenheden. |
| --- | --- |

—

Køretøjsenheden indleder processen med ægthedskontrol af køretøjsenheden.

| — | Grænsen for antallet af kommandoer og tilhørende svar inden for den aktuelle session er nået. For et bestemt kort defineres denne grænse af fabrikanten under hensyntagen til sikkerhedskravene for den anvendte hardware med et maksimum på 240 SM-kommandoer og tilhørende svar pr. session.« |
| --- | --- |

—

Grænsen for antallet af kommandoer og tilhørende svar inden for den aktuelle session er nået. For et bestemt kort defineres denne grænse af fabrikanten under hensyntagen til sikkerhedskravene for den anvendte hardware med et maksimum på 240 SM-kommandoer og tilhørende svar pr. session.«

| t) | I afsnit 11.3.2 foretages følgende ændringer:


  i) | Krav CSM_208, første afsnit, affattes således:

  »Under sammenkoblingen med en køretøjsenhed benytter eksternt GNSS-udstyr den protokol, der beskrives i Figur 5 (afsnit 10.2.2) til verifikation af køretøjsenhedens certifikatkæde.« |
| --- | --- | --- |

t)

I afsnit 11.3.2 foretages følgende ændringer:

i)

Krav CSM_208, første afsnit, affattes således:

»Under sammenkoblingen med en køretøjsenhed benytter eksternt GNSS-udstyr den protokol, der beskrives i Figur 5 (afsnit 10.2.2) til verifikation af køretøjsenhedens certifikatkæde.«

| ii) | Krav CSM_210 affattes således:


  »CSM_210 | Når det eksterne GNSS-udstyr har verificeret VU_MA-certifikatet, gemmer den dette certifikat til brug under normal drift; se afsnit 11.3.3.« |
| --- | --- | --- |

ii)

Krav CSM_210 affattes således:

»CSM_210

Når det eksterne GNSS-udstyr har verificeret VU_MA-certifikatet, gemmer den dette certifikat til brug under normal drift; se afsnit 11.3.3.«

| u) | Afsnit 11.3.3, krav CSM_211, første afsnit, affattes således:

  »Under normal drift benytter en køretøjsenhed og en EGF den protokol, der beskrives i Figur 11 til verifikation af den tidsmæssige gyldighed af det gemte EGF_MA-certifikat og til at indstille den offentlige VU_MA-nøgle til efterfølgende ægthedskontrol af køretøjsenheden. Der foretages ingen yderligere gensidig verificering af certifikatkæderne under normal drift.« |
| --- | --- |

u)

Afsnit 11.3.3, krav CSM_211, første afsnit, affattes således:

»Under normal drift benytter en køretøjsenhed og en EGF den protokol, der beskrives i Figur 11 til verifikation af den tidsmæssige gyldighed af det gemte EGF_MA-certifikat og til at indstille den offentlige VU_MA-nøgle til efterfølgende ægthedskontrol af køretøjsenheden. Der foretages ingen yderligere gensidig verificering af certifikatkæderne under normal drift.«

| v) | I afsnit 12.3 erstattes tabel 6 af følgende tabel:
  »Tabel 6


  Antal databyte i klartekst og krypteret form pr. instruktion defineret i [ISO 16844-3]


  Instruktion | Anmodning/svar | Beskrivelse af data | Antal databyte i klartekst i henhold til
  [ISO 16844-3] | Antal databyte i klartekst ved brug af AES-nøgler | Antal krypterede databyte ved brug af AES-nøgler med en bitlængde på |
| --- | --- | --- | --- | --- | --- | --- |
| 128 | 192 | 256 |
| 10 | anmodning | Ægthedskontroldata + filnummer | 8 | 8 | 16 | 16 | 16 |
| 11 | svar | Ægthedskontroldata + filindhold | 16 eller 32, afhænger af filen | 16 eller 32, afhænger af filen | 32 / 48 | 32 / 48 | 32 / 48 |
| 41 | anmodning | MoS-serienummer | 8 | 8 | 16 | 16 | 16 |
| 41 | svar | Parringsnøgle | 16 | 16 / 24 / 32 | 16 | 32 | 32 |
| 42 | anmodning | Sessionsnøgle | 16 | 16 / 24 / 32 | 16 | 32 | 32 |
| 43 | anmodning | Parringsoplysninger | 24 | 24 | 32 | 32 | 32 |
| 50 | svar | Parringsoplysninger | 24 | 24 | 32 | 32 | 32 |
| 70 | anmodning | Ægthedskontroldata | 8 | 8 | 16 | 16 | 16 |
| 80 | svar | MoS-tællerværdi + ægthedskontroldata | 8 | 8 | 16 | 16 | 16« |

v)

I afsnit 12.3 erstattes tabel 6 af følgende tabel:

»Tabel 6

Tabel 6

Antal databyte i klartekst og krypteret form pr. instruktion defineret i [ISO 16844-3]

Antal databyte i klartekst og krypteret form pr. instruktion defineret i [ISO 16844-3]

Instruktion

Anmodning/svar

Beskrivelse af data

Antal databyte i klartekst i henhold til

[ISO 16844-3]

Antal databyte i klartekst ved brug af AES-nøgler

Antal krypterede databyte ved brug af AES-nøgler med en bitlængde på

128

192

256

10

anmodning

Ægthedskontroldata + filnummer

8

8

16

16

16

11

svar

Ægthedskontroldata + filindhold

16 eller 32, afhænger af filen

16 eller 32, afhænger af filen

32 / 48

32 / 48

32 / 48

41

anmodning

MoS-serienummer

8

8

16

16

16

41

svar

Parringsnøgle

16

16 / 24 / 32

16

32

32

42

anmodning

Sessionsnøgle

16

16 / 24 / 32

16

32

32

43

anmodning

Parringsoplysninger

24

24

32

32

32

50

svar

Parringsoplysninger

24

24

32

32

32

70

anmodning

Ægthedskontroldata

8

8

16

16

16

80

svar

MoS-tællerværdi + ægthedskontroldata

8

8

16

16

16«

| w) | Afsnit 13.1, krav CSM_224, kravet til køretøjsenheden serienummer, affattes således:


  »køretøjsenhedens serienummer | køretøjsenhedens serienummer eller certifikatanmodningens ID (datatype VuSerialNumber eller CertificateRequestID) – se krav CSM_123«. |
| --- | --- | --- |

w)

Afsnit 13.1, krav CSM_224, kravet til køretøjsenheden serienummer, affattes således:

»køretøjsenhedens serienummer

køretøjsenhedens serienummer

køretøjsenhedens serienummer eller certifikatanmodningens ID (datatype VuSerialNumber eller CertificateRequestID) – se krav CSM_123«.

| x) | Afsnit 13.3, krav CSM_228, underafsnit 2, affattes således:


  »2 | Kontrolkortet bruger den angivne DSRC-hovednøgle i kombination med køretøjsenhedens serienummer eller certifikatanmodningens ID i DSRC-sikkerhedsdataene til at udlede de køretøjsenhedsspecifikke DSRC-nøgler K_VUDSRC_ENC og K_VUDSRC_MAC som specificeret i krav CSM_124.« |
| --- | --- | --- |

x)

Afsnit 13.3, krav CSM_228, underafsnit 2, affattes således:

»2

Kontrolkortet bruger den angivne DSRC-hovednøgle i kombination med køretøjsenhedens serienummer eller certifikatanmodningens ID i DSRC-sikkerhedsdataene til at udlede de køretøjsenhedsspecifikke DSRC-nøgler K_VUDSRC_ENC og K_VUDSRC_MAC som specificeret i krav CSM_124.«

DSRC

DSRC

| y) | I afsnit 14.3 foretages følgende ændringer:


  i) | Krav CSM_234, teksten før bemærkningerne til figur 13, affattes således:

  »En IDE kan foretage verifikation af en underskrift ud fra selve de overførte data eller kan benytte et kontrolkort til dette. Hvis det anvender et kontrolkort, skal verifikationen foregå som vist i Figur 13. Kontrolkortet anvender sit interne ur til at verificere den tidsmæssige gyldighed af et certifikat, som sendes af IDE-udstyret, som specificeret i krav CSM_167. Kontrolkortet ajourfører sit aktuelle tidspunkt, hvis den faktiske dato for et autentisk »gyldig tidsangiver«-certifikat er nyere end kortets aktuelle tidspunkt. Kortet accepterer kun følgende certifikater som gyldig tidsangiver:


  — | ERCA-forbindelsescertifikater af anden generation |
| --- | --- | --- | --- |

y)

I afsnit 14.3 foretages følgende ændringer:

i)

Krav CSM_234, teksten før bemærkningerne til figur 13, affattes således:

»En IDE kan foretage verifikation af en underskrift ud fra selve de overførte data eller kan benytte et kontrolkort til dette. Hvis det anvender et kontrolkort, skal verifikationen foregå som vist i Figur 13. Kontrolkortet anvender sit interne ur til at verificere den tidsmæssige gyldighed af et certifikat, som sendes af IDE-udstyret, som specificeret i krav CSM_167. Kontrolkortet ajourfører sit aktuelle tidspunkt, hvis den faktiske dato for et autentisk »gyldig tidsangiver«-certifikat er nyere end kortets aktuelle tidspunkt. Kortet accepterer kun følgende certifikater som gyldig tidsangiver:

—

ERCA-forbindelsescertifikater af anden generation

| — | MSCA-certifikater af anden generation |
| --- | --- |

—

MSCA-certifikater af anden generation

| — | VU_Sign- eller Card_Sign-certifikater af anden generation, som er udstedt af samme land som kontrolkortets eget kortcertifikat. |
| --- | --- |

—

VU_Sign- eller Card_Sign-certifikater af anden generation, som er udstedt af samme land som kontrolkortets eget kortcertifikat.

Hvis det selv foretager verifikationen af underskriften, skal IDE-udstyret verificere ægtheden og gyldigheden af alle certifikater i certifikatkæden i datafilen, og det skal verificere underskriften ud fra dataene i henhold til den underskriftsmetode, der defineres i [DSS]. I begge tilfælde er det for hvert certifikat, der læses fra datafilen, nødvendigt at kontrollere, at CHA-feltet (Card Holder Authorisation) er korrekt:

| — | EQT-certifikatets CHA-felt skal angive et køretøjsenheds- eller kortcertifikat (alt efter hvad der er relevant) til brug ved underskrift (se tillæg 1, datatypen Equipment Type). |
| --- | --- |

—

EQT-certifikatets CHA-felt skal angive et køretøjsenheds- eller kortcertifikat (alt efter hvad der er relevant) til brug ved underskrift (se tillæg 1, datatypen Equipment Type).

| — | CHA'en på EQT.CA-certifikatet skal angive en MSCA. |
| --- | --- |

—

CHA'en på EQT.CA-certifikatet skal angive en MSCA.

| — | CHA'en på EQT.Link-certifikatet skal angive ERCA'en.« |
| --- | --- |

—

CHA'en på EQT.Link-certifikatet skal angive ERCA'en.«

| ii) | Figur 13 erstattes af følgende figur:

  »
  Figur 13


  Protokol til verifikation af underskriften ud fra en overført datafil


  « |
| --- | --- |

ii)

Figur 13 erstattes af følgende figur:

»
  Figur 13

Figur 13

Protokol til verifikation af underskriften ud fra en overført datafil

Protokol til verifikation af underskriften ud fra en overført datafil

Image 103

  «

| 37) | I tillæg 12 foretages følgende ændringer:


  a) | I afsnit 3 foretages følgende ændringer:


  i) | Krav GNS_4, andet afsnit efter figur 2, affattes således:

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

37)

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

a)

I afsnit 3 foretages følgende ændringer:

i)

Krav GNS_4, andet afsnit efter figur 2, affattes således:

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

| ii) | Krav GNS_5 affattes således:


  »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) til at afgøre og registrere signalets tilgængelighed og nøjagtighed. 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 3


  GSA-sætningens struktur


  « |
| --- | --- | --- |

ii)

Krav GNS_5 affattes således:

»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) til at afgøre og registrere signalets tilgængelighed og nøjagtighed. 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 3

Figur 3

GSA-sætningens struktur

GSA-sætningens struktur

Image 104

  «

| iii) | Krav GNS_6 affattes således:


  »GNS_6 | GSA-sætningen gemmes med registreringsnummer »02« til »06«.« |
| --- | --- | --- |

iii)

Krav GNS_6 affattes således:

»GNS_6

GSA-sætningen gemmes med registreringsnummer »02« til »06«.«

| b) | I afsnit 4.2.1 foretages følgende ændringer:


  i) | Krav GNS_16 affattes således:


  »GNS_16 | Kommunikationsprotokollen understøtter ikke felter med udvidet længde.« |
| --- | --- | --- | --- |

b)

I afsnit 4.2.1 foretages følgende ændringer:

i)

Krav GNS_16 affattes således:

»GNS_16

Kommunikationsprotokollen understøtter ikke felter med udvidet længde.«

| ii) | Krav GNS_18 affattes således:


  »GNS_18 | Hvad angår funktionerne 1) indsamling og distribution af GNSS-data, 2) indsamling af konfigurationsdata for det eksterne GNSS-udstyr og 3) administrationsprotokollen, skal den sikre GNSS-sender/modtager simulere et intelligent kort med en filsystemarkitektur bestående af en masterfil (MF), en dedikeret fil (DF) med en applikations-ID som specificeret i tillæg 1, afsnit 6.2 (»FF 44 54 45 47 4D«) og med 3 elementærfiler, der indeholder certifikater og en enkelt elementærfil (EF.EGF) med en filidentifikator lig med »2F2F« som beskrevet i tabel 1.« |
| --- | --- | --- |

ii)

Krav GNS_18 affattes således:

»GNS_18

Hvad angår funktionerne 1) indsamling og distribution af GNSS-data, 2) indsamling af konfigurationsdata for det eksterne GNSS-udstyr og 3) administrationsprotokollen, skal den sikre GNSS-sender/modtager simulere et intelligent kort med en filsystemarkitektur bestående af en masterfil (MF), en dedikeret fil (DF) med en applikations-ID som specificeret i tillæg 1, afsnit 6.2 (»FF 44 54 45 47 4D«) og med 3 elementærfiler, der indeholder certifikater og en enkelt elementærfil (EF.EGF) med en filidentifikator lig med »2F2F« som beskrevet i tabel 1.«

| iii) | Krav GNS_20 affattes således:


  »GNS_20 | Den sikre GNSS-sender/modtager bruger en hukommelse til at gemme data, som kan udføre mindst 20 millioner skrive/læse-cykler. Bortset fra dette aspekt overlades det interne design og implementeringen af den sikre GNSS-sender/modtager til fabrikanterne.
  Kortlægningen af registernumre og data findes i tabel 1. Bemærk, at der findes fem GSA-sætninger for GNSS-konstellationerne og Satellite-Based Augmentation System (SBAS).« |
| --- | --- | --- |

iii)

Krav GNS_20 affattes således:

»GNS_20

Den sikre GNSS-sender/modtager bruger en hukommelse til at gemme data, som kan udføre mindst 20 millioner skrive/læse-cykler. Bortset fra dette aspekt overlades det interne design og implementeringen af den sikre GNSS-sender/modtager til fabrikanterne.

Kortlægningen af registernumre og data findes i tabel 1. Bemærk, at der findes fem GSA-sætninger for GNSS-konstellationerne og Satellite-Based Augmentation System (SBAS).«

| c) | Afsnit 4.2.2, krav GNS_23, underafsnit 5, affattes således:


  »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 positionen er gyldig. Hvis positionen ikke er gyldig, er positionsdataene endnu ikke tilgængelige, og de kan ikke anvendes til at registrere køretøjets position. Hvis positionen er gyldig, udtrækker køretøjsenhedens processor ligeledes værdierne HDOP af GSA NMEA-sætningerne og beregner mindsteværdien af de tilgængelige satellitsystemer (dvs. når den modtager et signal).« |
| --- | --- | --- |

c)

Afsnit 4.2.2, krav GNS_23, underafsnit 5, affattes således:

»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 positionen er gyldig. Hvis positionen ikke er gyldig, er positionsdataene endnu ikke tilgængelige, og de kan ikke anvendes til at registrere køretøjets position. Hvis positionen er gyldig, udtrækker køretøjsenhedens processor ligeledes værdierne HDOP af GSA NMEA-sætningerne og beregner mindsteværdien af de tilgængelige satellitsystemer (dvs. når den modtager et signal).«

| d) | Afsnit 4.4.1, krav GNS_28, affattes således:


  »GNS_28 | Hvis det ikke lykkes køretøjsenheden at kommunikere med det sammenkoblede eksterne GNSS-udstyr i mere end 20 på hinanden følgende minutter, genererer køretøjsenheden en hændelse af typen EventFaultType og registrerer den i køretøjsenheden med værdien enum »0E«H Kommunikationsfejl på ekstern GNSS-udstyr og med tidsstemplet indstillet til det aktuelle klokkeslæt. Hændelsen genereres kun, hvis følgende to betingelser er opfyldt: a) den intelligente takograf er ikke i kalibreringstilstand og b) køretøjet bevæger sig. 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.« |
| --- | --- | --- |

d)

Afsnit 4.4.1, krav GNS_28, affattes således:

»GNS_28

Hvis det ikke lykkes køretøjsenheden at kommunikere med det sammenkoblede eksterne GNSS-udstyr i mere end 20 på hinanden følgende minutter, genererer køretøjsenheden en hændelse af typen EventFaultType og registrerer den i køretøjsenheden med værdien enum »0E«H Kommunikationsfejl på ekstern GNSS-udstyr og med tidsstemplet indstillet til det aktuelle klokkeslæt. Hændelsen genereres kun, hvis følgende to betingelser er opfyldt: a) den intelligente takograf er ikke i kalibreringstilstand og b) køretøjet bevæger sig. 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.«

| e) | Afsnit 4.4.2, krav GNS_29, affattes således:


  »GNS_29 | Hvis det eksterne GNSS-udstyr er blevet brudt, skal den sikre GNSS-sender/modtager slette hele sin hukommelse, inklusive kryptografisk materiale. Som beskrevet i GNS_25 og GNS_26 detekterer køretøjsenheden manipulation, hvis Svar har status »6690«. Køretøjsenheden genererer herefter en begivenhed af typen EventFaultType enum»19«H Detektering af manipulering af GNSS. Det kan også være, at det eksterne GNSS-udstyr ikke svarer på nogen ekstern anmodning mere.« |
| --- | --- | --- |

e)

Afsnit 4.4.2, krav GNS_29, affattes således:

»GNS_29

Hvis det eksterne GNSS-udstyr er blevet brudt, skal den sikre GNSS-sender/modtager slette hele sin hukommelse, inklusive kryptografisk materiale. Som beskrevet i GNS_25 og GNS_26 detekterer køretøjsenheden manipulation, hvis Svar har status »6690«. Køretøjsenheden genererer herefter en begivenhed af typen EventFaultType enum»19«H Detektering af manipulering af GNSS. Det kan også være, at det eksterne GNSS-udstyr ikke svarer på nogen ekstern anmodning mere.«

| f) | Afsnit 4.4.3, krav GNS_30, affattes således:


  »GNS_30 | Hvis den sikre GNSS-sender/modtager ikke modtager data fra GNSS-modtageren i mere end tre på hinanden følgende timer, 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 kun en begivenhed af typen EventFaultType enum »0D«H Manglende positionsoplysninger fra GNSS-modtager med et tidsstempel lig med det aktuelle klokkeslæt, hvis følgende to betingelser er opfyldt: a) den intelligente takograf er ikke i kalibreringstilstand og b) køretøjet bevæger sig.« |
| --- | --- | --- |

f)

Afsnit 4.4.3, krav GNS_30, affattes således:

»GNS_30

Hvis den sikre GNSS-sender/modtager ikke modtager data fra GNSS-modtageren i mere end tre på hinanden følgende timer, 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 kun en begivenhed af typen EventFaultType enum »0D«H Manglende positionsoplysninger fra GNSS-modtager med et tidsstempel lig med det aktuelle klokkeslæt, hvis følgende to betingelser er opfyldt: a) den intelligente takograf er ikke i kalibreringstilstand og b) køretøjet bevæger sig.«

| g) | Afsnit 4.4.4, krav GNS_31, teksten frem til figur 4, affattes således:

  »Hvis køretøjsenheden detekterer, at EGF'ens certifikat, som anvendes til gensidig ægthedskontrol, ikke længere er gyldigt, genererer og registrerer køretøjsenheden en fejl på kontrolapparatet af typen EventFaultType enum
  »1B«H Eksternt GNSS-udstyrs certifikat udløbet med et tidsstempel lig med det aktuelle klokkeslæt. Køretøjsenheden anvender stadig de modtagne GNSS-positionsdata.« |
| --- | --- |

g)

Afsnit 4.4.4, krav GNS_31, teksten frem til figur 4, affattes således:

»Hvis køretøjsenheden detekterer, at EGF'ens certifikat, som anvendes til gensidig ægthedskontrol, ikke længere er gyldigt, genererer og registrerer køretøjsenheden en fejl på kontrolapparatet af typen EventFaultType enum
  »1B«H Eksternt GNSS-udstyrs certifikat udløbet med et tidsstempel lig med det aktuelle klokkeslæt. Køretøjsenheden anvender stadig de modtagne GNSS-positionsdata.«

»1B«H Eksternt GNSS-udstyrs certifikat udløbet

| h) | Afsnit 5.2.1, krav GNS_34, affattes således:


  »GNS_34 | Hvis køretøjsenheden ikke modtager data fra GNSS-modtageren i mere end tre på hinanden følgende timer, genererer og registrerer køretøjsenheden kun en begivenhed af typen EventFaultType enum »0D«H Manglende positionsoplysninger fra GNSS-modtager med et tidsstempel lig med det aktuelle klokkeslæt, hvis følgende to betingelser er opfyldt: a) den intelligente takograf er ikke i kalibreringstilstand og b) køretøjet bevæger sig.« |
| --- | --- | --- |

h)

Afsnit 5.2.1, krav GNS_34, affattes således:

»GNS_34

Hvis køretøjsenheden ikke modtager data fra GNSS-modtageren i mere end tre på hinanden følgende timer, genererer og registrerer køretøjsenheden kun en begivenhed af typen EventFaultType enum »0D«H Manglende positionsoplysninger fra GNSS-modtager med et tidsstempel lig med det aktuelle klokkeslæt, hvis følgende to betingelser er opfyldt: a) den intelligente takograf er ikke i kalibreringstilstand og b) køretøjet bevæger sig.«

| i) | Afsnit 6 affattes således:
  »6   GNSS-TIDSKONFLIKT
  Hvis køretøjsenheden detekterer en diskrepans på mere end 1 minut mellem tidspunktet i køretøjsenhedens tidsmålerfunktion og klokkeslættet fra GNSS-modtageren, registrerer køretøjsenheden en hændelse af typen EventFaultType enum
  »0B«H Tidskonflikt (GNSS i forhold til køretøjsenhedens interne ur). Efter at en tidskonfliktbegivenhed er blevet udløst, vil køretøjsenheden ikke kontrollere diskrepanser i klokkeslæt i de næste 12 timer. Denne hændelse skal ikke udløses, hvis GNSS-modtageren ikke har kunnet registrere et gyldigt GNSS-signal inden for de seneste 30 dage.« |
| --- | --- |

i)

Afsnit 6 affattes således:

»6   GNSS-TIDSKONFLIKT

Hvis køretøjsenheden detekterer en diskrepans på mere end 1 minut mellem tidspunktet i køretøjsenhedens tidsmålerfunktion og klokkeslættet fra GNSS-modtageren, registrerer køretøjsenheden en hændelse af typen EventFaultType enum
  »0B«H Tidskonflikt (GNSS i forhold til køretøjsenhedens interne ur). Efter at en tidskonfliktbegivenhed er blevet udløst, vil køretøjsenheden ikke kontrollere diskrepanser i klokkeslæt i de næste 12 timer. Denne hændelse skal ikke udløses, hvis GNSS-modtageren ikke har kunnet registrere et gyldigt GNSS-signal inden for de seneste 30 dage.«

»0B«H Tidskonflikt (GNSS i forhold til køretøjsenhedens interne ur)

| 38) | I tillæg 13 foretages følgende ændringer:


  a) | Afsnit 2, fjerde afsnit, affattes således:

  »Det skal præciseres, at følgende ikke specificeres i dette tillæg:


  — | indsamling af dataene og håndtering af disse i køretøjsenheden (som specificeres andetsteds i forordningen eller på anden måde er en funktion af produktdesignet) |
| --- | --- | --- | --- |

38)

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

a)

Afsnit 2, fjerde afsnit, affattes således:

»Det skal præciseres, at følgende ikke specificeres i dette tillæg:

ikke

—

indsamling af dataene og håndtering af disse i køretøjsenheden (som specificeres andetsteds i forordningen eller på anden måde er en funktion af produktdesignet)

dataene

forordningen

| — | formatet for præsentationen af de indsamlede data til applikationen på den eksterne anordning |
| --- | --- |

—

formatet for præsentationen af de indsamlede data til applikationen på den eksterne anordning

| — | ovenstående datasikkerhedsbestemmelser vedrørende Bluetooth® (såsom kryptering) for så vidt angår indholdet af dataene (som angives andetsteds i forordningen [tillæg 11, Fælles sikkerhedsmekanismer]) |
| --- | --- |

—

ovenstående datasikkerhedsbestemmelser vedrørende Bluetooth® (såsom kryptering) for så vidt angår indholdet af dataene (som angives andetsteds i forordningen [tillæg 11, Fælles sikkerhedsmekanismer])

dataene

forordningen

| — | Bluetooth®-protokollerne, som ITS-grænsefladen benytter.« |
| --- | --- |

—

Bluetooth®-protokollerne, som ITS-grænsefladen benytter.«

| b) | Afsnit 4.2, tredje afsnit, affattes således:

  »Når en ekstern anordning kommer inden for køretøjsenhedens rækkevidde første gang, kan Bluetooth®-parringsprocessen indledes (se også bilag 2). Anordningerne udveksler adresser, navne og profiler og den fælles hemmelige nøgle, som giver dem mulighed for at koble sig sammen, hver gang de er sammen fremover. Når dette trin er afsluttet, er den eksterne anordning godkendt og i stand til at indlede anmodninger om dataoverførsel fra takografen. Der er ikke planer om at tilføje krypteringsmekanismer ud over dem, som Bluetooth® tilbyder. Men hvis der er behov for yderligere sikkerhedsmekanismer, vil disse være i overensstemmelse med tillæg 11, Fælles sikkerhedsmekanismer.« |
| --- | --- |

b)

Afsnit 4.2, tredje afsnit, affattes således:

»Når en ekstern anordning kommer inden for køretøjsenhedens rækkevidde første gang, kan Bluetooth®-parringsprocessen indledes (se også bilag 2). Anordningerne udveksler adresser, navne og profiler og den fælles hemmelige nøgle, som giver dem mulighed for at koble sig sammen, hver gang de er sammen fremover. Når dette trin er afsluttet, er den eksterne anordning godkendt og i stand til at indlede anmodninger om dataoverførsel fra takografen. Der er ikke planer om at tilføje krypteringsmekanismer ud over dem, som Bluetooth® tilbyder. Men hvis der er behov for yderligere sikkerhedsmekanismer, vil disse være i overensstemmelse med tillæg 11, Fælles sikkerhedsmekanismer.«

| c) | I afsnit 4.3 foretages følgende ændringer:


  i) | Første afsnit affattes således:

  »Af sikkerhedshensyn vil køretøjsenheden kræve et godkendelsessystem med PIN-kode, som er separat fra Bluetooth-parringen. Hver køretøjsenhed skal kunne generere PIN-koder bestående af mindst fire cifre med henblik på ægthedskontrol. Hver gang en ekstern anordning parres med køretøjsenheden, skal den opgive den korrekte PIN-kode, før den modtager data.« |
| --- | --- | --- |

c)

I afsnit 4.3 foretages følgende ændringer:

i)

Første afsnit affattes således:

»Af sikkerhedshensyn vil køretøjsenheden kræve et godkendelsessystem med PIN-kode, som er separat fra Bluetooth-parringen. Hver køretøjsenhed skal kunne generere PIN-koder bestående af mindst fire cifre med henblik på ægthedskontrol. Hver gang en ekstern anordning parres med køretøjsenheden, skal den opgive den korrekte PIN-kode, før den modtager data.«

| ii) | Tredje afsnit efter tabel 1 affattes således:

  »Selv om fabrikanten kan tilbyde en mulighed for at ændre PIN-koden direkte gennem køretøjsenheden, kan PUK-koden ikke ændres. Hvis det er muligt at ændre PIN-koden, kræver det, at den aktuelle PIN-kode kan indtastes direkte i køretøjsenheden.« |
| --- | --- |

ii)

Tredje afsnit efter tabel 1 affattes således:

»Selv om fabrikanten kan tilbyde en mulighed for at ændre PIN-koden direkte gennem køretøjsenheden, kan PUK-koden ikke ændres. Hvis det er muligt at ændre PIN-koden, kræver det, at den aktuelle PIN-kode kan indtastes direkte i køretøjsenheden.«

| d) | Afsnit 4.4, andet afsnit efter overskriften »Datafelt«, affattes således:

  »Hvis de data, der skal overføres, er for store til at kunne rummes i en meddelelse, opdeles de i flere delmeddelelser. Hver delmeddelelse skal have samme header og SID, men indeholder en tæller på 2 byte, Counter Current (CC) og Counter Max (CM), som angiver nummeret på delmeddelelsen. For at der skal kunne foretages fejlkontrol og afbrydelse, kvitterer den modtagende enhed for hver delmeddelelse. Den modtagende enhed kan acceptere delmeddelelsen, anmode om, at den overføres på ny, anmode den afsendende enhed om at starte forfra eller afbryde dataoverførslen.« |
| --- | --- |

d)

Afsnit 4.4, andet afsnit efter overskriften »Datafelt«, affattes således:

»Hvis de data, der skal overføres, er for store til at kunne rummes i en meddelelse, opdeles de i flere delmeddelelser. Hver delmeddelelse skal have samme header og SID, men indeholder en tæller på 2 byte, Counter Current (CC) og Counter Max (CM), som angiver nummeret på delmeddelelsen. For at der skal kunne foretages fejlkontrol og afbrydelse, kvitterer den modtagende enhed for hver delmeddelelse. Den modtagende enhed kan acceptere delmeddelelsen, anmode om, at den overføres på ny, anmode den afsendende enhed om at starte forfra eller afbryde dataoverførslen.«

| e) | I bilag 1 foretages følgende ændringer:


  i) | Overskriften affattes således:
  »1)   LISTE OVER TILGÆNGELIGE DATA VIA ITS-GRÆNSEFLADEN« |
| --- | --- | --- |

e)

I bilag 1 foretages følgende ændringer:

i)

Overskriften affattes således:

»1)   LISTE OVER TILGÆNGELIGE DATA VIA ITS-GRÆNSEFLADEN«

LISTE OVER TILGÆNGELIGE DATA VIA ITS-GRÆNSEFLADEN«

| ii) | Følgende post indsættes i tabellen i nr. 3), efter posten »Manglende positionsoplysninger fra GNSS-modtager«:


  »Fejl ved kommunikation med det eksterne GNSS-udstyr | — | den længstvarende hændelse for hver af de 10 seneste dage, den er forekommet |
| --- | --- | --- | --- |

ii)

Følgende post indsættes i tabellen i nr. 3), efter posten »Manglende positionsoplysninger fra GNSS-modtager«:

»Fejl ved kommunikation med det eksterne GNSS-udstyr

—

den længstvarende hændelse for hver af de 10 seneste dage, den er forekommet

| — | de 5 længstvarende hændelser inden for de seneste 365 dage |
| --- | --- |

—

de 5 længstvarende hændelser inden for de seneste 365 dage

| — | hændelsens startdato og -klokkeslæt |
| --- | --- |

—

hændelsens startdato og -klokkeslæt

| — | hændelsens slutdato 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 |
| --- | --- |

—

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

—

antal tilsvarende hændelser den pågældende dag«

| iii) | I nr. 5) indsættes følgende led:


  »— | ITS-grænsefladefejl (hvis relevant)«. |
| --- | --- | --- |

iii)

I nr. 5) indsættes følgende led:

»—

ITS-grænsefladefejl (hvis relevant)«.

| f) | I bilag 3, ASN.1 Specifications, foretages følgende ændringer:


  i) | Efter linje 206 indsættes følgende linje 206a til 206e:
  »


  Tekst af billedet

  «206a
  206b
  DriverID ::= SEQUENCE{
  206c
  issuingMemberState OCTET STRING (SIZE(3)),
  206d
  cardNumber OCTET STRING (SIZE(16))
  206e }«;

  « |
| --- | --- | --- |

f)

I bilag 3, ASN.1 Specifications, foretages følgende ændringer:

i)

Efter linje 206 indsættes følgende linje 206a til 206e:

«206a

206b

DriverID ::= SEQUENCE{

206c

issuingMemberState OCTET STRING (SIZE(3)),

206d

cardNumber OCTET STRING (SIZE(16))

206e }«;

| ii) | Linje 262 til 264 affattes således:
  »


  Tekst af billedet

  »262
  driveRecognize BIT STRING ('00'B UNION '01'B),
  263
  driverCardDriver1 BIT STRING ('00'B UNION '01'B),
  264
  driverCardDriver2 BIT STRING ('00'B UNION '01'B), «;

  « |
| --- | --- |

ii)

Linje 262 til 264 affattes således:

»262

driveRecognize BIT STRING ('00'B UNION '01'B),

263

driverCardDriver1 BIT STRING ('00'B UNION '01'B),

264

driverCardDriver2 BIT STRING ('00'B UNION '01'B), «;

| iii) | Linje 275 affattes således:
  »


  Tekst af billedet

  »275
  outOfScopeCondition BIT STRING ('00'B UNION '01'B),»;

  « |
| --- | --- |

iii)

Linje 275 affattes således:

»275

outOfScopeCondition BIT STRING ('00'B UNION '01'B),»;

| iv) | Linje 288 til 310 affattes således:
  »


  Tekst af billedet

  »288
  driver1WorkingState BIT STRING ('000'B UNION '001'B UNION '010'B UNION
  289
  '011'B UNION '100'B UNION '101'B ...),
  290
  driver2WorkingState BIT STRING ('000'B UNION '001'B UNION '010'B UNION
  291
  '011'B UNION '100'B UNION '101'B ...),
  292
  293
  driver1TimeRelatedStates BIT STRING ('0000'B UNION '0001'B
  294
  UNION '0010'B UNION '0011'B UNION '0100'B UNION '0101'B UNION
  295
  '0110'B UNION '0111'B UNION '1000'B UNION '1001'B UNION '1010'B
  296
  UNION '1011'B UNION '1100'B UNION '1101'B ...),
  297
  298
  299
  driver2TimeRelatedStates BIT STRING ('0000'B UNION '0001'B
  300
  UNION '0010'B UNION '0011'B UNION '0100'B UNION '0101'B UNION
  301
  '0110'B UNION '0111'B UNION '1000'B UNION '1001'B UNION '1010'B
  302
  UNION '1011'B UNION '1100'B UNION '1101'B ...),
  303
  304
  305
  306
  overSpeed BIT STRING ('00 'B UNION '01 'B),
  307
  driver1Identification DriverID,
  308
  driver2Identification DriverID,
  309
  310«

  « |
| --- | --- |

iv)

Linje 288 til 310 affattes således:

»288

driver1WorkingState BIT STRING ('000'B UNION '001'B UNION '010'B UNION

289

'011'B UNION '100'B UNION '101'B ...),

290

driver2WorkingState BIT STRING ('000'B UNION '001'B UNION '010'B UNION

291

'011'B UNION '100'B UNION '101'B ...),

292

293

driver1TimeRelatedStates BIT STRING ('0000'B UNION '0001'B

294

UNION '0010'B UNION '0011'B UNION '0100'B UNION '0101'B UNION

295

'0110'B UNION '0111'B UNION '1000'B UNION '1001'B UNION '1010'B

296

UNION '1011'B UNION '1100'B UNION '1101'B ...),

297

298

299

driver2TimeRelatedStates BIT STRING ('0000'B UNION '0001'B

300

UNION '0010'B UNION '0011'B UNION '0100'B UNION '0101'B UNION

301

'0110'B UNION '0111'B UNION '1000'B UNION '1001'B UNION '1010'B

302

UNION '1011'B UNION '1100'B UNION '1101'B ...),

303

304

305

306

overSpeed BIT STRING ('00 'B UNION '01 'B),

307

driver1Identification DriverID,

308

driver2Identification DriverID,

309

310«

| v) | Linje 362 til 363 affattes således:
  »


  Tekst af billedet

  »362
  driver1MaximumDailyDrivingTime BIT STRING (SIZE(4)),
  363
  driver2MaximumDailyDrivingTime BIT STRING (SIZE(4)),«;

  « |
| --- | --- |

v)

Linje 362 til 363 affattes således:

»362

driver1MaximumDailyDrivingTime BIT STRING (SIZE(4)),

363

driver2MaximumDailyDrivingTime BIT STRING (SIZE(4)),«;

| vi) | Efter linje 410 indsættes følgende linje 410a til 410b:
  »


  Tekst af billedet

  »410a
  comErrorWithExternalGNSSFacility
  410b
  CommunicationErrorWithTheExternalGNSSFacility,«;

  « |
| --- | --- |

vi)

Efter linje 410 indsættes følgende linje 410a til 410b:

»410a

comErrorWithExternalGNSSFacility

410b

CommunicationErrorWithTheExternalGNSSFacility,«;

| vii) | Efter linje 539 indsættes følgende linje 539 a til 539j:
  »


  Tekst af billedet

  »539a
  CommunicationErrorWithTheExternalGNSSFacility ::= SEQUENCE{
  539b
  beginDate GeneralizedTime,
  539c
  endDate GeneralizedTime,
  539d
  cardsType SEQUENCE OF UTF8String,
  539e
  cardsNumber SEQUENCE OF INTEGER,
  539f
  issuingMemberState SEQUENCE OF NationAlpha,
  539g
  cardsGeneration SEQUENCE OF INTEGER,
  539h
  numberOfSimilarEvent INTEGER
  539i
  }
  539j«;

  « |
| --- | --- |

vii)

Efter linje 539 indsættes følgende linje 539 a til 539j:

»539a

CommunicationErrorWithTheExternalGNSSFacility ::= SEQUENCE{

539b

beginDate GeneralizedTime,

539c

endDate GeneralizedTime,

539d

cardsType SEQUENCE OF UTF8String,

539e

cardsNumber SEQUENCE OF INTEGER,

539f

issuingMemberState SEQUENCE OF NationAlpha,

539g

cardsGeneration SEQUENCE OF INTEGER,

539h

numberOfSimilarEvent INTEGER

539i

}

539j«;

| 39) | I tillæg 14 foretages følgende ændringer:


  a) | I indholdsfortegnelsen affattes afsnit 5.5 således:
  »5.5   Understøttelse af direktiv (EU) 2015/719 490«.... |
| --- | --- | --- |

39)

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

a)

I indholdsfortegnelsen affattes afsnit 5.5 således:

»5.5   Understøttelse af direktiv (EU) 2015/719 490«....

| b) | Afsnit 2, tredje afsnit, affattes således:

  »I dette scenario er der kun begrænset tid til rådighed til kommunikation, fordi kommunikationen er målrettet og har kort rækkevidde. Desuden kan de kompetente kontrolmyndigheder anvende de samme kommunikationsmidler til fjernovervågning af takografer (RTM) til andre formål (såsom de største tilladte dimensioner og den største tilladte vægt for tunge varekøretøjer, som defineret i direktiv (EU) 2015/719), og sådanne operationer kan være separate eller sekventielle alt efter de kompetente kontrolmyndigheders valg.« |
| --- | --- |

b)

Afsnit 2, tredje afsnit, affattes således:

»I dette scenario er der kun begrænset tid til rådighed til kommunikation, fordi kommunikationen er målrettet og har kort rækkevidde. Desuden kan de kompetente kontrolmyndigheder anvende de samme kommunikationsmidler til fjernovervågning af takografer (RTM) til andre formål (såsom de største tilladte dimensioner og den største tilladte vægt for tunge varekøretøjer, som defineret i direktiv (EU) 2015/719), og sådanne operationer kan være separate eller sekventielle alt efter de kompetente kontrolmyndigheders valg.«

kommunikationen

| c) | I afsnit 5.1 foretages følgende ændringer:


  i) | Krav DSC_19, tolvte led, affattes således:


  »— | DSRC-køretøjsenhedens antenne skal være anbragt i en position, hvor den optimerer DSRC-kommuniktionen mellem køretøjet og antennen i vejsiden, når denne er anbragt 15 m foran køretøjet og i 2 meters højde, rettet mod det horisontale og vertikale midtpunkt af køretøjets forrude. For lette køretøjer er montering svarende til den øverste del af frontruden hensigtsmæssig. For alle andre installeres DSRC-antennen enten nær den nedre eller den øvre del af forruden.« |
| --- | --- | --- | --- |

c)

I afsnit 5.1 foretages følgende ændringer:

i)

Krav DSC_19, tolvte led, affattes således:

»—

DSRC-køretøjsenhedens antenne skal være anbragt i en position, hvor den optimerer DSRC-kommuniktionen mellem køretøjet og antennen i vejsiden, når denne er anbragt 15 m foran køretøjet og i 2 meters højde, rettet mod det horisontale og vertikale midtpunkt af køretøjets forrude. For lette køretøjer er montering svarende til den øverste del af frontruden hensigtsmæssig. For alle andre installeres DSRC-antennen enten nær den nedre eller den øvre del af forruden.«

| ii) | Krav DSC_22, første afsnit, affattes således:

  »Antennens formfaktor defineres ikke og er genstand for en kommerciel beslutning, når blot den monterede DSRC-køretøjsenhed opfylder overensstemmelseskravene som defineret i afsnit 5 nedenfor. Antennen skal monteres som fastsat i krav DSC_19 og effektivt understøtte de anvendelsessituationer, der beskrives i afsnit 4.1.2 og 4.1.3.« |
| --- | --- |

ii)

Krav DSC_22, første afsnit, affattes således:

»Antennens formfaktor defineres ikke og er genstand for en kommerciel beslutning, når blot den monterede DSRC-køretøjsenhed opfylder overensstemmelseskravene som defineret i afsnit 5 nedenfor. Antennen skal monteres som fastsat i krav DSC_19 og effektivt understøtte de anvendelsessituationer, der beskrives i afsnit 4.1.2 og 4.1.3.«

| d) | Afsnit 5.4.3, nr. 7 i rækkefølgen, affattes således:


  »7 | REDCR | > | DSRC-køretøjsenhed | Sender GET.request om data anden Attribut (hvis relevant)« |
| --- | --- | --- | --- | --- | --- |

d)

Afsnit 5.4.3, nr. 7 i rækkefølgen, affattes således:

»7

REDCR

>

DSRC-køretøjsenhed

Sender GET.request om data anden Attribut (hvis relevant)«

| e) | I afsnit 5.4.4, krav DCS_40, ASN.1-moduldefinitionen, foretages følgende ændringer:


  i) | Første linje af sekvensen for


  affattes således:
  »


  Tekst af billedet

  »tp15638VehicleRegistrationPlate LPN – Vehicle Registration Plate as per EN 155091«

  « |
| --- | --- | --- |

e)

I afsnit 5.4.4, krav DCS_40, ASN.1-moduldefinitionen, foretages følgende ændringer:

i)

Image 112

»tp15638VehicleRegistrationPlate LPN – Vehicle Registration Plate as per EN 155091«

| ii) | Følgende indsættes som fodnote 1:


  »1 | Hvis en LPN indeholder en AlphabetIndicator LatinAlphabetNo2 eller latinCyrillicAlphabet, omskrives specialtegnene af fjernaflæseren under anvendelse af særlige regler i henhold til bilag E til ISO/DIS 14 906,2.« |
| --- | --- | --- |

ii)

Følgende indsættes som fodnote 1:

»1

Hvis en LPN indeholder en AlphabetIndicator LatinAlphabetNo2 eller latinCyrillicAlphabet, omskrives specialtegnene af fjernaflæseren under anvendelse af særlige regler i henhold til bilag E til ISO/DIS 14 906,2.«

| iii) | Det højtstillede 2 udgår i linjen Tidsstempel for aktuel registrering. |
| --- | --- |

iii)

Det højtstillede 2 udgår i linjen Tidsstempel for aktuel registrering.

| iv) | ASN.1-moduldefinitionen for


  affattes således:
  »


  Tekst af billedet

  »RtmTransferAck ::= INTEGER {
  Ok (1),
  NoK (2)
  } (1..255)«;

  « |
| --- | --- |

iv)

Image 114

»RtmTransferAck ::= INTEGER {

Ok (1),

NoK (2)

} (1..255)«;

| f) | Afsnit 5.4.5, tabel 14.3, posten REM12, affattes således:


  »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 der er registreret en hændelse af typen »35H« Følerfejl inden for de seneste 10 dage |
| --- | --- | --- | --- |

f)

Afsnit 5.4.5, tabel 14.3, posten REM12, affattes således:

»RTM12

RTM12

Følerfejl

Følerfejl

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

Køretøjsenheden tildeler variablen sensorFault en værdi på:

—

1 hvis der er registreret en hændelse af typen »35H« Følerfejl inden for de seneste 10 dage

| — | 2 hvis der er registreret en hændelse af typen GNSS-modtagerfejl (enten intern eller ekstern med enum-værdien »36«H eller »37«H) inden for de seneste 10 dage |
| --- | --- |

—

2 hvis der er registreret en hændelse af typen GNSS-modtagerfejl (enten intern eller ekstern med enum-værdien »36«H eller »37«H) inden for de seneste 10 dage

| — | 3 hvis der er registreret en hændelse af typen »0E«H Ekstern GNSS-kommunikationsfejl inden for de seneste 10 dage. |
| --- | --- |

—

3 hvis der er registreret en hændelse af typen »0E«H Ekstern GNSS-kommunikationsfejl inden for de seneste 10 dage.

| — | 4 Hvis der er registreret både følerfejl og GNSS-modtagerfejl inden for de seneste 10 dage |
| --- | --- |

—

4 Hvis der er registreret både følerfejl og GNSS-modtagerfejl inden for de seneste 10 dage

| — | 5 Hvis der er registreret både følerfejl og ekstern GNSS-kommunikationsfejl inden for de seneste 10 dage |
| --- | --- |

—

5 Hvis der er registreret både følerfejl og ekstern GNSS-kommunikationsfejl inden for de seneste 10 dage

| — | 6 Hvis der er registreret både GNSS- modtagerfejl og ekstern GNSS-kommunikationsfejl inden for de seneste 10 dage |
| --- | --- |

—

6 Hvis der er registreret både GNSS- modtagerfejl og ekstern GNSS-kommunikationsfejl inden for de seneste 10 dage

| — | 7 Hvis alle tre følerfejl er blevet registreret inden for de seneste 10 dage, ELSE tildeler den værdien 0 hvis der ikke er registreret nogen hændelser inden for de seneste 10 dage |
| --- | --- |

—

7 Hvis alle tre følerfejl er blevet registreret inden for de seneste 10 dage, ELSE tildeler den værdien 0 hvis der ikke er registreret nogen hændelser inden for de seneste 10 dage

— følerfejl en oktet i henhold til dataordlisten

Image 116

| g) | Afsnit 5.4.6, krav DSC_43, affattes således:


  »DSC_43 | Ved alle DSRC-udvekslinger skal dataene kodes med PER (Packed Encoding Rules) UNALIGNED, bortset fra


  og


, som skal kodes med OER (Octet Encoding Rules) som fastsat i ISO/IEC 8825-7, Rec. ITU-T X.696.« |
| --- | --- | --- |

g)

Afsnit 5.4.6, krav DSC_43, affattes således:

»DSC_43

Ved alle DSRC-udvekslinger skal dataene kodes med PER (Packed Encoding Rules) UNALIGNED, bortset fra

  Image 117
  og

  Image 118

, som skal kodes med OER (Octet Encoding Rules) som fastsat i ISO/IEC 8825-7, Rec. ITU-T X.696.«

| h) | Afsnit 5.4.7, fjerde kolonne i tabel 14.9, teksten i cellen med beskrivelsen af


, affattes således:
  »Objektidentifikator for den understøttede standard, del og version. Eksempel: ISO (1) Standard (0) TARV (15638) part9 (9) Version1 (1).
  Første oktet er 06H, som er objektidentifikatoren, anden oktet er 06H, som er dens længde. De efterfølgende 6 oktetter koder objektidentifikatoren i eksemplet.« |
| --- | --- |

h)

Image 119

»Objektidentifikator for den understøttede standard, del og version. Eksempel: ISO (1) Standard (0) TARV (15638) part9 (9) Version1 (1).

Første oktet er 06H, som er objektidentifikatoren, anden oktet er 06H, som er dens længde. De efterfølgende 6 oktetter koder objektidentifikatoren i eksemplet.«

| i) | Afsnit 5.5 og 5.5.1 affattes således:
  »5.5   Understøttelse af direktiv (EU) 2015/719

  5.5.1   Oversigt


  DSC_59 | For at understøtte direktiv (EU) 2015/719 om største tilladte dimensioner og største tilladte vægt for tunge lastbiler bliver transaktionsprotokollen til overførsel af OWS-data via 5,8 GHz DSRC-grænsefladeforbindelsen den samme, som bruges til RTM-data (se 5.4.1), idet den eneste forskel bliver, at den objektidentifikator, der vedrører TARV-standarden, vil henholde sig til ISO 15638-standarden (TARV), del 20, vedrørende WOB/OWS.« |
| --- | --- | --- |

i)

Afsnit 5.5 og 5.5.1 affattes således:

»5.5   Understøttelse af direktiv (EU) 2015/719

Understøttelse af direktiv (EU) 2015/719

5.5.1   Oversigt

Oversigt

DSC_59

For at understøtte direktiv (EU) 2015/719 om største tilladte dimensioner og største tilladte vægt for tunge lastbiler bliver transaktionsprotokollen til overførsel af OWS-data via 5,8 GHz DSRC-grænsefladeforbindelsen den samme, som bruges til RTM-data (se 5.4.1), idet den eneste forskel bliver, at den objektidentifikator, der vedrører TARV-standarden, vil henholde sig til ISO 15638-standarden (TARV), del 20, vedrørende WOB/OWS.«

| j) | Afsnit 5.6.1, krav DSC_68, litra a), affattes således:


  »a) | For at give mulighed for at bestille køretøjsenheden og DSRC-køretøjsenheden og forskellige partier af DSRC-køretøjsenheder fra forskellige leverandører skal forbindelsen mellem køretøjsenheden og DSRC-køretøjsenheden, som ikke er integreret i køretøjsenheden, være en åben standardforbindelse. Køretøjsenheden forbindes enten med DSRC-køretøjsenheden« |
| --- | --- | --- |

j)

Afsnit 5.6.1, krav DSC_68, litra a), affattes således:

»a)

For at give mulighed for at bestille køretøjsenheden og DSRC-køretøjsenheden og forskellige partier af DSRC-køretøjsenheder fra forskellige leverandører skal forbindelsen mellem køretøjsenheden og DSRC-køretøjsenheden, som ikke er integreret i køretøjsenheden, være en åben standardforbindelse. Køretøjsenheden forbindes enten med DSRC-køretøjsenheden«

| k) | Afsnit 5.7.1, krav DSC_77, affattes 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 registeret korrekt. 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.« |
| --- | --- | --- |

k)

Afsnit 5.7.1, krav DSC_77, affattes således:

»DSC_77

Dataene

VUSM

DSRC-køretøjsenheden

VUSM'en

DSRC-køretøjsenheden

køretøjsenheden

DSRC-køretøjsenhedens

| 40) | I tillæg 15 foretages følgende ændringer:


  a) | Afsnit 2.2, første afsnit, affattes således:

  »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 er interoperable med køretøjsenheder af anden generation i henhold til bilag I C i denne forordning. Desuden gælder følgende krav.« |
| --- | --- | --- |

40)

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

a)

Afsnit 2.2, første afsnit, affattes således:

»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 er interoperable med køretøjsenheder af anden generation i henhold til bilag I C i denne forordning. Desuden gælder følgende krav.«

| b) | I afsnit 2.4.1, krav MIG_11, foretages følgende ændringer:


  i) | Første led affattes således:


  »— | ikke-undertegnet elementærfilers ic og icc (valgfrit)«. |
| --- | --- | --- | --- |

b)

I afsnit 2.4.1, krav MIG_11, foretages følgende ændringer:

i)

Første led affattes således:

»—

ikke-undertegnet elementærfilers ic og icc (valgfrit)«.

| ii) | Tredje led affattes således:


  »— | 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. |
| --- | --- | --- |

ii)

Tredje led affattes således:

»—

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ører- (og værksteds-) kort af anden generation (applikationsdatas elementærfiler inden for den dedikerede fil Tachograph G2).«

| c) | Afsnit 2.4.3, krav MIG_014 og MIG_015, affattes således:


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

c)

Afsnit 2.4.3, krav MIG_014 og MIG_015, affattes således:

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

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

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

---

BILAG II

I bilag II til forordning (EU) 2016/799 foretages følgende ændringer:

| 1) | Kapitel I, afsnit 1, litra b), affattes således:


  »b) | et typegodkendelsesnummer, som svarer til nummeret i det typegodkendelsesdokument, der er udstedt for modellen af kontrolapparatet eller diagramarket eller takografkortet, og som anbringes et sted i nærheden af rektanglet.« |
| --- | --- | --- |

1)

Kapitel I, afsnit 1, litra b), affattes således:

»b)

et typegodkendelsesnummer, som svarer til nummeret i det typegodkendelsesdokument, der er udstedt for modellen af kontrolapparatet eller diagramarket eller takografkortet, og som anbringes et sted i nærheden af rektanglet.«

| 2) | Kapitel III, nr. 5, affattes således:


  »5. | Forelagt til godkendelse den ...«. |
| --- | --- | --- |

2)

Kapitel III, nr. 5, affattes således:

»5.

Forelagt til godkendelse den ...«.

| 3) | Kapitel IV, nr. 5, affattes således:


  »5. | Forelagt til godkendelse den ...«. |
| --- | --- | --- |

3)

Kapitel IV, nr. 5, affattes således:

»5.

Forelagt til godkendelse den ...«.

---