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

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

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

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

(3) Europa-Parlamentets og Rådets 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).

BILAG I

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

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

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

I afsnit 1 foretages følgende ændringer:

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

13)

I afsnit 3.12.5 foretages følgende ændringer:

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

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

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

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

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

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

15)

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

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

—	hændelsens startdato og -klokkeslæt

—	hændelsens slutdato og -klokkeslæt

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

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

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

—	kontrolapparat, dato og klokkeslæt

—	GNSS, dato og klokkeslæt

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

—	antal tilsvarende hændelser den pågæ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).

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

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

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

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

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

—	fabrikantens reservedelsnummer og fremstillingsår

—	komponentens serienummer

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

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

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

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

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

—	køretøjets kilometerstand.

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

—	køretøjets position

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

—	køretøjets kilometerstand.

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

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

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

—	effektiv dækperiferi i formen »l = … mm«

—	dækstørrelse

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

—	køretøjets identifikationsnummer

—	om der forefindes eksternt GNSS-udstyr

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

—	serienummeret på enheden til fjernkommunikation, hvis relevant

—	serienummeret på alle monterede plomber

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

—	den del af køretøjet, hvor bevægelsessensoren er 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

—	serienummeret på adapterens indlejrede bevægelsessensor.«

25)

I afsnit 5.3 foretages følgende ændringer:

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

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

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

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

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:

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

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

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

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

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

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

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

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

viii)

Afsnit 2.230 affattes således:

»2.230. Forbeholdt fremtidig brug«.

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

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

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

Afsnit 2.30 affattes således:

»2.30. CardRenewalIndex

Et kortfornyelsesindeks (definition i)).

Tekst af billedet

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

»0«	Første udstedelse.

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

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

Tekst af billedet

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

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

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

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

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

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

manufacturerCode er en kode for fabrikanten af plomben.

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

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

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

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

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

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

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 «

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

n)	Afsnit 2.120, den tilordnede værdi ‘16’H, affattes således: » Tekst af billedet ’16’HVuGNSSADRecord «.

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

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

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

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

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

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

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

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

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

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

Tekst af billedet

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

30)

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

I punkt 1.1 indsættes følgende forkortelser:

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

I afsnit 3.3 foretages følgende ændringer:

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

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

—	For ægthedsbekræftelse (anden generation)

ALW

PWD

ALW

Internal Authenticate

ALW

PWD

ALW

General Authenticate

ALW

Get Challenge

ALW

MSE:SET AT

ALW

MSE:SET DST

ALW

Process DSRC Message

Ikke relevant

PSO: Compute Digital Signature

ALW OR

SM-MAC-G2

ALW OR

SM-MAC-G2

Ikke relevant

PSO: Hash

Ikke relevant

ALW

Ikke relevant

PERFORM HASH OF FILE

ALW OR

SM-MAC-G2

ALW OR

SM-MAC-G2

Ikke relevant

PSO: Verify Certificate

ALW

PSO: Verify Digital Signature

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)

Ikke relevant

—	For ægthedsbekræftelse (anden generation)

ALW

PWD

ALW

Internal Authenticate

Ikke relevant

General Authenticate

ALW

Get Challenge

ALW

MSE:SET AT

ALW

MSE:SET DST

ALW

Process DSRC Message

Ikke relevant

ALW

Ikke relevant

PSO: Compute Digital Signature

ALW OR

SM-MAC-G2

ALW OR

SM-MAC-G2

Ikke relevant

PSO: Hash

Ikke relevant

ALW

Ikke relevant

PERFORM HASH OF FILE

ALW OR

SM-MAC-G2

ALW OR

SM-MAC-G2

Ikke relevant

PSO: Verify Certificate

ALW

PSO: Verify Digital Signature

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

Ikke relevant

—	For anden generation ægthedskontrol

ALW

PWD

ALW

Internal Authenticate

Ikke relevant

General Authenticate

ALW

Get Challenge

ALW

MSE:SET AT

ALW

MSE:SET DST

ALW

Process DSRC Message

Ikke relevant

PSO: Compute Digital Signature

Ikke relevant

PSO: Hash

Ikke relevant

PERFORM HASH OF FILE

Ikke relevant

PSO: Verify Certificate

ALW

PSO: Verify Digital Signature

Ikke relevant

Verify

Ikke relevant

ALW

Ikke relevant

Ikke relevant«

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

Normal behandling af data.

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

Advarselsbehandling. En del af svardata kan være beskadiget

Ægthedsbekræftelse mislykkedes (advarsel)

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

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

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

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

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)

Forkert længde (forkert Lc eller Le)

Sidste kommando i den forventede kæde

Forbudt kommando (intet svar foreligger i T = 0)

Sikkerhedsstatus ikke tilfredsstillet

Ægthedsbekræftelse blokeret

Betingelser for anvendelse ikke opfyldt

Kommando ikke tilladt (ingen aktuel elementærfil)

Forventede dataobjekter for sikker meddelelsesoverførsel mangler

Ukorrekte dataobjekter for sikker meddelelsesoverførsel

Ukorrekte parametre i datafelt

Filer ikke fundet

Forkerte parametre P1-P2

De adresserede data kunne ikke findes

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

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

Operationskode ikke understøttet eller ugyldig

Klasse ikke understøttet

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

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

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

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

I afsnit 3.5.2.1.1 foretages følgende ændringer:

I krav TCS_45 affattes tabellen således:

»Byte

Længde

Værdi

Beskrivelse

»81h«

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

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

»XX..XXh«

Ordinær dataværdi

#(2+L+NN)

»99h«

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

#(3+L+NN)

»02h«

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

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

»XX XXh«

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

#(6+L+NN)

»8Eh«

TCC: Etiket for kryptografisk kontrolsum

#(7+L+NN)

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

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

»XX..XXh«

Kryptografisk kontrolsum

»XXXXh«

Statusord (SW1, SW2)«

ii)

I krav TCS_46 affattes tabellen således:

»Byte

Længde

Værdi

Beskrivelse

»87h«

TPI CG: Etiket for krypterede data (kryptogram)

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

»01XX..XXh«

Krypterede data: Udfyldningsindikator og kryptogram

#(2+L+MM)

»99h«

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

#(3+L+MM)

»02h«

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

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

»XX XXh«

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

#(6+L+MM)

»8Eh«

TCC: Etiket for kryptografisk kontrolsum

#(7+L+MM)

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

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

»XX..XXh«

Kryptografisk kontrolsum

»XXXXh«

Statusord (SW1, SW2)«

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

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

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

»Le

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

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

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

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

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

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

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

»5 + L + 1

»00h«

Som foreskrevet i ISO/IEC 7816-4«

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

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

I afsnit 3.5.13 foretages følgende ændringer:

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

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

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

I afsnit 3.5.15 foretages følgende ændringer:

Tabellen i krav TCS_133 affattes således:

»Byte

Længde

Værdi

Beskrivelse

CLA

»00h«

CLA

INS

»2Ah«

Udfør sikkerhedsoperation

»00h«

»A8h«

Etiket: Datafeltet indeholder dataobjekter, der er relevante for verifikation

»XXh«

Længde Lc af det efterfølgende datafelt

»9Eh«

Etiket for digital underskrift

#7 eller

#7-#8

»NNh« eller

»81 NNh«

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

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

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

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

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

I afsnit 3.5.16 foretages følgende ændringer:

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

»5 + L + 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.«

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 «

ii)

I krav TCS_155 affattes posten

i tabellen således:

252

336«

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«

I afsnit 4.3.2 foretages følgende ændringer:

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

ii)

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

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

b)	Piktogramkombinationen for »Justering af klokkeslæt (foretaget af værksted)« erstattes af: » 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«.

32)

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

I afsnit 2 foretages følgende ændringer:

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«

ii)

Blok 11.5 affattes således:

»11.5

Position efter tre timers kumuleret køretid

tidspunkt

længdegrad for registreret position

breddegrad for registreret position

tidsstempel for bestemmelse af position

Kilometertæller

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

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«

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:

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

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

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

I afsnit 2.2.2 foretages følgende ændringer:

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«

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

I afsnit 2.2.2.9 foretages følgende ændringer:

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«

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

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

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

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

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

—	tidligere dataoverførsler til en virksomhed

—	virksomhedslåse

—	tidligere kontroller.«

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

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

iii)	Titlen »Datastruktur, anden generation« erstattes af følgende titel: »Datastruktur, anden generation (TREP 21 Hex)«.

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

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

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

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.

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

iii)	Titlen »Datastruktur, anden generation« erstattes af følgende titel: »Datastruktur, anden generation (TREP 24)«.

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

iii)	Titlen »Datastruktur, anden generation« erstattes af følgende titel: »Datastruktur, anden generation (TREP 25)«.

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.

—

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

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

—	Ved hver overførselssession er det obligatorisk som minimum at overføre elementærfilerne og .

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

—

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

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

—	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 opdateres -datoen i elementærfilen , og i de dedikerede filer Tachograph og, hvis relevant, .

—	Ved overførsel af et værkstedskort nulstilles kalibreringstælleren i elementærfilen -datoen, og i de dedikerede filer og, hvis relevant, .

—	Ved dataoverførsel fra et værkstedskort skal elementærfilen i de dedikerede filer og, hvis relevant, 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):«.

I punkt 3.3.3 affattes tabellen således:

»Kort

Retn.

IDE-enhed/kortlæser

Betydning/bemærkninger

Select 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

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

Gem de modtagne data på eksternt lagermedium

i henhold til 3.4 Data storage format

PSO: Compute Digital Signature

Udfør sikkerhedsoperationen »Compute Digital Signature« med anvendelse af den midlertidigt gemte hashværdi

Signature

Tilføj data til de data, som i forvejen er gemt på det eksterne lagermedium

i henhold til 3.4 Data storage format«

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

Eksempel på data i en fil overført til eksternt lagermedium:

Etiket

Længde

Værdi

—	Data i elementærfilen ICC

—	Data i elementærfilen Card_Certificate

—

...

Data i elementærfilen

(i den dedikerede fil

)

Underskrift af elementærfilen

(i den dedikerede fil

)

Data i elementærfilen

(i den dedikerede fil

)

Underskrift af elementærfilen

(i den dedikerede fil

)«

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

35)

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

Indholdsfortegnelsen, afsnit 6, affattes således:

»6	PRØVNING AF EKSTERNT UDSTYR TIL FJERNKOMMUNIKATION«.

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

I punkt 2 affattes tabellen om funktionsprøver for køretøjsenheder således:

»Nr.

Prøve

Beskrivelse

Tilknyttede krav

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

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

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

Miljøprøver

4.1

Temperatur

Funktionaliteten eftervises gennem:

Prøvning i overensstemmelse med ISO 16750-4, kapitel 5.1.1.2: Funktionsprøve ved lav temperatur (72 timer ved – 20 °C)

For denne prøve henvises til IEC 60068-2-1: Environmental testing — Part 2-1: Tests — Test A: Cold

Test i overensstemmelse med ISO 16750-4: kapitel 5.1.2.2: High temperature operation test (72 timer ved 70 °C)

For denne prøve henvises til IEC 60068-2-2: Basic environmental testing procedures; part 2: tests; tests B: dry heat

Test i overensstemmelse med ISO 16750-4: kapitel 5.3.2: Rapid change of temperature with specified transition duration (– 20°C/70 °C, 20 cycles, dwell time 2h at each temperature)

Et reduceret sæt prøvninger (af dem, som foreskrives i denne tabels punkt 3) kan udføres ved den lave temperatur, den høje temperatur og med gennemgang af 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

Sinusvibrationer.

Det kontrolleres, at køretøjsenheden kan modstå sinusvibrationer med følgende egenskaber:

Konstant skift mellem 5 og 11 Hz: Topværdi 10 mm

konstant acceleration mellem 11 og 300 Hz: 5 g

Prøvning for dette krav sker med IEC 60068-2-6, prøve Fc, med en mindste prøvningsvarighed på 3 × 12 timer (12 timer for hver akse)

ISO 16750-3 kræver ikke en sinusvibrationsprøvning for enheder, der sidder i afkoblede førerhuse.

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 -

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

(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

Prøver for elektromagnetisk kompatibilitet

5.1

Strålingsemission og følsomhed

Overensstemmelse med ECE-regulativ R10

218

5.2

Elektrostatisk udladning

Overensstemmelse med ISO 10605:2008 +

Technical Corrigendum:2010 +

AMD1: 2014: +/– 4 kV for kontakt og +/– 8 kV for udladning i luften

218

5.3

Transient nedre ledningsoverførsel for strømforsyning

For 24 V-udførelse: overensstemmelse med ISO 7637-2 og ECE-regulativ nr. 10, rev. 3:

impuls 1a: Vs = – 450 V, Ri = 50 ohm

impuls 2 a: Vs = + 37 V, Ri = 2 ohm

impuls 2b: Vs = + 20 V, Ri = 0,05 ohm

impuls 3 a: Vs = – 150 V, Ri = 50 ohm

impuls 3b: Vs = + 150 V, Ri = 50 ohm

impuls 4: Vs = – 16 V Va = – 12 V t6 = 100 ms

impuls 5: Vs = + 120 V Ri = 2,2 ohm td = 250 ms

For 12 V-udførelse: overensstemmelse med ISO 7637-1 og ECE-regulativ nr. 10, rev. 3:

impuls 1: Vs = – 75 V, Ri = 10 ohm

impuls 2a: Vs = + 37 V, Ri = 2 ohm

impuls 2b: Vs = + 10 V, Ri = 0,05 ohm

impuls 3a: Vs = – 112 V, Ri = 50 ohm

impuls 3b: Vs = + 75 V, Ri = 50 ohm

impuls 4: Vs = – 6 V Va = – 5 V t6 = 15 ms

impuls 5: Vs = + 65 V, Ri = 3 ohm td = 100 ms

Impuls 5 skal kun afprøves for køretø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«

Afsnit 6 affattes således:

»6 PRØVNING AF EKSTERNT UDSTYR TIL FJERNKOMMUNIKATION

Nr.

Prøve

Beskrivelse

Tilknyttede krav

Administrativ undersøgelse

1.1

Dokumentation

Dokumentationens korrekthed

Eftersyn

2.1.

Overensstemmelse med dokumentationen

2.2.

Identifikation/mærkning

225, 226

2.3

Materialer

219 til 223

Funktionsprøver

3.1

Fjernkommunikation i forbindelse med målrettede vejsidekontroller

4, 197 til 199

3.2

Registrering og lagring i datalager

3.3

Kommunikation med køretøjsenhed

Tillæg 14, krav DSC_66 til DSC_70, DSC_71 til DSC_76

Miljøprøver

4.1

Temperatur

Funktionaliteten eftervises gennem:

Prøvning i overensstemmelse med ISO 16750-4, kapitel 5.1.1.2: Funktionsprøve ved lav temperatur (72 timer ved – 20 °C)

For denne prøve henvises til IEC 60068-2-1: Environmental testing — Part 2-1: Tests — Test A: Cold

Test i overensstemmelse med ISO 16750-4: kapitel 5.1.2.2: High temperature operation test (72 timer ved 70 °C)

For denne prøve henvises til IEC 60068-2-2: Basic environmental testing procedures; part 2: tests; tests B: dry heat

Test i overensstemmelse med ISO 16750-4: kapitel 5.3.2: Rapid change of temperature with specified transition duration (– 20 °C/70 °C, 20 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

Prøver for elektromagnetisk kompatibilitet

5.1

Strålingsemission og følsomhed

Overensstemmelse med ECE-regulativ R10

218

5.2

Elektrostatisk udladning

Overensstemmelse med ISO 10605:2008 + Technical Corrigendum:2010 + AMD1: 2014: +/– 4 kV for kontakt og +/– 8 kV for udladning i luften

218

5.3

Transient nedre ledningsoverførsel for strømforsyning

For 24 V-udførelse: overensstemmelse med ISO 7637-2 og ECE-regulativ nr. 10, rev. 3:

impuls 1a: Vs = – 450 V, Ri = 50 ohm

impuls 2 a: Vs = + 37 V, Ri = 2 ohm

impuls 2b: Vs = + 20 V, Ri = 0,05 ohm

impuls 3 a: Vs = – 150 V, Ri = 50 ohm

impuls 3b: Vs = + 150 V, Ri = 50 ohm

impuls 4: Vs = – 16 V Va = – 12 V t6 = 100 ms

impuls 5: Vs = + 120 V Ri = 2,2 ohm td = 250 ms

For 12 V-udførelse: overensstemmelse med ISO 7637-1 og ECE-regulativ nr. 10, rev. 3:

impuls 1: Vs = – 75 V, Ri = 10 ohm

impuls 2 a: Vs = + 37 V, Ri = 2 ohm

impuls 2b: Vs = + 10 V, Ri = 0,05 ohm

impuls 3 a: Vs = – 112 V, Ri = 50 ohm

impuls 3b: Vs = + 75 V, Ri = 50 ohm

impuls 4: Vs = – 6 V Va = – 5 V t6 = 15 ms

impuls 5: Vs = + 65 V, Ri = 3 ohm td = 100 ms

Impuls 5 skal kun afprøves for køretøjsenheder bestemt til montering i køretøjer uden ekstern fælles overbelastningsbeskyttelse

For så vidt angår overbelastningsbeskyttelse henvises til ISO 16750-2, 4. udgave, kapitel 4.6.4.

218«

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

36)

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

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

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

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

I afsnit 9.1.5 foretages følgende ændringer:

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

—	for virksomhedskort: 5 år

—	for kontrolkort: 2 å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.«

I afsnit 9.1.6 foretages følgende ændringer:

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

I afsnit 9.1.7 foretages følgende ændringer:

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 «

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

I afsnit 9.2.1.1 foretages følgende ændringer:

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

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

I afsnit 9.2.2.1 foretages følgende ændringer:

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.

—

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

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

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

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

Afsnit 9.3.2.6, krav CSM_148, affattes således:

»CSM_148

Certifikatets faktiske gyldighedsdato angiver startdato og -tidspunkt for certifikatets gyldighedsperiode.«

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

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

I afsnit 10.2.1 foretages følgende ændringer:

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

I afsnit 10.2.2 foretages følgende ændringer:

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.

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

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 «

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

I afsnit 10.4, krav CSM_176, foretages følgende ændringer:

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

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

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.

Sammenfatning og eksempler

En kommando-APDU med anvendt sikker meddelelsesoverførsel vil have følgende struktur afhængigt af alternativet for den respektive ikke-sikrede kommando (DO står for dataobjekt):

Alternativ 1	:	CLA INS P1 P2 Lc' DO »8E« Le
Alternativ 2	:	CLA INS P1 P2 Lc' DO »97« DO»8E« Le
Alternativ 3 (lige INS-byte)	:	CLA INS P1 P2 Lc' DO »81« DO»8E« Le
Alternativ 3 (ulige INS-byte)	:	CLA INS P1 P2 Lc' DO »B3« DO»8E« Le
Alternativ 4 (lige INS-byte)	:	CLA INS P1 P2 Lc' DO »81« DO»97« DO»8E« Le
Alternativ 4 (ulige INS-byte)	:	CLA INS P1 P2 Lc' DO »B3« DO»97« DO»8E« Le

Hvor Le = »00« eller »00 00« afhængigt af, hvorvidt der benyttes felter med kort længde eller felter med udvidet længde; se [ISO 7816-4].

En svar-APDU med anvendt sikker meddelelsesoverførsel vil have følgende struktur afhængigt af alternativet for det respektive ikke-sikrede svar:

Alternativ 1 eller 3	:	DO »99« DO »8E« SW1SW2
Alternativ 2 eller 4 (lige INS-byte) uden kryptering	:	DO »81« DO »99« DO »8E« SW1SW2
Alternativ 2 eller 4 (lige INS-byte) med kryptering	:	DO »87« DO »99« DO »8E« SW1SW2
Alternativ 2 eller 4 (ulige INS-byte) uden kryptering	:	DO »B3« DO »99« DO »8E« SW1SW2

Bemærk: Alternativ 2 eller 4 (ulige INS-byte) med kryptering anvendes aldrig i kommunikationen mellem en køretøjsenhed og et kort.

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

Transformation af en autentificeret Alternativ 4-kommando-APDU

Figur 9

Transformation af en autentificeret Alternativ 1-/Alternativ 3-svar-APDU

Figur 10

Transformation af et krypteret og autentificeret Alternativ 2-/Alternativ 4-svar-APDU

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.

—	Et dataobjekt i en sikker meddelelsesoverførsel er forkert, f.eks. er MAC-værdien forkert, eller TLV-strukturen er forkert.

—	Strømmen afbrydes, eller enheden nulstilles.

—	Køretøjsenheden indleder processen med ægthedskontrol af køretøjsenheden.

—	Grænsen for antallet af kommandoer og tilhørende svar inden for den aktuelle session er nået. For et bestemt kort defineres denne grænse af fabrikanten under hensyntagen til sikkerhedskravene for den anvendte hardware med et maksimum på 240 SM-kommandoer og tilhørende svar pr. session.«

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

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

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

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

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

I afsnit 14.3 foretages følgende ændringer:

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

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

—	CHA'en på EQT.CA-certifikatet skal angive en MSCA.

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

37)

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

I afsnit 3 foretages følgende ændringer:

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

iii)

Krav GNS_6 affattes således:

»GNS_6

GSA-sætningen gemmes med registreringsnummer »02« til »06«.«

I afsnit 4.2.1 foretages følgende ændringer:

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

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

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

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

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

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

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

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

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

38)

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

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)

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

—	Bluetooth®-protokollerne, som ITS-grænsefladen benytter.«

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

I afsnit 4.3 foretages følgende ændringer:

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

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

I bilag 1 foretages følgende ændringer:

i)	Overskriften affattes således: »1) 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

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

—	hændelsens startdato og -klokkeslæt

—	hændelsens slutdato og -klokkeslæt

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

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

iii)

I nr. 5) indsættes følgende led:

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

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

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), «; «

iii)	Linje 275 affattes således: » Tekst af billedet »275 outOfScopeCondition BIT STRING ('00'B UNION '01'B),»; «

iv)

Linje 288 til 310 affattes således:

Tekst af billedet «

v)	Linje 362 til 363 affattes således: » Tekst af billedet »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,«; «

vii)

Efter linje 539 indsættes følgende linje 539 a til 539j:

Tekst af billedet «

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

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

I afsnit 5.1 foretages følgende ændringer:

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

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

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

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.

iv)	ASN.1-moduldefinitionen for affattes således:» Tekst af billedet »RtmTransferAck ::= INTEGER { Ok (1), NoK (2) } (1..255)«; «

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

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

—	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

—	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

— følerfejl en oktet i henhold til dataordlisten

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

, som skal kodes med OER (Octet Encoding Rules) som fastsat i ISO/IEC 8825-7, Rec. ITU-T X.696.«

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

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

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«

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

40)

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

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

I afsnit 2.4.1, krav MIG_11, foretages følgende ændringer:

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.

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

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