zur Änderung der Durchführungsverordnung (EU) 2016/799 zur Festlegung der Vorschriften über Bauart, Prüfung, Einbau, Betrieb und Reparatur von Fahrtenschreibern und ihren Komponenten

gestützt auf die Verordnung (EU) Nr. 165/2014 des Europäischen Parlaments und des Rates vom 4. Februar 2014 über Fahrtenschreiber im Straßenverkehr (1), insbesondere auf Artikel 11 und Artikel 12 Absatz 7,

Diese Verordnung tritt am zwanzigsten Tag nach ihrer Veröffentlichung im Amtsblatt der Europäischen Union in Kraft.

(2) Durchführungsverordnung (EU) 2016/799 der Kommission vom 18. März 2016 zur Durchführung der Verordnung (EU) Nr. 165/2014 des Europäischen Parlaments und des Rates zur Festlegung der Vorschriften über Bauart, Prüfung, Einbau, Betrieb und Reparatur von Fahrtenschreibern und ihren Komponenten (ABl. L 139 vom 26.5.2016, S. 1).

(3) Richtlinie 2014/53/EU des Europäischen Parlaments und des Rates vom 16. April 2014 über die Harmonisierung der Rechtsvorschriften der Mitgliedstaaten über die Bereitstellung von Funkanlagen auf dem Markt und zur Aufhebung der Richtlinie 1999/5/EG (ABl. L 153 vom 22.5.2014, S. 62).

ANHANG I

Anhang IC der Verordnung (EU) 2016/799 wird wie folgt geändert:

Das Inhaltsverzeichnis wird wie folgt geändert:

a)	Nummer 3.12.5 erhält folgende Fassung: „3.12.5 Orte und Positionen, an denen die tägliche Arbeitszeit beginnt, endet und/oder eine kumulierte Lenkzeit von 3 Stunden erreicht wird“

b)	Nummer 4.5.3.2.16 erhält folgende Fassung: „4.5.3.2.16 Ortsdaten zu drei Stunden kumulierter Lenkzeit“

c)	Nummer 4.5.4.2.14 erhält folgende Fassung: „4.5.4.2.14 Ortsdaten zu drei Stunden kumulierter Lenkzeit“

d)	Nummer 6.2 erhält folgende Fassung: „6.2 Prüfung neuer oder reparierter Komponenten“

Abschnitt 1 wird wie folgt geändert:

Die Begriffsbestimmung ll erhält folgende Fassung:

„ll)	‚Ausrüstung zur Fernkommunikation‘ oder ‚Ausrüstung zur Früherkennung per Fernkommunikation‘ das Gerät der Fahrzeugeinheit, das zur Durchführung gezielter Straßenkontrollen eingesetzt wird;“

Die Begriffsbestimmung tt erhält folgende Fassung:

„tt)	‚Zeiteinstellung‘ die Einstellung der aktuellen Zeit; diese Einstellung kann automatisch in regelmäßigen Abständen anhand der vom GNSS-Empfänger gelieferten Zeitangabe oder in der Betriebsart Kalibrierung vorgenommen werden;“

Der erste Gedankenstrich der Begriffsbestimmung yy erhält folgende Fassung:

„—	ausschließlich in Fahrzeuge der Klassen M1 und N1 (gemäß der Begriffsbestimmung in Anhang II der Richtlinie 2007/46/EG des Europäischen Parlaments und des Rates (*) in der zuletzt geänderten Fassung) eingebaut ist und eingesetzt wird;“

Die folgende neue Begriffsbestimmung fff wird angefügt:

„fff)

‚kumulierte Lenkzeit‘

Anzahl der insgesamt akkumulierten Minuten Lenkzeit in einem bestimmten Fahrzeug.

Der Wert der kumulierten Lenkzeit ist eine frei laufende Zählung aller Minuten, die die Funktion ‚Überwachung der Lenktätigkeiten‘ des Kontrollgeräts als LENK-Zeit betrachtet, und dient nur dazu, die Aufzeichnung der Fahrzeugposition immer dann auszulösen, wenn die kumulierte Lenkzeit ein Vielfaches von drei Stunden erreicht. Die Akkumulierung beginnt mit der Aktivierung des Kontrollgeräts. Sie bleibt von jeder anderen Bedingung, wie z. B. ‚Kontrollgerät nicht erforderlich‘ oder ‚Fährüberfahrt/Zugfahrt‘, unberührt.

Der Wert der kumulierten Lenkzeit ist nicht für die Anzeige, den Druck oder das Herunterladen bestimmt;“

In Abschnitt 2.3 Absatz 13 erhält der letzte Gedankenstrich folgende Fassung:

„—	die Fahrzeugeinheiten haben eine normale Gültigkeitsdauer von 15 Jahren ab dem Certificate Effective Date für die Fahrzeugeinheit; die Fahrzeugeinheiten können jedoch für weitere 3 Monate nur für das Herunterladen von Daten verwendet werden.“

Abschnitt 2.4 Absatz 1 erhält folgende Fassung:

„Durch die Systemsicherheit soll folgender Schutz gewährleistet sein: Schutz des Massenspeichers, sodass ein unbefugter Zugriff auf die Daten und deren Manipulation ausgeschlossen ist und alle entsprechenden Versuche entdeckt werden, Schutz der Integrität und Authentizität der zwischen Bewegungssensor und Fahrzeugeinheit ausgetauschten Daten, Schutz der Integrität und Authentizität der zwischen dem Kontrollgerät und den Fahrtenschreiberkarten ausgetauschten Daten, Schutz der Integrität und Authentizität der zwischen der Fahrzeugeinheit und der externen GNSS-Ausrüstung (soweit vorhanden) ausgetauschten Daten, Schutz der Vertraulichkeit, Integrität und Authentizität der zu Kontrollzwecken durch Früherkennung per Fernkommunikation ausgetauschten Daten sowie Überprüfung der Integrität und Authentizität heruntergeladener Daten.“

In Abschnitt 3.2 Absatz 27 erhält der zweite Gedankenstrich folgende Fassung:

„—	Positionen, an denen die kumulierte Lenkzeit ein Vielfaches von drei Stunden erreicht;“

Abschnitt 3.4 Absatz 49 erhält folgende Fassung:

„49)

Bei der ersten Tätigkeitsänderung auf UNTERBRECHUNG/RUHE oder BEREITSCHAFT innerhalb von 120 Sekunden nach dem automatischen Wechsel auf ARBEIT infolge des Anhaltens des Fahrzeugs wird davon ausgegangen, dass diese zum Zeitpunkt des Anhaltens eingetreten ist (sodass möglicherweise der Wechsel auf ARBEIT aufgehoben wird).“

Abschnitt 3.6.1 Absatz 59 erhält folgende Fassung:

„59)

Der Fahrer muss dann den derzeitigen Ort des Fahrzeugs eingeben, was als temporäre Eingabe gilt.

Unter den folgenden Bedingungen wird die bei der letzten Kartenentnahme vorgenommene temporäre Eingabe validiert (und kann somit nicht mehr überschrieben werden):

—	Eingabe eines Orts, an dem der aktuelle Arbeitstag beginnt, bei manueller Eingabe gemäß Randnummer 61;

—	nächste Eingabe eines Orts, an dem der aktuelle Arbeitstag beginnt, wenn der Karteninhaber bei der manuellen Eingabe gemäß Randnummer 61 keinen Ort eingibt, an dem der Arbeitstag beginnt oder endete.

Unter den folgenden Bedingungen wird die bei der letzten Kartenentnahme vorgenommene temporäre Eingabe überschrieben und der neue Wert validiert:

—	nächste Eingabe eines Orts, an dem der aktuelle Arbeitstag endet, wenn der Karteninhaber bei der manuellen Eingabe gemäß Randnummer 61 keinen Ort eingibt, an dem der Arbeitstag beginnt oder endete.“

In Abschnitt 3.6.2 erhalten der sechste und der siebte Gedankenstrich folgende Fassung:

„—	für die betreffende Zeit einen Ort einzugeben, an dem ein vorhergehender Arbeitstag endete (wodurch die bei der letzten Kartenentnahme erfolgte Eingabe überschrieben und validiert wird),

—	für die betreffende Zeit einen Ort einzugeben, an dem der aktuelle Arbeitstag beginnt (wodurch die bei der letzten Kartenentnahme erfolgte temporäre Eingabe validiert wird).“

Abschnitt 3.9.15 erhält folgende Fassung:

„3.9.15 Ereignis ‚Zeitkonflikt‘

86)

Dieses Ereignis wird, sofern sich das Kontrollgerät nicht in der Betriebsart Kalibrierung befindet, ausgelöst, wenn die Fahrzeugeinheit eine Abweichung von mehr als 1 Minute zwischen der Zeit der Zeitmessfunktion der Fahrzeugeinheit und der vom GNSS-Empfänger stammenden Zeit feststellt. Dieses Ereignis wird gemeinsam mit dem Wert der Systemuhr der Fahrzeugeinheit aufgezeichnet und geht mit einer automatischen Zeiteinstellung einher. Nachdem ein Ereignis ‚Zeitkonflikt‘ ausgelöst wurde, erzeugt die Fahrzeugeinheit in den nächsten 12 Stunden keine weiteren Zeitkonflikt-Ereignisse. Das Ereignis wird nicht ausgelöst, wenn der GNSS-Empfänger seit mindestens 30 Tagen kein gültiges GNSS-Signal feststellen konnte.“

10.

In Abschnitt 3.9.17 wird folgender Gedankenstrich angefügt:

„—	(ggf.) Störung der ITS-Schnittstelle“

11.

Abschnitt 3.10 wird wie folgt geändert:

i)	Der Text vor der Tabelle in Absatz 89 erhält folgende Fassung: „Mithilfe der Funktion ‚Integrierte Tests und Selbsttests‘ muss das Kontrollgerät zur Störungserkennung anhand der folgenden Tabelle in der Lage sein:“

ii)

In die Tabelle wird die folgende Zeile eingefügt:

„ITS-Schnittstelle (optional)

Ordnungsgemäßer Betrieb“

12.

In Abschnitt 3.12 erhält der zweite Gedankenstrich folgende Fassung:

„—

gelten als durchschnittliche Zahl der Positionen je Tag mindestens 6 Positionen, an denen die tägliche Arbeitszeit beginnt, 6 Positionen, wenn die kumulierte Lenkzeit ein Vielfaches von drei Stunden erreicht, und 6 Positionen, an denen die tägliche Arbeitszeit endet, sodass ‚365 Tage‘ mindestens 6570 Positionen umfassen;“

13.

Abschnitt 3.12.5 wird wie folgt geändert:

Die Überschrift und Absatz 108 erhalten folgende Fassung:

„3.12.5. Orte und Positionen, an denen die tägliche Arbeitszeit beginnt, endet und/oder eine kumulierte Lenkzeit von 3 Stunden erreicht wird“

108)

Das Kontrollgerät registriert und speichert in seinem Massenspeicher:

—	Orte und Positionen, an denen der Fahrer und/oder der Beifahrer seinen Arbeitstag beginnt,

—	Positionen, an denen die kumulierte Lenkzeit ein Vielfaches von drei Stunden erreicht,

—	Orte und Positionen, an denen der Fahrer und/oder der Beifahrer seinen Arbeitstag beendet.“

In Absatz 110 erhält der vierte Gedankenstrich folgende Fassung:

„—	Art der Eingabe (Beginn, Ende oder kumulierte Lenkzeit von 3 Stunden),“

Absatz 111 erhält folgende Fassung:

„111)

Die Speicherdauer der Orte und Positionen, an denen die tägliche Arbeitszeit beginnt, endet und/oder eine kumulierte Lenkzeit von 3 Stunden erreicht wird, im Massenspeicher muss mindestens 365 Tage betragen können.“

14.

Abschnitt 3.12.7 Absatz 116 erhält folgende Fassung:

„116)

Das Kontrollgerät registriert und speichert in seinem Massenspeicher zu jeder Sekunde mindestens der letzten 24 Stunden, in denen das Fahrzeug gefahren wurde, die Momentangeschwindigkeit des Fahrzeugs mit den dazugehörigen Datums- und Uhrzeitangaben.“

15.

In Abschnitt 3.12.8 wird die Tabelle wie folgt geändert:

Zwischen den Einträgen „Fehlende Positionsdaten des GNSS-Empfängers“ und „Bewegungsdatenfehler“ wird folgender Eintrag eingefügt:

„Ereignis ‚Kommunikationsfehler mit der externen GNSS-Ausrüstung‘

—	das längste Ereignis an jedem der letzten 10 Tage des Auftretens,

—	die 5 längsten Ereignisse in den letzten 365 Tagen.

—	Datum und Uhrzeit des Ereignisbeginns,

—	Datum und Uhrzeit des Ereignisendes,

—	Typ, Nummer, ausstellender Mitgliedstaat und Generation jeder zu Beginn und/oder Ende des Ereignisses eingesteckten Karte,

—	Anzahl ähnlicher Ereignisse an diesem Tag.“

Der Eintrag „Zeitkonflikt“ erhält folgende Fassung:

„Zeitkonflikt

—	das schwerwiegendste Ereignis an jedem der letzten 10 Tage des Auftretens (d. h. die Ereignisse mit dem größten Unterschied zwischen Datum und Uhrzeit des Kontrollgeräts und GNSS-Datum und -Uhrzeit),

—	die 5 schwerwiegendsten Ereignisse in den letzten 365 Tagen.

—	Datum und Uhrzeit Kontrollgerät,

—	GNSS-Datum und -Uhrzeit,

—	Typ, Nummer, ausstellender Mitgliedstaat und Generation jeder zu Beginn und/oder Ende des Ereignisses eingesteckten Karte,

—	Anzahl ähnlicher Ereignisse an diesem Tag.“

16.

Abschnitt 3.20 Absatz 200 erhält folgende Fassung:

„200)

Das Kontrollgerät kann auch mit genormten Schnittstellen ausgerüstet werden, die in den Betriebsarten Betrieb oder Kalibrierung die Nutzung der vom Fahrtenschreiber aufgezeichneten oder erzeugten Daten durch eine externe Ausrüstung ermöglichen.

In Anlage 13 ist eine optionale ITS-Schnittstelle spezifiziert und genormt. Parallel dazu können ähnliche VU-Schnittstellen bestehen, sofern sie in vollem Umfang den Anforderungen in Bezug auf die in Anlage 13 festgelegte Minimalliste von Daten, die Sicherheit und die Zustimmung des Fahrers genügen.

Die Zustimmung des Fahrers gilt nicht für die vom Kontrollgerät in das Fahrzeugnetzwerk übertragenen Daten. Werden in das Fahrzeugnetzwerk eingegebene personenbezogene Daten außerhalb des Fahrzeugnetzwerks weiterverarbeitet, muss der Fahrzeughersteller dafür sorgen, dass die Datenverarbeitung der Verordnung (EU) 2016/679 (‚Datenschutz-Grundverordnung‘) entspricht.

Die Zustimmung des Fahrers gilt auch nicht für Fahrtenschreiberdaten, die in einem entfernt angeschlossenen Unternehmen heruntergeladen werden, (Randnummer 193), da dieses Szenario von den Datenzugriffsrechten der Betriebsart Unternehmen erfasst wird.

Folgende Anforderungen gelten für über diese Schnittstelle zur Verfügung gestellte ITS-Daten:

—	bei diesen Daten handelt es sich um einen Satz ausgewählter bestehender Daten aus dem Datenglossar des Fahrtenschreibers (Anlage 1),

—	ein Teilsatz dieser ausgewählten Daten ist als ‚personenbezogene Daten‘ gekennzeichnet,

—	der Teilsatz ‚personenbezogene Daten‘ ist nur dann verfügbar, wenn die nachweisbare Zustimmung des Fahrers dazu, dass seine persönlichen Daten das Fahrzeugnetzwerk verlassen dürfen, aktiviert ist,

—	die Zustimmung des Fahrers kann jederzeit durch Menübefehle aktiviert oder deaktiviert werden, sofern die Fahrerkarte eingesteckt ist,

—	der Datensatz und der Datenteilsatz werden über Bluetooth-Funkprotokoll im Umkreis der Fahrerkabine mit einer Aktualisierungsrate von 1 Minute übertragen,

—	die Koppelung der ITS-Schnittstelle mit dem externen Gerät wird durch eine spezielle und nach dem Zufallsprinzip erstellte, mindestens 4-stellige PIN geschützt, die in jeder Fahrzeugeinheit gespeichert und über deren Anzeige verfügbar ist,

—	durch eine vorhandene ITS-Schnittstelle darf unter keinen Umständen das ordnungsgemäße Funktionieren und die Sicherheit der Fahrzeugeinheit gestört oder beeinträchtigt werden.

Zusätzlich zum Satz ausgewählter vorhandener Daten, der als Minimalliste gilt, können noch weitere Daten ausgegeben werden, sofern sie nicht als personenbezogene Daten gelten können.

Das Kontrollgerät muss in der Lage sein, den Fahrerzustimmungsstatus an andere Plattformen im Fahrzeugnetzwerk zu übertragen.

Bei eingeschalteter Zündung werden diese Daten ständig ausgesendet.“

17.

Abschnitt 3.23 Absatz 211 erhält folgende Fassung:

„211)

Die Zeit der Systemuhr der Fahrzeugeinheit wird automatisch alle 12 Stunden neu eingestellt. Ist diese Neueinstellung nicht möglich, da kein GNSS-Signal verfügbar ist, erfolgt die Zeiteinstellung, sobald die Fahrzeugeinheit je nach Zustand der Fahrzeugzündung Zugriff auf eine vom GNSS-Empfänger gelieferte gültige Zeit hat. Die Zeitreferenz für die automatische Zeiteinstellung der Systemuhr der Fahrzeugeinheit wird aus dem GNSS-Empfänger abgeleitet.“

18.

In Abschnitt 3.26 erhalten die Absätze 225 und 226 folgende Fassung:

„225)

An jeder gesonderten Komponente des Kontrollgeräts ist ein Typenschild mit folgenden Angaben anzubringen:

—	Name und Anschrift des Herstellers,

—	Teilnummer und Baujahr,

—	Seriennummer,

—	Typgenehmigungszeichen.

226)	Reicht der Platz nicht für alle vorstehend genannten Angaben aus, muss das Typenschild mindestens folgende Angaben enthalten: Name oder Logo des Herstellers und Teilnummer.“

19.	In Abschnitt 4.1 wird die Zeichnung der Vorder- und Rückseite der Fahrerkarte durch folgende Zeichnung ersetzt: „ Text von Bild „ “ “

20.

In Abschnitt 4.5.3.1.8 Absatz 263 erhält der erste Gedankenstrich folgende Fassung:

„—	Störung Karte (wenn die Karte Gegenstand der Störung ist),“

21.

In Abschnitt 4.5.3.2.8 Absatz 288 erhält der erste Gedankenstrich folgende Fassung:

„—	Störung Karte (wenn die Karte Gegenstand der Störung ist),“

22.

Abschnitt 4.5.3.2.16 erhält folgende Fassung:

„4.5.3.2.16 Ortsdaten zu drei Stunden kumulierter Lenkzeit

305)

Die Fahrerkarte muss die folgenden Daten zur Position des Fahrzeugs speichern können, wenn die kumulierte Lenkzeit ein Vielfaches von drei Stunden erreicht:

—	Datum und Uhrzeit, wann die kumulierte Lenkzeit ein Vielfaches von drei Stunden erreicht,

—	Position des Fahrzeugs,

—	GNSS-Genauigkeit, Datum und Uhrzeit der Feststellung der Position,

—	Kilometerstand.

306)

Die Fahrerkarte muss mindestens 252 derartige Datensätze speichern können.“

23.

Abschnitt 4.5.4.2.14 erhält folgende Fassung:

„4.5.4.2.14 Ortsdaten zu drei Stunden kumulierter Lenkzeit

353)

Die Werkstattkarte muss die folgenden Daten zur Position des Fahrzeugs speichern können, wenn die kumulierte Lenkzeit ein Vielfaches von drei Stunden erreicht:

—	Datum und Uhrzeit, wann die kumulierte Lenkzeit ein Vielfaches von drei Stunden erreicht,

—	Position des Fahrzeugs,

—	GNSS-Genauigkeit, Datum und Uhrzeit der Feststellung der Position.

—	Kilometerstand.

354)

Die Werkstattkarte muss mindestens 18 derartige Datensätze speichern können.“

24.

Abschnitt 5.2 Absatz 396 erhält folgende Fassung:

„396)

Die Einbauplakette muss mindestens die nachstehenden Angaben enthalten:

—	Name, Anschrift oder Firmenzeichen des zugelassenen Einbaubetriebs oder der zugelassenen Werkstatt,

—	Wegdrehzahl des Kraftfahrzeugs in der Form ‚w = … imp/km‘,

—	Konstante des Kontrollgeräts in der Form ‚k = … imp/km‘,

—	tatsächlicher Reifenumfang in der Form ‚l = … mm‘,

—	Reifengröße,

—	Datum der Messung der Wegdrehzahl des Kraftfahrzeugs und des tatsächlichen Reifenumfangs,

—	Fahrzeugidentifizierungsnummer,

—	externe GNSS-Ausrüstung (vorhanden/nicht vorhanden),

—	ggf. Seriennummer der externen GNSS-Ausrüstung,

—	ggf. Seriennummer der Fernkommunikationsausrüstung,

—	Seriennummer aller vorhandenen Plombierungen,

—	Fahrzeugteil, in dem der Adapter gegebenenfalls eingebaut wird,

—	Fahrzeugteil, in dem der Bewegungssensor eingebaut wird, wenn er nicht an das Getriebe angeschlossen ist oder kein Adapter verwendet wird,

—	Farbe des Kabels zwischen dem Adapter und diesem Fahrzeugteil, das seine Eingangsimpulse bereitstellt,

—	Seriennummer des eingebetteten Bewegungssensors des Adapters.“

25.

Abschnitt 5.3 wird wie folgt geändert:

Nach Absatz 398 wird ein neuer Absatz 398a eingefügt.

„398a)

Die vorstehend genannten Plombierungen müssen nach EN 16882:2016 zertifiziert sein.“

Absatz 401 Unterabsatz 2 erhält folgende Fassung:

„Diese eindeutige Nummer setzt sich wie folgt zusammen: MMNNNNNNNN als nicht entfernbare Angaben; dabei ist MM das einmalige Herstellerzeichen (die Registrierung in der Datenbank ist von der Europäischen Kommission zu verwalten) und NNNNNNNN die im Bereich des Herstellers einmalige alphanumerische Nummer der Plombierung.“

Absatz 403 erhält folgende Fassung:

„403)

Die Plombenhersteller werden in einer speziellen Datenbank registriert, wenn eines ihrer Plombenmodelle nach EN 16882:2016 zertifiziert wird, und veröffentlichen die Nummern der Plomben nach einem von der Europäischen Kommission festzulegenden Verfahren.“

Absatz 404 erhält folgende Fassung:

„404)

Die zugelassenen Werkstätten und Fahrzeughersteller verwenden im Rahmen der Verordnung (EU) Nr. 165/2014 ausschließlich nach EN 16882:2016 zertifizierte Plomben von Herstellern, die in der vorstehend genannten Datenbank registriert sind.“

26.

Abschnitt 6.2 erhält folgende Fassung:

„6.2 Prüfung neuer oder reparierter Komponenten

407)

Für jedes neue oder reparierte Einzelgerät werden die ordnungsgemäße Arbeitsweise und die Genauigkeit der Anzeigen und Aufzeichnungen innerhalb der in den Kapiteln 3.2.1, 3.2.2, 3.2.3 und 3.3 festgelegten Grenzen geprüft.“

27.

Abschnitt 6.3 Absatz 408 erhält folgende Fassung:

„408)

Beim Einbau in ein Fahrzeug muss die Gesamtanlage (einschließlich des Kontrollgeräts) den Vorschriften über die in den Kapiteln 3.2.1, 3.2.2, 3.2.3 und 3.3 festgelegten zulässigen Fehlergrenzen entsprechen. Die Gesamtanlage ist gemäß Kapitel 5.3 zu plombieren und muss eine Kalibrierung umfassen.“

28.

Abschnitt 8.1 wird wie folgt geändert:

In Abschnitt 8.1 erhält der einleitende Text vor Absatz 425 folgende Fassung:

„Im Sinne dieses Kapitels ist unter dem Ausdruck ‚Kontrollgerät‘ das ‚Kontrollgerät oder seine Komponenten‘ zu verstehen. Für das/die Verbindungskabel zwischen dem Bewegungssensor und der Fahrzeugeinheit, der externen GNSS-Ausrüstung und der Fahrzeugeinheit oder der externen Fernkommunikationsausrüstung und der Fahrzeugeinheit ist keine Typgenehmigung erforderlich. Das zur Verwendung durch das Kontrollgerät bestimmte Papier ist als Komponente des Kontrollgeräts zu betrachten.

Jeder Hersteller kann für Komponenten des Kontrollgeräts in Kombination mit jeder anderen Komponente des Kontrollgeräts die Typgenehmigung beantragen, sofern jede Komponente den Vorschriften dieses Anhangs entspricht. Alternativ kann der Hersteller auch die Typgenehmigung für das Kontrollgerät beantragen.

Wie in der Begriffsbestimmung 10 des Artikels 2 dieser Verordnung beschrieben, können die Komponenten der Fahrzeugeinheiten unterschiedlich zusammengestellt sein. Unabhängig von der Zusammenstellung der Fahrzeugeinheitkomponenten sind die externe Antenne und (sofern vorhanden) der mit dem GNSS-Empfänger oder der Fernkommunikationsausrüstung verbundene Antennensplitter nicht Bestandteil der Typgenehmigung der Fahrzeugeinheit.

Gleichwohl müssen Hersteller, die eine Typgenehmigung für das Kontrollgerät erhalten haben, eine öffentlich zugängliche Liste der Antennen und Splitter vorhalten, die mit den Fahrzeugeinheiten, externen GNSS-Ausrüstungen und externen Fernkommunikationsausrüstungen, die über eine Typgenehmigung verfügen, kompatibel sind.“

Absatz 427 erhält folgende Fassung:

„427)

Die Typgenehmigungsbehörden der Mitgliedstaaten erteilen erst dann eine Typgenehmigung, wenn ihnen

—	ein Sicherheitszertifikat (sofern nach diesem Anhang erforderlich),

—	ein Funktionszertifikat und

—	ein Interoperabilitätszertifikat (sofern nach diesem Anhang erforderlich)

für das Kontrollgerät oder die Fahrtenschreiberkarte, für die die Typgenehmigung beantragt wurde, vorliegen.“

29.

Anlage 1 wird wie folgt geändert:

Das Inhaltsverzeichnis wird wie folgt geändert:

i)	Nummer 2.63 erhält folgende Fassung: „2.63. Reserviert für künftige Verwendung“

ii)	Nummer 2.78 erhält folgende Fassung: „2.78. GNSSAccumulatedDriving“

iii)	Nummer 2.79 erhält folgende Fassung: „2.79. GNSSAccumulatedDrivingRecord“

iv)	Nummer 2.111 erhält folgende Fassung: „2.111. NoOfGNSSADRecords“

v)	Nummer 2.160 erhält folgende Fassung: „2.160. Reserviert für künftige Verwendung“

vi)	Nummer 2.203 erhält folgende Fassung: „2.203. VuGNSSADRecord“

vii)	Nummer 2.204 erhält folgende Fassung: „2.204. VuGNSSADRecordArray“

viii)

Nummer 2.230 erhält folgende Fassung:

„2.230. Reserviert für künftige Verwendung“

ix)	Nummer 2.231 erhält folgende Fassung: „2.231. Reserviert für künftige Verwendung“

In Abschnitt 2 wird vor dem Unterabschnitt 2.1 folgender Wortlaut eingefügt:

„Bei Kartendatentypen, die für Anwendungen der 1. und der 2. Generation verwendet werden, bezieht sich die in dieser Anlage angegebene Größe auf Anwendungen der 2. Generation. Es wird angenommen, dass das Abfragegerät die Größe für Anwendungen der 1. Generation bereits kennt. Die sich auf diese Datentypen beziehenden Randnummern von Anhang IC umfassen Anwendungen der 1. und der 2. Generation.“

Abschnitt 2.19 erhält folgende Fassung:

„2.19. CardEventData

1. Generation:

Auf einer Fahrer- oder Werkstattkarte gespeicherte Information zu den Ereignissen im Zusammenhang mit dem Karteninhaber (Anhang IC Randnummern 260 und 318).

Text von Bild

CardEventData — eine nach absteigendem Wert von EventFaultType geordnete Folge von cardEventRecords (mit Ausnahme von Versuchen der Sicherheitsverletzung, die in der letzten Gruppe der Folge zusammengefasst sind).

cardEventRecords — Ereignisdatensätze einer bestimmten Ereignisart (oder Kategorie bei Ereignissen Versuch Sicherheitsverletzung).

2. Generation:

Auf einer Fahrer- oder Werkstattkarte gespeicherte Information zu den Ereignissen im Zusammenhang mit dem Karteninhaber (Anhang IC Randnummern 285 und 341).

Text von Bild

cardEventRecords — Ereignisdatensätze einer bestimmten Ereignisart (oder Kategorie bei Ereignissen Versuch Sicherheitsverletzung).“

Abschnitt 2.30 erhält folgende Fassung:

„2.30 CardRenewalIndex

Ein Kartenerneuerungsindex (Begriffsbestimmung i)).

Text von Bild

Wertzuweisung: (siehe Kapitel 7 in diesem Anhang).

‚0‘	Erstausstellung.

Reihenfolge für die Erhöhung: ,0, …, 9, A, …, Z‘“

In Abschnitt 2.61 erhält der Text nach der Überschrift „2. Generation“ folgende Fassung:

„

Text von Bild

Zusätzlich zur 1. Generation werden folgende Datenelemente verwendet:

noOfGNSSADRecords — Anzahl der kumulierten GNSS-Lenkzeitendatensätze, die die Karte speichern kann.

noOfSpecificConditionRecords — Anzahl der Datensätze mit Bezug auf spezifische Bedingungen, die die Karte speichern kann.

noOfGNSSADRecords — Anzahl der Datensätze mit Informationen zu den genutzten Fahrzeugeinheiten, die die Karte speichern kann.“

f)	Abschnitt 2.63 erhält folgende Fassung: „2.63. Reserviert für künftige Verwendung“

In Abschnitt 2.67 erhält der Text unter der Überschrift „2. Generation“ folgende Fassung:

„Die Werte der 1. Generation werden um Folgendes ergänzt:

Text von Bild

Hinweis 1:

Die Werte der 2. Generation für Einbauplakette, Adapter und externen GNSS-Anschluss sowie die Werte der 1. Generation für Fahrzeugeinheit und Bewegungssensor können gegebenenfalls in SealRecord verwendet werden.

Hinweis 2:

Im Feld CardHolderAuthorisation (CHA) eines Zertifikats der 2. Generation sind die Werte (1), (2) und (6) als Angabe eines Zertifikats für die gegenseitige Authentisierung für den jeweiligen Gerätetyp zu verstehen. Zur Angabe des jeweiligen Zertifikats für die Erstellung einer digitalen Signatur sind die Werte (17), (18) oder (19) zu verwenden.“

In Abschnitt 2.70 erhält der Text unter der Überschrift „2. Generation“ folgende Fassung:

„2. Generation:

	Allgemeine Ereignisse, Keine weiteren Angaben, Einstecken einer ungültigen Karte, Kartenkonflikt, Zeitüberlappung, Lenken ohne geeignete Karte, Einstecken der Karte während des Lenkens, Letzter Vorgang nicht korrekt abgeschlossen, Geschwindigkeitsüberschreitung, Unterbrechung der Stromversorgung, Datenfehler Weg und Geschwindigkeit, Datenkonflikt Fahrzeugbewegung, Zeitkonflikt (zwischen GNSS und Systemuhr der VU), Kommunikationsfehler mit der Fernkommunikationsausrüstung, Fehlende Positionsdaten des GNSS-Empfängers Kommunikationsfehler mit der externen GNSS-Ausrüstung RFU,
	‚Versuch Sicherheitsverletzung‘ an der Fahrzeugeinheit, Keine weiteren Angaben, Fehlgeschlagene Authentisierung des Bewegungssensors, Authentisierungsfehler der Fahrtenschreiberkarte, Unbefugte Veränderung des Bewegungssensors, Integritätsfehler der Kartendateneingabedaten Integritätsfehler der gespeicherten Benutzerdaten, Interner Datenübertragungsfehler, Unberechtigtes Öffnen des Gehäuses, Hardwaremanipulation, Manipulationserkennung beim GNSS, Authentisierungsfehler der externen GNSS-Ausrüstung, Abgelaufenes Zertifikat der externen GNSS-Ausrüstung, RFU,
	„Versuch Sicherheitsverletzung“ Bewegungssensor, Keine weiteren Angaben, Fehlgeschlagene Authentisierung, Integritätsfehler der gespeicherten Daten, Interner Datenübertragungsfehler, Unberechtigtes Öffnen des Gehäuses, Hardwaremanipulation, RFU,
	Störungen Kontrollgerät, Keine weiteren Angaben, Interne Störung VU, Druckerstörung, Anzeigestörung, Störung beim Herunterladen, Sensorstörung, Interner GNSS-Empfänger, Externe GNSS-Ausrüstung, Fernkommunikationsausrüstung, ITS-Schnittstelle, RFU,
	Kartenstörungen, Keine weiteren Angaben, RFU,
	RFU,
	Herstellerspezifisch.“

Abschnitt 2.71 erhält folgende Fassung:

„2.71. ExtendedSealIdentifier

2. Generation:

Der erweiterte Plombenbezeichner dient der eindeutigen Identifizierung von Plomben (Anhang IC Randnummer 401).

Text von Bild

manufacturerCode — ein Code des Plombenherstellers.

sealIdentifier — ein Bezeichner für die Plombe, der für den Hersteller eindeutig sein muss.“

Die Abschnitte 2.78 und 2.79 erhalten folgende Fassung:

„2.78 GNSSAccumulatedDriving

2. Generation:

Auf einer Fahrer- oder Werkstattkarte gespeicherte Informationen im Zusammenhang mit der GNSS-Position des Fahrzeugs, wenn die kumulierte Lenkzeit ein Vielfaches von drei Stunden erreicht (Anhang IC Randnummern 306 und 354).

Text von Bild

gnssADPointerNewestRecord — Index des zuletzt aktualisierten kumulierten GNSS-Lenkzeitendatensatzes.

Wertzuweisung — Zahl, die dem Zähler des kumulierten GNSS-Lenkzeitendatensatzes entspricht, beginnend mit ‚0‘ für das erste Auftreten des kumulierten GNSS-Lenkzeitendatensatzes in der Struktur.

gnssAccumulatedDrivingRecords — Datensätze mit Datum und Uhrzeit, wann die kumulierte Lenkzeit ein Vielfaches von drei Stunden erreicht, sowie Informationen zur Position des Fahrzeugs.

2.79. GNSSAccumulatedDrivingRecord

2. Generation:

Text von Bild

timeStamp — Datum und Uhrzeit, wann die kumulierte Lenkzeit ein Vielfaches von drei Stunden erreicht.

gnssPlaceRecord — Informationen zur Position des Fahrzeugs.

vehicleOdometerValue — Kilometerstand, wenn die kumulierte Lenkzeit ein Vielfaches von drei Stunden erreicht.“

Abschnitt 2.86 erhält folgende Fassung:

„2.86. KeyIdentifier

Eindeutiger Bezeichner eines öffentlichen Schlüssels zur Herstellung eines Verweises auf den Schlüssel und für dessen Auswahl. Identifiziert zugleich den Inhaber des Schlüssels.

Text von Bild

Die erste Auswahlmöglichkeit eignet sich zum Verweis auf den öffentlichen Schlüssel einer Fahrzeugeinheit, einer Fahrtenschreiberkarte oder einer externen GNSS-Ausrüstung.

Die zweite Auswahlmöglichkeit eignet sich zum Verweis auf den öffentlichen Schlüssel einer Fahrzeugeinheit (falls die Seriennummer der Fahrzeugeinheit zum Zeitpunkt der Generierung des Zertifikats nicht bekannt ist).

Die dritte Auswahlmöglichkeit eignet sich zum Verweis auf den öffentlichen Schlüssel eines Mitgliedstaates.“

Abschnitt 2.92 erhält folgende Fassung:

„2.92. MAC

2. Generation:

Kryptografische Prüfsumme mit einer Länge von 8, 12 oder 16 Byte, entsprechend den in Anlage 11 spezifizierten Cipher Suites.

Text von Bild “

m)	Abschnitt 2.111 erhält folgende Fassung: „2.111. NoOfGNSSADRecords 2. Generation: Anzahl der kumulierten GNSS-Lenkzeitendatensätze, die die Karte speichern kann. Text von Bild NoOfGNSSADRecords ::= INTEGER (0..216-1) Wertzuweisung: siehe Anlage 2.“

n)	In Abschnitt 2.120 Absatz 1 erhält die Wertzuweisung „16H“ folgende Fassung: „ Text von Bild ’16’HVuGNSSADRecord “

o)	Abschnitt 2.160 erhält folgende Fassung: „2.160. Reserviert für künftige Verwendung“

Abschnitt 2.162 erhält folgende Fassung:

„2.162. TimeReal

Code für ein kombiniertes Datum/Uhrzeit-Feld, in dem Datum und Uhrzeit als Sekunden nach dem 1. Januar 1970 00h.00m.00s. UTC ausgedrückt sind.

Text von Bild

Wertzuweisung — Oktettanordnung: Anzahl der Sekunden seit dem 1. Januar 1970, 0.00 Uhr UTC.

Spätestmögliche(s) Datum/Uhrzeit ist im Jahr 2106.“

Abschnitt 2.179 erhält folgende Fassung:

„2.179 VuCardRecord

2. Generation:

In einer Fahrzeugeinheit gespeicherte Information zu einer verwendeten Fahrtenschreiberkarte (Anhang IC Randnummer 132).

Text von Bild

cardNumberAndGenerationInformation — vollständige Kartennummer und Generation der verwendeten Karte (Datentyp 2.74).

cardExtendedSerialNumber — ausgelesen aus der Datei EF_ICC unter MF der Karte.

cardStructureVersion — ausgelesen aus der Datei EF_Application_Identification unter DF_Tachograph_G2.

cardNumber — ausgelesen aus der Datei EF_Identification unter DF_Tachograph_G2.“

Die Abschnitte 2.203 und 2.204 erhalten folgende Fassung:

„2.203 VuGNSSADRecord

2. Generation:

In einer Fahrzeugeinheit gespeicherte Informationen zur GNSS-Position des Fahrzeugs, wenn die kumulierte Lenkzeit ein Vielfaches von drei Stunden erreicht (Anhang IC Randnummern 108 und 110).

Text von Bild

timeStamp — Datum und Uhrzeit, wann die kumulierte Lenkzeit ein Vielfaches von drei Stunden erreicht.

cardNumberAndGenDriverSlot — identifiziert die im Steckplatz Fahrer eingesteckte Karte und ihre Generation.

cardNumberAndGenCodriverSlot — identifiziert die im Steckplatz Beifahrer eingesteckte Karte und ihre Generation.

gnssPlaceRecord — Informationen zur Position des Fahrzeugs.

vehicleOdometerValue — Kilometerstand, wenn die kumulierte Lenkzeit ein Vielfaches von drei Stunden erreicht.

2.204. VuGNSSADRecordArray

2. Generation:

In einer Fahrzeugeinheit gespeicherte Informationen zur GNSS-Position des Fahrzeugs, wenn die kumulierte Lenkzeit ein Vielfaches von drei Stunden erreicht (Anhang IC Randnummern 108 und 110).

Text von Bild

recordType — Art des Datensatzes (VuGNSSADRecord).

Wertzuweisung: siehe RecordType.

recordSize — die Größe von VuGNSSADRecord in Byte.

noOfRecords — Anzahl der Datensätze in der Menge der Datensätze.

records — Menge der kumulierten GNSS-Lenkzeitendatensätze.“

s)	Die Abschnitte 2.230 und 2.231 erhalten folgende Fassung: „2.230. Reserviert für künftige Verwendung. 2.231. Reserviert für künftige Verwendung“

In Abschnitt 2.234 erhält der Text unter der Überschrift „2. Generation“ folgende Fassung:

„

Text von Bild

Zusätzlich zur 1. Generation werden folgende Datenelemente verwendet:

noOfGNSSADRecords — Anzahl der kumulierten GNSS-Lenkzeitendatensätze, die die Karte speichern kann.

noOfSpecificConditionRecords — Anzahl der Datensätze mit Bezug auf spezifische Bedingungen, die die Karte speichern kann.

noOfCardVehicleUnitRecords — Anzahl der Datensätze mit Informationen zu den genutzten Fahrzeugeinheiten, die die Karte speichern kann.“

30.

Anlage 2 wird wie folgt geändert:

In Abschnitt 1.1 werden folgende Abkürzungen eingefügt:

„CHA	Certificate Holder Authorisation (Autorisierung des Zertifikatsinhabers)
DO	Datenobjekt“

Abschnitt 3.3 wird wie folgt geändert:

Der Absatz TCS_24 erhält folgende Fassung:

„TCS_24

Diese Sicherheitsbedingungen können folgendermaßen verknüpft werden:

AND: Alle Sicherheitsbedingungen müssen erfüllt sein.

OR: Mindestens eine Sicherheitsbedingung muss erfüllt sein.

Die Zugriffsregeln für das Dateisystem, d. h., die Befehle SELECT, READ BINARY und UPDATE BINARY sind in Kapitel 4 spezifiziert. Die Zugriffsregeln für die verbleibenden Befehle sind in den folgenden Tabellen beschrieben. Der Ausdruck ‚Nicht zutreffend‘ wird verwendet, wenn der Befehl von keiner Randnummer unterstützt wird. Der Befehl kann dann gegebenenfalls unterstützt werden, aber die Zugriffsbedingung ist nicht anwendbar.“

ii)

Die Tabelle in Absatz TCS_25 erhält folgende Fassung:

„Befehl

Fahrerkarte

Werkstattkarte

Kontrollkarte

Unternehmenskarte

External Authenticate

—	Zur Authentisierung für die 1. Generation

ALW

—	Zur Authentisierung für die 2. 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

Nicht zutreffend

PSO: Compute Digital Signature

ALW OR

SM-MAC-G2

ALW OR

SM-MAC-G2

Nicht zutreffend

PSO: Hash

Nicht zutreffend

ALW

Nicht zutreffend

PERFORM HASH OF FILE

ALW OR

SM-MAC-G2

ALW OR

SM-MAC-G2

Nicht zutreffend

PSO: Verify Certificate

ALW

PSO: Verify Digital Signature

Nicht zutreffend

ALW

Nicht zutreffend

Verify

Nicht zutreffend

ALW

Nicht zutreffend

Nicht zutreffend“

iii)

Die Tabelle in Absatz TCS_26 erhält folgende Fassung:

„Befehl

Fahrerkarte

Werkstattkarte

Kontrollkarte

Unternehmenskarte

External Authenticate

—	Zur Authentisierung für die 1. Generation

Nicht zutreffend

—	Zur Authentisierung für die 2. Generation

ALW

PWD

ALW

Internal Authenticate

Nicht zutreffend

General Authenticate

ALW

Get Challenge

ALW

MSE:SET AT

ALW

MSE:SET DST

ALW

Process DSRC Message

Nicht zutreffend

ALW

Nicht zutreffend

PSO: Compute Digital Signature

ALW OR

SM-MAC-G2

ALW OR

SM-MAC-G2

Nicht zutreffend

PSO: Hash

Nicht zutreffend

ALW

Nicht zutreffend

PERFORM HASH OF FILE

ALW OR

SM-MAC-G2

ALW OR

SM-MAC-G2

Nicht zutreffend

PSO: Verify Certificate

ALW

PSO: Verify Digital Signature

Nicht zutreffend

ALW

Nicht zutreffend

Verify

Nicht zutreffend

ALW

Nicht zutreffend

Nicht zutreffend“

iv)

Die Tabelle in Absatz TCS_27 erhält folgende Fassung:

„Befehl

Fahrerkarte

Werkstattkarte

Kontrollkarte

Unternehmenskarte

External Authenticate

—	Zur Authentisierung für die 1. Generation

Nicht zutreffend

—	Zur Authentisierung für die 2. Generation

ALW

PWD

ALW

Internal Authenticate

Nicht zutreffend

General Authenticate

ALW

Get Challenge

ALW

MSE:SET AT

ALW

MSE:SET DST

ALW

Process DSRC Message

Nicht zutreffend

PSO: Compute Digital Signature

Nicht zutreffend

PSO: Hash

Nicht zutreffend

PERFORM HASH OF FILE

Nicht zutreffend

PSO: Verify Certificate

ALW

PSO: Verify Digital Signature

Nicht zutreffend

Verify

Nicht zutreffend

ALW

Nicht zutreffend

Nicht zutreffend“

In Abschnitt 3.4 erhält der Absatz TCS_29 folgende Fassung:

„TCS_29

In jeder Antwortnachricht werden die Statusbytes SW1 SW2 zurückgesendet, die den Verarbeitungszustand des Befehls bezeichnen.

SW1

SW2

Bedeutung

Normale Verarbeitung

Normale Verarbeitung XX = Zahl der verfügbaren Antwortbytes

Verarbeitungswarnung. Ein Teil der zurückgesendeten Daten kann beschädigt sein.

Authentisierung fehlgeschlagen (Warnung)

Falsche CHV (PIN). Zähler für verbleibende Versuche ‚X‘.

Ausführungsfehler — Zustand des nichtflüchtigen Speichers unverändert. Integritätsfehler.

Ausführungsfehler — Zustand des nichtflüchtigen Speichers verändert.

Ausführungsfehler — Zustand des nichtflüchtigen Speichers verändert – Speicherfehler.

Sicherheitsfehler

falsche kryptografische Prüfsumme (bei Secure Messaging) oder

falsches Zertifikat (bei Zertifikatsverifizierung) oder

falsches Kryptogramm (bei externer Authentisierung) oder

falsche Signatur (bei Signaturverifizierung)

Falsche Länge (falsche Lc oder Le)

Letzter Befehl der Kette erwartet

Verbotener Befehl (keine Antwort verfügbar in T=0)

Sicherheitsstatus nicht erfüllt

Authentisierungsverfahren blockiert

Nutzungsbedingungen nicht erfüllt

Befehl nicht zulässig (keine aktuelle EF)

Erwartete Secure-Messaging-Datenobjekte fehlen

Inkorrekte Secure-Messaging-Datenobjekte

Falsche Parameter im Datenfeld

Datei nicht gefunden

Falsche Parameter P1-P2

Bezugsdaten nicht gefunden

Falsche Parameter (Offset außerhalb der EF)

Falsche Länge, SW2 gibt die genaue Länge an. Kein Datenfeld wird zurückgesendet

Befehlscode nicht unterstützt oder ungültig

Klasse nicht unterstützt

—	Sonstige Prüffehler

Weitere in ISO/IEC 7816-4 definierte Statusbytes können zurückgesendet werden, wenn ihr Verhalten in dieser Anlage nicht ausdrücklich erwähnt wird.

Zum Beispiel können die folgenden Statusbytes optional zurückgesendet werden:

6881: Logischer Kanal nicht unterstützt

6882: Secure Messaging nicht unterstützt“

In Abschnitt 3.5.1.1 Absatz TCS_38 erhält der letzte Gedankenstrich folgende Fassung:

„—	Wird die ausgewählte Anwendung als verfälscht betrachtet (weil in den Dateiattributen ein Integritätsfehler festgestellt wurde), lautet der zurückgesendete Verarbeitungsstatus ‚6400‘ oder ‚6500‘.“

In Abschnitt 3.5.1.2 Absatz TCS_41 erhält der letzte Gedankenstrich folgende Fassung:

„—	Wird die ausgewählte Datei als verfälscht betrachtet (weil in den Dateiattributen ein Integritätsfehler festgestellt wurde), lautet der zurückgesendete Verarbeitungsstatus ‚6400‘ oder ‚6500‘.“

In Abschnitt 3.5.2.1 Absatz TCS_43 erhält der sechste Gedankenstrich folgende Fassung:

„—	Wird in den Dateiattributen ein Integritätsfehler festgestellt, so betrachtet die Karte die Datei als beschädigt und nicht wieder herstellbar und der zurückgesendete Verarbeitungsstatus lautet ‚6400‘ oder ‚6500‘.“

Abschnitt 3.5.2.1.1 wird wie folgt geändert:

Die Tabelle in Absatz TCS_45 erhält folgende Fassung:

„Byte

Länge

Wert

Beschreibung

‚81h‘

TPV: Tag für Klarwertdaten

‚NNh‘ oder

‚81 NNh‘

LPV: Länge der zurückgesendeten Daten (= Original Le).

L gleich 2 Bytes, wenn LPV > 127 Bytes

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

‚XX..XXh‘

Klardatenwert

#(2+L+NN)

‚99h‘

Tag für Verarbeitungsstatus (SW1-SW2) — optional für Secure Messaging der 1. Generation

#(3+L+NN)

‚02h‘

Länge des Verarbeitungsstatus — optional für Secure Messaging der 1. Generation

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

‚XX XXh‘

Verarbeitungsstatus der ungeschützten APDU-Antwort — optional für Secure Messaging der 1. Generation

#(6+L+NN)

‚8Eh‘

TCC: Tag für kryptografische Prüfsumme

#(7+L+NN)

‚XXh‘

LCC: Länge der folgenden kryptografischen Prüfsumme

‚04h‘ für Secure Messaging der 1. Generation (siehe Anlage 11 Teil A)

‚08h‘, ‚0Ch‘ oder ‚10h‘ in Abhängigkeit von der AES-Schlüssellänge für Secure Messaging der 2. Generation (siehe Anlage 11 Teil B)

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

‚XX..XXh‘

Kryptografische Prüfsumme

‚XXXXh‘

Statusbytes (SW1, SW2)“

ii)

Die Tabelle in Absatz TCS_46 erhält folgende Fassung:

„Byte

Länge

Wert

Beschreibung

‚87h‘

TPI CG: Tag für verschlüsselte Daten (Kryptogramm)

‚MMh‘ oder

‚81 MMh‘

LPI CG: Länge der zurückgesendeten verschlüsselten Daten (wegen Auffüllung anders als Original-Le des Befehls).

L gleich 2 Bytes, wenn LPI CG > 127 Bytes.

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

‚01XX..XXh‘

Verschlüsselte Daten: Auffüllindikator und Kryptogramm

#(2+L+MM)

‚99h‘

Tag für Verarbeitungsstatus (SW1-SW2) — optional für Secure Messaging der 1. Generation

#(3+L+MM)

‚02h‘

Länge des Verarbeitungsstatus — optional für Secure Messaging der 1. Generation

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

‚XX XXh‘

Verarbeitungsstatus der ungeschützten APDU-Antwort – optional für Secure Messaging der 1. Generation

#(6+L+MM)

‚8Eh‘

TCC: Tag für kryptografische Prüfsumme

#(7+L+MM)

‚XXh‘

LCC: Länge der folgenden kryptografischen Prüfsumme

‚04h‘ für Secure Messaging der 1. Generation (siehe Anlage 11 Teil A)

‚08h‘, ‚0Ch‘ oder ‚10h‘ in Abhängigkeit von der AES-Schlüssellänge für Secure Messaging der 2. Generation (siehe Anlage 11 Teil B)

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

‚XX..XXh‘

Kryptografische Prüfsumme

‚XXXXh‘

Statusbytes (SW1, SW2)“

In Abschnitt 3.5.2.2 Absatz TCS_50 erhält der sechste Gedankenstrich folgende Fassung:

„—	Wird in den Dateiattributen ein Integritätsfehler festgestellt, so betrachtet die Karte die Datei als beschädigt und nicht wieder herstellbar und der zurückgesendete Verarbeitungsstatus lautet ‚6400‘ oder ‚6500‘.“

Abschnitt 3.5.2.3 Absatz TCS_52 wird wie folgt geändert:

Die letzte Zeile der Tabelle erhält folgende Fassung:

„Le

‚XXh‘

Gemäß ISO/IEC 7816-4“

ii)	Folgender Satz wird angefügt: „Ist T=0, geht die Karte vom Wert Le = ‚00h‘ aus, sofern kein Secure Messaging angewandt wird. Bei T=1 lautet der zurückgesendete Verarbeitungsstatus ‚6700‘, falls Le= ‚01h‘.“

In Abschnitt 3.5.2.3 Absatz TCS_53 erhält der sechste Gedankenstrich folgende Fassung:

„—	Wird in den Dateiattributen ein Integritätsfehler festgestellt, so betrachtet die Karte die Datei als beschädigt und nicht wieder herstellbar und der zurückgesendete Verarbeitungsstatus lautet ‚6400‘ oder ‚6500‘.“

In Abschnitt 3.5.3.2 Absatz TCS_63 erhält der sechste Gedankenstrich folgende Fassung:

„—	Wird in den Dateiattributen ein Integritätsfehler festgestellt, so betrachtet die Karte die Datei als beschädigt und nicht wieder herstellbar und der zurückgesendete Verarbeitungsstatus lautet ‚6400‘ oder ‚6500‘.“

In Abschnitt 3.5.5 erhält der Absatz TCS_72 folgende Fassung:

„TCS_72

Die vom Benutzer eingegebene PIN muss ASCII-kodiert und durch das IFD bis zu einer Länge von 8 Byte nach rechts mit ‚FFh‘-Bytes aufgefüllt sein (siehe auch Datentyp WorkshopCardPIN in Anlage 1).“

Abschnitt 3.5.8 Absatz TCS_95 erhält folgende Fassung:

„TCS_95

Ist der Befehl INTERNAL AUTHENTICATE erfolgreich, wird der aktuelle Sitzungsschlüssel der 1. Generation, sofern vorhanden, gelöscht und ist nicht mehr verfügbar. Um einen neuen Sitzungsschlüssel der 1. Generation zur Verfügung zu haben, muss der Befehl EXTERNAL AUTHENTICATE für den Authentisierungsmechanismus der 1. Generation erfolgreich ausgeführt werden.

Hinweis:

Für Sitzungsschlüssel der 2. Generation siehe Anlage 11 CSM_193 und CSM_195. Werden Sitzungsschlüssel der 2. Generation erstellt und erhält die Fahrtenschreiberkarte den APDU-Klartextbefehl INTERNAL AUTHENTICATE, bricht sie die Secure-Messaging-Sitzung der 2. Generation ab und vernichtet die Sitzungsschlüssel der 2. Generation.“

Abschnitt 3.5.9 Absatz TCS_97 erhält folgende Fassung:

„TCS_97

Die Befehlsvariante für die gegenseitige VU-Karten-Authentisierung der 2. Generation kann in MF, DF Tachograph und DF Tachograph_G2 erfolgen (siehe auch TCS_34). Ist der Befehl EXTERNAL AUTHENTICATE der 2. Generation erfolgreich, wird der aktuelle Sitzungsschlüssel der 1. Generation, sofern vorhanden, gelöscht und ist nicht mehr verfügbar.

Hinweis:

Für Sitzungsschlüssel der 2. Generation siehe Anlage 11 CSM_193 und CSM_195. Werden Sitzungsschlüssel der 2. Generation erstellt und erhält die Fahrtenschreiberkarte den APDU-Klartextbefehl EXTERNAL AUTHENTICATE, bricht sie die Secure-Messaging-Sitzung der 2. Generation ab und vernichtet die Sitzungsschlüssel der 2. Generation.“

In Abschnitt 3.5.10 Absatz TCS_101 wird in der Tabelle die folgende Zeile angefügt:

„5 + L + 1

‚00h‘

Gemäß ISO/IEC 7816-4“

In Abschnitt 3.5.11.2.3 Absatz TCS_114 werden folgende Unterabsätze angefügt:

„—	Weist der Wert currentAuthenticatedTime der Karte einen späteren Zeitpunkt als das Ablaufdatum des ausgewählten öffentlichen Schlüssels auf, lautet der zurückgesendete Verarbeitungsstatus ‚6A88‘.

Hinweis:

Im Fall eines Befehls MSE:SET AT für die VU-Authentisierung ist der Schlüssel, auf den verwiesen wird, ein öffentlicher VU_MA-Schlüssel. Die Karte legt, falls in ihrem Speicher vorhanden, den öffentlichen VU_MA-Schlüssel für die Nutzung fest, der der im Befehlsdatenfeld angegebenen Referenz des Zertifikatinhabers (Certificate Holder Reference, CHR) entspricht (die Karte kann öffentliche VU_MA-Schlüssel anhand des CHA-Felds des Zertifikats identifizieren). Die Karte sendet ‚6A 88‘ auf diesen Befehl zurück, falls nur der öffentliche Schlüssel VU_Sign oder kein öffentlicher Schlüssel der Fahrzeugeinheit verfügbar ist. Siehe die Definition des CHA-Felds in Anlage 11 sowie des Datentyps EquipmentType in Anlage 1.

Ebenso ist der Schlüssel, auf den verwiesen wird, immer ein EQT_Sign-Schlüssel, der für die Verifizierung einer digitalen Signatur zu verwenden ist, wenn ein Befehl MSE: SET DST, der auf ein Gerät (EQT) (d. h. auf eine Fahrzeugeinheit oder Karte) verweist, an eine Kontrollkarte gesendet wird. Nach Anlage 11 Abbildung 13 hat die Kontrollkarte den relevanten öffentlichen Schlüssel EQT_Sign immer gespeichert. In manchen Fällen kann die Kontrollkarte auch den entsprechenden öffentlichen Schlüssel EQT_MA gespeichert haben. Die Kontrollkarte muss den zu verwendenden öffentlichen Schlüssel EQT_Sign immer festlegen, wenn sie einen Befehl MSE: SET DST erhält.“

Abschnitt 3.5.13 wird wie folgt geändert:

Der Absatz TCS_121 erhält folgende Fassung:

„TCS_121

Der temporär gespeicherte ‚hash of file‘-Wert ist zu löschen, wenn mithilfe des Befehls PERFORM HASH of FILE ein neuer Hashwert berechnet wird, wenn ein DF ausgewählt wird und wenn die Fahrtenschreiberkarte zurückgesetzt wird.“

ii)

Der Absatz TCS_123 erhält folgende Fassung:

„TCS_123

Die Fahrtenschreiberanwendung der 2. Generation muss den Algorithmus SHA-2, SHA-256, SHA-384 oder SHA-512 unterstützen, der durch die Cipher Suite in Anlage 11 Teil B für den Kartensignaturschlüssel Card_Sign spezifiziert wird.“

iii)

Die Tabelle in Absatz TCS_124 erhält folgende Fassung:

„Byte	Länge	Wert	Beschreibung
CLA	1	‚80h‘	CLA
INS	1	‚2Ah‘	Perform Security Operation
P1	1	‚90h‘	Tag: Hash
P2	1	‚00h‘	Algorithmus implizit bekannt Für die Fahrtenschreiberanwendung der 1. Generation: SHA-1 Für die Fahrtenschreiberanwendung der 2. Generation: SHA-2-Algorithmus (SHA-256, SHA-384 oder SHA-512) entsprechend der Cipher Suite in Anlage 11 Teil B für den Kartensignaturschlüssel Card_Sign“

Abschnitt 3.5.14 wird wie folgt geändert:

Der Text unter der Überschrift bis Absatz TCS_126 erhält folgende Fassung:

„Dieser Befehl wird zur Berechnung der digitalen Signatur des zuvor berechneten Hashcodes (siehe PERFORM HASH of FILE, Abschnitt 3.5.13) verwendet.

Nur die Fahrer- und die Werkstattkarte müssen diesen Befehl in DF Tachograph und DF Tachograph_G2 unterstützen.

Andere Arten von Fahrtenschreiberkarten können diesen Befehl gegebenenfalls implementieren. Im Falle einer Fahrtenschreiberanwendung der 2. Generation haben nur die Fahrerkarte und die Werkstattkarte einen Signaturschlüssel der 2. Generation, während andere Karten den Befehl nicht erfolgreich ausführen können und mit einem geeigneten Fehlercode abschließen.

Der Befehl kann in MF gegebenenfalls zur Verfügung stehen. Steht der Befehl in MF nicht zur Verfügung, schließt er mit einem geeigneten Fehlercode ab.

Dieser Befehl entspricht den Festlegungen von ISO/IEC 7816-8. Die Verwendung des Befehls ist jedoch im Vergleich zur entsprechenden Norm eingeschränkt.“

Abschnitt 3.5.15 wird wie folgt geändert:

Die Tabelle in Absatz TCS_133 erhält folgende Fassung:

„Byte

Länge

Wert

Beschreibung

CLA

‚00h‘

CLA

INS

‚2Ah‘

Perform Security Operation

‚00h‘

‚A8h‘

Tag: Datenfeld enthält für die Verifizierung relevante DO

‚XXh‘

Länge Lc des nachfolgenden Datenfelds

‚9Eh‘

Tag für digitale Signatur

#7 oder

#7 – #8

‚NNh‘ oder

‚81 NNh‘

Länge der digitalen Signatur (L gleich 2 Bytes, wenn die Länge der digitalen Signatur mehr als 127 Bytes beträgt):

128 Bytes, kodiert gemäß Anlage 11 Teil A für Fahrtenschreiberanwendung der 1. Generation.

Je nach der für die Fahrtenschreiberanwendung der 2. Generation ausgewählten Kurve (siehe Anlage 11 Teil B).

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

‚XX..XXh‘

Inhalt der digitalen Signatur“

ii)

In Absatz TCS_134 wird folgender Gedankenstrich angefügt:

„—

Weist der (zur Verifizierung der digitalen Signatur verwendete) ausgewählte öffentliche Schlüssel einen CHA.LSB (CertificateHolderAuthorisation.equipmentType) auf, der nicht für die Verifizierung der digitalen Signatur gemäß Anlage 11 geeignet ist, lautet der zurückgesendete Verarbeitungsstatus ‚6985‘.“

Abschnitt 3.5.16 wird wie folgt geändert:

In Absatz TCS_138 wird in die Tabelle die folgende Zeile eingefügt:

„5 + L + 1

‚00h‘

Gemäß ISO/IEC 7816-4“

ii)

In Absatz TCS_139 wird folgender Unterabsatz angefügt:

„—	‚6985‘ gibt an, dass der 4-Byte-Zeitstempel im Befehlsdatenfeld vor dem Zeitpunkt cardValidityBegin oder nach dem cardExpiryDate liegt.“

Abschnitt 4.2.2 wird wie folgt geändert:

i)	In der Datenstruktur in Absatz TCS_154 erhalten die Zeilen von DF Tachograph G2 bis EF CardMA_Certificate sowie die Zeilen von EF GNSS_Places bis zum Ende des Absatzes folgende Fassung: „ Text von Bild Datei/Datenelement Anzahl Datensätze Größe (Bytes) Standardwerte Min. Max. “

ii)

In Absatz TCS_155 erhält der Punkt

der Tabelle folgende Fassung:

„

252

336“

In Abschnitt 4.3.1 Absatz TCS_156 erhält der Text zur Abkürzung SC4 folgende Fassung:

„SC4	Für den Befehl READ BINARY mit geradem INS-Byte: (SM-C-MAC-G1 UND SM-R-ENC-MAC-G1) ODER (SM-C-MAC-G2 UND SM-R-ENC-MAC-G2) Für den Befehl READ BINARY mit ungeradem INS-Byte (falls unterstützt): NEV“

Abschnitt 4.3.2 wird wie folgt geändert:

In der Datenstruktur in Absatz TCS_162 erhalten die Zeilen von DF Tachograph G2 bis EF CardMA_Certificate, die Zeilen von EF Calibration bis extendedSealIdentifier und die Zeilen von EF GNSS_Places bis vehicleOdometerValue folgende Fassung:

„

Text von Bild

“

ii)

Der Eintrag NoOfGNSSCDRecords der Tabelle in Absatz TCS_163 erhält folgende Fassung:

„

24“

31.

Anlage 3 Abschnitt 2 wird wie folgt geändert:

a)	Nach der Zeile mit den Piktogrammen „Ort des Beginns des Arbeitstages“ und „Ort des Endes des Arbeitstages“ wird folgende Zeile eingefügt: „ Position nach 3 Stunden kumulierter Lenkzeit“

b)	Die Piktogrammkombination „Zeiteinstellung (durch Werkstatt)“ erhält folgende Fassung: „ Zeitkonflikt oder Zeiteinstellung (durch Werkstatt)“

c)	Der Ereignisliste werden folgende Piktogrammkombinationen hinzugefügt: „ Fehlende Positionsdaten des GNSS-Empfängers oder Kommunikationsfehler mit der externen GNSS-Ausrüstung Kommunikationsfehler mit der Fernkommunikationsausrüstung“

32.

Anlage 4 wird wie folgt geändert:

Abschnitt 2 wird wie folgt geändert:

Block Nummer 11.4 erhält folgende Fassung:

„11.4

Eingabe des Orts des Beginns und/oder des Endes des Arbeitstages

pi = Piktogramm Ort Beginn/Ende, Uhrzeit, Land, Region

Längengrad der aufgezeichneten Position

Breitengrad der aufgezeichneten Position

Zeitstempel der Positionsfeststellung

Kilometerstand

pihh:mm Cou Reg

lon ±DDDoMM.M’

lat ± DDoMM.M’

hh:mm

x xxx xxx km“

ii)

Block Nummer 11.5 erhält folgende Fassung:

„11.5

Positionen nach 3 Stunden kumulierter Lenkzeit

pi=Position nach 3 Stunden kumulierter Lenk

zeit

Längengrad der aufgezeichneten Position

Breitengrad der aufgezeichneten Position

Zeitstempel der Positionsfeststellung

Kilometerstand

“

In Abschnitt 3.1 erhält Punkt 11.5 zum Format des täglichen Ausdrucks folgende Fassung:

„11.5

Positionen nach 3 Stunden kumulierter Lenkzeit in chronologischer Reihenfolge“

In Abschnitt 3.2 erhält das Format des täglichen Ausdrucks folgende Fassung:

„1		Datum und Uhrzeit des Ausdrucks
2		Art des Ausdrucks
3		Angaben zum Karteninhaber (für alle in die VU eingesteckten Karten + GEN)
4		Fahrzeugkennung (Fahrzeug, von dem der Ausdruck erstellt wird)
5		VU-Kennung (VU, mit der der Ausdruck erstellt wird)
6		Letzte Kalibrierung dieser VU
7		Letzte Kontrolle auf diesem Fahrtenschreiber
9		Begrenzungszeichen Fahrertätigkeiten
10		Begrenzungszeichen Steckplatz Fahrer (Steckplatz 1)
10a		Bedingung ‚Kontrollgerät nicht erforderlich‘ zu Tagesbeginn
10.1 / 10.2 / 10.3 /10.3a / 10.4		Tätigkeiten in chronologischer Reihenfolge (Steckplatz Fahrer)
10		Begrenzungszeichen Steckplatz 2. Fahrer (Steckplatz 2)
10a		Bedingung ‚Kontrollgerät nicht erforderlich‘ zu Tagesbeginn
10.1 / 10.2 / 10.3 /10.3a / 10.4		Tätigkeiten in chronologischer Reihenfolge (Steckplatz Beifahrer)
11		Begrenzungszeichen Tageszusammenfassung
11.1		Zusammenfassung der Zeitabschnitte ohne Karte im Steckplatz Fahrer
11.4		Eingegebene Orte in chronologischer Reihenfolge
11.5		Positionen nach 3 Stunden kumulierter Lenkzeit in chronologischer Reihenfolge
11.7		Gesamtwerte Tätigkeiten
11.2		Zusammenfassung der Zeitabschnitte ohne Karte im Steckplatz Beifahrer
11.4		Eingegebene Orte in chronologischer Reihenfolge
11.5		Positionen nach 3 Stunden kumulierter Lenkzeit in chronologischer Reihenfolge
11.8		Gesamtwerte Tätigkeiten
11.3		Zusammenfassung der Tätigkeiten für einen Fahrer, beide Steckplätze
	11.4	Von diesem Fahrer eingegebene Orte in chronologischer Reihenfolge
	11.5	Positionen nach 3 Stunden kumulierter Lenkzeit in chronologischer Reihenfolge
11.9		Gesamtwerte Tätigkeiten für diesen Fahrer
13.1		Begrenzungszeichen Ereignisse/Störungen
13.4		Datensätze Ereignis/Störung (die letzten 5 in der VU gespeicherten oder andauernden Ereignisse/Störungen)
22.1		Kontrollort
22.2		Unterschrift des Kontrolleurs
22.3		Anfangszeit (Platz für die Angabe der zutreffenden Zeitabschnitte durch einen Fahrer ohne Karte)
22.4		Endzeit
22.5		Unterschrift des Fahrers“

In Abschnitt 3.7 erhält der Absatz PRT_014 folgende Fassung:

„PRT_014

Der Ausdruck Historie der eingesteckten Karten hat folgendes Format:

1	Datum und Uhrzeit des Ausdrucks
2	Art des Ausdrucks
3	Karteninhaberkennungen (sämtlicher in die VU eingesteckten Karten)
23	Zuletzt in VU eingesteckte Karte
23.1	Eingesteckte Karten (bis zu 88 Einträge)
12.3	Begrenzungszeichen Störungen“

33.

Anlage 7 wird wie folgt geändert:

Abschnitt 1.1 erhält folgende Fassung:

„1.1. Geltungsbereich

Das Herunterladen von Daten auf ein ESM kann erfolgen:

—	von einer Fahrzeugeinheit (Vehicle Unit, VU) durch ein an die VU angeschlossenes Intelligent Dedicated Equipment (IDE),

—	von einer Fahrtenschreiberkarte durch ein mit einem Kartenschnittstellengerät (IFD) ausgestattetes IDE,

—	von einer Fahrtenschreiberkarte über eine Fahrzeugeinheit durch ein an die VU angeschlossenes IDE.

Um eine Prüfung der Echtheit und Integrität der auf einem ESM gespeicherten heruntergeladenen Daten zu ermöglichen, werden die Daten mit einer gemäß Anlage 11 (Gemeinsame Sicherheitsmechanismen) angefügten Signatur heruntergeladen. Ebenfalls heruntergeladen werden die Kennung des Ursprungsgeräts (VU oder Karte) und dessen Sicherheitszertifikate (Mitgliedstaatszertifikat und Gerätezertifikat). Der Prüfer der Daten muss einen zuverlässigen europäischen öffentlichen Schlüssel besitzen.

Daten, die von einer VU heruntergeladen werden, werden gemäß Anlage 11 (Gemeinsame Sicherheitsmechanismen Teil B, Fahrtenschreibersystem der 2. Generation) unterzeichnet, außer wenn Fahrer von einer Nicht-EU-Kontrollbehörde mit einer Kontrollkarte der 1. Generation kontrolliert werden; in diesem Fall werden die Daten im Einklang mit Anlage 15 (Migration) Randnummer MIG_015 gemäß Anlage 11 (Gemeinsame Sicherheitsmechanismen Teil A, Fahrtenschreibersystem der 1. Generation) unterzeichnet.

In dieser Anlage werden daher zwei Arten des Datendownloads von VU spezifiziert:

—	VU-Datendownload der 2. Generation mit Datenstruktur der 2. Generation und Unterzeichnung gemäß Anlage 11 Gemeinsame Sicherheitsmechanismen Teil B,

—	VU-Datendownload der 1. Generation mit Datenstruktur der 1. Generation und Unterzeichnung gemäß Anlage 11 Gemeinsame Sicherheitsmechanismen Teil A.

Ebenso gibt es, wie in den Abschnitten 3 und 4 dieser Anlage ausgeführt, zwei Arten von Datendownloads von in VU eingesetzten Fahrerkarten der 2. Generation.“

Abschnitt 2.2.2 wird wie folgt geändert:

Die Tabelle erhält folgende Fassung:

„Nachrichtenstruktur		Max. 4 Bytes Kopf				Max. 255 Bytes Daten			1 Byte Prüfsumme
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	9B
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 Baud		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	0A	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 oder 21		97
Activities		80	EE	F0	06	36	02 oder 22	Datum	CS
Events & Faults		80	EE	F0	02	36	03 oder 23	Datum	99
Detailed Speed		80	EE	F0	02	36	04 oder 24	Datum	9A
Technical Data		80	EE	F0	02	36	05 oder 25	Datum	9B
Card download		80	EE	F0	02	36	06	Slot	CS
Positive Response Transfer Data		80	F0	EE	Len	76	TREP	Daten	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		Daten	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)

Den Anmerkungen nach der Tabelle werden folgende Gedankenstriche angefügt:

„—

TRTP 21 bis 25 werden für VU-Datendownload-Anforderungen der 2. Generation verwendet und TRTP 01 bis 05 für Anfragen für VU-Datendownload-Anforderungen der 1. Generation, die von der VU nur akzeptiert werden können, wenn Fahrer von einer Nicht-EU-Kontrollbehörde mit einer Kontrollkarte der 1. Generation kontrolliert werden.

—	TRTP 11 bis 19 und 31 bis 39 sind für herstellerspezifische Download-Anforderungen reserviert.“

Abschnitt 2.2.2.9 wird wie folgt geändert:

Absatz DDP_011 erhält folgende Fassung:

„DDP_011

Die Nachricht Transfer Data Request wird vom IDE gesendet und spezifiziert der VU den herunterzuladenden Datentyp. Mit dem Byte Transfer Request Parameter (TRTP) wird die Übertragungsart angegeben.

Es gibt sechs Arten der Datenübertragung. Beim VU-Datendownload können für jede Übertragungsart zwei unterschiedliche TRTP-Werte verwendet werden:

Datenübertragungsart	TRTP-Wert für VU-Datendownloads der 1. Generation	TRTP-Wert für VU-Datendownloads der 2. Generation
Überblick	01	21
Tätigkeiten eines bestimmten Tages	02	22
Ereignisse und Störungen	03	23
Genaue Geschwindigkeitsangaben	04	24
Technische Daten	05	25

Datenübertragungsart	TRTP-Wert
Kartendownload	06“

ii)

Absatz DDP_054 erhält folgende Fassung:

„DDP_054

Die IDE muss beim Herunterladen eine Überblicks-Datenübertragung (TRTP 01 oder 21) anfordern, da nur so die VU-Zertifikate in der heruntergeladenen Datei gespeichert werden (und die digitale Signatur geprüft werden kann).

Im zweiten Fall (TRTP 02 oder 22) schließt die Nachricht Transfer Data Request die Angabe des herunterzuladenden Kalendertags (Format ) ein.“

Abschnitt 2.2.2.10 Absatz DDP_055 erhält folgende Fassung:

„DDP_055

Im ersten Fall (TREP 01 oder 21) sendet die VU Daten, die es dem IDE-Bediener erleichtern, die von ihm herunterzuladenden Daten auszuwählen. Diese Nachricht enthält folgende Informationen:

—	Sicherheitszertifikate,

—	Fahrzeugkennung,

—	aktuelles Datum und Uhrzeit der VU,

—	min. und max. herunterladbares Datum (VU-Daten),

—	Angabe der in die VU eingesteckten Karten,

—	der vorherige Download an ein Unternehmen,

—	Unternehmenssperren,

—	bisherige Kontrollen.“

Abschnitt 2.2.2.16 Absatz DDP_018 letzter Gedankenstrich erhält folgende Fassung:

„—	FA data not available Das Datenobjekt einer Datenübertragungsanforderung ist in der VU nicht verfügbar (z. B. keine Karte eingesetzt, VU-Datendownload-Anforderung der 1. Generation außerhalb des Rahmens von Fahrerkontrollen durch eine Nicht-EU-Kontrollbehörde, …).“

Abschnitt 2.2.6.1 wird wie folgt geändert:

i)	Absatz DDP_029 Unterabsatz 1 erhält folgende Fassung: „Das Datenfeld der Nachricht Positive Response Transfer Data Overview liefert folgende Daten in folgender Reihenfolge unter SID 76 Hex und TREP 01 oder 21 Hex. Es muss eine geeignete Aufteilung und Zählung der Teilnachrichten erfolgen:“

ii)	Die Überschrift „Datenstruktur der 1. Generation“ erhält folgende Fassung: „Datenstruktur der 1. Generation (TREP 01 Hex)“

iii)	Die Überschrift „Datenstruktur der 2. Generation“ erhält folgende Fassung: „Datenstruktur der 2. Generation (TREP 21 Hex)“

Abschnitt 2.2.6.2 wird wie folgt geändert:

i)	Absatz DDP_030 Unterabsatz 1 erhält folgende Fassung: „Das Datenfeld der Nachricht Positive Response Transfer Data Activities liefert folgende Daten in folgender Reihenfolge unter SID 76 Hex und TREP 02 oder 22 Hex. Es muss eine geeignete Aufteilung und Zählung der Teilnachrichten erfolgen:“

ii)	Die Überschrift „Datenstruktur der 1. Generation“ erhält folgende Fassung: „Datenstruktur der 1. Generation (TREP 02 Hex)“

iii)	Die Überschrift „Datenstruktur der 2. Generation“ erhält folgende Fassung: „Datenstruktur der 2. Generation (TREP 22 Hex)“

iv)

Der Eintrag VuGNSSCDRecordArray unter der Überschrift „Datenstruktur der 2. Generation (TREP 22 Hex)“ erhält folgende Fassung:

„

GNSS-Position des Fahrzeugs, wenn die kumulierte Lenkzeit des Fahrzeugs ein Vielfaches von drei Stunden erreicht. Ist der Abschnitt leer, wird ein Array-Kopf mit noOfRecords = 0 gesendet.“

Abschnitt 2.2.6.3 wird wie folgt geändert:

Absatz DDP_031 Unterabsatz 1 erhält folgende Fassung:

„Das Datenfeld der Nachricht Positive Response Transfer Data Events and Faults liefert folgende Daten in folgender Reihenfolge unter SID 76 Hex und TREP 03 oder 23 Hex. Es muss eine geeignete Aufteilung und Zählung der Teilnachrichten erfolgen:“

ii)	Die Überschrift „Datenstruktur der 1. Generation“ erhält folgende Fassung: „Datenstruktur der 1. Generation (TREP 03 Hex)“

iii)	Die Überschrift „Datenstruktur der 2. Generation“ erhält folgende Fassung: „Datenstruktur der 2. Generation (TREP 23 Hex)“

iv)	Der Eintrag VuTimeAdjustmentGNSSRecordArray unter der Überschrift „Datenstruktur der 2. Generation (TREP 23 Hex)“ wird gestrichen.

Abschnitt 2.2.6.4 wird wie folgt geändert:

i)	Absatz DDP_032 Unterabsatz 1 erhält folgende Fassung: „Das Datenfeld der Nachricht Positive Response Transfer Data Detailed Speed liefert folgende Daten in folgender Reihenfolge unter SID 76 Hex und TREP 04 oder 24 Hex. Es muss eine geeignete Aufteilung und Zählung der Teilnachrichten erfolgen:“

ii)	Die Überschrift „Datenstruktur der 1. Generation“ erhält folgende Fassung: „Datenstruktur der 1. Generation (TREP 04)“

iii)	Die Überschrift „Datenstruktur der 2. Generation“ erhält folgende Fassung: „Datenstruktur der 2. Generation (TREP 24)“

Abschnitt 2.2.6.5 wird wie folgt geändert:

i)	Absatz DDP_033 Unterabsatz 1 erhält folgende Fassung: „Das Datenfeld der Nachricht Positive Response Transfer Data Technical Data liefert folgende Daten in folgender Reihenfolge unter SID 76 Hex und TREP 05 oder 25 Hex. Es muss eine geeignete Aufteilung und Zählung der Teilnachrichten erfolgen:“

ii)	Die Überschrift „Datenstruktur der 1. Generation“ erhält folgende Fassung: „Datenstruktur der 1. Generation (TREP 05)“

iii)	Die Überschrift „Datenstruktur der 2. Generation“ erhält folgende Fassung: „Datenstruktur der 2. Generation (TREP 25)“

Abschnitt 3.3 Absatz DDP_035 erhält folgende Fassung:

„DDP_035

Das Herunterladen einer Fahrtenschreiberkarte beinhaltet die folgenden Schritte:

—	Herunterladen der gemeinsamen Informationen der Karte in den EF und . Diese Informationen sind fakultativ und werden nicht mit einer digitalen Signatur gesichert.

—

(für Fahrtenschreiberkarten der 1. und 2. Generation) Herunterladen der EF innerhalb der :

—	Herunterladen der EF und . Diese Informationen werden nicht mit einer digitalen Signatur gesichert. Das Herunterladen dieser Dateien ist bei jedem Download-Vorgang obligatorisch.

—	Herunterladen der anderen Anwendungsdaten-EF (innerhalb der ) außer EF . Diese Informationen werden mit einer digitalen Signatur gemäß Anlage 11 Gemeinsame Sicherheitsmechanismen Teil B gesichert.

—	Bei jedem Download-Vorgang ist zumindest das Herunterladen der EF und obligatorisch.

—	Beim Herunterladen einer Fahrerkarte ist zudem der Download folgender EF obligatorisch: Text von Bild Events_Data, Faults_Data, Text von Bild Driver_Activity_Data, Vehicles_Used, Places, Control_Activity_Data, Specific_Conditions,

—

(nur für Fahrtenschreiberkarten der 2. Generation) Herunterladen der EF innerhalb der , außer im Fall von Datendownloads einer in eine VU eingesteckten Fahrerkarte bei Kontrollen durch eine Nicht-EU-Kontrollbehörde mit einer Kontrollkarte der 1. Generation:

—	Herunterladen der EF CardSignCertificate, CA_Certificate und Link_Certificate (falls vorhanden). Diese Informationen werden nicht mit einer digitalen Signatur gesichert. Das Herunterladen dieser Dateien ist bei jedem Download-Vorgang obligatorisch.

—	Herunterladen der anderen Anwendungsdaten-EF (innerhalb der ) außer EF . Diese Informationen werden mit einer digitalen Signatur gemäß Anlage 11 Gemeinsame Sicherheitsmechanismen Teil B gesichert.

—	Bei jedem Download-Vorgang ist zumindest das Herunterladen der EF und obligatorisch.

—	Beim Herunterladen einer Fahrerkarte ist zudem der Download folgender EF obligatorisch: Text von Bild Events_Data, Faults_Data, Driver_Activity_Data, Vehicles_Used, Places, Control_Activity_Data, Specific_Conditions, VehicleUnits_Used, GNSS Places.

—	Beim Herunterladen einer Fahrerkarte wird das Datum in der EF und DF Tachograph und gegebenenfalls aktualisiert.

—	Beim Herunterladen einer Werkstattkarte ist der Kalibrierungszähler in der EF in den DF und gegebenenfalls zurückzusetzen.

—	Beim Herunterladen einer Werkstattkarte ist in den DF und gegebenenfalls nicht herunterzuladen.“

l)	Abschnitt 3.3.2 Unterabsatz 1 Absatz DDP_037 erhält folgende Fassung: „Die Sequenz für das Herunterladen der EF ICC, IC, Card_Certificate (oder CardSignCertificate für DF Tachograph_G2), CA_Certificate und Link_Certificate (nur für DF Tachograph_G2) lautet folgendermaßen:“

Die Tabelle in Abschnitt 3.3.3 erhält folgende Fassung:

„Karte

Richtung

IDE / IFD

Bedeutung / Bemerkungen

Select File

Perform Hash of File

—	Berechnet den Hashwert über dem Dateninhalt der ausgewählten Datei mithilfe des vorgeschriebenen Hash-Algorithmus gemäß Anlage 11 Teil A oder B. Dieser Befehl ist kein ISO-Befehl.

Hash of File berechnen und Hashwert temporär speichern

Read Binary

Enthält die Datei mehr Daten, als der Puffer des Lesers oder der Karte fassen kann, ist der Befehl so lange zu wiederholen, bis die gesamte Datei ausgelesen ist.

File Data

Empfangene Daten auf ESM speichern

gemäß 3.4 Data storage format

PSO: Compute Digital Signature

Perform Security Operation ‚Compute Digital Signature‘ mithilfe des temporär gespeicherten Hashwerts

Signature

Daten an die zuvor auf dem ESM gespeicherten Daten anfügen

gemäß 3.4 Data storage format“

Abschnitt 3.4.2 Absatz DDP_046 erhält folgende Fassung:

„DDP_046

Eine Signatur wird als nächstes TLV-Objekt unmittelbar nach dem Objekt, das die Daten der Datei enthält, gespeichert.

Definition	Bedeutung	Länge
FID (2 Bytes) \|\| ‚00‘	Tag für EF (FID) in oder für gemeinsame Informationen der Karte	3 Bytes
FID (2 Bytes) \|\| ‚01‘	Tag für Signatur der EF (FID) in DF	3 Bytes
FID (2 Bytes) \|\| ‚02‘	Tag für Signatur der EF (FID) in DF	3 Bytes
FID (2 Bytes) \|\| ‚03‘	Tag für Signatur der EF (FID) in DF	3 Bytes
xx xx	Länge des Wertfelds	2 Bytes

Beispiel für Daten in einer Download-Datei auf einem ESM:

Tag

Länge

Wert

—	Daten von EF ICC

—	Daten von EF Card_Certificate

—

...

Daten von EF

(in DF

)

Signatur von EF

(in DF

)

Daten von EF

in DF

Signatur von EF

in DF

“

Abschnitt 4 Absatz DDP_049 erhält folgende Fassung:

„DDP_049

Fahrerkarten der 1. Generation: Für den Datendownload wird das Datendownload-Protokoll der 1. Generation verwendet, und die heruntergeladenen Daten haben das gleiche Format wie die von einer Fahrzeugeinheit der 1. Generation heruntergeladenen Daten.

Fahrerkarten der 2. Generation: Daraufhin lädt die VU die gesamte Karte dateiweise in Übereinstimmung mit dem in Abschnitt 3 definierten Download-Protokoll herunter und leitet alle von der Karte empfangenen Daten im entsprechenden TLV-Dateiformat (siehe 3.4.2) sowie eingekapselt in eine ‚Positive Response Transfer Data‘-Nachricht an das IDE weiter.“

34.	In Anlage 8 Abschnitt 2 erhält der Absatz unter der Überschrift „Referenzdokumente“ folgende Fassung: „ISO 14230-2: Road Vehicles — Diagnostic Systems — Keyword Protocol 2000 — Part 2: Data Link Layer. First edition: 1999.“

35.

Anlage 9 wird wie folgt geändert:

Nummer 6 des Inhaltsverzeichnisses erhält folgende Fassung:

„6.	PRÜFUNGEN DER EXTERNEN AUSRÜSTUNG ZUR FERNKOMMUNIKATION“

Abschnitt 1.1 erster Gedankenstrich erhält folgende Fassung:

„—	einer Sicherheitszertifizierung auf Grundlage der Spezifizierung Allgemeiner Kriterien anhand einer Sicherheitsvorgabe in völliger Übereinstimmung mit Anlage 10 dieses Anhangs,“

Die Tabelle in Abschnitt 2 über Funktionsprüfungen an der Fahrzeugeinheit erhält folgende Fassung:

„Nr.

Prüfung

Beschreibung

Anforderungsentsprechung

Administrative Prüfung

1.1

Dokumentation

Richtigkeit der Dokumentation

1.2

Prüfergebnisse des Herstellers

Ergebnisse der beim Einbau vom Hersteller durchgeführten Prüfung.

Nachweis auf Papier.

88, 89, 91

Sichtprüfung

2.1

Übereinstimmung mit der Dokumentation

2.2

Kennung / Markierungen

224 bis 226

2.3

Werkstoffe

219 bis 223

2.4

Plombierung

398, 401 bis 405

2.5

Externe Schnittstellen

Funktionsprüfungen

3.1

Mögliche Funktionen

02, 03, 04, 05, 07, 382

3.2

Betriebsarten

09 bis 11*, 134, 135

3.3

Funktionen und Datenzugriffsrechte

12* 13*, 382, 383, 386 bis 389

3.4

Überwachung des Einsteckens und Entnehmens der Karten

15, 16, 17, 18, 19*, 20*, 134

3.5

Geschwindigkeits- und Wegstreckenmessung

21 bis 31

3.6

Zeitmessung (Prüfung bei 20 °C)

38 bis 43

3.7

Überwachung der Fahrertätigkeiten

44 bis 53, 134

3.8

Überwachung des Status der Fahrzeugführung

54, 55, 134

3.9

Manuelle Eingabe durch die Fahrer

56 bis 62

3.10

Verwaltung der Unternehmenssperren

63 bis 68

3.11

Überwachung von Kontrollaktivitäten

69, 70

3.12

Feststellung von Ereignissen und Störungen

71 bis 88, 134

3.13

Kenndaten der Fahrzeugeinheit

93*, 94*, 97, 100

3.14

Einsteck- und Entnahmedaten der Fahrerkarte

102* bis 104*

3.15

Fahrertätigkeitsdaten

105* bis 107*

3.16

Orts- und Positionsdaten

108* bis 112*

3.17

Kilometerstanddaten

113* bis 115*

3.18

Detaillierte Geschwindigkeitsdaten

116*

3.19

Ereignisdaten

117*

3.20

Störungsdaten

118*

3.21

Kalibrierungsdaten

119* bis 121*

3.22

Zeiteinstellungsdaten

124*, 125*

3.23

Kontrolldaten

126*, 127*

3.24

Unternehmenssperredaten

128*

3.25

Erfassen des Herunterladens

129*

3.26

Daten zu spezifischen Bedingungen

130*, 131*

3.27

Aufzeichnung und Speicherung von Daten auf Fahrtenschreiberkarten

136, 137, 138*, 139*, 141*, 142, 143

144, 145, 146*, 147*, 148*, 149, 150

3.28

90, 134,

151 bis 168,

PIC_001, DIS_001

3.29

Drucken

90, 134,

169 bis 181, PIC_001, PRT_001 bis PRT_014

3.30

Warnung

134, 182 bis 191,

PIC_001

3.31

Herunterladen von Daten auf externe Datenträger

90, 134, 192 bis 196

3.32

Fernkommunikation für gezielte Straßenkontrollen

197 bis 199

3.33

Datenausgabe an zusätzliche externe Geräte

200, 201

3.34

Kalibrierung

202 bis 206*, 383, 384, 386 bis 391

3.35

Kalibrierungskontrolle unterwegs

207 bis 209

3.36

Zeiteinstellung

210 bis 212*

3.37

Störungsfreiheit zusätzlicher Funktionen

06, 425

3.38

Bewegungssensor-Schnittstelle

02, 122

3.39

Externe GNSS-Ausrüstung

03, 123

3.40

Überprüfen, dass die VU die herstellerdefinierten Ereignisse und/oder Störungen ermittelt, aufzeichnet und speichert, wenn ein gekoppelter Bewegungssensor auf Magnetfelder reagiert, die die Ermittlung von Fahrzeugbewegungsdaten stören.

217

3.41

Ziffernfolge und standardisierte Domänenparameter

CSM_48, CSM_50

Umweltprüfungen

4.1

Temperatur

Funktionsprüfung durch:

Prüfung gemäß ISO 16750-4, Kapitel 5.1.1.2: Betriebsprüfung bei niedrigen Temperaturen (72 h @ – 20 °C)

Diese Prüfung bezieht sich auf IEC 60068-2-1: Environmental testing — Part 2-1: Tests — Test A: Cold (Umgebungseinflüsse — Teil 2-1: Prüfverfahren – Prüfung A: Kälte)

Prüfung gemäß ISO 16750-4, Kapitel 5.1.2.2: Betriebsprüfung bei hohen Temperaturen (72 h @ 70 °C)

Diese Prüfung bezieht sich auf IEC 60068-2-2: Basic environmental testing procedures; part 2: tests; tests B: dry heat (Umgebungseinflüsse — Teil 2-2: Prüfverfahren — Prüfung B: Trockene Wärme)

Prüfung gemäß ISO 16750-4, Kapitel 5.3.2: Schnelle Temperaturwechsel mit angegebener Übergangsdauer (– 20 °C/70 °C, 20 Zyklen, Haltezeit 2 h bei jeder Temperatur)

In Bezug auf Mindest- und Höchsttemperatur sowie während der Temperaturzyklen ist (für die in Abschnitt 3 dieser Tabelle aufgeführten Prüfungen) eine geringere Anzahl an Prüfungen zulässig.

213

4.2

Luftfeuchtigkeit

IEC 60068-2-30, Prüfung Db, zum Nachweis, dass die Fahrzeugeinheit einer zyklischen Feuchtigkeitsprüfung (Wärmeprüfung) von sechs 24-Std.-Zyklen jeweils mit einer Temperaturänderung von + 25 °C bis + 55 °C und einer relativen Luftfeuchtigkeit von 97 % bei + 25 °C bzw. entsprechend 93 % bei + 55 °C standhält.

214

4.3

Mechanisch

Sinusschwingungen

Nachweis, dass die Fahrzeugeinheit Sinusschwingungen mit folgenden Merkmalen standhält:

konstante Verschiebung zwischen 5 und 11 Hz: max. 10 mm

konstante Beschleunigung zwischen 11 und 300 Hz: 5 g

Nachweis nach IEC 60068-2-6, Prüfung Fc, mit Mindestprüfdauer von 3 × 12 Std. (12 Std. je Achse)

ISO 16750-3 schreibt für Geräte, die sich in einer entkoppelten Fahrerkabine befinden, keine Prüfung mit Sinusschwingungen vor.

Zufallsschwingungen:

Prüfung gemäß ISO 16750-3, Kapitel 4.1.2.8: Prüfung VIII: Nutzfahrzeug, entkoppelte Fahrerkabine

Prüfung mit regellosem Schwingen, 10...2 000 Hz, RMS vertikal 21,3 m/s2, RMS longitudinal 11,8 m/s2, RMS lateral 13,1 m/s2, 3 Achsen, 32 Std. je Achse, einschließlich Temperaturzyklus – 20...70 °C.

Diese Prüfung bezieht sich auf IEC 60068-2-64: Environmental testing — Part 2-64: Tests — Test Fh: Vibration, broadband random and guidance (Umgebungseinflüsse — Teil 2-64: Prüfverfahren — Prüfung Fh: Schwingen, Breitbandrauschen (digital geregelt) und Leitfaden)

3.	Stöße: mechanische Stöße mit 3 g Halbsinus gemäß ISO 16750.

Diese Prüfungen werden an zwei unterschiedlichen Proben des zu prüfenden Gerätetyps durchgeführt.

219

4.4

Schutz vor Wasser und vor Fremdkörpern

Prüfung gemäß ISO 20653: Road vehicles — Degree of protection (IP code) — Protection of electrical equipment against foreign objects, water and access (Straßenfahrzeuge — Schutzarten (IP-Code) — Schutz gegen fremde Objekte, Wasser und Kontakt — elektrische Ausrüstungen) (Keine Parameteränderung); Mindestwert IP 40

220, 221

4.5

Überspannungsschutz

Nachweis, dass die Fahrzeugeinheit folgende Versorgungsspannungen aushält:

24-V-Versionen	:	34 V bei + 40 °C 1 Stunde
12-V-Versionen	:	17 V bei + 40 °C 1 Stunde

(ISO 16750-2)

216

4.6

Falschpolungsschutz

Nachweis, dass die Fahrzeugeinheit einer Umkehrung der Polarität der Stromversorgung standhält

(ISO 16750-2)

216

4.7

Kurzschlussschutz

Nachweis, dass für Eingangs-/Ausgangssignale Schutz vor Kurzschluss der Stromversorgung und vor Erdschluss besteht

(ISO 16750-2)

216

EMV-Prüfungen

5.1

Störaussendung und Störanfälligkeit

Einhaltung von ECE-Regelung R10

218

5.2

Elektrostatische Entladung

Einhaltung von ISO 10605:2008 +

Technische Korrektur:2010 +

AMD1:2014: +/– 4 kV Kontaktentladung und +/– 8 kV Luftentladung

218

5.3

Leitungsgeführte Störgrößen auf Versorgungsleitungen

24-V-Versionen: Einhaltung von ISO 7637-2 + ECE-Verordnung 10 Rev. 3:

Impuls 1a: Vs = – 450 V Ri = 50 Ohm

Impuls 2a: Vs = + 37 V Ri = 2 Ohm

Impuls 2b: Vs = + 20 V Ri = 0,05 Ohm

Impuls 3a: 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

12-V-Versionen: Einhaltung von ISO 7637-1 + ECE-Verordnung 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 = – V t6 = 15 ms

Impuls 5: Vs = + 65 V Ri = 3 Ohm td = 100 ms

Impuls 5 ist nur in Fahrzeugeinheiten zu prüfen, die in Fahrzeugen installiert werden sollen, für die keine gemeinsame externe Blindlast vorgesehen ist.

Blindlastvorschläge siehe ISO 16750-2, 4. Ausgabe, Kapitel 4.6.4.

218“

Abschnitt 6 erhält folgende Fassung:

„6. PRÜFUNGEN DER EXTERNEN AUSRÜSTUNG ZUR FERNKOMMUNIKATION

Nr.

Prüfung

Beschreibung

Anforderungsentsprechung

Administrative Prüfung

1.1

Dokumentation

Richtigkeit der Dokumentation

Sichtprüfung

2.1

Übereinstimmung mit der Dokumentation

2.2

Kennung / Markierungen

224 bis 226

2.3

Werkstoffe

219 bis 223

2.4

Plombierung

398, 401 bis 405

2.5

Externe Schnittstellen

Funktionsprüfungen

3.1

Fernkommunikation für gezielte Straßenkontrollen

4, 197 bis 199

3.2

Aufzeichnung und Speicherung von Daten im Massenspeicher

3.3

Kommunikation mit der Fahrzeugeinheit

Anlage 14 DSC_66 bis DSC_70, DSC_71 bis DSC_76

Umweltprüfungen

4.1

Temperatur

Funktionsprüfung durch:

Prüfung gemäß ISO 16750-4, Kapitel 5.1.1.2: Betriebsprüfung bei niedrigen Temperaturen (72 h @ – 20 °C)

Diese Prüfung bezieht sich auf IEC 60068-2-1: Environmental testing — Part 2-1: Tests — Test A: Cold (Umgebungseinflüsse — Teil 2-1: Prüfverfahren — Prüfung A: Kälte)

Prüfung gemäß ISO 16750-4, Kapitel 5.1.2.2: Betriebsprüfung bei hohen Temperaturen (72 h @ 70 °C)

Prüfung gemäß ISO 16750-4, Kapitel 5.3.2: Schnelle Temperaturwechsel mit angegebener Übergangsdauer (– 20 °C/70 °C, 20 Zyklen, Haltezeit 1 h bei jeder Temperatur)

In Bezug auf Mindest- und Höchsttemperatur sowie während der Temperaturzyklen ist (für die in Abschnitt 3 dieser Tabelle aufgeführten Prüfungen) eine geringere Anzahl an Prüfungen zulässig.

213

4.2

Schutz vor Wasser und vor Fremdkörpern

220, 221

EMV-Prüfungen

5.1

Störaussendung und Störanfälligkeit

Einhaltung von ECE-Regelung R10

218

5.2

Elektrostatische Entladung

Einhaltung von ISO 10605:2008 + Technische Korrektur:2010 + AMD1:2014: +/– 4 kV Kontaktentladung und +/– 8 kV Luftentladung

218

5.3

Leitungsgeführte Störgrößen auf Versorgungsleitungen

24-V-Versionen: Einhaltung von ISO 7637-2 + ECE-Verordnung 10 Rev. 3:

Impuls 1a: Vs = – 450 V Ri = 50 Ohm

Impuls 2a: Vs = + 37 V Ri = 2 Ohm

Impuls 2b: Vs = + 20 V Ri = 0,05 Ohm

Impuls 3a: 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

12-V-Versionen: Einhaltung von ISO 7637-1 + ECE-Verordnung 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 ist nur in Fahrzeugeinheiten zu prüfen, die in Fahrzeugen installiert werden sollen, für die keine gemeinsame externe Blindlast vorgesehen ist.

Blindlastvorschläge siehe ISO 16750-2, 4. Ausgabe, Kapitel 4.6.4.

218“

Die Tabelle in Abschnitt 8 (Interoperabilitätsprüfungen) erhält folgende Fassung:

„Nr.	Prüfung	Beschreibung
8.1 Interoperabilitätsprüfungen zwischen Fahrzeugeinheiten und Fahrtenschreiberkarten
1	Gegenseitige Authentisierung	Prüfen, dass die gegenseitige Authentisierung zwischen der Fahrzeugeinheit und der Fahrtenschreiberkarte normal abläuft
2	Lese-/Schreib-Prüfungen	Ausführung eines typischen Tätigkeitsszenarios an der Fahrzeugeinheit. Dabei sind in Abhängigkeit von der zu prüfenden Karte Schreibvorgänge in so vielen EF wie bei der Karte möglich durchzuführen. Durch Herunterladen von einer Fahrzeugeinheit ist nachzuprüfen, ob die entsprechenden Aufzeichnungen ordnungsgemäß erfolgt sind. Durch Herunterladen von einer Karte ist nachzuprüfen, ob die entsprechenden Aufzeichnungen ordnungsgemäß erfolgt sind. Anhand täglicher Ausdrucke ist zu überprüfen, ob alle entsprechenden Aufzeichnungen korrekt zu lesen sind.
8.2 Interoperabilitätsprüfungen zwischen Fahrzeugeinheiten und Bewegungssensoren
1	Koppelung	Prüfen, dass die Koppelung zwischen den Fahrzeugeinheiten und den Bewegungssensoren normal abläuft.
2	Tätigkeitsprüfungen	Ausführung eines typischen Tätigkeitsszenarios am Bewegungssensor. Das Szenario hat eine normale Tätigkeit sowie die Erstellung so vieler Ereignisse bzw. Störungen wie möglich zu beinhalten. Durch Herunterladen von einer Fahrzeugeinheit ist nachzuprüfen, ob die entsprechenden Aufzeichnungen ordnungsgemäß erfolgt sind. Durch Herunterladen von einer Karte ist nachzuprüfen, ob die entsprechenden Aufzeichnungen ordnungsgemäß erfolgt sind. Anhand eines täglichen Ausdrucks ist zu überprüfen, ob alle entsprechenden Aufzeichnungen korrekt zu lesen sind.
8.3 Interoperabilitätsprüfungen zwischen Fahrzeugeinheiten und externen GNSS-Ausrüstungen (soweit vorhanden)
1	Gegenseitige Authentisierung	Prüfen, dass die gegenseitige Authentisierung zwischen der Fahrzeugeinheit und dem externen GNSS-Modul normal abläuft.
2	Tätigkeitsprüfungen	Ausführung eines typischen Tätigkeitsszenarios an der externen GNSS-Ausrüstung. Das Szenario hat eine normale Tätigkeit sowie die Erstellung so vieler Ereignisse bzw. Störungen wie möglich zu beinhalten. Durch Herunterladen von einer Fahrzeugeinheit ist nachzuprüfen, ob die entsprechenden Aufzeichnungen ordnungsgemäß erfolgt sind. Durch Herunterladen von einer Karte ist nachzuprüfen, ob die entsprechenden Aufzeichnungen ordnungsgemäß erfolgt sind. Anhand eines täglichen Ausdrucks ist zu überprüfen, ob alle entsprechenden Aufzeichnungen korrekt zu lesen sind.“

36.

Anlage 11 wird wie folgt geändert:

Abschnitt 8.2.3 Absatz CSM_49 erhält folgende Fassung:

„CSM_49

Fahrzeugeinheiten, Fahrtenschreiberkarten und externe GNSS-Ausrüstung unterstützen die Algorithmen SHA-256, SHA-384 und SHA-512 gemäß Referenzdokument SHS.“

Abschnitt 9.1.2 Absatz CSM_58 Unterabsatz 1 erhält folgende Fassung:

„CSM_58

Immer wenn die ERCA ein neues europäisches Wurzel-Schlüsselpaar erzeugt, muss es ein Linkzertifikat für den neuen europäischen öffentlichen Schlüssel erstellen und dieses mit dem ehemaligen privaten Schlüssel signieren. Die Gültigkeitsdauer des Linkzertifikats beträgt 17 Jahre und 3 Monate. Dies wird auch in Abbildung 1 (Abschnitt 9.1.7) gezeigt.“

Abschnitt 9.1.4 Absatz CSM_72 erhält folgende Fassung:

„CSM_72

Für jede Fahrzeugeinheit müssen zwei eindeutige ECC-Schlüsselpaare erzeugt werden, die als VU_MA und VU_Sign bezeichnet werden. Diese Aufgabe wird von den Herstellern der VU übernommen. Immer wenn ein VU-Schlüsselpaar erzeugt wird, übermittelt die erzeugende Partei den öffentlichen Schlüssel an ihre MSCA, um das entsprechende durch die MSCA signierte VU-Zertifikat zu erhalten. Der private Schlüssel darf nur durch die Fahrzeugeinheit genutzt werden.“

Abschnitt 9.1.5 wird wie folgt geändert:

Absatz CSM_83 erhält folgende Fassung:

„CSM_83

Für jede Fahrtenschreiberkarte wird ein eindeutiges ECC-Schlüsselpaar unter dem Namen Card_MA erzeugt. Zusätzlich wird für jede Fahrerkarte und jede Werkstattkarte ein zweites eindeutiges ECC-Schlüsselpaar unter dem Namen Card_Sign erzeugt. Diese Aufgabe kann von den Kartenherstellern oder -integratoren übernommen werden. Immer wenn ein Kartenschlüsselpaar erzeugt wird, übermittelt die erzeugende Partei den öffentlichen Schlüssel an ihre MSCA, um das entsprechende durch die MSCA signierte Kartenzertifikat zu erhalten. Der private Schlüssel darf nur durch die Fahrtenschreiberkarte genutzt werden.“

ii)

Absatz CSM_88 erhält folgende Fassung:

„CSM_88

Die Gültigkeitsdauer des Card-MA-Zertifikats beträgt für

—	Fahrerkarten: 5 Jahre

—	Unternehmenskarten: 5 Jahre

—	Kontrollkarten: 2 Jahre

—	Werkstattkarten: 1 Jahr“

iii)

In Absatz CSM_91 wird folgender Text angefügt:

„—

Zusätzlich für Kontrollkarten, Unternehmenskarten und Werkstattkarten und nur, wenn solche Karten in den ersten drei Monaten der Gültigkeitsdauer eines neuen EUR-Zertifikats ausgestellt werden: das EUR-Zertifikat, das zwei Generationen älter ist, falls vorhanden.

Hinweis zum letzten Gedankenstrich: Beispielsweise müssen die genannten Karten in den ersten drei Monaten der Gültigkeit des ERCA(3)-Zertifikats (siehe Abbildung 1) das ERCA(1)-Zertifikat enthalten. Dies ist erforderlich, damit diese Karten für den Datendownload von ERCA(1)-Fahrzeugeinheiten verwendet werden können, deren normale Gültigkeitsdauer von 15 Jahren zuzüglich der drei Monate für das Herunterladen von Daten in diesen Monaten abläuft (siehe Anhang IC Randnummer 13 letzter Gedankenstrich).“

Abschnitt 9.1.6 wird wie folgt geändert:

Absatz CSM_93 erhält folgende Fassung:

„CSM_93

Für jede externe GNSS-Ausrüstung wird ein eindeutiges ECC-Schlüsselpaar unter dem Namen EGF_MA erzeugt. Diese Aufgabe wird von den Herstellern der externen GNSS-Ausrüstung übernommen. Immer wenn ein EGF-MA-Schlüsselpaar erzeugt wird, übermittelt die erzeugende Partei den öffentlichen Schlüssel an ihre MSCA, um das entsprechende durch die MSCA signierte EGF-MA-Schlüsselpaar zu erhalten. Der private Schlüssel darf nur durch die externe GNSS-Ausrüstung genutzt werden.“

ii)

Absatz CSM_95 erhält folgende Fassung:

„CSM_95

Externe GNSS-Ausrüstung darf ihr aus dem privaten Schlüssel EGF_MA.SK und dem öffentlichen Schlüssel EGF_MA.PK bestehendes EGF_MA-Schlüsselpaar ausschließlich dazu verwenden, die gegenseitige Authentisierung und Sitzungsschlüsselvereinbarung gegenüber Fahrzeugeinheiten durchzuführen, wie in Abschnitt 11.4 dieser Anlage beschrieben.“

Abschnitt 9.1.7 wird wie folgt geändert:

Abbildung 1 erhält folgende Fassung:

„Abbildung 1

Ausgabe und Nutzung der verschiedenen Generationen von ERCA-Wurzelzertifikaten, ERCA-Linkzertifikaten, MSCA-Zertifikaten und Ausrüstungszertifikaten

Text von Bild “

ii)

Nummer 6 der Hinweise zu Abbildung 1 erhält folgende Fassung:

„6.	Aus Platzgründen ist die unterschiedliche Gültigkeitsdauer der Zertifikate Card_MA und Card_Sign nur für die 1. Generation angegeben.“

Abschnitt 9.2.1.1 wird wie folgt geändert:

Absatz CSM_106 erster Gedankenstrich erhält folgende Fassung:

„—	Für 128-Bit-Bewegungssensor-Hauptschlüssel: CV = ‚B6 44 2C 45 0E F8 D3 62 0B 7A 8A 97 91 E4 5D 83‘“

ii)

Absatz CSM_107 Unterabsatz 1 erhält folgende Fassung:

„Die Hersteller von Bewegungssensoren generieren für jeden Bewegungssensor einen zufälligen, eindeutigen Koppelungsschlüssel KP und senden jeden einzelnen Koppelungsschlüssel an die Zertifizierungsstelle des Mitgliedstaates. Die MSCA verschlüsselt jeden Koppelungsschlüssel einzeln mit dem Bewegungssensor-Hauptschlüssel KM und übermittelt den kodierten Schlüssel zurück an den Hersteller des Bewegungssensors. Für jeden kodierten Schlüssel informiert die MSCA den Hersteller von Bewegungssensoren über die Versionsnummer des zugehörigen KM.“

iii)

Absatz CSM_108 erhält folgende Fassung:

„CSM_108

Die Hersteller von Bewegungssensoren generieren für jeden Bewegungssensor eine eindeutige Seriennummer und senden sämtliche Seriennummern an die Zertifizierungsstelle des Mitgliedstaates. Die MSCA verschlüsselt jede Seriennummer einzeln mit dem Identifikationsschlüssel KID und übermittelt die kodierte Seriennummer zurück an den Hersteller des Bewegungssensors. Für jede kodierte Seriennummer informiert die MSCA den Hersteller von Bewegungssensoren über die Versionsnummer des zugehörigen KID.“

Abschnitt 9.2.2.1 wird wie folgt geändert:

Absatz CSM_123 erhält folgende Fassung:

„CSM_123

Für jede Fahrzeugeinheit erstellt der Hersteller der Fahrzeugeinheit eine eindeutige VU-Seriennummer und sendet diese an die Zertifizierungsstelle des Mitgliedstaates, um eine Gruppe von zwei VU-spezifischen DSRC-Schlüsseln zu beantragen. Die VU-Seriennummer verfügt über den Datentyp

Hinweis:

—	Die VU-Seriennummer muss mit dem Element ‚vuSerialNumber‘ von VuIdentification (siehe Anlage 1) und mit der Certificate Holder Reference in den Zertifikaten der VU übereinstimmen.

—

Die VU-Seriennummer ist zu dem Zeitpunkt, zu dem der Hersteller einer Fahrzeugeinheit die VU-spezifischen DSRC-Schlüssel beantragt, unter Umständen nicht bekannt. In diesem Fall sendet der Hersteller der VU stattdessen die bei der Beantragung der VU-Zertifikate verwendete eindeutige Kennung für den Zertifikatsantrag (siehe CSM_153). Diese Kennung des Zertifikatsantrags muss deshalb mit der Certificate Holder Reference in den Zertifikaten der VU übereinstimmen.“

ii)	In Absatz CSM_124 Schritt 2 erhält die Info-Anforderung folgende Fassung: „info = VU-Seriennummer oder Kennung des Zertifikatsantrags gemäß CSM_123“

iii)

Absatz CSM_128 erhält folgende Fassung:

„CSM_128

Die MSCA muss Aufzeichnungen aller von ihr erzeugten VU-spezifischen DSRC-Schlüssel samt Versionsnummer und der zu ihrer Ableitung verwendeten VU-Seriennummer oder Kennung des Zertifikatsantrags führen.“

Abschnitt 9.3.1 Absatz CSM_135 Unterabsatz 1 erhält folgende Fassung:

„Zur Kodierung der Datenobjekte innerhalb der Zertifikate sind die Distinguished Encoding Rules (DER) gemäß ISO 8825-1 zu verwenden. Tabelle 4 zeigt die vollständige Kodierung der Zertifikate, einschließlich aller Tags und Längenbytes.“

Abschnitt 9.3.2.3 Absatz CSM_141 erhält folgende Fassung:

„CSM_141

Mit ‚Certificate Holder Authorisation‘ wird die Zertifikatart angegeben. Sie besteht aus den sechs höchstwertigen Bytes der Fahrtenschreiberanwendungs-ID, verkettet mit dem Gerätetyp, der die Art des Geräts angibt, für die das Zertifikat vorgesehen ist. Bei VU-Zertifikaten, Fahrerkarten- oder Werkstattkartenzertifikaten wird der Gerätetyp auch verwendet, um zwischen einem Zertifikat für die gegenseitige Authentisierung und einem Zertifikat für die Erzeugung digitaler Signaturen zu unterscheiden (siehe Abschnitt 9.1 und Anlage 1, Datentyp EquipmentType).“

In Abschnitt 9.3.2.5 Absatz CSM_146 wird folgender Unterabsatz angefügt:

„Hinweis: Bei Kartenzertifikaten muss der Wert der CHR dem Wert von ‚cardExtendedSerialNumber‘ in EF_ICC entsprechen (siehe Anlage 2). Bei EGF-Zertifikaten muss der Wert der CHR dem Wert von ‚sensorGNSSSerialNumber‘ in EF_ICC entsprechen (siehe Anlage 14). Bei VU-Zertifikaten muss der Wert der CHR dem Element „vuSerialNumber“ von ‚VuIdentification‘ entsprechen (siehe Anlage 1), es sei denn, dem Hersteller ist die herstellerspezifische Seriennummer zum Zeitpunkt der Beantragung des Zertifikats nicht bekannt.“

Abschnitt 9.3.2.6 Absatz CSM_148 erhält folgende Fassung:

„CSM_148

Certificate Effective Date gibt Anfangsdatum und -uhrzeit der Gültigkeitsdauer des Zertifikats an.“

Abschnitt 9.3.3 wird wie folgt geändert:

i)	Absatz CSM_151 Unterabsatz 1 erhält folgende Fassung: „Beim Beantragen eines Zertifikats muss die MSCA der ERCA die folgenden Daten übermitteln:“

ii)

Absatz CSM_153 erhält folgende Fassung:

„CSM_153

Der Gerätehersteller muss der MSCA in einem Zertifikatsantrag die folgenden Daten übermitteln, damit Letztgenannte die Certificate Holder Reference des neuen Gerätezertifikats erstellen kann:

—	falls bekannt (siehe CSM_154), die Seriennummer des Geräts zur eindeutigen Identifizierung von Hersteller, Gerätetyp und Herstellungsmonat. Andernfalls eine eindeutige Kennung für den Zertifikatsantrag.

—	Monat und Jahr der Geräteherstellung oder des Zertifikatsantrags.

Der Hersteller muss sicherstellen, dass diese Angaben richtig sind und dass das von der MSCA übermittelte Zertifikat in die vorgesehene Ausrüstung eingesetzt wird.“

Abschnitt 10.2.1 wird wie folgt geändert:

In Absatz CSM_157 erhält der Text vor den Hinweisen zu Abbildung 4 folgende Fassung:

„Die Fahrzeugeinheiten verifizieren mithilfe des in Abbildung 4 dargestellten Protokolls die Zertifikatkette einer Fahrtenschreiberkarte. Bei jedem aus der Karte ausgelesenem Zertifikat überprüft die VU die Richtigkeit des Feldes Certificate Holder Authorisation (CHA):

—	Im Feld CHA des Kartenzertifikats muss ein Kartenzertifikat für die gegenseitige Authentisierung angegeben sein (siehe Anlage 1, Datentyp EquipmentType).

—	In der CHA des Card.CA-Zertifikats muss eine MSCA angegeben sein.

—	In der CHA des Card.Link-Zertifikats muss die ERCA angegeben sein.“

ii)	In Absatz CSM_159 wird folgender Satz angefügt: „Während die Speicherung aller anderen Arten von Zertifikaten optional ist, muss ein von einer Karte vorgelegtes neues Linkzertifikat von der VU gespeichert werden.“

Abschnitt 10.2.2 wird wie folgt geändert:

In Absatz CSM_161 erhält der Text vor Abbildung 5 folgende Fassung:

„Die Fahrtenschreiberkarten verifizieren mithilfe des in Abbildung 5 dargestellten Protokolls die Zertifikatkette einer VU. Bei jedem von der VU vorgelegtem Zertifikat überprüft die Karte die Richtigkeit des Feldes Certificate Holder Authorisation (CHA):

—	In der CHA des VU.Link-Zertifikats muss die ERCA angegeben sein.

—	In der CHA des VU.CA-Zertifikats muss eine MSCA angegeben sein.

—	Im Feld CHA des VU-Zertifikats muss ein VU-Zertifikat für die gegenseitige Authentisierung angegeben sein (siehe Anlage 1, Datentyp EquipmentType).“

ii)

Absatz CSM_165 erhält folgende Fassung:

„CSM_165

Wenn der Befehl ‚MSE: Set AT‘ erfolgreich ausgeführt wird, legt die Karte den angegebenen VU.PK zur weiteren Verwendung im Rahmen der VU-Authentisierung fest und speichert Comp(VU.PKeph) temporär. Wenn vor der Vereinbarung des Sitzungsschlüssels zwei oder mehr erfolgreiche Befehle ‚MSE: Set AT‘ gesendet werden, speichert die Karte lediglich den letzten erhaltenen Comp(VU.PKeph). Nach einem erfolgreichen Befehl GENERAL AUTHENTICATE setzt die Karte Comp(VU.PKeph) zurück.“

Abschnitt 10.3 wird wie folgt geändert:

i)	Absatz CSM_170 Unterabsatz 1 erhält folgende Fassung: „Neben der Zufallszahl enthält die Signatur der VU die dem Kartenzertifikat entnommene Kennung des Zertifikatinhabers.“

ii)	Abschnitt CSM_171 Abbildung 6 erhält folgende Fassung: „Abbildung 6 VU-Authentisierungsprotokoll “

iii)

Absatz CSM_174 erhält folgende Fassung:

„CSM_174

Nach Erhalt der VU-Signatur in einem Befehl EXTERNAL AUTHENTICATE führt die Karte Folgendes durch:

—	Sie berechnet den Authentisierungstoken, indem sie Card.CHR, den rcard der Kartenzufallszahl und die Kennung des flüchtigen öffentlichen Schlüssels der VU, Comp(VU.PKeph), miteinander verkettet;

—	sie überprüft die Signatur der VU unter Verwendung des ECDSA-Algorithmus und des Hash-Algorithmus, der an die Schlüsselgröße des VU_MA-Schlüsselpaars der VU gebunden ist (siehe CSM_50), in Kombination mit VU.PK und dem berechneten Authentisierungstoken.“

Abschnitt 10.4 Absatz CSM_176 wird wie folgt geändert:

Nummer 2 erhält folgende Fassung:

„2.

Die VU sendet den öffentlichen Punkt VU.PKeph ihres flüchtigen Schlüsselpaars an die Karte. Der öffentliche Punkt ist gemäß TR-03111 in einen Oktettstring umzuwandeln. Dabei ist das unkomprimierte Verschlüsselungsformat zu verwenden. Wie in CSM_164 erläutert, hat die VU dieses flüchtige Schlüsselpaar bereits vor der Verifizierung der VU-Zertifikatkette generiert. Dabei sendete die VU die Kennung des flüchtigen öffentlichen Schlüssels Comp(VU.PKeph) an die Karte, die diese Kennung speicherte.“

ii)

Nummer 6 erhält folgende Fassung:

„6.

Mithilfe von KMAC berechnet die Karte anhand der Kennung des flüchtigen öffentlichen Punkts der VU einen Authentisierungstoken: TPICC = CMAC(KMAC, VU.PKeph). Der öffentliche Punkt muss das von der VU verwendete Format haben (siehe Nummer 2 oben). Die Karte übermittelt NPICC und TPICC an die Fahrzeugeinheit.“

Abschnitt 10.5.2 Absatz CSM_191 erhält folgende Fassung:

„CSM_191

Sämtliche zu verschlüsselnde Datenobjekte sind gemäß ISO 7816-4 mithilfe von Padding Indicator ‚01‘ aufzufüllen. Zur Berechnung des MAC müssen Datenobjekte im APDU gemäß ISO 7816-4 aufgefüllt werden.

Hinweis: Bei Secure Messaging erfolgt das Auffüllen immer durch die Secure-Messaging-Schicht, nicht durch die CMAC- oder CBC-Algorithmen.

Zusammenfassung und Beispiele

Ein APDU-Befehl mit angewandtem Secure Messaging besitzt die folgende Struktur, je nach dem jeweiligen ungesicherten Befehl (DO ist Datenobjekt):

Fall 1	:	CLA INS P1 P2 \|\| Lc' \|\| DO ‘8E’ \|\| Le
Fall 2	:	CLA INS P1 P2 \|\| Lc' \|\| DO ‘97’ \|\| DO‘8E’ \|\| Le
Fall 3 (gerades INS-Byte)	:	CLA INS P1 P2 \|\| Lc' \|\| DO ‘81’ \|\| DO‘8E’ \|\| Le
Fall 3 (ungerades INS-Byte)	:	CLA INS P1 P2 \|\| Lc' \|\| DO ‘B3’ \|\| DO‘8E’ \|\| Le
Fall 4 (gerades INS-Byte)	:	CLA INS P1 P2 \|\| Lc' \|\| DO ‘81’ \|\| DO‘97’ \|\| DO‘8E’ \|\| Le
Fall 4 (ungerades INS-Byte)	:	CLA INS P1 P2 \|\| Lc' \|\| DO ‘B3’ \|\| DO‘97’ \|\| DO‘8E’ \|\| Le

Dabei ist Le = ‘00’ oder ‘00 00’, je nachdem, ob kurze Längenfelder oder erweiterte Längenfelder verwendet werden; siehe ISO 7816-4.

Eine APDU-Antwort mit angewandtem Secure Messaging besitzt die folgende Struktur, je nach dem jeweiligen ungesicherten Befehl (DO ist Datenobjekt):

Fall 1 oder 3	:	DO ‘99’ \|\| DO ‘8E’ \|\| SW1SW2
Fall 2 oder 4 (gerades INS-Byte) ohne Verschlüsselung	:	DO ‘81’ \|\| DO ‘99’ \|\| DO ‘8E’ \|\| SW1SW2
Fall 2 oder 4 (gerades INS-Byte) mit Verschlüsselung	:	DO ‘87’ \|\| DO ‘99’ \|\| DO ‘8E’ \|\| SW1SW2
Fall 2 oder 4 (ungerades INS-Byte) ohne Verschlüsselung	:	DO ‘B3’ \|\| DO ‘99’ \|\| DO ‘8E’ \|\| SW1SW2

Hinweis: Fall 2 oder 4 (ungerades INS-Byte) mit Verschlüsselung kommt in der Kommunikation zwischen VU und Karte nie zum Einsatz.

Im Folgenden sind drei APDU-Transformationen für Befehle mit geradem INS-Code beispielhaft aufgeführt. Abbildung 8 zeigt einen authentisierten APDU-Befehl für Fall 4, Abbildung 9 zeigt eine authentisierte APDU-Antwort für Fall 1/Fall 3, und Abbildung 10 zeigt eine verschlüsselte und authentisierte APDU-Antwort für Fall 2/Fall 4.

Abbildung 8

Transformation eines authentisierten APDU-Befehls für Fall 4

Abbildung 9

Transformation einer authentisierten Antwort-APDU für Fall 1/Fall 3

Abbildung 10

Transformation einer verschlüsselten und authentisierten

“

Abschnitt 10.5.3 Absatz CSM_193 erhält folgende Fassung:

„CSM_193

Eine Fahrtenschreiberkarte muss eine laufende Secure-Messaging-Sitzung abbrechen, wenn (und nur wenn) eine der folgenden Bedingungen eintritt:

—	Sie erhält einen APDU-Befehl in Klartext.

—

Sie entdeckt in einem APDU-Befehl einen Secure-Messaging-Fehler:

—	Ein erwartetes Secure-Messaging-Datenobjekt fehlt, die Reihenfolge der Datenobjekte ist falsch, oder ein unbekanntes Datenobjekt ist vorhanden.

—	Ein Secure-Messaging-Datenobjekt ist fehlerhaft, beispielsweise ist der MAC-Wert oder die TLV-Struktur fehlerhaft.

—	Sie ist ohne Stromversorgung oder wurde zurückgesetzt.

—	Die VU leitet die VU-Authentisierung ein.

—

Der Grenzwert für die innerhalb der aktuellen Sitzung zulässige Anzahl an Befehlen und zugehörigen Antworten ist erreicht. Dieser Grenzwert wird für eine Karte von ihrem Hersteller festgelegt, der dabei die Sicherheitsanforderungen der verwendeten Hardware berücksichtigt; der Höchstwert beträgt 240 SM-Befehle und zugehörige Antworten pro Sitzung.“

Abschnitt 11.3.2 wird wie folgt geändert:

i)	Absatz CSM_208 Unterabsatz 1 erhält folgende Fassung: „Während der Koppelung an eine VU verwendet die externe GNSS-Ausrüstung das in Abbildung 5 (Abschnitt 10.2.2) dargestellte Protokoll, um die Zertifikatkette der VU zu verifizieren.“

ii)

Absatz CSM_210 erhält folgende Fassung:

„CSM_210

Wenn die externe GNSS-Ausrüstung das VU_MA-Zertifikat verifiziert hat, speichert sie es zur Verwendung im Normalbetrieb; siehe Abschnitt 11.3.3.“

Abschnitt 11.3.3 Absatz CSM_211 Unterabsatz 1 erhält folgende Fassung:

„Im Normalbetrieb verwenden Fahrzeugeinheit und EGF das in Abbildung 11 dargestellte Protokoll, um die temporäre Gültigkeit des gespeicherten EGF_MA-Zertifikats zu überprüfen und um den öffentlichen VU_MA-Schlüssel zur anschließenden VU-Authentisierung festzulegen. Im Normalbetrieb findet keine weitere gegenseitige Verifizierung der Zertifikatketten statt.“

Nummer 12.3 Tabelle 6 erhält folgende Fassung:

„Tabelle 6

Anzahl der Klartext- und verschlüsselten Datenbytes pro Befehl gemäß ISO 16844-3

Anweisung	Anforderung/Antwort	Beschreibung der Daten	Anz. der Klartext-Datenbytes gemäß ISO 16844-3	Anz. der Klartext-Datenbytes bei Verwendung von AES-Schlüsseln	Anz. der verschlüsselten Datenbytes bei Verwendung von AES-Schlüsseln mit Bitlänge
Anweisung	Anforderung/Antwort	Beschreibung der Daten	Anz. der Klartext-Datenbytes gemäß ISO 16844-3		128	192	256
10	Anforderung	Authentisierungsdaten + Nummer der Datei	8	8	16	16	16
11	Antwort	Authentisierungsdaten + Inhalte der Datei	16 oder 32, je nach Datei	16 oder 32, je nach Datei	32/48	32/48	32/48
41	Anforderung	Seriennummer des Sensors	8	8	16	16	16
41	Antwort	Koppelungsschlüssel	16	16/24/32	16	32	32
42	Anforderung	Sitzungsschlüssel	16	16/24/32	16	32	32
43	Anforderung	Koppelungsinformation	24	24	32	32	32
50	Antwort	Koppelungsinformation	24	24	32	32	32
70	Anforderung	Authentisierungsdaten	8	8	16	16	16
80	Antwort	Zählerwert Bewegungssensor + Authentisierungsdaten	8	8	16	16	16“

In Abschnitt 13.1 Unterabsatz CSM_224 erhält die Anforderung an die VU-Seriennummer folgende Fassung:

„VU serial number

die Seriennummer der VU oder die Kennung für den Zertifikatsantrag (Datentyp VuSerialNumber oder CertificateRequestID) — siehe CSM_123“

Abschnitt 13.3 Absatz CSM_228 Nummer 2 erhält folgende Fassung:

„2.	Die Kontrollkarte verwendet den angegebenen DSRC-Hauptschlüssel in Kombination mit der VU-Seriennummer oder der Kennung für den Zertifikatsantrag in den DSRC-Sicherheitsdaten, um daraus die VU-spezifischen DSRC-Schlüssel K_VUDSRC_ENC und K_VUDSRC_MAC abzuleiten (siehe CSM_124).“

Abschnitt 14.3 wird wie folgt geändert:

In Absatz CSM_234 erhält der Text vor den Hinweisen zu Abbildung 13 folgende Fassung:

„Ein IDE kann die Verifizierung einer Signatur anhand heruntergeladener Daten selbst durchführen oder zu diesem Zweck eine Kontrollkarte verwenden. Falls es eine Kontrollkarte verwendet, ist die Verifizierung der Signatur gemäß Abbildung 13 durchzuführen. Die Kontrollkarte überprüft die temporäre Gültigkeit eines vom IDE vorgelegten Zertifikats mithilfe ihrer internen aktuellen Uhrzeit (siehe CSM_167). Die Kontrollkarte darf dann ihre aktuelle Uhrzeit aktualisieren, wenn das Effective Date eines authentischen Zertifikats einer ‚gültigen Zeitquelle‘ jünger ist als die aktuelle Uhrzeit der Karte. Die Karte darf nur die folgenden Zertifikate als gültige Zeitquelle akzeptieren:

—	ERCA-Linkzertifikate der 2. Generation

—	MSCA-Zertifikate der 2. Generation

—	VU_Sign- oder Card_Sign-Zertifikate der 2. Generation, die vom selben Land ausgestellt sind wie das bzw. die Kartenzertifikat(e) der Kontrollkarte selbst.

Falls es die Verifizierung der Signatur selbst durchführt, muss das IDE die Authentizität und Gültigkeit aller Zertifikate in der Zertifikatkette der Datei sowie die Signatur anhand der Daten gemäß dem in DSS definierten Signatursystem überprüfen. In beiden Fällen ist es erforderlich, bei jedem aus der Datei ausgelesenem Zertifikat die Richtigkeit des Feldes Certificate Holder Authorisation (CHA) zu überprüfen:

—	Im Feld CHA des EQT-Zertifikats muss ein VU-Zertifikat bzw. ein Kartenzertifikat zur Signierung angegeben sein (siehe Anlage 1, Datentyp EquipmentType).

—	In der CHA des EQT.CA-Zertifikats muss eine MSCA angegeben sein.

—	In der CHA des EQT.Link-Zertifikats muss die ERCA angegeben sein.“

ii)	Abbildung 13 erhält folgende Fassung: „Abbildung 13 Protokoll für die Verifizierung der Signatur mithilfe einer heruntergeladenen Datei “

37.

Anlage 12 wird wie folgt geändert:

Abschnitt 3 wird wie folgt geändert:

In Absatz GNS_4 erhält der zweite Unterabsatz nach Abbildung 2 folgende Fassung:

„Die Auflösung der Position basiert auf dem oben beschriebenen RMC-Datensatzformat. Der erste Teil der Felder 3) und 5) wird verwendet, um die Gradwerte darzustellen. Der Rest dient dazu, die Minuten mit drei Dezimalzahlen darzustellen. Die Auflösung ist also 1/1 000 Minute oder 1/60 000 Grad (da eine Minute 1/60 Grad ist).“

ii)

Absatz GNS_5 erhält folgende Fassung:

„GNS_5

Die Fahrzeugeinheit muss die Positionsinformation zur Breite und Länge mit einer Auflösung von 1/10 Minute oder 1/600 Grad in der VU-Datenbank speichern, wie in Anlage 1 für GeoCoordinates beschrieben.

Der Befehl GPS DOP und aktive Satelliten (GSA) kann von der VU verwendet werden, um die Signalverfügbarkeit und -genauigkeit zu bestimmen und aufzuzeichnen. Die HDOP dient insbesondere dazu, die Genauigkeit der aufgezeichneten Standortdaten anzugeben (siehe 4.2.2). Die VU speichert den Wert der Horizontalgenauigkeit (HDOP), der als niedrigster der in den verfügbaren GNSS-Systemen erfassten HDOP-Werte berechnet wird.

Die ID des GNSS gibt für jede GNSS-Konstellation und satellitengestützte Ergänzungssysteme (Satellite-Based Augmentation System, SBAS) die entsprechende NMEA-ID an.

Abbildung 3

Struktur des GSA-Datensatzes

“

iii)

Absatz GNS_6 erhält folgende Fassung:

„GNS_6

Der GSA-Datensatz muss unter der Datensatznummer ‘02’ bis ‘06’ gespeichert werden.“

Abschnitt 4.2.1 wird wie folgt geändert:

Absatz GNS_16 erhält folgende Fassung:

„GNS_16

Im Kommunikationsprotokoll müssen erweiterte Längenfelder nicht unterstützt werden.“

ii)

Absatz GNS_18 erhält folgende Fassung:

„GNS_18

Im Hinblick auf die Funktionen 1) Erfassen und Verteilen von GNSS-Daten, 2) Erfassen der Konfigurationsdaten der externen GNSS-Ausrüstung und 3) Verwaltungsprotokoll muss der GNSS Secure Transceiver eine Chipkarte mit einer Dateisystemarchitektur simulieren, die sich aus einem Wurzelverzeichnis (Master File, MF), einer Verzeichnisdatei (Dedicated File, DF) mit Anwendungskennung gemäß Spezifikation in Anlage 1 Kapitel 6.2 (‘FF 44 54 45 47 4D’) und mit 3 EF, die Zertifikate enthalten, sowie aus einer Elementardatei (EF.EGF) mit Dateikennung ‘2F2F’ gemäß Beschreibung in Tabelle 1 zusammensetzt.“

iii)

Absatz GNS_20 erhält folgende Fassung:

„GNS_20

Der GNSS Secure Transceiver muss für die Speicherung der Daten einen Speicher verwenden und mindestens 20 Millionen Schreib/Lese-Zyklen durchführen können. Von diesem Aspekt abgesehen bleiben das Innendesign und die Implementierung des GNSS Secure Transceivers dem Hersteller überlassen.

Das Mapping der Datensatznummern und Daten geht aus Tabelle 1 hervor. Es ist zu beachten, dass es fünf GSA-Datensätze für die GNSS-Konstellationen und satellitengestützte Ergänzungssysteme (Satellite-Based Augmentation System, SBAS) gibt.“

Abschnitt 4.2.2 Absatz GNS_23 Nummer 5 erhält folgende Fassung:

„5.

Der VU-Prozessor prüft die empfangenen Daten, indem er die Informationen (z. B. Breite, Länge, Zeit) aus dem RMC NMEA-Datensatz extrahiert. Der RMC NMEA-Datensatz gibt Auskunft darüber, ob die Position gültig ist. Wenn die Position nicht gültig ist, sind die Standortdaten noch nicht verfügbar und können nicht zur Aufzeichnung der Fahrzeugposition verwendet werden. Wenn die Position gültig ist, extrahiert der VU-Prozessor auch die HDOP-Werte aus den GSA NMEA-Datensätzen und berechnet den Mindestwert für das verfügbare Satellitensystem (z. B. wenn die Ortung verfügbar ist).“

Abschnitt 4.4.1 Absatz GNS_28 erhält folgende Fassung:

„GNS_28

Kann die VU länger als 20 Minuten durchgehend nicht mit der gekoppelten externen GNSS-Ausrüstung kommunizieren, muss die VU ein Ereignis des Typs EventFaultType Enum ‘0E’H Communication error with the external GNSS facility (Kommunikationsfehler mit der externen GNSS-Ausrüstung) und mit dem Zeitstempel der aktuellen Zeit aufzeichnen. Das Ereignis wird nur generiert, wenn die folgenden beiden Bedingungen erfüllt sind: a) der intelligente Fahrtenschreiber befindet sich nicht im Kalibrierungsmodus und b) das Fahrzeug bewegt sich. In diesem Kontext wird ein Kommunikationsfehler ausgelöst, wenn der VU Secure Transceiver im Anschluss an eine Anforderungsnachricht gemäß 4.2 keine Antwortnachricht erhält.“

Abschnitt 4.4.2 Absatz GNS_29 erhält folgende Fassung:

„GNS_29

Wenn bei der externen GNSS-Ausrüstung eine Sicherheitsverletzung stattgefunden hat, muss der GNSS Secure Transceiver seinen gesamten Speicher löschen, einschließlich des kryptografischen Materials. Gemäß GNS_25 und GNS_26 muss die VU einen Eingriff erkennen, wenn die Antwort den Status ‘6690’ aufweist. Die VU generiert dann ein Ereignis des Typs EventFaultType Enum ‘19’H Tamper detection of GNSS (Manipulationserkennung beim GNSS). Alternativ kann die externe GNSS-Ausrüstung auch auf keine externen Anfragen mehr antworten.“

Abschnitt 4.4.3 Absatz GNS_30 erhält folgende Fassung:

„GNS_30

Wenn der GNSS Secure Transceiver länger als 3 Stunden durchgehend keine Daten vom GNSS-Empfänger erhält, generiert der GNSS Secure Transceiver auf den Befehl READ RECORD eine Antwortnachricht mit der RECORD-Nummer ‘01’ und einem Datenfeld von 12 Bytes, die alle auf 0xFF gesetzt sind. Bei Erhalt der Antwortnachricht mit diesem Wert im Datenfeld muss die VU ein Ereignis des Typs EventFaultType Enum ‘0D’H Absence of position information from GNSS receiver (Fehlende Positionsdaten des GNSS-Empfängers) mit einem Zeitstempel des aktuellen Zeitwerts generieren und aufzeichnen, wenn die folgenden beiden Bedingungen erfüllt sind: a) der intelligente Fahrtenschreiber befindet sich nicht im Kalibrierungsmodus und b) das Fahrzeug bewegt sich.“

In Abschnitt 4.4.4 Absatz GNS_31 erhält der Text bis Abbildung 4 folgende Fassung:

„Wenn die VU erkennt, dass das EGF-Zertifikat zur gegenseitigen Authentisierung nicht mehr gültig ist, muss die VU ein Kontrollgerät-Ereignis des Typs EventFaultType Enum ‘1B’H External GNSS facility certificate expired (Abgelaufenes Zertifikat der externen GNSS-Ausrüstung) mit einem Zeitstempel des aktuellen Zeitwerts generieren und aufzeichnen. Die VU verwendet weiterhin die erhaltenen GNSS-Positionsdaten.“

Abschnitt 5.2.1 Absatz GNS_34 erhält folgende Fassung:

„GNS_34

Erhält die VU mehr als 3 Stunden durchgehend keine Daten vom GNSS-Empfänger, so muss die VU ein Ereignis des Typs EventFaultType Enum ‘0D’H Absence of position information from GNSS receiver (Fehlende Positionsdaten des GNSS-Empfängers) mit einem Zeitstempel des aktuellen Zeitwerts nur generieren und aufzeichnen, wenn die folgenden beiden Bedingungen erfüllt sind: a) der intelligente Fahrtenschreiber befindet sich nicht im Kalibrierungsmodus und b) das Fahrzeug bewegt sich.“

Abschnitt 6 erhält folgende Fassung:

„6. GNSS-ZEITKONFLIKT

Stellt die VU eine Abweichung von mehr als 1 Minute zwischen der Zeit der VU-Zeitmessfunktion und der vom GNSS-Empfänger stammenden Zeit fest, muss die VU ein Ereignis des Typs EventFaultType Enum ‘0B’H Time conflict (GNSS versus VU internal clock) aufzeichnen. Wenn ein Zeitkonflikt-Ereignis ausgelöst wurde, prüft die VU die Zeitabweichung in den nächsten 12 Stunden nicht. Das Ereignis wird nicht ausgelöst, wenn der GNSS-Empfänger innerhalb der letzten 30 Tage kein gültiges GNSS-Signal empfangen konnte.“

38.

Anlage 13 wird wie folgt geändert:

In Abschnitt 2 erhält der vierte Absatz folgende Fassung:

„Folgendes wird in dieser Anlage nicht spezifiziert:

—	Erfassung und Verwaltung der Daten innerhalb der VU (dies ist an anderer Stelle in der Verordnung festgelegt oder ergibt sich aus dem Produktdesign).