EUR-Lex Document 02016R0799-20230821

Dieser Text dient lediglich zu Informationszwecken und hat keine Rechtswirkung. Die EU-Organe übernehmen keine
Haftung für seinen Inhalt. Verbindliche Fassungen der betreffenden Rechtsakte einschließlich ihrer Präambeln sind nur die
im Amtsblatt der Europäischen Union veröffentlichten und auf EUR-Lex verfügbaren Texte. Diese amtlichen Texte sind über
die Links in diesem Dokument unmittelbar zugänglich
►B 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
(Text von Bedeutung für den EWR)
(ABl. L 139 vom 26.5.2016, S. 1)
Geändert durch:
Amtsblatt
Nr. Seite Datum
►M1 Durchführungsverordnung (EU) 2018/502 der Kommission vom
28. Februar 2018
L 85 1 28.3.2018
►M2 Durchführungsverordnung (EU) 2020/158 der Kommission vom
5. Februar 2020
L 34 20 6.2.2020
►M3 Durchführungsverordnung (EU) 2021/1228 der Kommission vom 16.
Juli 2021
L 273 1 30.7.2021
►M4 Durchführungsverordnung (EU) 2023/980 der Kommission vom 16.
Mai 2023
L 134 28 22.5.2023
Berichtigt durch:
►C1 Berichtigung, ABl. L 146 vom 3.6.2016, S. 31 (2016/799)
►C2 Berichtigung, ABl. L 27 vom 1.2.2017, S. 169 (2016/799)
02016R0799 — DE — 21.08.2023 — 003.002 — 1
02016R0799 — DE — 21.08.2023 — 003.002 — 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
(Text von Bedeutung für den EWR)
Artikel 1
Gegenstand und Geltungsbereich
1. Diese Verordnung legt die notwendigen Bestimmungen für die
einheitliche Behandlung folgender Aspekte des Fahrtenschreibers fest:
a) Aufzeichnung der Position des Fahrzeugs an bestimmten Punkten
während der täglichen Arbeitszeit des Fahrers;
b) Früherkennung von möglicher Manipulation oder möglichem Miss­
brauch des intelligenten Fahrtenschreibers per Fernkommunikation;
c) Schnittstelle zu intelligenten Verkehrssystemen;
d) administrative und technische Anforderungen an Typgenehmigungs­
verfahren von Fahrtenschreibern, einschließlich der Sicherheits­
mechanismen.
▼M1
2. Bauart, Prüfung, Einbau, Nachprüfung, Betrieb und Reparatur von
intelligenten Fahrtenschreibern und ihren Komponenten müssen den
technischen Anforderungen des Anhangs IC dieser Verordnung genü­
gen.
3. Andere als intelligente Fahrtenschreiber müssen – hinsichtlich
Bauart, Prüfung, Einbau, Nachprüfung, Betrieb und Reparatur – wei­
terhin den Anforderungen des Anhangs I der Verordnung (EU)
Nr. 165/2014 bzw. des Anhangs IB der Verordnung (EWG) Nr. 3821/85
des Rates ( 1 ) genügen.
▼B
4. Gemäß Artikel 10d der Richtlinie 96/53/EG des Europäischen
Parlaments und des Rates übermittelt die Ausrüstung zur Früherkennung
per Fernkommunikation auch die von bordeigenen Wiegesystemen be­
reitgestellten Gewichtsdaten zum Zweck der frühzeitigen Aufdeckung
von Betrugsfällen.
▼M1
5. Diese Verordnung berührt nicht die Richtlinie 2014/53/EU des
Europäischen Parlaments und des Rates ( 2 ).
▼B
Artikel 2
Begriffsbestimmungen
Für die Zwecke dieser Verordnung gelten die Begriffsbestimmungen in
Artikel 2 der Verordnung (EU) Nr. 165/2014.
▼B
( 1 ) Verordnung (EWG) Nr. 3821/85 des Rates vom 20. Dezember 1985 über das
Kontrollgerät im Straßenverkehr (ABl. L 370 vom 31.12.1985, S. 8).
( 2 ) Richtlinie 2014/53/EU des Europäischen Parlaments und des Rates vom
16. April 2014 über die Harmonisierung der Rechtsvorschriften der Mitglied­
staaten ü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).
02016R0799 — DE — 21.08.2023 — 003.002 — 3
Zusätzlich gelten folgende Begriffsbestimmungen:
1) „digitaler Fahrtenschreiber“ oder „Fahrtenschreiber der ersten Ge­
neration“ ist ein digitaler Fahrtenschreiber, bei dem es sich nicht
um einen intelligenten Fahrtenschreiber handelt;
2) „externe GNSS-Ausrüstung“ ist eine Ausrüstung, die den GNSS-
Empfänger (wenn die Fahrzeugeinheit nicht aus einem Einzelgerät
besteht) sowie andere Komponenten enthält, die erforderlich sind
für den Schutz der Kommunikation der Positionsdaten an die übrige
Fahrzeugeinheit;
▼M1
3) „Informationsdossier“ ist das Gesamtdossier in elektronischer Form
oder auf Papier, das alle Angaben enthält, die der Hersteller oder
dessen Beauftragter der Typgenehmigungsbehörde für die Zwecke
der Typgenehmigung des Fahrtenschreibers oder einer seiner Kom­
ponenten vorgelegt hat, einschließlich der Zertifikate nach Arti­
kel 12 Absatz 3 der Verordnung (EU) Nr. 165/2014, der Durch­
führung der Prüfungen gemäß Anhang IC dieser Verordnung sowie
Zeichnungen, Fotografien und anderer relevanter Unterlagen;
▼B
4) „Informationspaket“ ist das Informationsdossier in elektronischer
Form oder auf Papier, zusammen mit etwaigen anderen Unterlagen,
die die Typgenehmigungsbehörde im Zuge der Wahrnehmung ihrer
Aufgaben dem Informationsdossier beigefügt hat, darunter auch —
am Ende des Typgenehmigungsverfahrens — der EG-Typgenehmi­
gungsbogen des Fahrtenschreibers oder einer seiner Komponenten;
5) „Inhaltsverzeichnis des Informationspakets“ ist die Unterlage, in der
der nummerierte Inhalt des Informationspakets einschließlich aller
relevanten Teile dieses Pakets aufgeführt ist. Das Format dieser
Unterlage muss die Unterscheidung der aufeinander folgenden
Schritte im Verfahren für die Erteilung der EG-Typgenehmigung,
einschließlich der Daten etwaiger Überarbeitungen und Aktualisie­
rungen dieses Pakets, erlauben;
6) „Ausrüstung zur Früherkennung per Fernkommunikation“ ist die
Ausrüstung der Fahrzeugeinheit, die zur Durchführung gezielter
Straßenkontrollen verwendet wird;
▼M1
7) „intelligenter Fahrtenschreiber“ oder „Fahrtenschreiber der zweiten
Generation“ ist ein digitaler Fahrtenschreiber gemäß den Artikeln 8,
9 und 10 der Verordnung (EU) Nr. 165/2014 sowie gemäß An­
hang IC dieser Verordnung;
8) „Komponente eines Fahrtenschreibers“ ist einer der folgenden Be­
standteile: die Fahrzeugeinheit, der Bewegungssensor, das Schau­
blatt, die externe GNSS-Ausrüstung oder die Ausrüstung zur Früh­
erkennung per Fernkommunikation;
▼B
9) „Typgenehmigungsbehörde“ ist die Behörde eines Mitgliedstaats,
die für die Durchführung der Typgenehmigung des Fahrtenschrei­
bers oder seiner Komponenten, das Zulassungsverfahren, die Aus­
stellung und gegebenenfalls den Entzug von Typgenehmigungs­
bögen zuständig ist, die als Kontaktstelle für die Genehmigungs­
behörden der anderen Mitgliedstaaten fungiert und sicherstellt, dass
die Hersteller ihren Verpflichtungen im Hinblick auf die Erfüllung
der Anforderungen dieser Verordnung nachkommen ;
▼M1
10) „Fahrzeugeinheit“ ist der Fahrtenschreiber ohne den Bewegungs­
sensor und ohne die Verbindungskabel zum Bewegungssensor.
Sie kann aus einem Einzelgerät oder aus mehreren im Fahrzeug
verteilten Geräten bestehen und umfasst eine Verarbeitungseinheit,
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 4
einen Massenspeicher, eine Zeitmessfunktion, zwei Chipkarten-
Schnittstellengeräte für Fahrer und Beifahrer, einen Drucker, eine
Datenanzeige, Steckverbinder und Bedienelemente für Nutzereinga­
ben, einen GNSS-Empfänger und eine Ausrüstung zur Fernkom­
munikation.
Die Fahrzeugeinheit kann aus folgenden typgenehmigungspflichti­
gen Teilen bestehen:
— Fahrzeugeinheit als Einzelkomponente (einschließlich GNSS-
Empfänger und Fernkommunikationsausrüstung),
— Hauptgehäuse der Fahrzeugeinheit (einschließlich Fernkom­
munikationsausrüstung) und externer GNSS-Ausrüstung,
— Hauptgehäuse der Fahrzeugeinheit (einschließlich GNSS-Emp­
fänger) und externer Fernkommunikationsausrüstung,
— Hauptgehäuse der Fahrzeugeinheit, externer GNSS-Ausrüstung
und externer Fernkommunikationsausrüstung.
Besteht die Fahrzeugeinheit aus mehreren im Fahrzeug verteilten
Geräten, so sind im Hauptgehäuse der Fahrzeugeinheit die Ver­
arbeitungseinheit, der Massenspeicher und die Zeitmessfunktion
untergebracht.
Das Kürzel „VU“ (vehicle unit) wird für „Fahrzeugeinheit“ oder
„Hauptgehäuse der Fahrzeugeinheit“ verwendet.
▼B
Artikel 3
Standortgestützte Dienste
1. Die Hersteller gewährleisten, dass intelligente Fahrtenschreiber mit
den durch das Satelliten-Navigationssystem Galileo und die Europäische
Erweiterung des geostationären Navigationssystems (EGNOS) erbrach­
ten Positionsbestimmungsdiensten kompatibel sind.
2. Zusätzlich zu den in Absatz 1 genannten Systemen können die
Hersteller auch die Kompatibilität mit anderen Satellitennavigationssys­
temen gewährleisten.
Artikel 4
Verfahren für die Typgenehmigung von Fahrtenschreibern und
Komponenten des Fahrtenschreibers
1. Der Hersteller oder dessen Beauftragter beantragt die Typgeneh­
migung für einen Fahrtenschreiber oder eine seiner Komponenten oder
Gruppe von Komponenten bei der von einem Mitgliedstaat benannten
Typgenehmigungsbehörde. Der Antrag umfasst ein Informationsdossier
mit den Angaben zu jeder einzelnen Komponente, einschließlich, falls
vorhanden, der Typgenehmigungsbögen von anderen, zur Vervollstän­
digung des Fahrtenschreibers erforderlichen Komponenten, sowie alle
sonstigen relevanten Unterlagen.
2. Ein Mitgliedstaat erteilt die Typgenehmigung für den Fahrten­
schreiber, die Komponente oder Gruppe von Komponenten, die den
administrativen und technischen Anforderungen nach Artikel 1 Absätze
2 bzw. 3 genügen. In diesem Fall stellt die Typgenehmigungsbehörde
dem Antragsteller einen Typgenehmigungsbogen nach dem Muster in
Anhang II dieser Verordnung aus.
3. Die Typgenehmigungsbehörde kann vom Hersteller oder dessen
Beauftragtem zusätzliche Informationen verlangen.
▼M1
02016R0799 — DE — 21.08.2023 — 003.002 — 5
4. Der Hersteller oder dessen Beauftragter stellt den Typgenehmi­
gungsbehörden sowie den für die Ausstellung der Zertifikate nach Ar­
tikel 12 Absatz 3 der Verordnung (EU) Nr. 165/2014 zuständigen Stel­
len so viele Fahrtenschreiber oder Komponenten des Fahrtenschreibers
zur Verfügung, wie für die ordnungsgemäße Durchführung des Typge­
nehmigungsverfahrens erforderlich sind.
5. Beantragt der Hersteller oder dessen Beauftragter eine Typgeneh­
migung für bestimmte Komponenten oder Gruppen von Komponenten
eines Fahrtenschreibers, so stellt er den für die Typgenehmigung zu­
ständigen Behörden die übrigen Komponenten, für die bereits eine Typ­
genehmigung vorliegt, sowie andere für den Bau des vollständigen
Fahrtenschreibers erforderliche Teile zur Verfügung, damit diese Behör­
den die erforderlichen Prüfungen durchführen können.
Artikel 5
Änderungen der Typgenehmigungen
1. Der Hersteller oder dessen Beauftragter unterrichtet die Typgeneh­
migungsbehörden, die die ursprüngliche Typgenehmigung erteilt haben,
unverzüglich über jegliche Änderung der Software oder Hardware des
Fahrtenschreibers oder der für dessen Herstellung verwendeten Werk­
stoffe, die im Informationspaket verzeichnet sind, und beantragt die
Änderung der Typgenehmigung.
2. Die Typgenehmigungsbehörden können je nach Art und Merkma­
len der Änderungen eine bestehende Typgenehmigung ändern oder er­
weitern oder eine neue Typgenehmigung erteilen.
Eine „Änderung“ wird vorgenommen, wenn die Genehmigungsbehörde
der Auffassung ist, dass es sich um geringfügige Änderungen an der
Software oder Hardware des Fahrtenschreibers oder der für seine Her­
stellung verwendeten Werkstoffe handelt. In diesem Fall stellt die Typ­
genehmigungsbehörde die geänderten Unterlagen des Informations­
pakets aus, aus denen die Art der Änderungen und das Datum ihrer
Genehmigung hervorgehen. Eine aktualisierte Fassung des Informations­
pakets in konsolidierter Form zusammen mit einer ausführlichen Be­
schreibung der vorgenommenen Änderungen reicht zur Erfüllung dieser
Anforderung aus.
Eine „Erweiterung“ wird vorgenommen, wenn die Genehmigungs­
behörde der Auffassung ist, dass es sich um wesentliche Änderungen
an der Software oder Hardware des Fahrtenschreibers oder der für seine
Herstellung verwendeten Werkstoffe handelt. In diesem Fall kann sie
die Durchführung neuer Prüfungen verlangen und teilt dies dem Her­
steller oder dessen Beauftragtem mit. Verlaufen diese Prüfungen zufrie­
denstellend, stellt die Typgenehmigungsbehörde einen geänderten Typ­
genehmigungsbogen aus, dessen Nummer auf die gewährte Erweiterung
hinweist. Auf dem Typgenehmigungsbogen sind der Grund für die Er­
weiterung und das Ausstellungsdatum anzugeben.
3. Im Inhaltsverzeichnis zum Informationspaket ist das Datum der
jüngsten Erweiterung oder Änderung der Typgenehmigung oder das
Datum der jüngsten Konsolidierung der aktualisierten Fassung der Typ­
genehmigung anzugeben.
4. Eine neue Typgenehmigung ist erforderlich, wenn die beantragten
Änderungen des zugelassenen Fahrtenschreibers oder seiner Komponen­
ten zur Erteilung eines neuen Sicherheits- oder Interoperabilitätszertifi­
kats führen würden.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 6
Artikel 6
Inkrafttreten
Diese Verordnung tritt am zwanzigsten Tag nach ihrer Veröffentlichung
im Amtsblatt der Europäischen Union in Kraft.
Sie gilt ab 2. März 2016.
▼M1
Der Anhang IC gilt jedoch ab dem 15. Juni 2019, ausgenommen An­
lage 16, die ab dem 2. März 2016 gilt.
▼B
Diese Verordnung ist in allen ihren Teilen verbindlich und gilt unmittel­
bar in jedem Mitgliedstaat.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 7
ANHANG I C
Vorschriften für Bau, Prüfung, Einbau und Nachprüfung
EINLEITUNG
1 BEGRIFFSBESTIMMUNGEN
2 ALLGEMEINE FUNKTIONSMERKMALE DES KONTROLL­
GERÄTS
2.1 Allgemeine Merkmale
2.2 Funktionen
2.3 Betriebsarten
2.4 Sicherheit
3 BAUART- UND FUNKTIONSMERKMALE DES KONTROLL­
GERÄTS
3.1 Überwachung des Einsteckens und Entnehmens von Karten
3.2 Geschwindigkeits-, Positions- und Wegstreckenmessung
3.2.1 Messung der zurückgelegten Wegstrecke
3.2.2 Geschwindigkeitsmessung
3.2.3 Messung der Position
3.3 Zeitmessung
3.4 Überwachung der Fahrertätigkeiten
3.5 Überwachung des Status der Fahrzeugführung
3.6 Eingaben durch die Fahrer
3.6.1 Eingabe des Orts des Beginns und/oder des Endes des Arbeitstages
3.6.2 Manuelle Eingabe der Fahrertätigkeiten und Zustimmung des Fah­
rers für die ITS-Schnittstelle
3.6.3 Eingabe spezifischer Bedingungen
▼M3
3.6.4 Eingabe von Be-/Entladevorgängen
▼B
3.7 Unternehmenssperren
3.8 Überwachung von Kontrollen
3.9 Feststellung von Ereignissen und/oder Störungen
3.9.1 Ereignis „Einstecken einer ungültigen Karte“
3.9.2 Ereignis „Kartenkonflikt“
3.9.3 Ereignis „Zeitüberlappung“
3.9.4 Ereignis „Lenken ohne geeignete Karte“
3.9.5 Ereignis „Einstecken der Karte während des Lenkens“
3.9.6 Ereignis „Letzter Vorgang nicht korrekt abgeschlossen“
3.9.7 Ereignis „Geschwindigkeitsüberschreitung“
3.9.8 Ereignis „Unterbrechung der Stromversorgung“
3.9.9 Ereignis „Kommunikationsfehler mit der Fernkommunikationsaus­
rüstung“
3.9.10 Ereignis „Fehlende Positionsdaten des GNSS-Empfängers“
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 8
3.9.11 Ereignis „Kommunikationsfehler mit der externen GNSS-Ausrüs­
tung“
3.9.12 Ereignis „Datenfehler Bewegungssensor“
3.9.13 Ereignis „Datenkonflikt Fahrzeugbewegung“
3.9.14 Ereignis „Versuch einer Sicherheitsverletzung“
3.9.15 Ereignis „Zeitkonflikt“
3.9.16 Störung „Kartenfehlfunktion“
3.9.17 Störung „Kontrollgerät“
▼M3
3.9.18 Ereignis „GNSS-Anomalie“
▼B
3.10 Integrierte Tests und Selbsttests
3.11 Auslesen von Daten aus dem Massenspeicher
3.12 Aufzeichnung und Speicherung von Daten im Massenspeicher
3.12.1 Gerätekenndaten
3.12.1.1 Kenndaten der Fahrzeugeinheit
3.12.1.2 Kenndaten des Bewegungssensors
3.12.1.3 Kenndaten der globalen Satellitennavigationssysteme
3.12.2 Schlüssel und Zertifikate
3.12.3 Einsteck- und Entnahmedaten der Fahrer- oder der Werkstattkarte
3.12.4 Fahrertätigkeitsdaten
▼M1
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
3.12.6 Kilometerstandsdaten
3.12.7 Detaillierte Geschwindigkeitsdaten
3.12.8 Ereignisdaten
3.12.9 Störungsdaten
3.12.10 Kalibrierungsdaten
3.12.11 Zeiteinstellungsdaten
3.12.12 Kontrolltätigkeitsdaten
3.12.13 Unternehmenssperrdaten
3.12.14 Erfassen des Herunterladens
3.12.15 Daten zu spezifischen Bedingungen
3.12.16 Daten der Fahrtenschreiberkarte
▼M3
3.12.17 Grenzüberschreitungen
3.12.18 Be-/Entladevorgänge
3.12.19 Digitale Karte
▼B
3.13 Auslesen von Daten aus Fahrtenschreiberkarten
3.14 Aufzeichnung und Speicherung von Daten auf Fahrtenschreiberkarten
3.14.1 Aufzeichnung und Speicherung von Daten auf Fahrtenschreiberkar­
ten der ersten Generation
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 9
3.14.2 Aufzeichnung und Speicherung von Daten auf Fahrtenschreiberkar­
ten der zweiten Generation
3.15 Anzeige
3.15.1 Standardanzeige
3.15.2 Warnanzeige
3.15.3 Menübedienung
3.15.4 Sonstige Anzeigen
3.16 Drucken
3.17 Warnsignale
3.18 Herunterladen von Daten auf externe Datenträger
3.19 Fernkommunikation für die Durchführung gezielter Straßenkontrollen
▼M3
3.20 Datenaustausch mit externen Zusatzgeräten
▼B
3.21 Kalibrierung
3.22 Straßenseitige Kalibrierungsüberprüfung
3.23 Zeiteinstellung
3.24 Leistungsmerkmale
3.25 Werkstoffe
3.26 Markierungen
▼M3
3.27 Überwachung von Grenzüberschreitungen
3.28 Softwareaktualisierung
▼B
4 BAUART- UND FUNKTIONSMERKMALE DER FAHRTEN­
SCHREIBERKARTEN
4.1 Sichtbare Daten
4.2 Sicherheit
4.3 Normen
4.4 Spezifikationen für Umgebung und Elektrizität
4.5 Datenspeicherung
4.5.1 Elementardateien für Kennung und Kartenverwaltung
4.5.2 IS-Kartenkennung
4.5.2.1 Chipkennung
4.5.2.2 DIR (nur in Fahrtenschreiberkarten der zweiten Generation enthalten)
4.5.2.3 ATR-Angaben (eingeschränkt, nur in Fahrtenschreiberkarten der
zweiten Generation enthalten)
4.5.2.4 Erweiterte Längenangabe (eingeschränkt, nur in Fahrtenschreiber­
karten der zweiten Generation enthalten)
4.5.3 Fahrerkarte
4.5.3.1 Fahrtenschreiberanwendung (zugänglich für Fahrzeugeinheiten der
ersten und zweiten Generation)
4.5.3.1.1 Anwendungskennung
4.5.3.1.2 Schlüssel und Zertifikate
4.5.3.1.3 Kartenkennung
4.5.3.1.4 Karteninhaberkennung
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 10
4.5.3.1.5 Herunterladen von der Karte
4.5.3.1.6 Führerscheininformationen
4.5.3.1.7 Ereignisdaten
4.5.3.1.8 Störungsdaten
4.5.3.1.9 Fahrertätigkeitsdaten
4.5.3.1.10 Daten zu gefahrenen Fahrzeugen
4.5.3.1.11 Ort des Beginns und/oder des Endes des Arbeitstages
4.5.3.1.12 Kartenvorgangsdaten
4.5.3.1.13 Kontrolltätigkeitsdaten
4.5.3.1.14 Daten zu spezifischen Bedingungen
4.5.3.2 Fahrtenschreiberanwendung der zweiten Generation (für Fahrzeug­
einheiten der ersten Generation nicht zugänglich)
4.5.3.2.1 Anwendungskennung
▼M3
4.5.3.2.1.1 Zusätzliche Anwendungskennung (nicht zugänglich für Version 1
von Fahrzeugeinheiten der zweiten Generation)
▼B
4.5.3.2.2 Schlüssel und Zertifikate
4.5.3.2.3 Kartenkennung
4.5.3.2.4 Karteninhaberkennung
4.5.3.2.5 Herunterladen von der Karte
4.5.3.2.6 Führerscheininformationen
4.5.3.2.7 Ereignisdaten
4.5.3.2.8 Störungsdaten
4.5.3.2.9 Fahrertätigkeitsdaten
4.5.3.2.10 Daten zu gefahrenen Fahrzeugen
4.5.3.2.11 Ort und Position des Beginns und/oder des Endes des Arbeitstages
4.5.3.2.12 Kartenvorgangsdaten
4.5.3.2.13 Kontrolltätigkeitsdaten
4.5.3.2.14 Daten zu spezifischen Bedingungen
4.5.3.2.15 Daten zu den genutzten Fahrzeugeinheiten
▼M1
4.5.3.2.16 Ortsdaten zu drei Stunden kumulierter Lenkzeit
▼M3
4.5.3.2.17 Authentisierungsstatus für Positionen, die sich auf den Ort des
Beginns und/oder des Endes der täglichen Arbeitszeit beziehen
(nicht zugänglich für Version 1 von Fahrzeugeinheiten der zweiten
Generation)
4.5.3.2.18 Authentisierungsstatus für Positionen, an denen die kumulierte
Lenkzeit drei Stunden erreicht (nicht zugänglich für Version 1
von Fahrzeugeinheiten der zweiten Generation)
4.5.3.2.19 Grenzüberschreitungen (nicht zugänglich für Version 1 von Fahr­
zeugeinheiten der zweiten Generation)
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 11
4.5.3.2.20 Be-/Entladevorgänge (nicht zugänglich für Version 1 von Fahr­
zeugeinheiten der zweiten Generation)
4.5.3.2.21 Eingaben der Art der Ladung (nicht zugänglich für Version 1 von
Fahrzeugeinheiten der zweiten Generation)
4.5.3.2.22 Konfigurationen der Fahrzeugeinheit (nicht zugänglich für Ver­
sion 1 von Fahrzeugeinheiten der zweiten Generation)
▼B
4.5.4 Werkstattkarte
4.5.4.1 Fahrtenschreiberanwendung (zugänglich für Fahrzeugeinheiten der
ersten und zweiten Generation)
4.5.4.1.1 Anwendungskennung
4.5.4.1.2 Schlüssel und Zertifikate
4.5.4.1.3 Kartenkennung
4.5.4.1.4 Karteninhaberkennung
4.5.4.1.5 Herunterladen von der Karte
4.5.4.1.6 Kalibrierungs- und Zeiteinstellungsdaten
4.5.4.1.7 Ereignis- und Störungsdaten
4.5.4.1.8 Fahrertätigkeitsdaten
4.5.4.1.9 Daten zu gefahrenen Fahrzeugen
4.5.4.1.10 Daten zum Beginn und/oder Ende des Arbeitstages
4.5.4.1.11 Kartenvorgangsdaten
4.5.4.1.12 Kontrolltätigkeitsdaten
4.5.4.1.13 Daten zu spezifischen Bedingungen
4.5.4.2 Fahrtenschreiberanwendung der zweiten Generation (für Fahrzeug­
einheiten der ersten Generation nicht zugänglich)
4.5.4.2.1 Anwendungskennung
▼M3
4.5.4.2.1.1 Zusätzliche Anwendungskennung (nicht zugänglich für Version 1
von Fahrzeugeinheiten der zweiten Generation)
▼B
4.5.4.2.2 Schlüssel und Zertifikate
4.5.4.2.3 Kartenkennung
4.5.4.2.4 Karteninhaberkennung
4.5.4.2.5 Herunterladen von der Karte
4.5.4.2.6 Kalibrierungs- und Zeiteinstellungsdaten
4.5.4.2.7 Ereignis- und Störungsdaten
4.5.4.2.8 Fahrertätigkeitsdaten
4.5.4.2.9 Daten zu gefahrenen Fahrzeugen
4.5.4.2.10 Daten zum Beginn und/oder Ende des Arbeitstages
4.5.4.2.11 Kartenvorgangsdaten
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 12
4.5.4.2.12 Kontrolltätigkeitsdaten
4.5.4.2.13 Daten zu den genutzten Fahrzeugeinheiten
▼M1
4.5.4.2.14 Ortsdaten zu drei Stunden kumulierter Lenkzeit
▼B
4.5.4.2.15 Daten zu spezifischen Bedingungen
▼M3
4.5.4.2.16 Authentisierungsstatus für Positionen, die sich auf den Ort des
Beginns und/oder des Endes der täglichen Arbeitszeit beziehen
(nicht zugänglich für Version 1 von Fahrzeugeinheiten der zweiten
Generation)
4.5.4.2.17 Authentisierungsstatus für Positionen, an denen die kumulierte
Lenkzeit drei Stunden erreicht (nicht zugänglich für Version 1
von Fahrzeugeinheiten der zweiten Generation)
4.5.4.2.18 Grenzüberschreitungen (nicht zugänglich für Version 1 von Fahr­
zeugeinheiten der zweiten Generation)
4.5.4.2.19 Be-/Entladevorgänge (nicht zugänglich für Version 1 von Fahr­
zeugeinheiten der zweiten Generation)
4.5.4.2.20 Eingaben der Art der Ladung (nicht zugänglich für Version 1 von
Fahrzeugeinheiten der zweiten Generation)
4.5.4.2.21 Zusätzliche Kalibrierungsdaten (nicht zugänglich für Version 1 von
Fahrzeugeinheiten der zweiten Generation)
4.5.4.2.22 Konfigurationen der Fahrzeugeinheit (nicht zugänglich für Ver­
sion 1 von Fahrzeugeinheiten der zweiten Generation)
▼B
4.5.5 Kontrollkarte
4.5.5.1 Fahrtenschreiberanwendung (zugänglich für Fahrzeugeinheiten der
ersten und zweiten Generation)
4.5.5.1.1 Anwendungskennung
4.5.5.1.2 Schlüssel und Zertifikate
4.5.5.1.3 Kartenkennung
4.5.5.1.4 Karteninhaberkennung
4.5.5.1.5 Kontrolltätigkeitsdaten
4.5.5.2 Fahrtenschreiberanwendung G2 (für Fahrzeugeinheiten der ersten
Generation nicht zugänglich)
4.5.5.2.1 Anwendungskennung
▼M3
4.5.5.2.1.1 Zusätzliche Anwendungskennung (nicht zugänglich für Version 1
von Fahrzeugeinheiten der zweiten Generation)
▼B
4.5.5.2.2 Schlüssel und Zertifikate
4.5.5.2.3 Kartenkennung
4.5.5.2.4 Karteninhaberkennung
4.5.5.2.5 Kontrolltätigkeitsdaten
▼M3
4.5.5.2.6 Konfigurationen der Fahrzeugeinheit (nicht zugänglich für Ver­
sion 1 von Fahrzeugeinheiten der zweiten Generation)
▼B
4.5.6 Unternehmenskarte
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 13
4.5.6.1 Fahrtenschreiberanwendung (zugänglich für Fahrzeugeinheiten der
ersten und zweiten Generation)
4.5.6.1.1 Anwendungskennung
4.5.6.1.2 Schlüssel und Zertifikate
4.5.6.1.3 Kartenkennung
4.5.6.1.4 Karteninhaberkennung
4.5.6.1.5 Unternehmensaktivitätsdaten
4.5.6.2 Fahrtenschreiberanwendung G2 (für Fahrzeugeinheiten der ersten
Generation nicht zugänglich)
4.5.6.2.1 Anwendungskennung
▼M3
4.5.6.2.1.1 Zusätzliche Anwendungskennung (nicht zugänglich für Version 1
von Fahrzeugeinheiten der zweiten Generation)
▼B
4.5.6.2.2 Schlüssel und Zertifikate
4.5.6.2.3 Kartenkennung
4.5.6.2.4 Karteninhaberkennung
4.5.6.2.5 Unternehmensaktivitätsdaten
▼M3
4.5.6.2.6 Konfigurationen der Fahrzeugeinheit (nicht zugänglich für Ver­
sion 1 von Fahrzeugeinheiten der zweiten Generation)
▼B
5 EINBAU EINES KONTROLLGERÄTS
5.1 Einbau
5.2 Einbauplakette
5.3 Plombierung
6 EINBAUPRÜFUNGEN, NACHPRÜFUNGEN UND REPARA­
TUREN
6.1 Zulassung der Einbaubetriebe, Werkstätten und Fahrzeughersteller
▼M1
6.2 Prüfung neuer oder reparierter Komponenten
▼B
6.3 Einbauprüfung
6.4 Regelmäßige Nachprüfungen
6.5 Messung der Anzeigefehler
6.6 Reparaturen
7 KARTENAUSGABE
8 TYPGENEHMIGUNG VON KONTROLLGERÄTEN UND
FAHRTENSCHREIBERKARTEN
8.1 Allgemeines
8.2 Sicherheitszertifikat
8.3 Funktionszertifikat
8.4 Interoperabilitätszertifikat
8.5 Typgenehmigungsbogen
8.6 Ausnahmeverfahren: für die ersten Interoperabilitätszertifikate für
Kontrollgeräte und Fahrtenschreiberkarten der zweiten Generation
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 14
EINLEITUNG
Dieser Anhang enthält die Anforderungen an die Kontrollgeräte und Fahrten­
schreiberkarten der zweiten Generation.
Seit dem 15. Juni 2019 werden Kontrollgeräte der zweiten Generation in erstmals
in der Union zugelassene Fahrzeuge eingebaut und Fahrtenschreiberkarten der
zweiten Generation ausgestellt.
Im Hinblick auf eine reibungslose Einführung des Fahrtenschreibersystems der
zweiten Generation müssen Fahrtenschreiberkarten der zweiten Generation so
ausgelegt sein, dass sie auch in Fahrzeugeinheiten der ersten Generation ver­
wendet werden können, die gemäß Anhang IB der Verordnung (EWG)
Nr. 3821/85 gebaut wurden.
Umgekehrt können Fahrtenschreiberkarten der ersten Generation in Fahrzeugein­
heiten der zweiten Generation verwendet werden. Fahrzeugeinheiten der zweiten
Generation können jedoch nur mit Werkstattkarten der zweiten Generation kali­
briert werden.
Die Anforderungen in Bezug auf die Interoperabilität zwischen den Fahrten­
schreibersystemen der ersten und der zweiten Generation sind in diesem Anhang
festgelegt. Anlage 15 enthält diesbezüglich weitere Einzelheiten zum Umgang
mit der Koexistenz beider Generationen.
Darüber hinaus werden mit dieser Verordnung aufgrund der Implementierung
neuer Funktionen wie der Authentisierung von Navigationsnachrichten im Offe­
nen Dienst von Galileo, der Erkennung von Grenzüberschreitungen, der Eingabe
von Be-/Entladevorgängen und der Notwendigkeit, die Kapazität der Fahrerkarte
auf 56 Tage Fahrertätigkeiten zu erhöhen, die technischen Anforderungen für die
Kontrollgeräte und Fahrtenschreiberkarten der zweiten Generation Version 2 ein­
geführt.
▼B
Verzeichnis der Anlagen
Anlage 1: DATENGLOSSAR
Anlage 2: SPEZIFIKATION DER FAHRTENSCHREIBERKARTEN
Anlage 3: PIKTOGRAMME
Anlage 4: AUSDRUCKE
Anlage 5: ANZEIGE
Anlage 6: STECKANSCHLUSS AN DER VORDERSEITE FÜR KALI­
BRIERUNG UND HERUNTERLADEN
Anlage 7: PROTOKOLLE ZUM HERUNTERLADEN DER DATEN
Anlage 8: KALIBRIERUNGSPROTOKOLL
Anlage 9: TYPGENEHMIGUNG MINDESTANFORDERUNG AN DIE
DURCHZUFÜHRENDEN PRÜFUNGEN
Anlage 10: SICHERHEITSANFORDERUNGEN
Anlage 11: GEMEINSAME SICHERHEITSMECHANISMEN
Anlage 12: POSITIONSBESTIMMUNG MITHILFE EINES GLOBALEN
SATELLITENNAVIGATIONSSYSTEMS (GNSS)
Anlage 13: ITS-SCHNITTSTELLE
Anlage 14: FERNKOMMUNIKATIONSFUNKTION
Anlage 15: MIGRATION: VERWALTUNG GLEICHZEITIG VORHANDE­
NER AUSRÜSTUNGSGENERATIONEN
Anlage 16: ADAPTER FÜR FAHRZEUGE DER KLASSEN M1 UND N1
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 15
1 BEGRIFFSBESTIMMUNGEN
Im Sinne dieses Anhangs bedeutet:
a) „Aktivierung“
Phase, in der der Fahrtenschreiber mithilfe einer Werkstattkarte
seine volle Einsatzbereitschaft erlangt und alle Funktionen,
einschließlich Sicherheitsfunktionen, erfüllt;
b) „Authentisierung“
Funktion zur Feststellung und Überprüfung der Identität einer
Person;
c) „Authentizität“
Eigenschaft einer Information, die von einem Beteiligten
stammt, dessen Identität überprüft werden kann;
d) „Integrierter Test“
Tests auf Anforderung, ausgelöst durch den Bediener oder
durch ein externes Gerät;
e) „Kalendertag“
einen von 0.00 Uhr bis 24.00 Uhr dauernden Tag. Alle Ka­
lendertage beziehen sich auf UTC-Zeitangaben (koordinierte
Weltzeit);
▼M3
f) „Kalibrierung eines intelligenten Fahrtenschreibers“
die Aktualisierung oder Bestätigung von Fahrzeugparametern,
die im Massenspeicher zu speichern sind. Zu den Fahrzeug­
parametern gehören die Fahrzeugkennung (Fahrzeugidentifizie­
rungsnummer (VIN), amtliches Kennzeichen (VRN) und zu­
lassender Mitgliedstaat) sowie Fahrzeugmerkmale (Wegdreh­
zahl, Kontrollgerätkonstante, tatsächlicher Reifenumfang, Rei­
fengröße, Einstellung des Geschwindigkeitsbegrenzers (wenn
zutreffend), aktuelle UTC-Zeit, aktueller Kilometerstand, stan­
dardmäßige Art der Ladung); während der Kalibrierung eines
Kontrollgeräts sind auch Art und Kennung aller vorhandenen,
die Typgenehmigung betreffenden Plombierungen im Massen­
speicher zu speichern;
eine Aktualisierung oder Bestätigung lediglich der UTC-Zeit
gilt als Zeiteinstellung und nicht als Kalibrierung, sofern sie
nicht im Widerspruch zu Nummer 6.4 Randnummer 409 steht;
zum Kalibrieren eines Kontrollgeräts muss eine Werkstattkarte
verwendet werden;
g) „Kartennummer“
eine aus 16 alphanumerischen Zeichen bestehende Nummer
zur eindeutigen Identifizierung einer Fahrtenschreiberkarte in­
nerhalb eines Mitgliedstaates. Die Kartennummer enthält eine
Kennung, die aus Angaben zum Fahrer oder Angaben zum
Karteninhaber zusammen mit einem fortlaufenden Karten­
index, einem Kartenersatzindex und einem Kartenerneuerungs­
index besteht;
die eindeutige Zuordnung einer Karte erfolgt somit anhand des
Codes des ausstellenden Mitgliedstaates und der Kartennum­
mer;
▼B
h) „Fortlaufender Kartenindex“
das 14. alphanumerische Zeichen einer Kartennummer zur Un­
terscheidung der verschiedenen Karten, die für ein(e) zum
Empfang mehrerer Fahrtenschreiberkarten berechtigte(s) Unter­
nehmen, Werkstatt oder Kontrollbehörde ausgestellt wurden.
Die eindeutige Identifizierung des Unternehmens, der Werk­
statt bzw. der Kontrollbehörde erfolgt durch die 13 ersten
Zeichen der Kartennummer;
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 16
i) „Kartenerneuerungsindex“
das 16. alphanumerische Zeichen einer Kartennummer, das
sich um eine Stelle erhöht, wenn die Fahrtenschreiberkarte,
die einer bestimmten Kennung (d. h. Angaben zum Fahrer
oder Angaben zum Karteninhaber zusammen mit einem fort­
laufenden Index) entspricht, ersetzt wird;
j) „Kartenersatzindex“
das 15. alphanumerische Zeichen einer Kartennummer, das
sich um eine Stelle erhöht, wenn die Fahrtenschreiberkarte,
die einer bestimmten Kennung (d. h. Angaben zum Fahrer
oder Angaben zum Karteninhaber zusammen mit einem fort­
laufenden Index) entspricht, ersetzt wird
▼B
k) „Wegdrehzahl des Kraftfahrzeugs“
die Kenngröße, die den Zahlenwert des Ausgangssignals an­
gibt, das am Anschlussstutzen für das Kontrollgerät am Kraft­
fahrzeug (Getriebestutzen bzw. Radachse) bei einer unter nor­
malen Prüfbedingungen zurückgelegten Wegstrecke von einem
Kilometer gemäß Randnummer 414 entsteht. Die Wegdrehzahl
wird in Impulsen je Kilometer (w = … Imp/km) ausgedrückt;
l) „Unternehmenskarte“
eine Fahrtenschreiberkarte, die die Behörden eines Mitglied­
staats einem Verkehrsunternehmen ausstellen, das mit einem
Fahrtenschreiber ausgerüstete Fahrzeuge betreiben muss, und
die das Verkehrsunternehmen ausweist und das Anzeigen, He­
runterladen und Ausdrucken der Daten ermöglicht, die in dem
von diesem Verkehrsunternehmen gesperrten Fahrtenschreiber
gespeichert sind;
m) „Konstante des Kontrollgerätes“
die Kenngröße, die den Wert des Eingangssignals angibt, der
für das Anzeigen und Aufzeichnen einer zurückgelegten Weg­
strecke von 1 km erforderlich ist; diese Konstante wird in
Impulsen je Kilometer (k = … Imp/km) ausgedrückt;
n) „ununterbrochene Lenkzeit“, im Kontrollgerät errechnet als ( 1 ):
die jeweiligen akkumulierten Lenkzeiten eines bestimmten
Fahrers seit Ende seiner letzten BEREITSCHAFT oder UN­
TERBRECHUNG/RUHE oder UNBEKANNTEN Zeit ( 2 ) von
45 oder mehr Minuten (dieser Zeitraum kann gemäß der
Verordnung (EG) Nr. 561/2006 des Europäischen Parlaments
und des Rates ( 3 ) aufgeteilt worden sein). Bei den Berechnun­
gen werden nach Bedarf die auf der Fahrerkarte gespeicherten
bisherigen Tätigkeiten berücksichtigt. Hat der Fahrer seine
Karte nicht eingesteckt, beruhen die Berechnungen auf den
Massenspeicheraufzeichnungen zu dem Zeitraum, in dem
keine Karte eingesteckt war, und zum entsprechenden Steck­
platz;
▼M3
( 1 ) Diese Art der Berechnung der ununterbrochenen Lenkzeit und der kumulativen Unter­
brechungszeit dient dem Kontrollgerät zur Errechnung der Warnung für ununterbrochene
Lenkzeit. Sie stellt keinen Vorgriff auf die rechtliche Auslegung dieser Zeiten dar.
Alternative Arten der Berechnung der ununterbrochenen Lenkzeit und der kumulativen
Unterbrechungszeit können als Ersatz für diese Begriffsbestimmungen verwendet wer­
den, falls diese durch Aktualisierungen anderer einschlägiger Rechtsvorschriften hinfällig
werden.
( 2 ) UNBEKANNT sind Zeiträume, in denen die Fahrerkarte nicht in ein Kontrollgerät einge­
steckt war und für die kein manueller Eintrag über die Fahrertätigkeit vorgenommen
wurde.
( 3 ) Verordnung (EG) Nr. 561/2006 des Europäischen Parlaments und des Rates vom
15. März 2006 zur Harmonisierung bestimmter Sozialvorschriften im Straßenverkehr
und zur Änderung der Verordnungen (EWG) Nr. 3821/85 und (EG) Nr. 2135/98 des
Rates sowie zur Aufhebung der Verordnung (EWG) Nr. 3820/85 des Rates (ABl. L 102
vom 11.4.2006, S. 1).
02016R0799 — DE — 21.08.2023 — 003.002 — 17
o) „Kontrollkarte“
eine Fahrtenschreiberkarte, die die Behörden eines Mitglied­
staats einer zuständigen nationalen Kontrollbehörde ausstellen,
die die Kontrollbehörde, und fakultativ den Kontrolleur, aus­
weist und das Auslesen, Ausdrucken und/oder Herunterladen
der im Massenspeicher, auf Fahrerkarten, und fakultativ auf
Werkstattkarten gespeicherten Daten, ermöglicht;
sie ermöglicht außerdem den Zugriff auf die Funktion straßen­
seitige Kalibrierungsüberprüfung und die Daten im Fernabfra­
gegerät.
p) „kumulative Unterbrechungszeit“, im Kontrollgerät errechnet
als ( 1 ):
die kumulative Lenkzeitunterbrechung eines bestimmten Fah­
rers wird errechnet als die jeweilige akkumulierte Zeit aus
BEREITSCHAFT, UNTERBRECHUNG/RUHE oder UNBE­
KANNT ( 2 ) von 15 oder mehr Minuten seit dem Ende der
letzten BEREITSCHAFT oder UNTERBRECHUNG/RUHE
oder UNBEKANNTEN Zeit ( 2 ) von 45 oder mehr Minuten
(dieser Zeitraum kann gemäß der Verordnung (EG)
Nr. 561/2006 aufgeteilt worden sein).
Bei den Berechnungen werden nach Bedarf die auf der Fah­
rerkarte gespeicherten bisherigen Tätigkeiten berücksichtigt.
Unbekannte Zeiträume mit negativer Dauer (Beginn des unbe­
kannten Zeitraums > Ende des unbekannten Zeitraums) auf­
grund von zeitlichen Überlappungen verschiedener Kontroll­
geräte werden bei der Berechnung nicht berücksichtigt.
Hat der Fahrer seine Karte nicht eingesteckt, beruhen die Be­
rechnungen auf den Massenspeicheraufzeichnungen für den
Zeitraum, in dem keine Karte eingesteckt war, und den ent­
sprechenden Steckplatz;
q) „Massenspeicher“
ein in das Kontrollgerät eingebautes Speichermedium;
r) „digitale Signatur“
die an einen Datenblock angehängte Datenmenge oder die
verschlüsselte Umwandlung eines Datenblocks, die es dem
Empfänger des Datenblocks ermöglicht, sich der Authentizität
und Integrität des Datenblocks zu vergewissern;
s) „Herunterladen“
das Kopieren eines Teils oder aller im Massenspeicher der
Fahrzeugeinheit oder der im Speicher einer Fahrtenschreiber­
karte enthaltenen Datendateien zusammen mit der digitalen
Signatur, sofern gespeicherte Daten dabei weder verändert
noch gelöscht werden;
▼B
( 1 ) Diese Art der Berechnung der ununterbrochenen Lenkzeit und der kumulativen Unter­
brechungszeit dient dem Kontrollgerät zur Errechnung der Warnung für ununterbrochene
Lenkzeit. Sie stellt keinen Vorgriff auf die rechtliche Auslegung dieser Zeiten dar.
Alternative Arten der Berechnung der ununterbrochenen Lenkzeit und der kumulativen
Unterbrechungszeit können als Ersatz für diese Begriffsbestimmungen verwendet wer­
den, falls diese durch Aktualisierungen anderer einschlägiger Rechtsvorschriften hinfällig
werden.
( 2 ) UNBEKANNT sind Zeiträume, in denen die Fahrerkarte nicht in ein Kontrollgerät einge­
steckt war und für die kein manueller Eintrag über die Fahrertätigkeit vorgenommen
wurde.
02016R0799 — DE — 21.08.2023 — 003.002 — 18
die Hersteller von intelligenten Fahrtenschreiber-Fahrzeugein­
heiten und die Hersteller der zum Herunterladen von Daten­
dateien konzipierten und bestimmten Geräte treffen alle zumut­
baren Maßnahmen, um zu gewährleisten, dass das Herunter­
laden dieser Daten unter möglichst geringen Zeitverlusten
durch die Verkehrsunternehmen und Fahrer erfolgen kann.
Die Datei mit detaillierten Geschwindigkeitsdaten muss mög­
licherweise zur Feststellung der Einhaltung der Verordnung
(EG) Nr. 561/2006 nicht heruntergeladen werden, kann aber
für andere Zwecke, z. B. zur Ermittlung eines Unfallhergangs,
verwendet werden.
t) „Fahrerkarte“
eine Fahrtenschreiberkarte, die einem bestimmten Fahrer von
den Behörden eines Mitgliedstaats ausgestellt wird, den Fahrer
ausweist und die Speicherung von Tätigkeitsdaten des Fahrers
ermöglicht;
u) „tatsächlicher Umfang der Fahrzeugreifen“
der Mittelwert der von jedem Antriebsrad bei einer vollen
Umdrehung zurückgelegten Wegstrecke. Die Messung dieser
Wegstrecken muss unter normalen Prüfbedingungen gemäß
Randnummer 414 erfolgen und wird in folgender Form aus­
gedrückt: „l = … mm“. Fahrzeughersteller können die Mes­
sung dieser Wegstrecken durch eine theoretische Berechnung
ersetzen, bei der die Achslastverteilung des fahrbereiten, unbe­
ladenen Fahrzeugs berücksichtigt wird ( 1 ). Die Verfahren für
diese theoretische Berechnung bedürfen der Genehmigung
durch eine zuständige Behörde des Mitgliedstaats und können
nur vor der Aktivierung des Fahrtenschreibers durchgeführt
werden;
v) „Ereignis“
eine vom intelligenten Fahrtenschreiber festgestellte Betriebs­
abweichung, die möglicherweise auf einen Betrugsversuch zu­
rückgeht;
w) „externe GNSS-Ausrüstung“
eine Ausrüstung, die den GNSS-Empfänger (wenn die Fahr­
zeugeinheit (VU) nicht aus einem Einzelgerät besteht) sowie
andere Komponenten enthält, die erforderlich sind für den
Schutz der Kommunikation der Positionsdaten an die übrige
Fahrzeugeinheit;
x) „Störung“
eine vom intelligenten Fahrtenschreiber festgestellte Betriebs­
abweichung, die möglicherweise auf eine technische Fehlfunk­
tion oder ein technisches Versagen zurückgeht;
y) „GNSS-Empfänger“
ein elektronisches Gerät, das die Signale von einem oder meh­
reren globalen Satellitennavigationssystem(en) (GNSS) emp­
fängt und digital verarbeitet, um Positions-, Geschwindigkeits-
und Zeitangaben liefern zu können;
▼B
( 1 ) Verordnung (EU) Nr. 1230/2012 der Kommission vom 12. Dezember 2012 zur Durch­
führung der Verordnung (EG) Nr. 661/2009 des Europäischen Parlaments und des Rates
hinsichtlich der Anforderungen an die Typgenehmigung von Kraftfahrzeugen und Kraft­
fahrzeuganhängern bezüglich ihrer Massen und Abmessungen und zur Änderung der
Richtlinie 2007/46/EG des Europäischen Parlaments und des Rates (ABl. L 353 vom
21.12.2012, S. 31), in der zuletzt geänderten Fassung.
02016R0799 — DE — 21.08.2023 — 003.002 — 19
z) „Einbau“
die Montage eines Fahrtenschreibers in einem Fahrzeug;
aa) „Interoperabilität“
die Fähigkeit von Systemen, Daten auszutauschen und Infor­
mationen weiterzugeben, sowie die ihnen zugrundeliegenden
Geschäftsabläufe;
bb) „Schnittstelle“
„Schnittstelle“ ist eine Einrichtung zwischen Systemen, die der
Verbindung und der Kommunikation zwischen den Systemen
dient;
cc) „Position“
geografische Koordinaten des Fahrzeugs zu einem bestimmten
Zeitpunkt;
dd) „Bewegungssensor“
den Bestandteil des Fahrtenschreibers, der ein Signal bereit­
stellt, das die Fahrzeuggeschwindigkeit und/oder die zurück­
gelegte Wegstrecke darstellt;
▼M3
ee) „ungültige Karte“
eine Karte, die als fehlerhaft festgestellt wurde oder deren
Authentisierung fehlgeschlagen oder deren Gültigkeitsbeginn
noch nicht erreicht oder deren Ablaufdatum überschritten ist;
eine Karte wird von der Fahrzeugeinheit auch in folgenden
Fällen als ungültig betrachtet:
— wenn eine Karte desselben ausstellenden Mitgliedstaats mit
der gleichen Kennung, d. h. Angaben zum Fahrer oder
Angaben zum Karteninhaber zusammen mit dem fortlau­
fenden Index, und einem höheren Kartenerneuerungsindex
bereits in die Fahrzeugeinheit eingesteckt wurde, oder
— wenn eine Karte desselben ausstellenden Mitgliedstaats mit
der gleichen Kennung, d. h. Angaben zum Fahrer oder
Angaben zum Karteninhaber zusammen mit dem fortlau­
fenden Index und dem Erneuerungsindex, jedoch mit ei­
nem höheren Kartenersatzindex bereits in die Fahrzeugein­
heit eingesteckt wurde;
▼B
ff) „offene Norm“
eine Norm, die in einem Normenspezifikationsdokument auf­
geführt ist, das kostenlos oder gegen eine Schutzgebühr zur
Verfügung steht und gebührenfrei oder gegen eine Schutz­
gebühr kopiert, verteilt oder benutzt werden darf;
gg) „Kontrollgerät nicht erforderlich“
wenn die Anwendung des Kontrollgeräts gemäß den Bestim­
mungen der Verordnung (EG) Nr. 561/2006 nicht erforderlich
ist;
hh) „Geschwindigkeitsüberschreitung“
die Überschreitung der zulässigen Fahrzeuggeschwindigkeit,
definiert als Zeitraum von mehr als 60 Sekunden, in dem
die gemessene Fahrzeuggeschwindigkeit den Höchstwert für
die Einstellung des Geschwindigkeitsbegrenzers gemäß Richt­
linie 92/6/EWG des Rates vom 10. Februar 1992 über Einbau
und Benutzung von Geschwindigkeitsbegrenzern für be­
stimmte Kraftfahrzeugklassen in der Gemeinschaft ( 1 ) in der
zuletzt geänderten Fassung überschreitet;
▼B
( 1 ) Richtlinie 92/6/EWG des Rates vom 10. Februar 1992 über Einbau und Benutzung von
Geschwindigkeitsbegrenzern für bestimmte Kraftfahrzeugklassen in der Gemeinschaft
(ABl. L 57 vom 2.3.1992, S. 27).
02016R0799 — DE — 21.08.2023 — 003.002 — 20
ii) „regelmäßige Nachprüfung“
einen Komplex von Arbeitsgängen zur Überprüfung der ord­
nungsgemäßen Funktion des Fahrtenschreibers und der Über­
einstimmung seiner Einstellungen mit den Fahrzeugparametern
sowie zur Kontrolle, dass keine Manipulationsvorrichtungen an
den Fahrtenschreiber angeschlossen sind;
jj) „Drucker“
eine Komponente des Kontrollgeräts, das Ausdrucke gespei­
cherter Daten liefert;
kk) „Fernkommunikation zur Früherkennung“
die Kommunikation zwischen der Ausrüstung zur Früherken­
nung per Fernkommunikation und dem Fernabfragegerät im
Rahmen gezielter Straßenkontrollen zur Fernerkennung mögli­
cher Manipulationen oder möglichen Missbrauchs des Kon­
trollgeräts;
▼M3
ll) „Ausrüstung zur Fernkommunikation“, „Fernkommunikations­
modul“ oder „Ausrüstung zur Früherkennung per Fernkom­
munikation“
das Gerät der Fahrzeugeinheit, das zur Durchführung gezielter
Straßenkontrollen eingesetzt wird;
▼B
mm) „Fernabfragegerät“
das von den Kontrolleuren bei gezielten Straßenkontrollen ver­
wendete System;
▼M3
nn) „Kartenerneuerung“
die Ausgabe einer neuen Fahrtenschreiberkarte bei Ablauf der
Gültigkeit einer vorhandenen Karte oder wenn die vorhandene
Karte defekt ist und der ausstellenden Behörde zurückgegeben
wurde;
▼B
oo) „Reparatur“
die Reparatur eines Bewegungssensors oder einer Fahrzeug­
einheit oder eines Kabels, wozu die Trennung von der Strom­
versorgung oder die Trennung von anderen Komponenten des
Fahrtenschreibers oder die Öffnung des Bewegungssensors
oder der Fahrzeugeinheit erforderlich ist;
▼M3
pp) „Kartenersatz“
die Ausgabe einer neuen Fahrtenschreiberkarte als Ersatz für
eine vorhandene Karte, die als verloren, gestohlen oder defekt
gemeldet und der ausstellenden Behörde nicht zurückgegeben
wurde;
▼B
qq) „Sicherheitszertifizierung“
der Prozess der Zertifizierung durch eine Common-Criteria-
Zertifizierungsstelle, dass das untersuchte Kontrollgerät (oder
die Komponente) oder die untersuchte Fahrtenschreiberkarte
die in den jeweiligen Schutzprofilen festgelegten Sicherheits­
anforderungen erfüllt;
rr) „Selbsttest“
zyklisch und automatisch vom Kontrollgerät durchgeführte
Tests zur Feststellung von Störungen;
ss) „Zeitmessung“
die ununterbrochene digitale Aufzeichnung der koordinierten
Weltzeit aus Kalenderdatum und Uhrzeit (UTC);
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 21
tt) „Zeiteinstellung“
die Einstellung der aktuellen Zeit; diese Einstellung kann auto­
matisch anhand der vom GNSS-Empfänger gelieferten Zeit­
angabe oder in der Betriebsart Kalibrierung vorgenommen
werden;
▼B
uu) „Reifengröße“
die Bezeichnung der Abmessungen der Reifen (äußere An­
triebsräder) gemäß Richtlinie 92/23/EWG des Rates ( 1 ) in der
zuletzt geänderten Fassung;
vv) „Fahrzeugkennung“
Nummern, mit deren Hilfe das Fahrzeug identifiziert werden
kann: amtliches Kennzeichen (VRN) mit Angabe des zulassen­
den Mitgliedstaats und der Fahrzeug-Identifizierungsnummer
(VIN) ( 2 );
ww) „Woche“ (zu Berechnungszwecken im Kontrollgerät)
den Zeitraum zwischen Montag 0.00 Uhr UTC und Sonntag
24.00 Uhr UTC;
xx) „Werkstattkarte“
eine Fahrtenschreiberkarte, die die Behörden eines Mitglied­
staats benannten Mitarbeitern eines von diesem Mitgliedstaat
zugelassenen Fahrtenschreiberherstellers, Einbaubetriebs, Fahr­
zeugherstellers oder einer von ihm zugelassenen Werkstatt aus­
stellen, den Karteninhaber ausweist und das Prüfen, Kalibrie­
ren und Aktivieren von Fahrtenschreibern und/oder das Herun­
terladen der Daten von diesen ermöglicht;
yy) „Adapter“
ein Gerät, das ein anderes als das für die unabhängige Bewe­
gungserkennung verwendete, permanent die Fahrzeug­
geschwindigkeit und/oder die zurückgelegte Wegstrecke dar­
stellendes Signal bereitstellt und
▼M3
— ausschließlich in Fahrzeuge der Klassen M1 und N1 (ge­
mäß der Begriffsbestimmung in Artikel 4 der Verord­
nung (EU) 2018/858 des Europäischen Parlaments und
des Rates ( 3 )) eingebaut ist und eingesetzt wird;
▼B
— an einem Ort eingebaut ist, an dem der Einbau eines be­
stehenden Bewegungssensors anderer Art, der ansonsten
den Bestimmungen dieses Anhangs und dessen Anlagen
1 bis 15 entspricht, mechanisch unmöglich ist;
▼M3
( 1 ) Richtlinie 92/23/EWG des Rates vom 31. März 1992 über Reifen von Kraftfahrzeugen
und Kraftfahrzeuganhängern und über ihre Montage (ABl. L 129 vom 14.5.1992, S. 95).
( 2 ) Richtlinie 76/114/EWG des Rates vom 18. Dezember 1975 zur Angleichung der Rechts­
vorschriften der Mitgliedstaaten über Schilder, vorgeschriebene Angaben, deren Lage
und Anbringungsart an Kraftfahrzeugen und Kraftfahrzeuganhängern (ABl. L 24 vom
30.1.1976, S. 1).
( 3 ) Verordnung (EU) 2018/858 des Europäischen Parlaments und des Rates vom 30. Mai
2018 über die Genehmigung und die Marktüberwachung von Kraftfahrzeugen und Kraft­
fahrzeuganhängern sowie von Systemen, Bauteilen und selbstständigen technischen Ein­
heiten für diese Fahrzeuge, zur Änderung der Verordnungen (EG) Nr. 715/2007 und (EG)
Nr. 595/2009 und zur Aufhebung der Richtlinie 2007/46/EG (ABl. L 151 vom
14.6.2018, S. 1).
02016R0799 — DE — 21.08.2023 — 003.002 — 22
— zwischen der Fahrzeugeinheit und dem Ort der Erzeugung
von Geschwindigkeits-/Entfernungsimpulsen durch inte­
grierte Sensoren oder alternative Schnittstellen eingebaut
ist,
— aus Sicht einer Fahrzeugeinheit verhält sich der Adapter
ebenso, als wäre ein den Bestimmungen dieses Anhangs
und dessen Anlagen 1 bis 16 entsprechender Bewegungs­
sensor an die Fahrzeugeinheit angeschlossen;
Der Einsatz eines solchen Adapters in den oben beschriebenen
Fahrzeugen muss den Einbau und die ordnungsgemäße Nut­
zung einer Fahrzeugeinheit im Einklang mit allen Vorschriften
dieses Anhangs ermöglichen.
Der intelligente Fahrtenschreiber für diese Fahrzeuge besteht
aus Verbindungskabeln, einem Adapter und einer Fahrzeugein­
heit;
zz) „Datenintegrität“
die Richtigkeit und Konsistenz gespeicherter Daten, die da­
durch angezeigt wird, dass zwischen zwei Aktualisierungen
eines Datensatzes die Daten nicht verändert werden. Integrität
bedeutet, dass es sich bei den Daten um eine genaue Kopie der
Originalfassung handelt, d. h., dass sie während des Schrei­
bens auf bzw. beim Auslesen eine(r) Fahrtenschreiberkarte
oder eine(r) spezielle(n) Ausrüstung oder bei der Übermittlung
durch einen Kommunikationskanal nicht verfälscht wurde;
▼M3
aaa) reserviert für künftige Verwendung;
▼B
bbb) „intelligentes Fahrtenschreibersystem“
das Kontrollgerät, die Fahrtenschreiberkarten und die gesamte
direkt oder indirekt interagierende Ausrüstung während Bau,
Einbau, Benutzung, Prüfung und Kontrolle, u. a. Karten, das
Fernabfragegerät und sonstige Ausrüstungen für das Herunter­
laden von Daten, Datenanalysen, die Kalibrierung, die Erstel­
lung, Verwaltung oder Einführung von Sicherheitselementen;
▼M3
ccc) „Einführungstermin“
das in der Verordnung (EU) Nr. 165/2014 festgelegte Datum,
ab dem erstmals zugelassene Fahrzeuge mit einem Fahrten­
schreiber gemäß dieser Verordnung ausgerüstet sein müssen;
▼B
ddd) „Schutzprofil“
ein im Rahmen des Common-Criteria-Zertifizierungsverfahrens
verwendetes Dokument mit implementationsneutralen Spezifi­
kationen von Sicherheitsanforderungen für die Informations­
sicherung;
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 23
eee) „GNSS-Genauigkeit“
im Rahmen der Aufzeichnung der Position über das globale
Satellitennavigationssystem (GNSS) mit Fahrtenschreibern den
Wert der Horizontalgenauigkeit (Horizontal Dilution of Preci­
sion, HDOP), berechnet als das Minimum der von den ver­
fügbaren GNSS-Systemen erfassten HDOP-Werte;
▼M1
fff) „kumulierte Lenkzeit“
Anzahl der insgesamt akkumulierten Minuten Lenkzeit in ei­
nem bestimmten Fahrzeug.
Der Wert der kumulierten Lenkzeit ist eine frei laufende Zäh­
lung aller Minuten, die die Funktion „Überwachung der Lenk­
tä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.
▼B
2 ALLGEMEINE FUNKTIONSMERKMALE DES KONTROLL­
GERÄTS
2.1 Allgemeine Merkmale
Aufgabe des Kontrollgeräts ist das Aufzeichnen, Speichern, Anzei­
gen, Ausdrucken und Ausgeben von tätigkeitsbezogenen Daten des
Fahrers.
Ein Fahrzeug, das mit einem den Bestimmungen dieses Anhangs
genügenden Kontrollgerät ausgestattet ist, muss über eine Geschwin­
digkeitsanzeige und einen Kilometerzähler verfügen. Diese Funktio­
nen können in das Kontrollgerät integriert sein.
01) Das Kontrollgerät besteht aus Verbindungskabeln, einem
Bewegungssensor und einer Fahrzeugeinheit.
02) Die Schnittstelle zwischen Bewegungssensoren und Fahr­
zeugeinheiten muss den Vorschriften gemäß Anlage 11
entsprechen.
03) Die Fahrzeugeinheit muss an ein oder mehrere globale(s)
Satellitennavigationssystem(e) gemäß Anlage 12 angebun­
den sein.
04) Die Fahrzeugeinheit muss mit den Fernabfragegeräten ge­
mäß Anlage 14 kommunizieren.
▼M3
05) Die Fahrzeugeinheit umfasst eine in Anlage 13 spezifizierte
ITS-Schnittstelle.
Das Kontrollgerät kann durch zusätzliche Schnittstellen
und/oder durch die ITS-Schnittstelle auch mit anderen Aus­
rüstungen verbunden werden.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 24
06) Werden Zusatzeinrichtungen in das Kontrollgerät eingebaut
oder daran angeschlossen, dürfen sie unabhängig davon, ob
sie zugelassen sind, die einwandfreie Arbeitsweise des
Kontrollgeräts und die Bestimmungen dieser Verordnung
weder faktisch noch potenziell beeinträchtigen.
Benutzer des Kontrollgeräts weisen sich gegenüber dem
Gerät mit Fahrtenschreiberkarten aus.
07) Je nach Art und/oder Identität des Benutzers bietet das
Kontrollgerät einen selektiven Zugang zu Daten und Funk­
tionen.
Das Kontrollgerät zeichnet Daten auf und speichert sie in seinem
Massenspeicher, der Fernkommunikationsausrüstung und auf Fahr­
tenschreiberkarten.
▼M3
Dies geschieht in Übereinstimmung mit den geltenden Datenschutz­
vorschriften der Union und im Einklang mit Artikel 7 der Verord­
nung (EU) Nr. 165/2014.
▼B
2.2 Funktionen
08) Das Kontrollgerät muss folgende Funktionen gewährleisten:
— Überwachung des Einsteckens und Entnehmens von
Karten,
— Geschwindigkeits-, Wegstrecken- und Positionsmes­
sung,
— Zeitmessung,
— Überwachung der Fahrertätigkeiten,
— Überwachung des Status der Fahrzeugführung,
▼M3
— manuelle Eingabe durch die Fahrer:
— Eingabe des Orts des Beginns und/oder des Endes
des Arbeitstages,
— manuelle Eingabe der Fahrertätigkeiten und Zustim­
mung des Fahrers für die ITS-Schnittstelle,
— Eingabe spezifischer Bedingungen,
— Eingabe von Be-/Entladevorgängen,
▼B
— Unternehmenssperren,
— Überwachung von Kontrollen,
— Feststellung von Ereignissen und/oder Störungen,
— integrierte Tests und Selbsttests,
— Auslesen von Daten aus dem Massenspeicher,
— Aufzeichnung und Speicherung von Daten im Massen­
speicher,
— Auslesen von Daten aus Fahrtenschreiberkarten,
— Aufzeichnung und Speicherung von Daten auf Fahrten­
schreiberkarten,
— Datenanzeige,
— Ausdrucken,
— Warnsignale,
— Herunterladen von Daten auf externe Datenträger,
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 25
— Fernkommunikation für die Durchführung gezielter
Straßenkontrollen,
— Datenausgabe an zusätzliche Ausrüstungen,
— Kalibrierung,
— straßenseitige Kalibrierungsüberprüfung,
— Zeiteinstellung,
▼M3
— Überwachung von Grenzüberschreitungen,
— Softwareaktualisierung.
▼B
2.3 Betriebsarten
09) Das Kontrollgerät verfügt über vier Betriebsarten:
— Betrieb,
— Kontrolle,
— Kalibrierung,
— Unternehmen.
10) Je nachdem, welche gültige Fahrtenschreiberkarte in die
Kartenschnittstellen eingesteckt ist, schaltet das Kontroll­
gerät auf folgende Betriebsart. Für die Wahl der Betriebsart
ist es unerheblich, zu welcher Generation die Fahrtenschrei­
berkarte gehört, sofern die eingesteckte Karte gültig ist.
Eine Werkstattkarte der ersten Generation gilt immer als
ungültig, wenn sie in eine Fahrzeugeinheit (VU) der zwei­
ten Generation eingesteckt wird.
Betriebsart
Steckplatz des Fahrers
Keine Karte Fahrerkarte Kontrollkarte Werkstattkarte Unternehmenskarte
S
te
ck
pl
at
z
de
s
B
ei
fa
hr
er
s
Keine Karte Betrieb Betrieb Kontrolle Kalibrierung Unternehmen
Fahrerkarte Betrieb Betrieb Kontrolle Kalibrierung Unternehmen
Kontrollkarte Kontrolle Kontrolle Kontrolle (*) Betrieb Betrieb
Werkstattkarte Kalibrierung Kalibrierung Betrieb Kalibrierung (*) Betrieb
Unternehmens­
karte
Unternehmen Unternehmen Betrieb Betrieb Unternehmen (*)
(*) In diesen Zuständen verwendet das Kontrollgerät nur die im Steckplatz des Fahrers eingesteckte Fahrtenschreiberkarte.
11) Ungültige Karten, die eingesteckt werden, sind vom Kon­
trollgerät zu ignorieren, doch müssen das Anzeigen, Aus­
drucken oder Herunterladen von auf abgelaufenen Karten
gespeicherten Daten möglich sein.
12) Alle in 2.2 aufgeführten Funktionen sind in jeder Betriebs­
art zu gewährleisten, wobei folgende Ausnahmen gelten:
— die Funktion Kalibrierung ist nur in der Betriebsart Ka­
librierung verfügbar,
— die Funktion straßenseitige Kalibrierungsüberprüfung ist
nur in der Betriebsart Kontrolle verfügbar,
— die Funktion Unternehmenssperre ist nur in der Be­
triebsart Unternehmen verfügbar,
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 26
— die Funktion Überwachung von Kontrollen ist nur in
der Betriebsart Kontrolle verfügbar,
▼M3
— die Funktion Herunterladen von Daten ist in der Be­
triebsart Betrieb nicht verfügbar, außer:
a) gemäß Randnummer 193,
b) zum Herunterladen einer Fahrerkarte, wenn keine
andere Karte in die Fahrzeugeinheit eingesteckt ist.
▼B
13) Das Kontrollgerät kann jegliche Daten an Anzeige-,
Drucker- oder externe Schnittstellen ausgeben, wobei fol­
gende Ausnahmen gelten:
— in der Betriebsart Betrieb werden persönliche Daten
(Vor- und Zuname), die nicht zur einer eingesteckten
Fahrtenschreiberkarte gehören, ausgeblendet, und eine
Kartennummer, die nicht zu einer eingesteckten Fahr­
tenschreiberkarte gehört, wird teilweise ausgeblendet
(von links nach rechts jedes zweite Zeichen),
▼M3
— in der Betriebsart Unternehmen (Randnummern 102,
105, 108, 133a und 133e) lassen sich Fahrerdaten nur
für Zeiträume ausgeben, für die keine Sperrung besteht
oder kein anderes Unternehmen (ausgewiesen durch die
ersten 13 Stellen der Unternehmenskartennummer) eine
Sperrung innehat,
▼B
— ist keine Karte in das Kontrollgerät eingesteckt, lassen
sich Fahrerdaten nur für den aktuellen und die 8 vor­
hergehenden Kalendertage ausgeben,
▼M3
— personenbezogene Daten, die vom Fahrtenschreiber
oder von den Fahrtenschreiberkarten aufgezeichnet
oder erzeugt wurden, dürfen nur dann durch die ITS-
Schnittstelle der Fahrzeugeinheit ausgegeben werden,
wenn die Zustimmung des Fahrers, auf den sich die
Daten beziehen, überprüft wurde,
▼M1
— die Fahrzeugeinheiten haben eine normale Gültigkeits­
dauer 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.
▼B
2.4 Sicherheit
▼M1
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 entspre­
chenden Versuche entdeckt werden, Schutz der Integrität und Au­
thentizität der zwischen Bewegungssensor und Fahrzeugeinheit aus­
getauschten Daten, Schutz der Integrität und Authentizität der zwi­
schen dem Kontrollgerät und den Fahrtenschreiberkarten aus­
getauschten Daten, Schutz der Integrität und Authentizität der zwi­
schen der Fahrzeugeinheit und der externen GNSS-Ausrüstung (so­
weit vorhanden) ausgetauschten Daten, Schutz der Vertraulichkeit,
Integrität und Authentizität der zu Kontrollzwecken durch Früh­
erkennung per Fernkommunikation ausgetauschten Daten sowie
Überprüfung der Integrität und Authentizität heruntergeladener Da­
ten.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 27
14) Zur Gewährleistung der Systemsicherheit müssen folgende
Komponenten die in ihren Schutzprofilen spezifizierten Si­
cherheitsanforderungen gemäß Anlage 10 erfüllen:
— Fahrzeugeinheit,
— Fahrtenschreiberkarte,
— Bewegungssensor,
▼M3
— externe GNSS-Ausrüstung (dieses Profil ist nur für die
externe Variante der GNSS-Ausrüstung erforderlich und
anwendbar).
▼B
3 BAUART- UND FUNKTIONSMERKMALE DES KONTROLL­
GERÄTS
3.1 Überwachung des Einsteckens und Entnehmens von Karten
15) Das Kontrollgerät überwacht die Kartenschnittstellen und
erkennt das Einstecken und Entnehmen einer Karte.
▼M3
16) Beim Einstecken einer Karte (oder bei der Fernauthentisie­
rung einer Karte) erkennt das Kontrollgerät, ob es sich um
eine gültige Fahrtenschreiberkarte im Sinne der Begriffs­
bestimmung ee in Abschnitt 1 handelt, und identifiziert in
diesem Fall die Kartenart und die Kartengeneration.
Zur Überprüfung, ob eine Karte bereits eingesteckt wurde,
verwendet das Kontrollgerät die in seinem Massenspeicher
gespeicherten Daten der Fahrtenschreiberkarte gemäß Rand­
nummer 133.
▼B
17) Die Fahrtenschreiberkarten der ersten Generation gelten für
das Kontrollgerät als ungültig, nachdem die Möglichkeit
der Verwendung von Fahrtenschreiberkarten der ersten Ge­
neration von einer Werkstatt in Übereinstimmung mit An­
lage 15 (Anforderung MIG003) unterdrückt wurde.
18) Werkstattkarten der ersten Generation, die in ein Kontroll­
gerät der zweiten Generation eingesteckt werden, gelten als
ungültig.
19) Das Kontrollgerät muss so ausgelegt sein, dass die Fahrten­
schreiberkarten nach dem ordnungsgemäßen Einstecken in
die Kartenschnittstelle einrasten.
▼M3
20) Das Entnehmen der Fahrtenschreiberkarten darf nur bei
stehendem Fahrzeug und nach der Speicherung der jewei­
ligen Daten auf die Karten sowie durch entsprechende Ein­
wirkung des Benutzers möglich sein.
▼B
3.2 Geschwindigkeits-, Positions- und Wegstreckenmessung
21) Der (möglicherweise in den Adapter eingebettete) Bewe­
gungssensor ist die wichtigste Quelle für die Geschwindig­
keits- und Wegstreckenmessung.
22) Diese Funktion muss unter Verwendung der vom Bewe­
gungssensor bereitgestellten Impulse kontinuierlich den Ki­
lometerstand entsprechend der gesamten vom Fahrzeug zu­
rückgelegten Wegstrecke messen und angeben können.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 28
23) Diese Funktion muss unter Verwendung der vom Bewe­
gungssensor bereitgestellten Impulse kontinuierlich die Ge­
schwindigkeit des Fahrzeugs messen und angeben können.
24) Die Geschwindigkeitsmessfunktion liefert auch Informatio­
nen darüber, ob das Fahrzeug fährt oder steht. Das Fahr­
zeug gilt als fahrend, sobald die Funktion vom Bewegungs­
sensor mindestens 5 Sekunden lang mehr als 1 Imp/s erhält;
ansonsten gilt das Fahrzeug als stehend.
25) Geräte zur Anzeige der Geschwindigkeit (Tachometer) und
der zurückgelegten Gesamtwegstrecke (Kilometerzähler),
die in einem mit einem verordnungsgemäßen Kontrollgerät
ausgerüsteten Fahrzeug eingebaut sind, müssen den Vor­
schriften über die in diesem Anhang (siehe 3.2.1 und 3.2.2)
festgelegten zulässigen Fehlergrenzen entsprechen.
▼M3
26) Zur Ermittlung einer etwaigen Manipulation der Bewe­
gungsdaten sind die vom Bewegungssensor stammenden
Informationen durch Daten zur Fahrzeugbewegung zu un­
termauern, die aus dem GNSS-Empfänger oder anderen
vom Bewegungssensor unabhängigen Quellen gewonnen
werden. Mindestens eine weitere unabhängige Fahrzeug­
bewegungsquelle muss sich innerhalb der Fahrzeugeinheit
befinden, ohne dass eine externe Schnittstelle benötigt wird.
27) Diese Funktion misst die Position des Fahrzeugs, um die
Aufzeichnung der
— Positionen, an denen der Fahrer und/oder der Beifahrer
seinen Arbeitstag beginnt,
— Positionen, an denen die kumulierte Lenkzeit ein Viel­
faches von drei Stunden erreicht,
— Positionen, an denen das Fahrzeug die Grenze eines
Landes überschritten hat,
— Positionen, an denen Be-/Entladevorgänge durchgeführt
wurden,
— Positionen, an denen der Fahrer und/oder der Beifahrer
seinen Arbeitstag beendet, zu ermöglichen.
▼B
3.2.1 Messung der zurückgelegten Wegstrecke
28) Die zurückgelegte Wegstrecke kann gemessen werden:
— als Kumulierung der Vorwärts- und der Rückwärtsfahrt
oder
— nur beim Vorwärtsfahren.
29) Das Kontrollgerät misst Wegstrecken von 0 bis 9 999 999,9
km.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 29
30) Die gemessene Wegstrecke muss innerhalb folgender Feh­
lergrenzen liegen (Strecken von mindestens 1 000 m):
— ± 1 % vor dem Einbau,
— ± 2 % beim Einbau und bei den regelmäßigen Nach­
prüfungen,
— ± 4 % während des Betriebs.
▼M3
Die Fehlergrenzen dürfen nicht dazu verwendet werden, die
gemessene Wegstrecke absichtlich zu verändern.
▼B
31) Die Wegstreckenmessung erfolgt auf mindestens 0,1 km
genau.
3.2.2 Geschwindigkeitsmessung
32) Das Kontrollgerät misst die Geschwindigkeit von 0 bis 220
km/h.
▼M3
33) Zur Gewährleistung einer zulässigen Fehlergrenze der ange­
zeigten Geschwindigkeit im Betrieb von ±6 km/h und unter
Berücksichtigung
— einer Fehlergrenze von ±2 km/h für Inputabweichungen
(Reifenabweichungen, …),
— einer Fehlergrenze von ±1 km/h bei Messungen beim
Einbau oder bei den regelmäßigen Nachprüfungen
misst das Kontrollgerät bei Geschwindigkeiten zwischen 20
und 180 km/h und bei Wegdrehzahlen des Fahrzeugs zwi­
schen 2 400 und 25 000 Imp/km die Geschwindigkeit in­
nerhalb einer Fehlergrenze von ±1 km/h (bei konstanter
Geschwindigkeit).
Anmerkung: Aufgrund der Auflösung der Datenspeiche­
rung ergibt sich eine weitere zulässige Fehlergrenze von
±0,5 km/h für die vom Kontrollgerät gespeicherte Ge­
schwindigkeit.
▼B
34) Die Geschwindigkeit muss innerhalb der zulässigen Fehler­
grenzen innerhalb von 2 Sekunden nach Abschluss einer
Geschwindigkeitsänderung korrekt gemessen werden,
wenn sich die Geschwindigkeit mit bis zu 2 m/s 2 geändert
hat.
35) Die Geschwindigkeitsmessung erfolgt auf mindestens 1
km/h genau.
3.2.3 Messung der Position
36) Das Kontrollgerät misst die absolute Position des Fahrzeugs
unter Verwendung des GNSS-Empfängers.
▼M3
37) Die absolute Position wird in geografischen Koordinaten
der Breite und Länge in Grad und Minuten mit einer Auf­
lösung von 1/10 Minute gemessen.
▼B
3.3 Zeitmessung
38) Die Zeitmessfunktion läuft ständig und stellt Datum und
Uhrzeit digital in UTC bereit.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 30
39) Für Datierungsdaten im Kontrollgerät (Aufzeichnungen,
Datenaustausch) und für sämtliche in Anlage 4 „Ausdru­
cke“ aufgeführten Ausdrucke sind durchgängig Datum und
Uhrzeit in UTC zu verwenden.
40) Zur Anzeige der Ortszeit muss es möglich sein, den Versatz
der angezeigten Zeit in Halbstundenschritten zu ändern. Ein
anderer Versatz als negative oder positive Vielfache von
halben Stunden ist nicht zulässig.
▼M3
41) Die Zeitabweichung darf bei fehlender Zeiteinstellung
±1 Sekunde/Tag unter Temperaturbedingungen gemäß
Randnummer 213 betragen.
41a) Die Zeitgenauigkeit muss bei einer Zeiteinstellung durch
eine Werkstatt gemäß Randnummer 212 bei 3 Sekunden
oder weniger liegen.
41b) Die Fahrzeugeinheit muss einen Zeitabweichungszähler
umfassen, der die maximale Zeitabweichung seit der letzten
Einstellung gemäß Nummer 3.23 berechnet. Die maximale
Zeitabweichung ist vom Hersteller der Fahrzeugeinheit fest­
zulegen und darf gemäß Randnummer 41 nicht mehr als
1 Sekunde pro Tag betragen.
41c) Der Zeitabweichungszähler ist nach jeder Zeiteinstellung
des Kontrollgeräts gemäß Nummer 3.23 auf 1 Sekunde zu­
rückzusetzen. Dies umfasst Folgendes:
— automatische Zeiteinstellung,
— Zeiteinstellung im Kalibrierungsmodus.
▼B
42) Die Zeitmessung erfolgt auf mindestens 1 Sekunde genau.
43) Die Zeitmessung darf durch eine Unterbrechung der exter­
nen Stromversorgung von weniger als 12 Monaten unter
Typgenehmigungsbedingungen nicht beeinträchtigt werden.
3.4 Überwachung der Fahrertätigkeiten
44) Diese Funktion überwacht ständig und gesondert die Tätig­
keiten des Fahrers und des Beifahrers.
45) Fahrertätigkeiten sind LENKEN, ARBEIT, BEREIT­
SCHAFT und UNTERBRECHUNG/RUHE.
46) ARBEIT, BEREITSCHAFT sowie UNTERBRECHUNG/
RUHE müssen vom Fahrer und/oder vom Beifahrer manu­
ell ausgewählt werden können.
47) Während der Fahrt wird für den Fahrer automatisch LEN­
KEN und für den Beifahrer automatisch BEREITSCHAFT
ausgewählt.
48) Bei Halt wird für den Fahrer automatisch ARBEIT aus­
gewählt.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 31
49) Bei der ersten Tätigkeitsänderung auf UNTERBRE­
CHUNG/RUHE oder BEREITSCHAFT innerhalb von
120 Sekunden nach dem automatischen Wechsel auf AR­
BEIT infolge des Anhaltens des Fahrzeugs wird davon aus­
gegangen, dass diese zum Zeitpunkt des Anhaltens einge­
treten ist (sodass möglicherweise der Wechsel auf ARBEIT
aufgehoben wird).
▼B
50) Die Ausgabe von Tätigkeitsveränderungen an die Aufzeich­
nungsfunktionen erfolgt auf eine Minute genau.
51) Wird zu irgendeinem Zeitpunkt innerhalb der unmittelbar
der Kalenderminute vorausgehenden und nachfolgenden
Minute die Tätigkeit LENKEN registriert, gilt die gesamte
Minute als LENK-Zeit.
52) Für eine Kalenderminute, die aufgrund der Randnummer
051 nicht als LENK-Zeit gilt, wird die Tätigkeit angesetzt,
die als längste Tätigkeit innerhalb der Minute ausgeführt
wurde (oder bei gleichlangen Tätigkeiten diejenige, die zu­
letzt ausgeführt wurde).
53) Diese Funktion dient auch der ständigen Überwachung der
ununterbrochenen Lenkzeit und der kumulativen Unterbre­
chungszeit des Fahrers.
3.5 Überwachung des Status der Fahrzeugführung
54) Diese Funktion überwacht ständig und automatisch den
Status der Fahrzeugführung.
55) Wenn zwei gültige Fahrerkarten in das Gerät eingesteckt
sind, wird automatisch der Status TEAM gewählt, in allen
anderen Fällen der Status EINMANNBETRIEB.
3.6 Eingaben durch die Fahrer
3.6.1 Eingabe des Orts des Beginns und/oder des Endes des Arbeitstages
56) Diese Funktion ermöglicht dem Fahrer und/oder dem Bei­
fahrer die Eingabe des Ortes, an dem sein jeweiliger Ar­
beitstag beginnt und/oder endet.
▼M3
57) Als Ort gilt ein Land und gegebenenfalls zusätzlich die
entsprechende Region.
58) Bei Entnahme der Fahrerkarte (oder Werkstattkarte) zeigt
das Kontrollgerät den aktuellen Standort des Fahrzeugs auf
der Grundlage der GNSS-Informationen und der gemäß
Nummer 3.12.19 gespeicherten digitalen Karte an und der
Karteninhaber wird vom Kontrollgerät aufgefordert, den Ort
zu bestätigen oder manuell zu berichtigen.
59) Der gemäß Randnummer 58 eingegebene Ort gilt als der
Ort, an dem der aktuelle Arbeitstag endet. Er wird auf der
betreffenden Fahrerkarte (oder Werkstattkarte) als temporä­
rer Datensatz erfasst und kann daher später überschrieben
werden.
Unter den folgenden Bedingungen wird die bei der letzten
Kartenentnahme vorgenommene temporäre Eingabe vali­
diert (und kann somit nicht mehr überschrieben werden):
— Eingabe eines Orts, an dem der aktuelle Arbeitstag be­
ginnt, bei manueller Eingabe gemäß Randnummer 61;
▼M1
02016R0799 — DE — 21.08.2023 — 003.002 — 32
— nächste Eingabe eines Orts, an dem der aktuelle Ar­
beitstag beginnt, wenn der Karteninhaber bei der manu­
ellen Eingabe gemäß Randnummer 61 keinen Ort ein­
gibt, an dem der Arbeitstag beginnt oder endete.
Unter den folgenden Bedingungen wird die bei der letzten
Kartenentnahme vorgenommene temporäre Eingabe über­
schrieben und der neue Wert validiert:
— nächste Eingabe eines Orts, an dem der aktuelle Ar­
beitstag endet, wenn der Karteninhaber bei der manuel­
len Eingabe gemäß Randnummer 61 keinen Ort eingibt,
an dem der Arbeitstag beginnt oder endete.
▼B
60) Die Eingabe des Orts des Beginns und/oder des Endes des
Arbeitstages muss durch Befehle in den Menus möglich
sein. Erfolgt innerhalb einer Kalenderminute mehr als
eine Eingabe, so wird nur die jeweils letzte in dieser Zeit
vorgenommene Eingabe des Orts des Beginns und des En­
des des Arbeitstages aufgezeichnet.
▼M3
Das Kontrollgerät zeigt den aktuellen Standort des Fahr­
zeugs auf der Grundlage der GNSS-Informationen und
der gemäß Nummer 3.12.19 gespeicherten digitalen
Karte(n) an und der Fahrer wird vom Kontrollgerät auf­
gefordert, den Ort zu bestätigen oder manuell zu
berichtigen.
▼B
3.6.2 Manuelle Eingabe der Fahrertätigkeiten und Zustimmung des Fah­
rers für die ITS-Schnittstelle
▼M3
61) Beim Einstecken der Fahrerkarte (oder der Werkstattkarte),
und nur zu diesem Zeitpunkt, lässt das Kontrollgerät ma­
nuelle Eingaben von Tätigkeiten zu. Manuelle Eingaben
von Tätigkeiten werden unter Nutzung der aktuell für die
Fahrzeugeinheit eingestellten Ortszeit- und –datumswerte
(UTC-Versatz) vorgenommen.
Beim Einstecken der Fahrerkarte oder der Werkstattkarte
zeigt das Gerät dem Karteninhaber Folgendes an:
— Datum und Uhrzeit der letzten Kartenentnahme,
— optional: derzeit für die Fahrzeugeinheit eingestellter
Ortszeitversatz.
Beim ersten Einstecken einer bestimmten Fahrerkarte oder
Werkstattkarte, die der Fahrzeugeinheit noch nicht bekannt
ist, wird der Karteninhaber aufgefordert, seine Zustimmung
zur Ausgabe personenbezogener Daten im Zusammenhang
mit dem Fahrtenschreiber über die ITS-Schnittstelle zu er­
teilen. Zur Überprüfung, ob eine Karte bereits eingesteckt
wurde, verwendet das Kontrollgerät die in seinem Massen­
speicher gespeicherten Daten der Fahrtenschreiberkarte ge­
mäß Randnummer 133.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 33
Die Zustimmung des Fahrers (bzw. der Werkstatt) kann
jederzeit durch Menübefehle aktiviert oder deaktiviert wer­
den, sofern die Fahrerkarte (bzw. die Werkstattkarte) einge­
steckt ist.
Es muss möglich sein, Tätigkeiten mit den folgenden Ein­
schränkungen einzugeben:
— Tätigkeitsart ist ARBEIT, BEREITSCHAFT oder UN­
TERBRECHUNG/RUHE,
— Beginn- und Endzeit jeder Tätigkeit liegen ausschließ­
lich in dem Zeitraum zwischen der letzten Entnahme
und dem aktuellen Einstecken der Karte,
— zeitliche Überschneidungen von Tätigkeiten sind nicht
zulässig.
Beim ersten Einstecken einer zuvor unbenutzten Fahrer­
karte (oder Werkstattkarte) sind erforderlichenfalls manuelle
Eingaben möglich.
Das Verfahren für manuelle Eingaben von Tätigkeiten um­
fasst so viele aufeinanderfolgende Schritte, wie notwendig
sind, um für jede Tätigkeit eine Tätigkeitsart sowie eine
Beginn- und Endzeit einzustellen. Der Karteninhaber hat
für jeden Abschnitt des Zeitraums zwischen der letzten Ent­
nahme und dem aktuellen Einstecken der Karte die Option,
keine Tätigkeit anzugeben.
Während der manuellen Eingaben im Rahmen des Karten­
einsteckens hat der Karteninhaber gegebenenfalls die Mög­
lichkeit,
— für die betreffende Zeit einen Ort einzugeben, an dem
ein vorhergehender Arbeitstag endete (wodurch die bei
der letzten Kartenentnahme erfolgte Eingabe überschrie­
ben 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 va­
lidiert wird).
Als den Ort, an dem der aktuelle Arbeitstag beim aktuellen
Einstecken der Karte beginnt, zeigt das Kontrollgerät den
aktuellen Standort des Fahrzeugs auf der Grundlage der
GNSS-Informationen und der gespeicherten digitalen
Karte(n) gemäß Nummer 3.12.19 an und der Fahrer wird
vom Kontrollgerät aufgefordert, den Ort zu bestätigen oder
manuell zu berichtigen.
Gibt der Karteninhaber während der manuellen Eingaben
beim Einstecken der Karte keinen Ort ein, an dem der
Arbeitstag beginnt oder endete, so gilt dies als Erklärung,
dass sein Arbeitstag sich seit der letzten Kartenentnahme
nicht geändert hat. Durch den nächsten Eintrag eines Orts,
an dem ein vorhergehender Arbeitstag endet, wird dann die
temporäre Eingabe bei der letzten Kartenentnahme über­
schrieben.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 34
Bei Eingabe eines Ortes wird dieser auf der entsprechenden
Fahrtenschreiberkarte aufgezeichnet.
Manuelle Eingaben werden in folgenden Fällen
unterbrochen:
— wenn die Karte entnommen wird oder
— wenn das Fahrzeug fährt, während die Karte in den
Kartensteckplatz des Fahrers eingesteckt ist.
Weitere Unterbrechungen, z. B. ein Timeout nach einer
bestimmten Inaktivitätszeit des Nutzers, sind möglich. Im
Falle der Unterbrechung manueller Eingaben validiert das
Kontrollgerät alle bereits vorgenommenen vollständigen
Orts- und Tätigkeitseingaben (mit eindeutiger Angabe von
Ort und Zeit oder Tätigkeitsart, Beginn- und Endzeit).
Wird eine zweite Fahrer- oder Werkstattkarte eingesteckt,
während manuelle Eingaben von Tätigkeiten für eine zuvor
eingesteckte Karte vorgenommen werden, so ist die Fertig­
stellung der manuellen Eingaben für diese vorherige Karte
vor Beginn der manuellen Eingaben für die zweite Karte zu
erlauben.
Der Karteninhaber hat die Option, nach folgendem Mini­
malverfahren manuelle Eingaben vorzunehmen:
— Manuelle Eingabe von Tätigkeiten in zeitlicher Reihen­
folge für den Zeitraum zwischen der letzten Kartenent­
nahme und dem aktuellen Einstecken der Karte.
— Der Zeitpunkt des Beginns der ersten Tätigkeit wird auf
den Zeitpunkt der Kartenentnahme festgelegt. Für jede
nachfolgende Eingabe wird der Zeitpunkt des Beginns
so voreingestellt, dass er unmittelbar auf den Zeitpunkt
des Endes der vorherigen Eingabe folgt. Für jede Tätig­
keit wird die Tätigkeitsart sowie der Zeitpunkt des Be­
ginns und des Endes gewählt.
Das Verfahren endet, wenn der Zeitpunkt des Endes einer
manuell eingegebenen Tätigkeit dem Zeitpunkt des Einste­
ckens der Karte entspricht.
Das Kontrollgerät ermöglicht es Fahrern und Werkstätten,
manuelle Eingaben, die während des Verfahrens einge­
geben werden müssen, im Wechsel über die in Anlage 13
spezifizierte ITS-Schnittstelle und optional über andere
Schnittstellen hochzuladen.
Das Kontrollgerät ermöglicht es dem Karteninhaber, Ände­
rungen an den manuell eingegebenen Tätigkeiten vorzuneh­
men, bis mittels eines speziellen Befehls die Validierung
erfolgt. Danach sind solche Änderungen nicht mehr zuläs­
sig.
▼B
3.6.3 Eingabe spezifischer Bedingungen
▼M3
62) Das Kontrollgerät gestattet dem Fahrer die Eingabe der
folgenden beiden spezifischen Bedingungen in Echtzeit:
— „KONTROLLGERÄT NICHT ERFORDERLICH“
(Anfang, Ende),
— „FÄHRÜBERFAHRT/ZUGFAHRT“ (Anfang, Ende).
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 35
Bei eingeschalteter Bedingung „KONTROLLGERÄT
NICHT ERFORDERLICH“ darf keine „FÄHRÜBER­
FAHRT/ZUGFAHRT“ erfolgen. Wenn die Bedingung
„KONTROLLGERÄT NICHT ERFORDERLICH“ einge­
schaltet ist, darf das Kontrollgerät den Benutzern nicht ge­
statten, einen Merker für den Anfang einer „FÄHRÜBER­
FAHRT/ZUGFAHRT“ einzugeben.
Beim Einstecken oder Entnehmen einer Fahrerkarte muss
die eingeschaltete Bedingung „KONTROLLGERÄT
NICHT ERFORDERLICH“ automatisch ausgeschaltet
werden.
Die eingeschaltete Bedingung „KONTROLLGERÄT
NICHT ERFORDERLICH“ muss die folgenden Ereignisse
und Warnsignale unterbinden:
— Lenken ohne geeignete Karte,
— mit der ununterbrochenen Lenkzeit verbundene Warn­
signale.
Der Fahrer muss den Merker für den Anfang der Bedin­
gung „FÄHRÜBERFAHRT/ZUGFAHRT“ sofort nach der
Auswahl von „UNTERBRECHUNG/RUHE“ auf der
Fähre/im Zug eingeben.
Die eingeschaltete Bedingung „FÄHRÜBERFAHRT/ZUG­
FAHRT“ muss durch das Kontrollgerät beendet werden,
wenn eine der folgenden Optionen gilt:
— der Fahrer beendet die Bedingung „FÄHRÜBER­
FAHRT/ZUGFAHRT“ manuell, was bei der Ankunft
am Zielort der Fähre/des Zugs erfolgen muss, bevor
er von der Fähre/aus dem Zug fährt,
— eine Bedingung „KONTROLLGERÄT NICHT ER­
FORDERLICH“ wird eingeschaltet,
— der Fahrer entnimmt seine Karte,
— die Fahrertätigkeit wird während einer Kalenderminute
gemäß Nummer 3.4 als LENKEN berechnet.
Wird innerhalb einer Kalenderminute mehr als eine spezi­
fische Bedingung derselben Art eingegeben, so ist nur die
letzte zu erfassen.
3.6.4 Eingabe von Be-/Entladevorgängen
62a) Das Kontrollgerät ermöglicht es dem Fahrer, in Echtzeit
Informationen einzugeben und zu bestätigen, die anzeigen,
dass das Fahrzeug gerade beladen, entladen oder gleichzei­
tig beladen/entladen wird.
Wird innerhalb einer Kalenderminute mehr als ein
Be-/Entladevorgang derselben Art eingegeben, so ist nur
der letzte zu erfassen.
62b) Be-/Entladevorgänge oder gleichzeitige Be-/Entladevorgänge
sind als voneinander getrennte Ereignisse zu erfassen.
62c) Die Angaben zur Be-/Entladung sind einzugeben, bevor das
Fahrzeug den Ort verlässt, an dem der Be-/Entladevorgang
durchgeführt wird.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 36
3.7 Unternehmenssperren
63) Diese Funktion ermöglicht die Verwaltung der Sperren, die
ein Unternehmen einsetzt, um den Datenzugang in der Be­
triebsart Unternehmen auf sich selbst zu beschränken.
64) Unternehmenssperren bestehen aus einem Anfangszeitpunkt
(Datum/Uhrzeit) (Sperrung, Lock-in) und einem Endzeit­
punkt (Datum/Uhrzeit) (Entsperrung, Lock-out) im Zusam­
menhang mit der Identifizierung des Unternehmens anhand
der Unternehmenskartennummer (bei der Sperrung).
65) Sperren können nur in Echtzeit ein- oder ausgeschaltet
werden.
66) Das Ausschalten der Sperre kann nur durch das Unterneh­
men (ausgewiesen durch die ersten 13 Stellen der Unter­
nehmenskartennummer) erfolgen, dessen Sperre eingeschal­
tet ist, oder
67) erfolgt automatisch, wenn ein anderes Unternehmen seine
Sperre einschaltet.
68) Aktiviert ein Unternehmen die Sperrung (Lock-in) und die
vorhergehende Sperrung war für dasselbe Unternehmen,
dann wird davon ausgegangen, dass vorher keine Entsper­
rung vorgenommen worden ist und die Sperre noch einge­
schaltet ist.
3.8 Überwachung von Kontrollen
69) Diese Funktion überwacht die Aktivitäten ANZEIGE,
DRUCK, FAHRZEUGEINHEIT sowie HERUNTER­
LADEN von der Karte und STRASSENSEITIGE KALI­
BRIERUNGSÜBERPRÜFUNG in der Betriebsart Kon­
trolle.
70) Diese Funktion überwacht darüber hinaus in der Betriebsart
Kontrolle die KONTROLLE GESCHWINDIGKEITS­
ÜBERSCHREITUNG. Eine Kontrolle Geschwindigkeits­
überschreitung gilt als erfolgt, wenn in der Betriebsart Kon­
trolle der Ausdruck „Geschwindigkeitsüberschreitung“ an
den Drucker oder an die Anzeige gesandt wurde oder
wenn „Ereignis- und Störungsdaten“ aus dem Massenspei­
cher der Fahrzeugeinheit heruntergeladen wurden.
3.9 Feststellung von Ereignissen und/oder Störungen
71) Diese Funktion stellt folgende Ereignisse und/oder Störun­
gen fest:
3.9.1 Ereignis „Einstecken einer ungültigen Karte“
72) Dieses Ereignis wird beim Einstecken einer ungültigen
Karte, beim Einstecken einer bereits ersetzen Fahrerkarte
und/oder beim Ablauf einer eingesteckten gültigen Karte
ausgelöst.
3.9.2 Ereignis „Kartenkonflikt“
73) Dieses Ereignis wird ausgelöst, wenn eine der in der fol­
genden Tabelle mit X gekennzeichneten Kombinationen
von gültigen Karten vorliegt:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 37
Kartenkonflikt
Steckplatz des Fahrers
Keine Karte Fahrerkarte Kontrollkarte Werkstattkarte Unternehmenskarte
S
te
ck
pl
at
z
de
s
B
ei
fa
hr
er
s Keine Karte
Fahrerkarte X
Kontrollkarte X X X
Werkstattkarte X X X X
Unternehmenskarte X X X
3.9.3 Ereignis „Zeitüberlappung“
74) Dieses Ereignis wird ausgelöst, wenn Datum/Uhrzeit der
letzten Entnahme einer Fahrerkarte beim Auslesen der
Karte der aktuellen Datums-/Uhrzeiteinstellung des Kon­
trollgeräts voraus sind.
3.9.4 Ereignis „Lenken ohne geeignete Karte“
75) Dieses Ereignis wird bei einer in der folgenden Tabelle mit
X gekennzeichneten Kombination gültiger Fahrtenschrei­
berkarten ausgelöst, wenn die Fahrertätigkeit auf LENKEN
wechselt oder wenn während der Fahrertätigkeit LENKEN
eine Änderung der Betriebsart erfolgt.
Lenken ohne geeignete Karte
Steckplatz des Fahrers
Keine (oder un­
gültige) Karte
Fahrerkarte Kontrollkarte Werkstattkarte Unternehmenskarte
S
te
ck
pl
at
z
de
s
B
ei
fa
hr
er
s Keine (oder ungül­
tige) Karte
X X X
Fahrerkarte X X X X
Kontrollkarte X X X X X
Werkstattkarte X X X X
Unternehmenskarte X X X X X
3.9.5 Ereignis „Einstecken der Karte während des Lenkens“
76) Dieses Ereignis wird ausgelöst, wenn eine Fahrtenschreiber­
karte während der Fahrertätigkeit LENKEN in einen der
Steckplätze eingesteckt wird.
3.9.6 Ereignis „Letzter Vorgang nicht korrekt abgeschlossen“
77) Dieses Ereignis wird ausgelöst, wenn das Kontrollgerät
beim Einstecken der Karte feststellt, dass trotz der Bestim­
mungen in Nummer 3.1 der vorherige Kartenvorgang nicht
korrekt abgeschlossen wurde (Kartenentnahme, bevor alle
relevanten Daten auf der Karte gespeichert wurden). Dieses
Ereignis wird nur von Fahrer- und Werkstattkarten aus­
gelöst.
3.9.7 Ereignis „Geschwindigkeitsüberschreitung“
78) Dieses Ereignis wird bei jeder Geschwindigkeitsüberschrei­
tung ausgelöst.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 38
3.9.8 Ereignis „Unterbrechung der Stromversorgung“
79) Dieses Ereignis wird, sofern sich das Kontrollgerät nicht in
der Betriebsart Kalibrierung oder Kontrolle befindet, bei
einer 200 Millisekunden überschreitenden Unterbrechung
der Stromversorgung des Bewegungssensors und/oder der
Fahrzeugeinheit ausgelöst. Die Unterbrechungsschwelle
wird vom Hersteller festgelegt. Nicht ausgelöst wird das
Ereignis durch den Stromabfall beim Starten des Fahrzeug­
motors.
3.9.9 Ereignis „Kommunikationsfehler mit der Fernkommunikationsaus­
rüstung“
80) Dieses Ereignis wird, sofern sich das Kontrollgerät nicht in
der Betriebsart Kalibrierung befindet, ausgelöst, wenn
die Fernkommunikationsausrüstung nach mehr als drei Ver­
suchen nicht den erfolgreichen Empfang der von der Fahr­
zeugeinheit übermittelten Fernkommunikationsdaten bestä­
tigt.
3.9.10 Ereignis „Fehlende Positionsdaten des GNSS-Empfängers“
81) Dieses Ereignis wird, sofern sich das Kontrollgerät nicht in
der Betriebsart Kalibrierung befindet, ausgelöst, wenn
während der Fahrt vom (internen oder externen) GNSS-
Empfänger stammende Positionsdaten für mehr als 3 Stun­
den kumulierte Lenkzeit fehlen.
3.9.11 Ereignis „Kommunikationsfehler mit der externen GNSS-Ausrüs­
tung“
82) Dieses Ereignis wird, sofern sich das Kontrollgerät nicht in
der Betriebsart Kalibrierung befindet, ausgelöst, wenn
während der Fahrt die Kommunikation zwischen der exter­
nen GNSS-Ausrüstung und dem Fahrzeug für mehr als 20
Minuten durchgehend unterbrochen ist.
3.9.12 Ereignis „Datenfehler Bewegungssensor“
▼M3
83) Dieses Ereignis wird, sofern sich das Kontrollgerät nicht in
der Betriebsart Kalibrierung befindet, bei einer Unter­
brechung des normalen Datenflusses zwischen dem Bewe­
gungssensor und der Fahrzeugeinheit und/oder bei einem
Datenintegritäts- oder Datenauthentizitätsfehler während
des Datenaustauschs zwischen Bewegungssensor und Fahr­
zeugeinheit ausgelöst. Dieses Ereignis wird, sofern sich das
Kontrollgerät nicht in der Betriebsart Kalibrierung be­
findet, auch dann ausgelöst, wenn sich die vom Bewe­
gungssensor berechnete Geschwindigkeit innerhalb von
1 Sekunde von 0 auf mehr als 40 km/h erhöht und dann
mindestens 3 Sekunden lang über 40 km/h bleibt.
▼B
3.9.13 Ereignis „Datenkonflikt Fahrzeugbewegung“
▼M3
84) Dieses Ereignis wird, sofern sich das Kontrollgerät nicht in
der Betriebsart Kalibrierung befindet, gemäß Anlage 12
ausgelöst, wenn die vom Bewegungssensor berechneten
Bewegungsangaben in Widerspruch zu den vom internen
GNSS-Empfänger oder von der externen GNSS-Ausrüstung
berechneten Bewegungsangaben und optional zu den Be­
wegungsangaben aus anderen unabhängigen Quellen gemäß
Randnummer 26 stehen. Dieses Ereignis wird während ei­
ner Fährüberfahrt/Zugfahrt nicht ausgelöst.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 39
3.9.14 Ereignis „Versuch einer Sicherheitsverletzung“
85) Dieses Ereignis wird, sofern sich das Kontrollgerät nicht in
der Betriebsart Kalibrierung befindet, bei jedem sonstigen
Ereignis ausgelöst, das die Sicherheit des Bewegungssen­
sors und/oder der Fahrzeugeinheit und/oder der externen
GNSS-Ausrüstung gemäß Anlage 10 beeinträchtigt.
▼M1
3.9.15 Ereignis „Zeitkonflikt“
▼M3
86) Dieses Ereignis wird, sofern sich das Kontrollgerät nicht in
der Betriebsart Kalibrierung befindet, ausgelöst, wenn
die Fahrzeugeinheit eine Abweichung zwischen der Zeit
der Zeitmessfunktion der Fahrzeugeinheit und der Zeit fest­
stellt, die aus den vom internen GNSS-Empfänger oder der
externen GNSS-Ausrüstung übertragenen authentisierten
Positionen stammt. Eine „Zeitabweichung“ wird erkannt,
wenn die Zeitdifferenz entsprechend der in Randnum­
mer 41a festgelegten Zeitgenauigkeit ±3 Sekunden über­
schreitet, wobei letzterer Wert um die maximale Zeitabwei­
chung pro Tag erhöht wird. Dieses Ereignis wird gemein­
sam mit dem Wert der Systemuhr der Fahrzeugeinheit auf­
gezeichnet. Die Fahrzeugeinheit führt die Prüfung auf Aus­
lösung des Ereignisses „Zeitkonflikt“ unmittelbar vor dem
Zeitpunkt durch, an dem die Fahrzeugeinheit die Systemuhr
der Fahrzeugeinheit gemäß Randnummer 211 automatisch
neu einstellt.
▼B
3.9.16 Störung „Kartenfehlfunktion“
87) Diese Störung wird ausgelöst, wenn während des Betriebs
eine Fehlfunktion der Fahrtenschreiberkarte auftritt.
3.9.17 Störung „Kontrollgerät“
88) Diese Störung wird bei folgenden Fehlfunktionen ausgelöst,
sofern sich das Kontrollgerät nicht in der Betriebsart Kali­
brierung befindet:
— interne Störung der Fahrzeugeinheit
— Druckerstörung
— Anzeigestörung
— Störung beim Herunterladen
— Sensorstörung
— Störung des GNSS-Empfängers oder der externen
GNSS-Ausrüstung
— Störung der Fernkommunikationsausrüstung
▼M3
— Störung der ITS-Schnittstelle.
3.9.18 Ereignis „GNSS-Anomalie“
88a) Dieses Ereignis wird, sofern sich das Kontrollgerät nicht in
der Betriebsart Kalibrierung befindet, ausgelöst, wenn der
GNSS-Empfänger einen Angriff erkennt oder wenn die Au­
thentisierung von Navigationsnachrichten gemäß Anlage 12
fehlgeschlagen ist. Nachdem ein Ereignis „GNSS-Anoma­
lie“ ausgelöst wurde, erzeugt die Fahrzeugeinheit in den
nächsten 10 Minuten keine weiteren „GNSS-Anomalie“-Er­
eignisse.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 40
3.10 Integrierte Tests und Selbsttests
89) ►M1 Mithilfe der Funktion „Integrierte Tests und Selbst­
tests“ muss das Kontrollgerät zur Störungserkennung an­
hand der folgenden Tabelle in der Lage sein: ◄
Zu testende Unterbaugruppe Selbsttest Integrierter Test
Software Integrität
Massenspeicher Zugang Zugang, Datenintegrität
Kartenschnittstellen Zugang Zugang
Tastatur Manuelle Prüfung
Drucker (dem Hersteller
überlassen)
Ausdruck
Datenanzeige Sichtprüfung
Herunterladen
(nur während des Herunter­
ladens)
Ordnungsgemäßer
Betrieb
Sensor Ordnungsgemäßer
Betrieb
Ordnungsgemäßer Be­
trieb
Fernkommunikationsausrüs­
tung
Ordnungsgemäßer
Betrieb
Ordnungsgemäßer Be­
trieb
GNSS-Ausrüstung Ordnungsgemäßer
Betrieb
Ordnungsgemäßer Be­
trieb
▼M3
ITS-Schnittstelle Ordnungsgemäßer
Betrieb
▼B
3.11 Auslesen von Daten aus dem Massenspeicher
90) Das Kontrollgerät muss sämtliche in seinem Massenspei­
cher gespeicherte Daten auslesen können.
3.12 Aufzeichnung und Speicherung von Daten im Massenspeicher
▼M3
Im Sinne dieser Nummer
— sind „365 Tage“ 365 Kalendertage mit durchschnittlicher Fahrer­
tätigkeit in einem Fahrzeug. Als durchschnittliche Tätigkeit je
Tag in einem Fahrzeug gelten mindestens 6 Fahrer oder Beifah­
rer, 6 Karteneinsteck-/-entnahmevorgänge und 256 Tätigkeits­
wechsel. Somit umfassen „365 Tage“ mindestens 2190 Fahrer/
Beifahrer, 2190 Karteneinsteck-/-entnahmevorgänge und
93 440 Tätigkeitswechsel;
— gelten als durchschnittliche Zahl der Ortseingaben je Tag min­
destens 6 Eingaben von Orten, an denen die tägliche Arbeitszeit
beginnt, und 6 Eingaben von Orten, an denen die tägliche Ar­
beitszeit endet, sodass „365 Tage“ mindestens 4380 Eingaben
umfassen;
— gelten als durchschnittliche Zahl der Positionen pro Tag, an
denen die kumulierte Lenkzeit ein Vielfaches von drei Stunden
erreicht, mindestens 6 Positionen, sodass „365 Tage“ mindestens
2190 solcher Positionen umfassen;
— gelten als durchschnittliche Zahl der Grenzüberschreitungen pro
Tag mindestens 20 Grenzüberschreitungen, sodass „365 Tage“
mindestens 7300 solcher Grenzüberschreitungen umfassen;
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 41
— gelten als durchschnittliche Anzahl der Be-/Entladevorgänge pro
Tag mindestens 25 Vorgänge (unabhängig von der Art), sodass
„365 Tage“ mindestens 9125 solcher Vorgänge umfassen;
— erfolgt die Zeitaufzeichnung auf eine Minute genau, sofern nicht
anders angegeben;
— erfolgt die Aufzeichnung des Kilometerstands auf einen Kilo­
meter genau;
— erfolgt die Geschwindigkeitsaufzeichnung auf 1 km/h genau;
— werden Positionen (Längen- und Breitengrade) in Grad und Mi­
nuten mit einer Auflösung von 1/10 Minute des GNSS auf­
gezeichnet, zusammen mit der jeweiligen GNSS-Genauigkeit
und dem Aufnahmezeitpunkt sowie mit einem Merker, ob die
Position authentisiert wurde.
▼B
91) Die im Massenspeicher gespeicherten Daten dürfen durch
eine Unterbrechung der externen Stromversorgung von we­
niger als 12 Monaten unter Typgenehmigungsbedingungen
nicht beeinträchtigt werden. Darüber hinaus dürfen in der
Fernkommunikationsausrüstung nach Anlage 14 gespei­
cherte Daten nicht durch eine Unterbrechung der Stromver­
sorgung von weniger als 28 Tagen beeinträchtigt werden.
92) Das Kontrollgerät muss in seinem Massenspeicher Folgen­
des implizit oder explizit aufzeichnen und speichern kön­
nen:
3.12.1 Gerätekenndaten
3.12.1.1 K e n n d a t e n d e r F a h r z e u g e i n h e i t
93) Das Kontrollgerät muss in seinem Massenspeicher folgende
Kenndaten der Fahrzeugeinheit speichern können:
— Name des Herstellers,
— Anschrift des Herstellers,
— Teilnummer,
— Seriennummer,
— Generation der Fahrzeugeinheit,
— Fähigkeit zur Verwendung von Fahrtenschreiberkarten
der ersten Generation,
— Softwareversionsnummer,
— Installationsdatum der Softwareversion,
— Herstellungsjahr,
— Typgenehmigungsnummer,
▼M3
— Kennung der digitalen Kartenversion (Randnummer 133l).
94) Die Kenndaten der Fahrzeugeinheit werden von deren Her­
steller aufgezeichnet und dauerhaft gespeichert; eine Aus­
nahme bilden die Daten, die bei einer Aktualisierung der
Software gemäß dieser Verordnung verändert werden dür­
fen, sowie die Fähigkeit zur Verwendung von Fahrten­
schreiberkarten der ersten Generation.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 42
3.12.1.2 K e n n d a t e n d e s B e w e g u n g s s e n s o r s
95) Der Bewegungssensor muss in seinem Speicher folgende
Kenndaten speichern können:
— Name des Herstellers,
— Seriennummer,
— Typgenehmigungsnummer,
— Bezeichner der eingebetteten Sicherheitskomponenten
(z. B. Teilnummer des internen Chips/Prozessors),
— Betriebssystembezeichner (z. B. Softwareversionsnum­
mer).
96) Die Kenndaten des Bewegungssensors werden von dessen
Hersteller aufgezeichnet und dauerhaft gespeichert.
▼M3
97) Die Fahrzeugeinheit muss in ihrem Massenspeicher fol­
gende Daten in Bezug auf die 20 jüngsten erfolgreichen
Koppelungen von Bewegungssensoren speichern können
(erfolgen mehrere Koppelungen binnen eines Kalender­
tages, so sind nur die erste und die letzte Koppelung des
Tages zu speichern):
▼B
Zu den einzelnen Koppelungen sind folgende Daten zu
speichern:
— Kenndaten des Bewegungssensors:
— Seriennummer
— Typgenehmigungsnummer,
— Koppelungsdaten des Bewegungssensors:
— Koppelungsdatum.
3.12.1.3 K e n n d a t e n d e r g l o b a l e n S a t e l l i t e n n a v i g a t i o n s ­
s y s t e m e
98) Die externe GNSS-Ausrüstung muss in ihrem Speicher fol­
gende Kenndaten speichern können:
— Name des Herstellers,
— Seriennummer,
— Typgenehmigungsnummer,
— Bezeichner der eingebetteten Sicherheitskomponenten
(z. B. Teilnummer des internen Chips/Prozessors),
— Betriebssystembezeichner (z. B. Softwareversionsnum­
mer).
99) Die Kenndaten werden vom Hersteller der externen
GNSS-Ausrüstung aufgezeichnet und dauerhaft gespeichert.
▼M3
100) Die Fahrzeugeinheit muss in ihrem Massenspeicher fol­
gende Daten in Bezug auf die 20 jüngsten erfolgreichen
Kopplungen von externen GNSS-Ausrüstungen speichern
können (erfolgen mehrere Kopplungen binnen eines Kalen­
dertages, so sind nur die erste und die letzte Kopplung des
Tages zu speichern).
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 43
Zu den einzelnen Kopplungen sind folgende Daten zu
speichern:
— Kenndaten der externen GNSS-Ausrüstung:
— Seriennummer,
— Typgenehmigungsnummer,
— Kopplungsdaten der externen GNSS-Ausrüstung:
— Kopplungsdatum.
3.12.2 Schlüssel und Zertifikate
101) Das Kontrollgerät muss eine Reihe kryptografischer Schlüs­
sel und Zertifikate gemäß Anlage 11 Teil A und Teil B
speichern können.
3.12.3 Einsteck- und Entnahmedaten der Fahrer- oder der Werkstattkarte
102) Bei jedem Einsteck-/Entnahmevorgang einer Fahrer- oder
Werkstattkarte registriert und speichert das Kontrollgerät
folgende Daten in seinem Massenspeicher:
— Name und Vorname(n) des Karteninhabers in der auf
der Karte gespeicherten Form,
— Kartennummer, ausstellender Mitgliedstaat und Ablauf
der Gültigkeit in der auf der Karte gespeicherten Form,
— die Kartengeneration,
— Datum und Uhrzeit des Einsteckens,
— Kilometerstand beim Einstecken der Karte,
— Steckplatz, in den die Karte eingesteckt wurde,
— Datum und Uhrzeit der Entnahme,
— Kilometerstand bei Kartenentnahme,
— folgende Informationen über das zuvor vom Fahrer be­
nutzte Fahrzeug in der auf der Karte gespeicherten
Form:
— amtliches Kennzeichen und zulassender Mitglied­
staat,
— Generation der Fahrzeugeinheit (sofern verfügbar),
— Datum und Uhrzeit der Kartenentnahme,
— Merker zur Angabe, ob der Karteninhaber beim Einste­
cken Tätigkeiten manuell eingegeben hat oder nicht.
103) Die Speicherdauer dieser Daten im Massenspeicher muss
mindestens 365 Tage betragen können.
104) Ist die Speicherkapazität erschöpft, werden die ältesten Da­
ten durch neue überschrieben.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 44
3.12.4 Fahrertätigkeitsdaten
105) Bei jedem Wechsel der Tätigkeit des Fahrers und/oder Bei­
fahrers und/oder bei jedem Wechsel des Status der Fahr­
zeugführung und/oder bei jedem Einstecken bzw. jeder Ent­
nahme einer Fahrer- oder Werkstattkarte wird im Massen­
speicher des Kontrollgeräts aufgezeichnet und gespeichert:
— der Status der Fahrzeugführung (TEAM, EINMANN­
BETRIEB),
— den Steckplatz (FAHRER, BEIFAHRER),
— der Kartenstatus im jeweiligen Steckplatz (EINGE­
STECKT, NICHT EINGESTECKT),
— die Tätigkeit (LENKEN, BEREITSCHAFT, ARBEIT,
UNTERBRECHUNG/RUHE),
— Datum und Uhrzeit des Wechsels.
EINGESTECKT bedeutet, dass eine gültige Fahrer- oder
Werkstattkarte im Steckplatz eingesteckt ist. NICHT EIN­
GESTECKT bedeutet das Gegenteil, d. h. es ist keine gül­
tige Fahrer- oder Werkstattkarte eingesteckt (z. B. ist eine
Unternehmenskarte oder keine Karte eingesteckt).
Vom Fahrer manuell eingegebene Tätigkeitsdaten werden
im Massenspeicher nicht aufgezeichnet.
106) Die Speicherdauer der Fahrertätigkeitsdaten im Massenspei­
cher muss mindestens 365 Tage betragen können.
107) Ist die Speicherkapazität erschöpft, werden die ältesten Da­
ten durch neue überschrieben.
▼M1
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 Mas­
senspeicher:
— Orte und Positionen, an denen der Fahrer und/oder der
Beifahrer seinen Arbeitstag beginnt,
— Positionen, an denen die kumulierte Lenkzeit ein Viel­
faches von drei Stunden erreicht,
— Orte und Positionen, an denen der Fahrer und/oder der
Beifahrer seinen Arbeitstag beendet.
▼B
109) Wenn die Position des Fahrzeugs zu diesen Zeiten nicht
über den GNSS-Empfänger verfügbar ist, verwendet das
Kontrollgerät die letzte verfügbare Position und das ent­
sprechende Datum und die entsprechende Uhrzeit.
110) Zusammen mit jedem Ort bzw. jeder Position registriert das
Kontrollgerät und speichert in seinem Massenspeicher:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 45
— die Nummer der Fahrerkarte und/oder Beifahrerkarte
und den ausstellenden Mitgliedstaat
▼B
— die Kartengeneration,
— Datum und Uhrzeit der Eingabe,
▼M1
— Art der Eingabe (Beginn, Ende oder kumulierte Lenk­
zeit von 3 Stunden),
▼B
— die damit verbundene GNSS-Genauigkeit, Datum und
Uhrzeit, falls zutreffend,
— Kilometerstand,
▼M3
— Merker, der angibt, ob die Position authentisiert wurde.
110a) Für Orte, an denen die tägliche Arbeitszeit beginnt oder
endet, werden beim manuellen Eingabeverfahren beim Ein­
stecken der Karte gemäß Randnummer 61 der aktuelle Ki­
lometerstand und die aktuelle Position des Fahrzeugs
gespeichert.
▼M1
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.
▼B
112) Ist die Speicherkapazität erschöpft, werden die ältesten Da­
ten durch neue überschrieben.
3.12.6 Kilometerstandsdaten
113) Das Kontrollgerät registriert in seinem Massenspeicher an
jedem Kalendertag um Mitternacht den Kilometerstand des
Fahrzeugs und das dazugehörige Datum.
114) Die Speicherdauer des mitternächtlichen Kilometerstands
im Massenspeicher muss mindestens 365 Tage betragen
können.
115) Ist die Speicherkapazität erschöpft, werden die ältesten Da­
ten durch neue überschrieben.
3.12.7 Detaillierte Geschwindigkeitsdaten
▼M1
116) Das Kontrollgerät registriert und speichert in seinem Mas­
senspeicher zu jeder Sekunde mindestens der letzten
24 Stunden, in denen das Fahrzeug gefahren wurde, die
Momentangeschwindigkeit des Fahrzeugs mit den dazuge­
hörigen Datums- und Uhrzeitangaben.
▼B
3.12.8 Ereignisdaten
Im Sinne dieses Unterabsatzes erfolgt die Zeitspeicherung auf 1
Sekunde genau.
117) Bei jedem festgestellten Ereignis registriert und speichert
das Kontrollgerät die folgenden Daten entsprechend den
nachfolgend aufgeführten Speicherungsvorschriften:
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 46
Ereignis Speicherungsvorschriften Pro Ereignis zu speichernde Daten
Einstecken einer ungülti­
gen Karte
— Die 10 jüngsten Ereignisse. — Datum und Uhrzeit des Ereignisses,
— Kartentyp, Nummer, ausstellender Mit­
gliedstaat und Generation der Karte, die
das Ereignis hervorgerufen hat.
— Anzahl gleichartiger Ereignisse an die­
sem Tag.
Kartenkonflikt — Die 10 jüngsten Ereignisse. — Datum und Uhrzeit des Beginns des Er­
eignisses,
— Datum und Uhrzeit des Endes des Ereig­
nisses,
— Typ der Karte(n), Nummer, ausstellender
Mitgliedstaat und Generation der beiden
Karten, die den Konflikt hervorrufen.
Lenken ohne geeignete
Karte
— Das längste Ereignis an jedem der letz­
ten 10 Tage des Auftretens,
— die 5 längsten Ereignisse in den letzten
365 Tagen.
— Datum und Uhrzeit des Beginns des Er­
eignisses,
— Datum und Uhrzeit des Endes des Ereig­
nisses,
— Kartentyp, Nummer, ausstellender Mit­
gliedstaat und Generation jeder zu Be­
ginn und/oder Ende des Ereignisses ein­
gesteckten Karte,
— Anzahl gleichartiger Ereignisse an die­
sem Tag.
Einstecken der Karte wäh­
rend des Lenkens
— Das letzte Ereignis an jedem der letzten
10 Tage des Auftretens,
— Datum und Uhrzeit des Ereignisses,
— Typ der Karte(n), Nummer, ausstellender
Mitgliedstaat und Generation,
— Anzahl gleichartiger Ereignisse an die­
sem Tag.
▼M3
Letzter Vorgang nicht
korrekt abgeschlossen
— Die 10 jüngsten Ereignisse. — Datum und Uhrzeit des Einsteckens der
Karte,
— Typ der Karte(n), Nummer, ausstellender
Mitgliedstaat und Generation,
— Daten des letzten Vorgangs beim Aus­
lesen der Karte:
— Datum und Uhrzeit des Einsteckens der
Karte.
▼B
Geschwindigkeitsüber­
schreitung (1)
— Das schwerwiegendste Ereignis an je­
dem der letzten 10 Tage des Auftretens
(d. h. das Ereignis mit der höchsten
Durchschnittsgeschwindigkeit),
— die 5 schwerwiegendsten Ereignisse in
den letzten 365 Tagen
— das erste Ereignis oder die erste Stö­
rung nach der letzten Kalibrierung
— Datum und Uhrzeit des Beginns des Er­
eignisses,
— Datum und Uhrzeit des Endes des Ereig­
nisses,
— die während des Ereignisses gemessene
Höchstgeschwindigkeit,
— die während des Ereignis gemessene
arithmetische Durchschnittsgeschwindig­
keit,
— Typ der Karte, Nummer, ausstellender
Mitgliedstaat und Generation der Fahrer­
karte (falls zutreffend),
— Anzahl gleichartiger Ereignisse an die­
sem Tag.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 47
Ereignis Speicherungsvorschriften Pro Ereignis zu speichernde Daten
Unterbrechung der Strom­
versorgung (2)
— Das längste Ereignis an jedem der letz­
ten 10 Tage des Auftretens,
— die 5 längsten Ereignisse in den letzten
365 Tagen.
— Datum und Uhrzeit des Beginns des Er­
eignisses,
— Datum und Uhrzeit des Endes des Ereig­
nisses,
— Typ der Karte(n), Nummer, ausstellender
Mitgliedstaat und Generation jeder zu
Beginn und/oder Ende des Ereignisses
eingesteckten Karte,
— Anzahl gleichartiger Ereignisse an die­
sem Tag.
Kommunikationsfehler
mit der Fernkommunikati­
onsausrüstung
— Das längste Ereignis an jedem der letz­
ten 10 Tage des Auftretens,
— die 5 längsten Ereignisse in den letzten
365 Tagen.
— Datum und Uhrzeit des Beginns des Er­
eignisses,
— Datum und Uhrzeit des Endes des Ereig­
nisses,
— Typ der Karte(n), Nummer, ausstellender
Mitgliedstaat und Generation jeder zu
Beginn und/oder Ende des Ereignisses
eingesteckten Karte,
— Anzahl gleichartiger Ereignisse an die­
sem Tag.
Fehlende Positionsdaten
des GNSS-Empfängers
— Das längste Ereignis an jedem der letz­
ten 10 Tage des Auftretens,
— die 5 längsten Ereignisse in den letzten
365 Tagen.
— Datum und Uhrzeit des Beginns des Er­
eignisses,
— Datum und Uhrzeit des Endes des Ereig­
nisses,
— Typ der Karte(n), Nummer, ausstellender
Mitgliedstaat und Generation jeder zu
Beginn und/oder Ende des Ereignisses
eingesteckten Karte,
— Anzahl gleichartiger Ereignisse an die­
sem Tag.
▼M1
Ereignis „Kommunikati­
onsfehler mit der externen
GNSS-Ausrüstung“
— das längste Ereignis an jedem der letz­
ten 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 Mitglied­
staat und Generation jeder zu Beginn
und/oder Ende des Ereignisses einge­
steckten Karte,
— Anzahl ähnlicher Ereignisse an diesem
Tag.
▼B
Datenfehler Weg und Ge­
schwindigkeit
— Das längste Ereignis an jedem der letz­
ten 10 Tage des Auftretens,
— die 5 längsten Ereignisse in den letzten
365 Tagen.
— Datum und Uhrzeit des Beginns des Er­
eignisses,
— Datum und Uhrzeit des Endes des Ereig­
nisses,
— Typ der Karte(n), Nummer, ausstellender
Mitgliedstaat und Generation jeder zu
Beginn und/oder Ende des Ereignisses
eingesteckten Karte,
— Anzahl gleichartiger Ereignisse an die­
sem Tag.
Datenkonflikt Fahrzeug­
bewegung
— Das längste Ereignis an jedem der letz­
ten 10 Tage des Auftretens,
— die 5 längsten Ereignisse in den letzten
365 Tagen.
— Datum und Uhrzeit des Beginns des Er­
eignisses,
— Datum und Uhrzeit des Endes des Ereig­
nisses,
— Typ der Karte(n), Nummer, ausstellender
Mitgliedstaat und Generation jeder zu
Beginn und/oder Ende des Ereignisses
eingesteckten Karte,
— Anzahl gleichartiger Ereignisse an die­
sem Tag.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 48
Ereignis Speicherungsvorschriften Pro Ereignis zu speichernde Daten
Versuch einer Sicherheits­
verletzung
— Die 10 jüngsten Ereignisse je Ereignis­
art,
— Datum und Uhrzeit des Beginns des Er­
eignisses,
— Datum und Uhrzeit des Endes des Ereig­
nisses(sofern relevant),
— Typ der Karte(n), Nummer, ausstellender
Mitgliedstaat und Generation jeder zu
Beginn und/oder Ende des Ereignisses
eingesteckten Karte,
— Art des Ereignisses.
▼M1
Zeitkonflikt — das schwerwiegendste Ereignis an je­
dem der letzten 10 Tage des Auftretens
(d. h. die Ereignisse mit dem größten
Unterschied zwischen Datum und Uhr­
zeit des Kontrollgeräts und GNSS-Da­
tum und -Uhrzeit),
— die 5 schwerwiegendsten Ereignisse in
den letzten 365 Tagen.
— Datum und Uhrzeit Kontrollgerät,
— GNSS-Datum und -Uhrzeit,
— Typ, Nummer, ausstellender Mitglied­
staat und Generation jeder zu Beginn
und/oder Ende des Ereignisses einge­
steckten Karte,
— Anzahl ähnlicher Ereignisse an diesem
Tag.
▼M3
GNSS-Anomalie — die längsten Ereignisse an jedem der
letzten 10 Tage des Auftretens,
— die 5 längsten Ereignisse in den letzten
365 Tagen.
— Datum und Uhrzeit des Beginns des Er­
eignisses,
— Datum und Uhrzeit des Endes des Ereig­
nisses,
— Typ der Karte(n), Nummer, ausstellender
Mitgliedstaat und Generation jeder zu
Beginn und/oder Ende des Ereignisses
eingesteckten Karte,
— Anzahl gleichartiger Ereignisse an die­
sem Tag.
▼B
(1) Im Massenspeicher des Kontrollgeräts sind darüber hi­
naus folgende Daten aufzuzeichnen und zu speichern:
— Datum und Uhrzeit der letzten KONTROLLE GE­
SCHWINDIGKEITSÜBERSCHREITUNG,
— Datum und Uhrzeit der ersten Geschwindigkeits­
überschreitung nach dieser KONTROLLE GE­
SCHWINDIGKEITSÜBERSCHREITUNG,
— Anzahl der Ereignisse Geschwindigkeitsüberschrei­
tung seit der letzten KONTROLLE GESCHWIN­
DIGKEITSÜBERSCHREITUNG.
(2) Diese Daten können erst nach Wiederherstellung der
Stromversorgung aufgezeichnet werden, wobei die Ge­
nauigkeit hier eine Minute betragen kann.
3.12.9 Störungsdaten
Im Sinne dieses Unterabsatzes erfolgt die Zeitaufzeichnung auf 1
Sekunde genau.
118) Bei jeder festgestellten Störung muss das Kontrollgerät ver­
suchen, die folgenden Daten entsprechend den nachfolgend
aufgeführten Speicherungsvorschriften aufzuzeichnen und
zu speichern:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 49
Störung Speicherungsvorschriften Je Störung aufzuzeichnende Daten
Kartenfehlfunktion — Die 10 jüngsten Fahrerkartenfehlfunk­
tionen.
— Datum und Uhrzeit des Beginns der
Störung,
— Datum und Uhrzeit des Endes der Stö­
rung,
— Typ der Karte (n), Nummer, ausstellen­
der Mitgliedstaat und Generation.
Störungen Kontrollgerät — Die 10 jüngsten Störungen jeder Stö­
rungsart,
— die erste Störung nach der letzten Ka­
librierung.
— Datum und Uhrzeit des Beginns der
Störung,
— Datum und Uhrzeit des Endes der Stö­
rung,
— Art der Störung,
— Typ der Karte(n), Nummer und ausstel­
lender Mitgliedstaat und Generation je­
der zu Beginn und/oder Ende der Stö­
rung eingesteckten Karte.
3.12.10 Kalibrierungsdaten
119) Im Massenspeicher des Kontrollgeräts sind Daten auf­
zuzeichnen und zu speichern, die folgendes betreffen:
— bekannte Kalibrierungsparameter zum Zeitpunkt der
Aktivierung,
— seine erste Kalibrierung nach der Aktivierung,
— seine erste Kalibrierung im derzeitigen Fahrzeug (iden­
tifiziert anhand von dessen Fahrzeug-Identifizierungs­
nummer),
— die 20 jüngsten Kalibrierungen (erfolgen an einem Ka­
lendertag mehrere Kalibrierungen, sind nur die erste
und die letzte des Tages zu speichern).
120) Zu den einzelnen Kalibrierungen sind folgende Daten zu
speichern:
— Zweck der Kalibrierung (Aktivierung, Ersteinbau, Ein­
bau, regelmäßige Nachprüfung),
— Name und Anschrift der Werkstatt,
— Werkstattkartennummer, ausstellender Mitgliedstaat und
Ablauf der Gültigkeit der Karte,
— Fahrzeugkennung,
— aktualisierte oder bestätigte Parameter: Wegdrehzahl
(w), Kontrollgerätkonstante (k), tatsächlicher Reifen­
umfang (l), Reifengröße, Einstellung des Geschwindig­
keitsbegrenzers, Kilometerstand (alt und neu), Datum
und Uhrzeit (alte und neue Werte),
— Typ und Kennung aller vorhandenen Plombierungen ,
▼M3
— Seriennummern des Bewegungssensors, der externen
GNSS-Ausrüstung (soweit vorhanden) und der externen
Ausrüstung zur Fernkommunikation (soweit vorhan­
den),
— die dem Fahrzeug zugeordnete standardmäßige Art der
Ladung (Güter oder Personen),
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 50
— das Land, in dem die Kalibrierung durchgeführt wurde,
und das Datum, an dem die Position, die zur Bestim­
mung dieses Landes verwendet wurde, vom GNSS-
Empfänger bereitgestellt wurde.
▼B
121) Zusätzlich ist im Massenspeicher des Kontrollgeräts seine
Fähigkeit zur Verwendung von Fahrtenschreiberkarten der
ersten Generation (noch aktiviert oder nicht) aufzuzeichnen
und zu speichern.
122) Im Speicher des Bewegungssensors sind folgende Einbau­
daten aufzuzeichnen und zu speichern:
— erste Koppelung mit einer Fahrzeugeinheit (Datum,
Uhrzeit, VU-Typgenehmigungsnummer, VU-Serien­
nummer),
— letzte Koppelung mit einer Fahrzeugeinheit (Datum,
Uhrzeit, VU-Typgenehmigungsnummer, VU-Serien­
nummer).
123) Im Speicher der externen GNSS-Ausrüstung sind folgende
Einbaudaten aufzuzeichnen und zu speichern:
— erste Kopplung mit einer Fahrzeugeinheit (Datum, Uhr­
zeit, VU-Typgenehmigungsnummer, VU-Seriennum­
mer),
— letzte Kopplung mit einer Fahrzeugeinheit (Datum, Uhr­
zeit, VU-Typgenehmigungsnummer, VU-Seriennum­
mer).
3.12.11 Zeiteinstellungsdaten
124) Im Massenspeicher des Kontrollgeräts sind Daten zu Zeit­
einstellungen, die in der Betriebsart Kalibrierung außerhalb
einer normalen Kalibrierung (Begriffsbestimmung f) vor­
genommen werden, aufzuzeichnen und zu speichern:
— die jüngste Zeiteinstellung,
— die 5 größten Zeiteinstellungen.
125) Zu den einzelnen Zeiteinstellungen sind folgende Daten zu
speichern:
— Datum und Uhrzeit, alter Wert,
— Datum und Uhrzeit, neuer Wert,
— Name und Anschrift der Werkstatt,
— Werkstattkartennummer, ausstellender Mitgliedstaat,
Kartengeneration und Ablauf der Gültigkeit der Karte.
3.12.12 Kontrolltätigkeitsdaten
126) Im Massenspeicher des Kontrollgeräts sind folgende Daten
in Bezug auf die 20 jüngsten Kontrolltätigkeiten auf­
zuzeichnen und zu speichern:
— Datum und Uhrzeit der Kontrolle,
— Kontrollkartennummer, ausstellender Mitgliedstaat und
Kartengeneration,
— Art der Kontrolle (Anzeige und/oder Drucken und/oder
Herunterladen von der Fahrzeugeinheit und/oder Herun­
terladen von der Karte und/oder straßenseitige Kalibrie­
rungsüberprüfung).
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 51
127) Beim Herunterladen sind zudem die ältesten und die jüngs­
ten heruntergeladenen Tage aufzuzeichnen.
3.12.13 Unternehmenssperrdaten
128) Im Massenspeicher des Kontrollgeräts sind folgende Daten
in Bezug auf die 255 jüngsten Unternehmenssperren auf­
zuzeichnen und zu speichern:
— Sperrung (/Lock-in) — Datum und Uhrzeit,
— Entsperrung (/Lock-out) — Datum und Uhrzeit,
— Unternehmenskartennummer, ausstellender Mitglied­
staat und Kartengeneration,
— Name und Anschrift des Unternehmens.
Daten, die zuvor durch eine Sperre gesperrt waren, die
aufgrund obiger Begrenzung aufgehoben wurde, werden
als nicht gesperrt behandelt.
3.12.14 Erfassen des Herunterladens
129) Im Massenspeicher des Kontrollgeräts sind in Bezug auf
das letzte Herunterladen vom Massenspeicher auf externe
Datenträger in den Betriebsarten Unternehmen oder Kali­
brierung folgende Daten aufzuzeichnen und zu speichern:
— Datum und Uhrzeit des Herunterladens,
— Unternehmens- oder Werkstattkartennummer, ausstel­
lender Mitgliedstaat und Kartengeneration,
— Name des Unternehmens oder der Werkstatt.
3.12.15 Daten zu spezifischen Bedingungen
130) Im Massenspeicher des Kontrollgeräts sind folgende Daten
in Bezug auf spezifische Bedingungen aufzuzeichnen:
— Datum und Uhrzeit der Eingabe,
— Art der spezifischen Bedingung.
131) Die Speicherdauer der Daten zu spezifischen Bedingungen
im Massenspeicher muss mindestens 365 Tage betragen
können (unter der Annahme, dass pro Tag 1 Bedingung
ein- und ausgeschaltet wird). Ist die Speicherkapazität er­
schöpft, werden die ältesten Daten durch neue überschrie­
ben.
3.12.16 Daten der Fahrtenschreiberkarte
132) Das Kontrollgerät muss die folgenden Daten in Bezug auf
die verschiedenen in der Fahrzeugeinheit verwendeten
Fahrtenschreiberkarten speichern können:
— Nummer und Seriennummer der Fahrtenschreiberkarte,
— Hersteller der Fahrtenschreiberkarte,
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 52
— Art der Fahrtenschreiberkarte,
— Version der Fahrtenschreiberkarte.
133) Das Kontrollgerät muss mindestens 88 derartige Datensätze
speichern können.
▼M3
3.12.17 Grenzüberschreitungen
133a) Das Kontrollgerät zeichnet die folgenden Informationen
über Grenzüberschreitungen auf und speichert sie in seinem
Massenspeicher:
— Land, das das Fahrzeug verlässt,
— Land, in das das Fahrzeug einfährt,
— Position, an der das Fahrzeug die Grenze eines Landes
überschreitet.
133b) Zusammen mit den Ländern und der Position zeichnet das
Kontrollgerät die folgenden Informationen auf und spei­
chert sie in seinem Massenspeicher:
— Nummer der Fahrerkarte und/oder Beifahrerkarte und
den ausstellenden Mitgliedstaat,
— Kartengeneration,
— die damit verbundene GNSS-Genauigkeit, Datum und
Uhrzeit,
— Merker, der angibt, ob die Position authentisiert wurde,
— Kilometerstand des Fahrzeugs zum Zeitpunkt der Fest­
stellung der Grenzüberschreitung.
133c) Die Speicherdauer der Grenzüberschreitungen im Massen­
speicher muss mindestens 365 Tage betragen können.
133d) Ist die Speicherkapazität erschöpft, werden die ältesten Da­
ten durch neue überschrieben.
3.12.18 Be-/Entladevorgänge
133e) Das Kontrollgerät zeichnet die folgenden Informationen
über Be- und Entladevorgänge des Fahrzeugs auf und spei­
chert sie in seinem Massenspeicher:
— Art des Vorgangs (Beladen, Entladen oder gleichzeiti­
ges Be- und Entladen),
— Position, an der der Be-/Entladevorgang stattgefunden
hat.
133f) Ist die Position des Fahrzeugs zum Zeitpunkt des
Be-/Entladevorgangs nicht vom GNSS-Empfänger verfüg­
bar, so verwendet das Kontrollgerät die letzte verfügbare
Position und das zugehörige Datum sowie die entspre­
chende Uhrzeit.
133g) Zusammen mit der Art des Vorgangs und der Position
zeichnet das Kontrollgerät folgende Informationen auf und
speichert sie in seinem Massenspeicher:
— Nummer der Fahrerkarte und/oder Beifahrerkarte und
den ausstellenden Mitgliedstaat,
— Kartengeneration,
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 53
— Datum und Uhrzeit der Be-/Entladevorgangs,
— die damit verbundene GNSS-Genauigkeit, Datum und
Uhrzeit, falls zutreffend,
— Merker, der angibt, ob die Position authentisiert wurde,
— Kilometerstand.
133h) Die Speicherdauer der Be-/Entladevorgänge im Massenspei­
cher muss mindestens 365 Tage betragen können.
133i) Ist die Speicherkapazität erschöpft, werden die ältesten Da­
ten durch neue überschrieben.
3.12.19 Digitale Karte
133j) Zur Aufzeichnung der Position des Fahrzeugs zum Zeit­
punkt der Überschreitung der Grenze eines Landes spei­
chert das Kontrollgerät eine digitale Karte in seinem Mas­
senspeicher.
133k) Zulässige digitale Karten zur Unterstützung der Über­
wachung von Grenzüberschreitungen durch das Kontroll­
gerät werden von der Europäischen Kommission in ver­
schiedenen Formaten zum Herunterladen von einer eigens
dafür eingerichteten gesicherten Website zur Verfügung
gestellt.
133l) Für jede dieser Karten sind eine Versionskennung und ein
Hashwert auf der Website verfügbar.
133m) Die Karte hat folgende Merkmale:
— eine Definitionsebene, die der NUTS-Ebene 0 gemäß
der Systematik der Gebietseinheiten für die Statistik
entspricht,
— einen Maßstab 1:1 Million.
133n) Die Fahrtenschreiberhersteller wählen eine Karte auf der
Website aus und laden sie sicher herunter.
133o) Die Fahrtenschreiberhersteller verwenden eine von der
Website heruntergeladene Karte erst, nachdem sie ihre In­
tegrität unter Verwendung des Hashwerts der Karte über­
prüft haben.
133p) Die ausgewählte Karte wird vom Hersteller in einem geeig­
neten Format in das Kontrollgerät importiert, wobei jedoch
die Semantik der importierten Karte unverändert bleibt.
133q) Der Hersteller speichert auch die Versionskennung der
Karte, die im Kontrollgerät verwendet wird.
133r) Es muss möglich sein, die gespeicherte digitale Karte durch
eine neue, von der Europäischen Kommission zur Ver­
fügung gestellte Karte zu aktualisieren oder zu ersetzen.
133s) Aktualisierungen digitaler Karten werden mithilfe der vom
Hersteller gemäß den Randnummern 226d und 226e einge­
richteten Mechanismen zur Softwareaktualisierung vor­
genommen, damit das Kontrollgerät die Authentizität und
Integrität einer neuen importierten Karte überprüfen kann,
bevor sie gespeichert wird und die vorherige Karte ersetzt.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 54
133t) Die Fahrtenschreiberhersteller können der Basiskarte gemäß
Randnummer 133m für andere Zwecke als die Aufzeich­
nung von Grenzüberschreitungen, z. B. die Grenzen der
EU-Regionen, zusätzliche Informationen hinzufügen, sofern
die Semantik der Basiskarte nicht geändert wird.
▼B
3.13 Auslesen von Daten aus Fahrtenschreiberkarten
134) Das Kontrollgerät muss aus Fahrtenschreiberkarten der ers­
ten und der zweiten Generation die erforderlichen Daten
— zur Identifizierung der Kartenart, des Karteninhabers,
des zuvor genutzten Fahrzeugs, des Datums und der
Uhrzeit der letzten Kartenentnahme und der zu jenem
Zeitpunkt gewählten Tätigkeit,
— zur Kontrolle des korrekten Abschlusses des letzten
Kartenvorgangs,
▼M3
— zur Berechnung der ununterbrochenen Lenkzeit, der ku­
mulativen Unterbrechungszeit und der kumulierten
Lenkzeit für die vorangegangene und für die laufende
Woche,
▼B
— zur Anfertigung von Ausdrucken von auf einer Fahrer­
karte aufgezeichneten Daten,
— zum Herunterladen einer Fahrerkarte auf externe Daten­
träger auslesen können.
Diese Anforderung gilt für Fahrtenschreiberkarten der ers­
ten Generation nur, wenn ihre Verwendung nicht von einer
Werkstatt unterdrückt wurde.
135) Bei einem Lesefehler verwendet das Kontrollgerät maximal
dreimal erneut den gleichen Lesebefehl. Schlagen alle Ver­
suche fehl, wird die Karte für fehlerhaft und ungültig er­
klärt.
▼M3
135a) Die Struktur in der „TACHO_G2“-Anwendung hängt von
der Version ab. Karten der Version 2 enthalten weitere
Elementardateien (Elementary Files, EF) zusätzlich zu de­
nen in Karten der Version 1, insbesondere:
— in Fahrer- und Werkstattkarten:
— Die EF Places_Authentication muss den Authenti­
sierungsstatus der in der EF Places gespeicherten
Fahrzeugpositionen enthalten. Mit jedem Authenti­
sierungsstatus wird ein Zeitstempel gespeichert, der
genau dem Datum und der Uhrzeit des Eintrags ent­
spricht, der zusammen mit der entsprechenden Po­
sition in der EF Places gespeichert ist.
— Die EF GNSS_Places_Authentication muss den Au­
thentisierungsstatus der in der EF GNSS_Places ge­
speicherten Fahrzeugpositionen enthalten. Mit jedem
Authentisierungsstatus wird ein Zeitstempel gespei­
chert, der genau dem Datum und der Uhrzeit des
Eintrags entspricht, der zusammen mit der entspre­
chenden Position in der EF Places gespeichert ist.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 55
— Die EF Border_Crossings, EF Load_Unload_Opera­
tions und EF Load_Type_Entries müssen Daten zu
Grenzüberschreitungen, Be-/Entladevorgängen und
Ladungsarten enthalten.
— in Werkstattkarten:
— Die EF Calibration_Add_Data muss Kalibrierungs­
daten zusätzlich den in EF Calibration gespeicherten
Daten enthalten. Das alte Datum und der alte Zeit­
wert sowie die Fahrzeugidentifizierungsnummer
müssen mit jedem zusätzlichen Kalibrierungsdaten­
satz gespeichert werden und müssen genau dem al­
ten Datum und dem alten Zeitwert sowie der Fahr­
zeugidentifizierungsnummer entsprechen, die mit
den entsprechenden Kalibrierungsdaten in EF Cali­
bration gespeichert sind.
— in allen Fahrtenschreiberkarten:
— Die EF VU_Configuration muss die spezifischen
Einstellungen des Fahrtenschreibers des Karteninha­
bers enthalten.
Die Fahrzeugeinheit ignoriert jeden Authentisierungsstatus
in der EF Places_Authentication oder der EF GNSS_Pla­
ces_Authentication, wenn keine Fahrzeugposition mit dem­
selben Zeitstempel in der EF Places oder der EF
GNSS_Places zu finden ist.
Die Fahrzeugeinheit ignoriert die Elementardatei EF
VU_Configuration in allen Karten, sofern für die Verwen­
dung dieser Elementardatei keine spezifischen Regeln fest­
gelegt wurden. Solche Regeln werden durch eine Änderung
von Anhang IC festgelegt, was auch die Änderung oder
Streichung dieser Randnummer beinhaltet.
▼B
3.14 Aufzeichnung und Speicherung von Daten auf Fahrtenschreiber­
karten
3.14.1 Aufzeichnung und Speicherung von Daten auf Fahrtenschreiberkar­
ten der ersten Generation
136) Sofern die Verwendung von Fahrtenschreiberkarten der ers­
ten Generation nicht von einer Werkstatt unterdrückt
wurde, registriert und speichert das Kontrollgerät Daten in
genau der gleichen Weise wie ein Kontrollgerät der ersten
Generation.
137) Sofort nach dem Einstecken der Karte stellt das Kontroll­
gerät die „Kartenvorgangsdaten“ auf der Fahrer- oder
Werkstattkarte ein.
138) Das Kontrollgerät aktualisiert die auf gültigen Fahrer-,
Werkstatt-, Unternehmens- und/oder Kontrollkarten gespei­
cherten Daten mit sämtlichen erforderlichen Daten, die für
den Karteninhaber und für den Zeitraum, in dem die Karte
eingesteckt ist, relevant sind. Die auf diesen Karten gespei­
cherten Daten sind in Kapitel 4 spezifiziert.
139) Das Kontrollgerät aktualisiert die auf gültigen Fahrer- und
Werkstattkarten gespeicherten Fahrertätigkeits- und Orts­
daten (gemäß den Kapiteln 4.5.3.1.9 und 4.5.3.1.11) mit
Tätigkeits- und Ortsdaten, die vom Karteninhaber manuell
eingegeben werden.
▼M3
140) Alle Ereignisse und Störungen, die für Kontrollgeräte der
ersten Generation nicht definiert sind, werden nicht auf
Fahrer- und Werkstattkarten der ersten Generation
gespeichert.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 56
141) Die Aktualisierung der Fahrtenschreiberkarten erfolgt so,
dass bei Bedarf und unter Berücksichtigung der Speicher­
kapazität der Karte die jeweils ältesten Daten durch die
jüngsten Daten ersetzt werden.
142) Bei einem Schreibfehler verwendet das Kontrollgerät maxi­
mal dreimal erneut den gleichen Schreibbefehl. Schlagen
alle Versuche fehl, wird die Karte für fehlerhaft und ungül­
tig erklärt.
▼M3
143) Vor der Entnahme einer Fahrer- oder Werkstattkarte und
nach Speicherung aller relevanten Daten auf der Karte setzt
das Kontrollgerät alle „Kartenvorgangsdaten“ zurück.
▼B
3.14.2 Aufzeichnung und Speicherung von Daten auf Fahrtenschreiberkar­
ten der zweiten Generation
144) Fahrtenschreiberkarten der zweiten Generation enthalten 2
verschiedene Kartenanwendungen; bei der ersten handelt es
sich um genau dieselbe Anwendung wie die TACHO-An­
wendung für Fahrtenschreiberkarten der ersten Generation,
bei der zweiten um die „TACHO_G2“-Anwendung, gemäß
Kapitel 4 und Anlage 2.
▼M3
Die Struktur in der „TACHO_G2“-Anwendung hängt von
der Version ab. Karten der Version 2 enthalten weitere
Elementardateien (EF) zusätzlich zu denen in Karten der
Version 1.
▼B
145) Sofort nach dem Einstecken der Karte stellt das Kontroll­
gerät die „Kartenvorgangsdaten“ auf der Fahrer- oder
Werkstattkarte ein.
146) Das Kontrollgerät aktualisiert die auf den beiden Karten­
anwendungen gültiger Fahrer-, Werkstatt-, Unternehmens-
und/oder Kontrollkarten gespeicherten Daten mit sämtlichen
erforderlichen Daten, die für den Karteninhaber und für den
Zeitraum, in dem die Karte eingesteckt ist, relevant sind.
Die auf diesen Karten gespeicherten Daten sind in Kapitel 4
spezifiziert.
147) Das Kontrollgerät aktualisiert die auf gültigen Fahrer- und
Werkstattkarten gespeicherten Fahrertätigkeits-, Orts- und
Positionsdaten (gemäß den Kapiteln 4.5.3.1.9, 4.5.3.1.11,
4.5.3.2.9 und 4.5.3.2.11) mit Tätigkeits- und Ortsdaten,
die vom Karteninhaber manuell eingegeben werden.
▼M3
147a) Beim Einstecken einer Fahrer- oder Werkstattkarte spei­
chert das Kontrollgerät die standardmäßige Art der Ladung
des Fahrzeugs auf der Karte.
147b) Beim Einstecken einer Fahrer- oder Werkstattkarte und
nach der manuellen Eingabe überprüft das Kontrollgerät
den letzten auf der Karte gespeicherten Ort, an dem der
aktuelle Arbeitstag beginnt oder endet. Dabei kann es
sich um einen temporären Ort gemäß Randnummer 59 han­
deln. Befindet sich dieser Ort in einem anderen Land als
dem, in dem sich das Fahrzeug derzeit befindet, so spei­
chert das Kontrollgerät auf der Karte einen Grenzüber­
schreitungsdatensatz mit folgenden Angaben:
— Land, das der Fahrer verlassen hat: nicht verfügbar,
— Land, in das der Fahrer einfährt: das Land, in dem sich
das Fahrzeug aktuell befindet;
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 57
— Datum und Uhrzeit der Grenzüberschreitung des Fah­
rers: die Einsteckzeit der Karte,
— Position des Fahrers zum Zeitpunkt der Überschreitung
der Grenze: nicht verfügbar,
— Kilometerstand: nicht verfügbar.
▼B
148) Die Aktualisierung der Fahrtenschreiberkarten erfolgt so,
dass bei Bedarf und unter Berücksichtigung der Speicher­
kapazität der Karte die jeweils ältesten Daten durch die
jüngsten Daten ersetzt werden.
149) Bei einem Schreibfehler verwendet das Kontrollgerät maxi­
mal dreimal erneut den gleichen Schreibbefehl. Schlagen
alle Versuche fehl, wird die Karte für fehlerhaft und ungül­
tig erklärt.
150) Vor der Entnahme einer Fahrerkarte und nach Speicherung
aller relevanten Daten auf beiden Kartenanwendungen der
Karte setzt das Kontrollgerät alle „Kartenvorgangsdaten“
zurück.
▼M3
150a) Die Fahrzeugeinheit ignoriert die Elementardatei EF
VU_Configuration in allen Karten, sofern für die Verwen­
dung dieser Elementardatei keine spezifischen Regeln fest­
gelegt wurden. Solche Regeln werden durch eine Änderung
von Anhang IC festgelegt, was auch die Änderung oder
Streichung dieses Absatzes beinhaltet.
▼B
3.15 Anzeige
151) Die Anzeige enthält mindestens 20 Zeichen.
152) Die Mindesthöhe der Zeichen beträgt 5 mm und die Min­
destbreite 3,5 mm.
153) Die Anzeige muss die in Anlage 1 Kapitel 4 „Zeichensätze“
spezifizierten Zeichen unterstützen. Die Anzeige kann ver­
einfachte Zeichen verwenden (z. B. können mit Akzent
versehene Zeichen ohne Akzent oder Kleinbuchstaben als
Großbuchstaben dargestellt werden).
154) Die Anzeige ist mit einer blendfreien Beleuchtung
auszustatten.
155) Die in der Anzeige dargestellten Zeichen müssen von au­
ßerhalb des Kontrollgeräts gut sichtbar sein.
156) Vom Kontrollgerät müssen folgende Daten angezeigt wer­
den können:
— Standarddaten,
— Warndaten,
— Menüzugangsdaten,
— andere von einem Benutzer angeforderte Daten.
Vom Kontrollgerät können zusätzliche Informationen ange­
zeigt werden, sofern sie von den vorstehend verlangten
Informationen deutlich unterscheidbar sind.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 58
157) Die Anzeige des Kontrollgeräts verwendet die in Anlage 3
aufgeführten Piktogramme oder Piktogrammkombinationen.
Es können auch zusätzliche Piktogramme oder Pikto­
grammkombinationen angezeigt werden, sofern sie sich
deutlich von den genannten Piktogrammen und Pikto­
grammkombinationen unterscheiden.
158) Die Anzeige muss sich bei fahrendem Fahrzeug stets im
eingeschalteten Zustand befinden.
159) Das Kontrollgerät kann eine manuelle oder automatische
Abschaltvorrichtung für die Anzeige aufweisen, wenn sich
das Fahrzeug nicht in Fahrt befindet.
Das Anzeigeformat ist in Anlage 5 spezifiziert.
3.15.1 Standardanzeige
160) Wenn keine anderen Informationen angezeigt werden müs­
sen, sind vom Kontrollgerät standardmäßig folgende Anga­
ben anzuzeigen:
— die Ortszeit (UTC + durch den Fahrer eingestellter Ver­
satz),
— die Betriebsart,
— die derzeitige Tätigkeit des Fahrers und die derzeitige
Tätigkeit des Beifahrers,
— Informationen zum Fahrer:
— Falls derzeitige Tätigkeit LENKEN ist: aktuelle un­
unterbrochene Lenkzeit und aktuelle kumulative Unter­
brechungszeit,
— falls derzeitige Tätigkeit nicht LENKEN ist: aktuelle
Dauer der anderen Tätigkeit (seit der Auswahl) und
aktuelle kumulative Unterbrechungszeit.
161) Die Anzeige von Daten zu den Fahrern muss klar, deutlich
und eindeutig sein. Lassen sich Fahrer- und Beifahrerinfor­
mationen nicht gleichzeitig anzeigen, zeigt das Kontroll­
gerät standardmäßig die Informationen zum Fahrer an und
ermöglicht dem Benutzer, auf die Anzeige der Informatio­
nen zum Beifahrer umzuschalten.
162) Lässt die Anzeigebreite eine ständige Anzeige der Betriebs­
art nicht zu, zeigt das Kontrollgerät bei Betriebsartwechsel
die neue Betriebsart kurz an.
163) Beim Einstecken der Karte wird der Name des Karteninha­
bers kurz angezeigt.
164) Ist die Bedingung KONTROLLGERÄT NICHT ERFOR­
DERLICH oder FÄHRÜBERFAHRT/ZUGFAHRT einge­
schaltet, muss die Standardanzeige das entsprechende Pik­
togramm aufweisen (es ist zulässig, dass die aktuelle Fah­
rertätigkeit nicht gleichzeitig angezeigt wird).
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 59
3.15.2 Warnanzeige
165) Das Kontrollgerät zeigt Warninformationen vorrangig unter
Verwendung der Piktogramme gemäß Anlage 3 an, die
gegebenenfalls durch zahlencodierte Informationen ergänzt
werden. Darüber hinaus kann zusätzlich eine textliche Be­
schreibung der Warnung in der bevorzugten Sprache des
Fahrers erfolgen.
3.15.3 Menübedienung
166) Das Kontrollgerät stellt die erforderlichen Befehle über eine
geeignete Menüstruktur bereit.
3.15.4 Sonstige Anzeigen
167) Nach Bedarf müssen sich folgende Anzeigen auswählen
lassen:
— Datum und Uhrzeit in UTC sowie Ortszeitversatz,
▼M3
— der Inhalt der in Randnummer 169 aufgeführten Aus­
drucke in den gleichen Formaten wie die Ausdrucke
selbst,
▼B
— ununterbrochene Lenkzeit und kumulative Unterbre­
chungszeit des Fahrers,
— ununterbrochene Lenkzeit und kumulative Unterbre­
chungszeit des Beifahrers,
▼M3
— kumulierte Lenkzeit des Fahrers für die Vorwoche und
die laufende Woche,
— kumulierte Lenkzeit des Beifahrers für die Vorwoche
und die laufende Woche,
▼B
optional:
— aktuelle Dauer der Tätigkeit des Beifahrers (seit der
Auswahl),
▼M3
— kumulierte Lenkzeit des Fahrers für die laufende Wo­
che,
— kumulierte Lenkzeit des Beifahrers für den aktuellen
Arbeitstag,
— kumulierte Lenkzeit des Fahrers für den aktuellen Ar­
beitstag.
▼B
168) Die Anzeige des Ausdruckinhalts erfolgt sequenziell, Zeile
für Zeile. Beträgt die Anzeigebreite weniger als 24 Zeichen,
erhält der Benutzer die vollständige Information durch ein
geeignetes Mittel (mehrere Zeilen, Rollen usw.).
Für handschriftliche Einträge vorgesehene Ausdruckzeilen
brauchen nicht angezeigt zu werden.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 60
3.16 Drucken
169) Das Kontrollgerät muss Informationen aus seinem Massen­
speicher und/oder von Fahrtenschreiberkarten anhand der
folgenden sieben Ausdrucke drucken können:
— täglicher Ausdruck Fahrertätigkeiten von der Karte,
— täglicher Ausdruck Fahrertätigkeiten von der Fahrzeug­
einheit,
— Ausdruck Ereignisse und Störungen von der Karte,
— Ausdruck Ereignisse und Störungen von der Fahrzeug­
einheit,
— Ausdruck Technische Daten,
— Ausdruck Geschwindigkeitsüberschreitung,
— Fahrtenschreiberkartenvorgänge für eine bestimmte
Fahrzeugeinheit (siehe Kapitel 3.12.16)
Genaue Angaben zu Format und Inhalt dieser Ausdrucke
sind in Anlage 4 enthalten.
Am Ende der Ausdrucke können zusätzliche Daten bereit­
gestellt werden.
Vom Kontrollgerät können auch zusätzliche Ausdrucke be­
reitgestellt werden, sofern sie von den vorgenannten sieben
Ausdrucken deutlich unterscheidbar sind.
170) Der „tägliche Ausdruck Fahrertätigkeiten von der Karte“
und der „Ausdruck Ereignisse und Störungen von der
Karte“ dürfen verfügbar sein, wenn eine Fahrerkarte oder
eine Werkstattkarte in das Kontrollgerät eingesetzt sind.
Das Kontrollgerät muss die auf der betreffenden Karte ge­
speicherten Daten vor Beginn des Ausdrucks aktualisieren.
171) Zur Herstellung des „täglichen Ausdrucks Fahrertätigkeiten
von der Karte“ und des „Ausdrucks Ereignisse und Störun­
gen von der Karte“
— wählt das Kontrollgerät entweder automatisch die Fah­
rerkarte oder die Werkstattkarte, wenn nur eine dieser
Karten eingesteckt ist,
— oder ermöglicht einen Befehl zur Auswahl der Quellen­
karte oder zur Auswahl der Karte im Fahrersteckplatz,
wenn beide Kartenarten im Kontrollgerät eingesteckt
sind.
172) Der Drucker muss 24 Zeichen pro Zeile drucken können.
173) Die Mindesthöhe der Zeichen beträgt 2,1 mm und die Min­
destbreite 1,5 mm.
174) Der Drucker muss die in Anlage 1 Kapitel 4 „Zeichensätze“
spezifizierten Zeichen unterstützen.
175) Drucker müssen von ihrer Auslegung her diese Ausdrucke
mit einem Auflösungsniveau liefern, das Missverständnisse
beim Lesen ausschließt.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 61
176) Die Abmessungen der Ausdrucke und die Eintragungen
auf den Ausdrucken dürfen unter normalen Feuchtigkeits-
(10-90 %) und Temperaturbedingungen keinerlei Verände­
rungen unterliegen.
177) Auf dem vom Kontrollgerät verwendeten typgenehmigten
Papier sind das Typgenehmigungszeichen und der Typ/die
Typen des Kontrollgeräts anzugeben, mit dem/denen es
eingesetzt werden kann.
178) Die Ausdrucke müssen unter normalen Aufbewahrungs­
bedingungen hinsichtlich Lichtintensität, Feuchtigkeit und
Temperatur mindestens zwei Jahre lang deutlich lesbar
und identifizierbar bleiben.
179) Die Ausdrucke müssen mindestens den Prüfspezifikationen
gemäß Anlage 9 entsprechen.
180) Es muss möglich sein, auf diesen Ausdrucken zusätzliche
manuelle Eintragungen wie die Unterschrift des Fahrers
vorzunehmen.
181) Tritt während des Druckens das Ereignis „Kein Papier“ auf,
muss das Kontrollgerät nach dem Nachladen des Papiers
den Druckvorgang vom Anfang des Ausdrucks starten
oder den Druck fortsetzen, wobei ein eindeutiger Hinweis
auf den zuvor gedruckten Teil zu erfolgen hat.
3.17 Warnsignale
182) Bei Feststellung eines Ereignisses und/oder einer Störung
erhält der Fahrer vom Kontrollgerät ein Warnsignal.
183) Das Warnsignal für das Ereignis Unterbrechung der Strom­
versorgung kann bis zur Wiederherstellung der Stromver­
sorgung aufgeschoben werden.
184) Das Kontrollgerät warnt den Fahrer 15 Minuten vor dem
Zeitpunkt sowie zum Zeitpunkt der Überschreitung der
höchstzulässigen ununterbrochenen Lenkzeit.
185) Die Warnsignale erfolgen optisch. Zusätzlich zu optischen
können auch akustische Warnsignale abgegeben werden.
186) Optische Warnsignale müssen für den Benutzer eindeutig
erkennbar sein, sich im Sichtfeld des Fahrers befinden und
sowohl am Tage als auch in der Nacht deutlich lesbar sein.
187) Optische Warnsignale können in das Kontrollgerät einge­
baut oder gerätefern installiert sein.
188) Im letzteren Fall erfolgt die Kennzeichnung mit einem
„T“-Symbol.
189) Die Warnsignale haben eine Dauer von mindestens 30 Se­
kunden, sofern sie nicht vom Benutzer durch Betätigen
einer Taste am Kontrollgerät bestätigt werden. Mit dieser
ersten Bestätigung darf die im nächsten Absatz angeführte
Anzeige des Grundes für das Warnsignal nicht gelöscht
werden.
190) Der Grund für das Warnsignal wird am Kontrollgerät ange­
zeigt und bleibt so lange sichtbar, bis der Benutzer ihn mit
einer bestimmten Taste oder mit einem bestimmten Befehl
über das Kontrollgerät bestätigt.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 62
191) Es können zusätzliche Warnsignale abgegeben werden, so­
lange sie bei den Fahrern zu keinen Verwechslungen mit
den vorstehend festgelegten Warnsignalen führen.
3.18 Herunterladen von Daten auf externe Datenträger
192) Das Kontrollgerät muss bei Bedarf über den Steckanschluss
zum Kalibrieren/Herunterladen Daten aus seinem Massen­
speicher oder von einer Fahrerkarte an externe Speicherme­
dien herunterladen können. Das Kontrollgerät muss die auf
der betreffenden Karte gespeicherten Daten vor Beginn des
Herunterladens aktualisieren.
▼M3
193) Zusätzlich und als optionales Leistungsmerkmal kann das
Kontrollgerät in jeder Betriebsart Daten über eine andere
Schnittstelle an ein auf diesem Weg authentisiertes Unter­
nehmen herunterladen. In diesem Fall gelten für das Herun­
terladen die Datenzugriffsrechte der Betriebsart Unterneh­
men.
▼B
194) Beim Herunterladen dürfen gespeicherte Daten weder ver­
ändert noch gelöscht werden.
195) Die elektrische Schnittstelle des Anschlusses zum Kalibrie­
ren/Herunterladen ist in Anlage 6 spezifiziert.
196) Die Protokolle zum Herunterladen sind in Anlage 7
spezifiziert.
▼M3
196a) Ein Verkehrsunternehmen, das Fahrzeuge einsetzt, die mit
einem Kontrollgerät ausgestattet sind, das diesem Anhang
entspricht und in den Anwendungsbereich der Verordnung
(EG) Nr. 561/2006 fällt, muss sicherstellen, dass alle Daten
von der Fahrzeugeinheit und den Fahrerkarten heruntergela­
den werden.
Die Höchstzeiträume, innerhalb denen die relevanten Daten
heruntergeladen werden müssen, betragen:
— 90 Tage für Daten der Fahrzeugeinheit;
— 28 Tage für Daten der Fahrerkarte.
196b) Verkehrsunternehmen müssen die von der Fahrzeugeinheit
und den Fahrerkarten heruntergeladenen Daten nach der
Aufzeichnung mindestens zwölf Monate lang aufbewahren.
▼B
3.19 Fernkommunikation für die Durchführung gezielter Straßen­
kontrollen
197) Bei eingeschalteter Zündung speichert die Fahrzeugeinheit
alle 60 Sekunden in der Fernkommunikationsausrüstung die
jüngsten für die Zwecke der gezielten Straßenkontrolle er­
forderlichen Daten. Diese Daten werden gemäß Anlage 11
und Anlage 14 verschlüsselt und unterzeichnet.
198) Aus der Ferne zu kontrollierende Daten müssen für Fern­
abfragegeräte durch drahtlose Kommunikation gemäß An­
lage 14 verfügbar sein.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 63
199) Daten für die Zwecke der gezielten Straßenkontrolle bezie­
hen sich auf:
— den letzten Versuch einer Sicherheitsverletzung,
— die längste Unterbrechung der Stromversorgung,
— Sensorstörung,
— Datenfehler Weg und Geschwindigkeit,
— Datenkonflikt Fahrzeugbewegung,
— Fahren ohne gültige Karte,
— Einstecken der Karte während des Lenkens,
— Zeiteinstellungsdaten,
— Kalibrierungsdaten einschließlich der Daten der zwei
zuletzt gespeicherten Kalibrierungsdatensätze,
— amtliches Kennzeichen des Fahrzeugs,
— vom Fahrtenschreiber aufgezeichnete Geschwindigkeit ,
▼M3
— Fahrzeugposition,
— eine Angabe, ob der Fahrer derzeit gegen die Lenkzei­
ten verstoßen könnte.
3.20 Datenaustausch mit externen Zusatzgeräten
200) Das Kontrollgerät ist auch mit einer ITS-Schnittstelle ge­
mäß Anlage 13 ausgerüstet, die die Nutzung der vom Fahr­
tenschreiber oder den Fahrtenschreiberkarten aufgezeichne­
ten oder erzeugten Daten durch eine externe Ausrüstung
ermöglicht.
In der Betriebsart Betrieb ist die Zustimmung des Fahrers
zur Übermittlung personenbezogener Daten über die
ITS-Schnittstelle erforderlich. Die Zustimmung des Fahrers
ist jedoch für den Zugriff auf Fahrtenschreiber- oder Kar­
tendaten in den Betriebsarten Kontrolle, Unternehmen oder
Kalibrierung nicht erforderlich. Die Daten- und Funktions­
zugriffsrechte in diesen Betriebsarten sind in den Randnum­
mern 12 und 13 festgelegt.
Folgende Anforderungen gelten für über diese Schnittstelle
zur Verfügung gestellte ITS-Daten:
— personenbezogene Daten dürfen erst zur Verfügung ste­
hen, nachdem der Fahrer seine nachweisbare Zustim­
mung erteilt hat und akzeptiert hat, dass personenbezo­
gene Daten das Fahrzeugnetzwerk verlassen dürfen.
Ein Satz ausgewählter vorhandener Daten, die über die
ITS-Schnittstelle verfügbar sein können, und die Ein­
stufung der Daten als personenbezogene oder nicht per­
sonenbezogene Daten sind in Anlage 13 aufgeführt.
Zusätzlich zu dem in Anlage 13 genannten Satz von
Daten können weitere Daten ausgegeben werden. Der
Hersteller der Fahrzeugeinheit stuft diese Daten als
„personenbezogen“ oder „nicht personenbezogen“ ein,
wobei die Zustimmung des Fahrers für die Daten an­
wendbar ist, die als „personenbezogen“ eingestuft sind,
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 64
— die Zustimmung des Fahrers kann jederzeit durch Me­
nübefehle aktiviert oder deaktiviert werden, sofern die
Fahrerkarte eingesteckt ist,
— durch eine vorhandene ITS-Schnittstelle darf unter kei­
nen Umständen das ordnungsgemäße Funktionieren und
die Sicherheit der Fahrzeugeinheit gestört oder beein­
trächtigt werden.
Parallel dazu können zusätzliche Schnittstellen der Fahr­
zeugeinheit bestehen, sofern sie in vollem Umfang den An­
forderungen von Anlage 13 in Bezug auf die Zustimmung
des Fahrers genügen. Das Kontrollgerät muss in der Lage
sein, den Fahrerzustimmungsstatus an andere Plattformen
im Fahrzeugnetzwerk und an externe Geräte zu übertragen.
Werden in das Fahrzeugnetzwerk eingegebene personenbe­
zogene Daten außerhalb des Fahrzeugnetzwerks weiterver­
arbeitet, so liegt es nicht in der Verantwortung des Fahrten­
schreiberherstellers, dafür zu sorgen, dass die Verarbeitung
der personenbezogenen Daten in Übereinstimmung mit den
geltenden Datenschutzvorschriften der Union erfolgt.
Die ITS-Schnittstelle muss auch die Dateneingabe während
der manuellen Eingabe gemäß Randnummer 61 sowohl
durch den Fahrer als auch durch den Beifahrer zulassen.
Die ITS-Schnittstelle kann auch genutzt werden, um zusätz­
liche Informationen in Echtzeit einzugeben, z. B.:
— Fahrertätigkeitsauswahl gemäß Randnummer 46,
— Orte gemäß Randnummer 56,
— spezifische Bedingungen gemäß Randnummer 62,
— Be-/Entladevorgänge gemäß Randnummer 62a.
Diese Informationen können auch über andere Schnittstel­
len eingegeben werden.
201) Im Hinblick auf die Rückwärtskompatibilität können Fahr­
tenschreiber weiterhin mit der Schnittstelle für die serielle
Verbindung gemäß Anhang IB der Verordnung (EWG)
Nr. 3821/85 in der zuletzt geänderten Fassung ausgerüstet
sein. Die serielle Verbindung wird als Teil des Fahrzeug­
netzwerks gemäß Randnummer 200 eingestuft.
▼B
3.21 Kalibrierung
202) Die Kalibrierungsfunktion gestattet folgende Vorgänge:
— automatische Koppelung des Bewegungssensors mit der
Fahrzeugeinheit,
— automatische Kopplung der externen GNSS-Ausrüstung
mit der Fahrzeugeinheit, falls zutreffend,
— digitale Angleichung der Konstante des Kontrollgeräts
(k) an die Wegdrehzahl des Fahrzeugs (w),
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 65
— Einstellung der aktuellen Uhrzeit innerhalb der Gültig­
keitsdauer der eingesteckten Werkstattkarte,
— Einstellung des aktuellen Kilometerstands,
— Aktualisierung der im Massenspeicher gespeicherten
Kenndaten des Bewegungssensors,
— gegebenenfalls Aktualisierung der im Massenspeicher
gespeicherten Kenndaten der externen GNSS-Ausrüs­
tung,
— Aktualisierung von Typ und Kennung aller vorhande­
nen Plombierungen,
▼M3
— Aktualisierung oder Bestätigung anderer dem Kontroll­
gerät bekannter Parameter: Fahrzeugkennung, Wegdreh­
zahl (w), Reifenumfang (l), Reifengröße und gegebe­
nenfalls Einstellung des Geschwindigkeitsbegrenzers
sowie standardmäßige Art der Ladung,
— automatische Speicherung des Landes, in dem die Ka­
librierung durchgeführt wurde, und des Datums, an dem
die Position, die zur Bestimmung dieses Landes ver­
wendet wurde, vom GNSS-Empfänger bereitgestellt
wurde.
▼B
203) Darüber hinaus ermöglicht es die Kalibrierungsfunktion, die
Fähigkeit zur Verwendung von Fahrtenschreiberkarten der
ersten Generation im Kontrollgerät zu unterdrücken, sofern
die in Anlage 15 festgelegten Bedingungen erfüllt sind.
204) Die Koppelung des Bewegungssensors mit der Fahrzeug­
einheit besteht mindestens
— in der Aktualisierung der vom Bewegungssensor ge­
speicherten Installationsdaten (nach Bedarf),
— im Kopieren erforderlicher Kenndaten des Bewegungs­
sensors von diesem in den Massenspeicher der Fahr­
zeugeinheit.
▼M3
205) Die Kopplung der externen GNSS-Ausrüstung mit der
Fahrzeugeinheit besteht mindestens
— in der Aktualisierung der von der externen GNSS-Aus­
rüstung gespeicherten Einbaudaten (nach Bedarf),
— im Kopieren erforderlicher Kenndaten der externen
GNSS-Ausrüstung von dieser in den Massenspeicher
der Fahrzeugeinheit, einschließlich der Seriennummer
der externen GNSS-Ausrüstung.
▼B
206) Mit der Kalibrierungsfunktion muss es möglich sein, die
erforderlichen Daten über den Anschluss zum Kalibrieren/
Herunterladen gemäß dem in Anlage 8 festgelegten Kali­
brierungsprotokoll einzugeben. Die Eingabe erforderlicher
Daten durch die Kalibrierungsfunktion kann auch auf an­
derem Wege erfolgen.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 66
3.22 Straßenseitige Kalibrierungsüberprüfung
207) Die Funktion straßenseitige Kalibrierungsüberprüfung er­
möglicht das Auslesen der Seriennummer des (möglicher­
weise in den Adapter eingebetteten) Bewegungssensors und
der Seriennummer der zum Zeitpunkt der Anforderung mit
der Fahrzeugeinheit verbundenen externen GNSS-Ausrüs­
tung (falls zutreffend).
208) Dieses Auslesen muss zumindest auf der Anzeige der Fahr­
zeugeinheit durch Menübefehle möglich sein.
209) Die Funktion straßenseitige Kalibrierungsüberprüfung er­
möglicht ferner die Steuerung der Auswahl der E/A-Be­
triebsart der Kalibrierungs-E/A-Signalleitung gemäß Anlage
6 über die Schnittstelle der K-Leitung. Dies erfolgt über
den Einstellvorgang „ECUAdjustmentSession“ gemäß An­
lage 8 Abschnitt 7 „Prüfimpulssteuerung — Funktionsein­
heit Eingabe/Ausgabe-Steuerung“.
▼M3
Wenn die E/A-Betriebsart der Kalibrierungs-E/A-Signallei­
tung gemäß dieser Randnummer aktiv ist, darf die Fahr­
zeugeinheit die Warnmeldung „Lenken ohne geeignete
Karte“ (Randnummer 75) nicht auslösen.
▼B
3.23 Zeiteinstellung
210) Mit der Funktion Zeiteinstellung ist eine automatische Ein­
stellung der aktuellen Uhrzeit möglich. Im Kontrollgerät
werden zwei Zeitquellen zur Zeiteinstellung verwendet: 1)
die Systemuhr der Fahrzeugeinheit, 2) der GNSS-Empfänger.
▼M3
211) Die Zeit der Systemuhr der Fahrzeugeinheit wird auto­
matisch in variablen Zeitabständen neu eingestellt. Die
nächste automatische Zeiteinstellung muss zwischen
72 Stunden und 168 Stunden nach der vorherigen erfolgen
und nachdem die Fahrzeugeinheit über eine gültige authen­
tisierte Positionsnachricht gemäß Anlage 12 auf die
GNSS-Zeit zugreifen kann. Die Zeiteinstellung darf jedoch
nie über die kumulierte maximale Zeitabweichung pro Tag,
wie vom Hersteller der Fahrzeugeinheit gemäß Randnum­
mer 41b berechnet, hinausgehen. Wenn die Differenz zwi­
schen der von der Systemuhr der Fahrzeugeinheit und der
vom GNSS-Empfänger stammenden Zeit größer als die ku­
mulierte maximale Zeitabweichung pro Tag ist, muss bei
der Zeiteinstellung die Zeit der Systemuhr der Fahrzeug­
einheit so nahe wie möglich an die Zeit des GNSS-Emp­
fängers angeglichen werden. Die Zeiteinstellung darf nur
erfolgen, wenn die vom GNSS-Empfänger stammende
Zeit unter Verwendung authentisierter Positionsnachrichten
gemäß Anlage 12 erlangt wird. Die Zeitreferenz für die
automatische Zeiteinstellung der Systemuhr der Fahrzeug­
einheit ist die Zeit, die in der authentisierten Positionsnach­
richt bereitgestellt wird.
212) In der Betriebsart Kalibrierung ermöglicht es die Funktion
Zeiteinstellung ferner, eine Einstellung der aktuellen Uhr­
zeit auszulösen.
Werkstätten können die Zeit auf folgende Weise einstellen:
— entweder durch Schreiben eines Zeitwerts in die Fahr­
zeugeinheit unter Verwendung des Dienstes WriteData­
ByIdentifier gemäß Anlage 8 Abschnitt 6.2,
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 67
— oder durch Anfordern einer Anpassung der Systemuhr
der Fahrzeugeinheit an die vom GNSS-Empfänger be­
reitgestellte Zeit. Dies darf nur erfolgen, wenn die vom
GNSS-Empfänger stammende Zeit unter Verwendung
authentisierter Positionsnachrichten erlangt wird. In
letzterem Fall muss der Dienst RoutineControl gemäß
Anlage 8 Abschnitt 8 genutzt werden.
▼B
3.24 Leistungsmerkmale
213) Die Fahrzeugeinheit muss im Temperaturbereich von – 20
°C bis 70 °C, die externe GNSS-Ausrüstung im Tempera­
turbereich von – 20 °C bis 70 °C und der Bewegungssen­
sor im Temperaturbereich von – 40 °C bis 135 °C voll
einsatzbereit sein; der Inhalt des Massenspeichers muss
bis zu Temperaturen von – 40 °C erhalten bleiben.
214) Der Fahrtenschreiber muss bei einer Luftfeuchtigkeit von
10 bis 90 % voll einsatzbereit sein.
215) Die im intelligenten Fahrtenschreiber verwendeten Plombie­
rungen müssen den gleichen Bedingungen standhalten wie
sie für die Komponenten des Fahrtenschreibers, an denen
sie angebracht sind, gelten.
216) Das Kontrollgerät muss gegen Überspannung, Falschpolung
der Stromversorgung und Kurzschluss geschützt sein.
217) Bewegungssensoren müssen entweder
— auf ein Magnetfeld, das die Ermittlung von Fahrzeug­
bewegungsdaten stört, reagieren — unter diesen Um­
ständen registriert und speichert die Fahrzeugeinheit
eine Sensorstörung (Randnummer 88) — oder
— über einen Sensor verfügen, der vor Magnetfeldern ge­
schützt oder dagegen unempfindlich ist.
218) Das Kontrollgerät und die externe GNSS-Ausrüstung müs­
sen der internationalen UN/ECE-Regelung Nr. 10 genügen
und gegen elektrostatische Entladungen und Störgrößen ge­
schützt sein.
3.25 Werkstoffe
219) Alle Bauteile des Kontrollgeräts müssen aus Werkstoffen
mit hinreichender Stabilität und mechanischer Festigkeit
sowie genügender elektrischer und magnetischer Unver­
änderlichkeit bestehen.
220) Zur Gewährleistung normaler Betriebsbedingungen müssen
alle Teile des Geräts gegen Feuchtigkeit und Staub ge­
schützt sein.
221) Die Fahrzeugeinheit und die externe GNSS-Ausrüstung
müssen den Schutzgrad IP 40 und der Bewegungssensor
muss den Schutzgrad IP 64 gemäß Norm IEC 60529:1989
einschließlich A1:1999 und A2:2013 erfüllen.
222) Das Kontrollgerät muss den geltenden technischen Spezifi­
kationen hinsichtlich der ergonomischen Gestaltung genü­
gen.
223) Das Kontrollgerät muss gegen unbeabsichtigte Beschädi­
gungen geschützt sein.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 68
3.26 Markierungen
224) Sind am Kontrollgerät Kilometerstand und Geschwindigkeit
ablesbar, müssen in der Anzeige folgende Angaben
erscheinen:
— in der Nähe der Zahl, die die zurückgelegte Wegstrecke
anzeigt, die Maßeinheit der zurückgelegten Wegstre­
cken mit der Abkürzung „km“,
— in der Nähe der Zahl, die die Geschwindigkeit anzeigt,
die Abkürzung „km/h“.
Das Kontrollgerät kann auch auf eine Geschwindigkeits­
anzeige in Meilen pro Stunde umgeschaltet werden; in die­
sem Fall wird als Maßeinheit der Geschwindigkeit die Ab­
kürzung „mph“ angezeigt. Das Kontrollgerät kann auch auf
eine Anzeige der zurückgelegten Wegstrecke in Meilen
umgeschaltet werden; in diesem Fall wird als Maßeinheit
der zurückgelegten Wegstrecke die Abkürzung „mi“
angezeigt.
▼M1
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 Anga­
ben aus, muss das Typenschild mindestens folgende Anga­
ben enthalten: Name oder Logo des Herstellers und Teil­
nummer.
▼M3
3.27 Überwachung von Grenzüberschreitungen
226a) Diese Funktion muss erkennen, dass das Fahrzeug die
Grenze eines Landes überschritten hat, welches Land ver­
lassen wurde und in welches Land eingefahren wurde.
226b) Die Erkennung der Grenzüberschreitung muss auf der vom
Kontrollgerät gemessenen Position und der gespeicherten
digitalen Karte gemäß Nummer 3.12.19 basieren.
226c) Grenzüberschreitungen im Zusammenhang mit der Anwe­
senheit des Fahrzeugs in einem Land während eines Zeit­
raums von weniger als 120 Sekunden werden nicht
aufgezeichnet.
3.28 Softwareaktualisierung
226d) Die Fahrzeugeinheit muss über eine Funktion für die Im­
plementierung von Softwareaktualisierungen verfügen,
wenn solche Aktualisierungen nicht die Verfügbarkeit zu­
sätzlicher Hardware-Ressourcen erfordern, die über die in
Randnummer 226f genannten Ressourcen hinausgehen, und
wenn die Typgenehmigungsbehörden die Softwareaktuali­
sierungen auf der Grundlage der bestehenden typgenehmig­
ten Fahrzeugeinheit gemäß Artikel 12 Absatz 5 der Ver­
ordnung (EU) Nr. 165/2014 genehmigen.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 69
226e) Die Funktion zur Softwareaktualisierung ist so auszulegen,
dass sie die folgenden Funktionsmerkmale unterstützt,
wann immer diese gesetzlich vorgeschrieben sind:
— Änderung der in Nummer 2.2 genannten Funktionen,
mit Ausnahme der Funktion zur Softwareaktualisierung
selbst,
— Hinzufügung neuer Funktionen, die in unmittelbarem
Zusammenhang mit der Durchsetzung der Rechtsvor­
schriften der Union im Bereich des Straßenverkehrs
stehen,
— Änderung der Betriebsarten gemäß Nummer 2.3,
— Änderung der Dateistruktur, z. B. Hinzufügung neuer
Daten oder Erhöhung der Dateigröße,
— Bereitstellung von Software-Patches zur Behebung von
Software- und Sicherheitsmängeln oder gemeldeten An­
griffen auf die Funktionen des Kontrollgeräts.
226f) Die Fahrzeugeinheit stellt freie Hardware-Ressourcen im
Umfang von mindestens 35 % für Software und Daten,
die für die Umsetzung von Randnummer 226e erforderlich
sind, sowie freie Hardware-Ressourcen im Umfang von
mindestens 65 % für die Aktualisierung der digitalen Karte
auf der Grundlage der Hardware-Ressourcen, die für die
NUTS-0-Kartenversion 2021 erforderlich sind, bereit.
▼B
4 BAUART- UND FUNKTIONSMERKMALE DER FAHRTEN­
SCHREIBERKARTEN
4.1 Sichtbare Daten
Die Vorderseite enthält:
227) je nach Kartentyp in Großbuchstaben die Wörter „Fahrer­
karte“ oder „Kontrollkarte“ oder „Werkstattkarte“ oder
„Unternehmenskarte“ in der Sprache bzw. den Sprachen
des ausstellenden Mitgliedstaats;
228) den Namen des Mitgliedstaats, der die Karte ausstellt (optional);
229) das Unterscheidungszeichen des ausstellenden Mitglied­
staats, im Negativdruck in einem blauen Rechteck, umge­
ben von 12 gelben Sternen. Die Unterscheidungszeichen
lauten wie folgt:
B
BG
CZ
CY
Belgien
Bulgarien
Tschechische Republik
Zypern
LV
L
LT
M
Lettland
Luxemburg
Litauen
Malta
DK Dänemark NL Niederlande
D
EST
Deutschland
Estland
A
PL
Österreich
Polen
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 70
GR Griechenland P
RO
SK
SLO
Portugal
Rumänien
Slowakei
Slowenien
E Spanien FIN Finnland
F
HR
H
Frankreich
Kroatien
Ungarn
S Schweden
IRL Irland UK Vereinigtes König­
reich
I Italien
230) wie folgt nummerierte Angaben zu der ausgestellten Karte:
Fahrerkarte Kontrollkarte
Unternehmens- oder Werkstatt­
karte
1. Name des Fahrers Name der Kontrollstelle Name des Unternehmens
oder der Werkstatt
2. Vorname(n) des Fahrers Name des Kontrolleurs
(falls zutreffend)
Name des Karteninhabers
(falls zutreffend)
3. Geburtsdatum des Fahrers Vorname(n) des Kontrol­
leurs
(falls zutreffend)
Vorname(n) des Karten­
inhabers
(falls zutreffend)
4.a Gültig ab
4.b Gültig bis
4.c Name der ausstellenden Behörde (kann auch auf die Rückseite gedruckt werden)
4.d andere Nummer als unter 5 für Verwaltungszwecke (optional)
5.a Führerscheinnummer:
(am Ausstellungstag der
Fahrerkarte)
— —
5.b Kartennummer
6. Lichtbild des Fahrers Lichtbild des Kontrolleurs
(optional)
Lichtbild des Einbau­
betriebs (optional)
7. Unterschrift des Inhabers (optional)
8. Wohnort oder Anschrift
des Inhabers (optional)
Anschrift der Kontrollstelle Anschrift des Unterneh­
mens oder der Werkstatt
231) Das zu verwendende Datumsformat ist „TT/MM/JJJJ“ oder
„TT.MM.JJJJ“ (Tag, Monat, Jahr).
Die Rückseite enthält:
232) eine Erläuterung zu den nummerierten Angaben auf der
Vorderseite der Karte,
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 71
233) mit ausdrücklicher schriftlicher Zustimmung des Inhabers
auch Angaben, die nicht mit der Verwaltung der Fahrer­
karte im Zusammenhang stehen; durch derartige Zusätze
ändert sich nichts an der Verwendung des Musters als Fah­
rerkarte.
234) Die Fahrtenschreiberkarten werden mit folgenden Hinter­
grundfarben gedruckt:
— Fahrerkarte: Weiß,
— Kontrollkarte: Blau,
— Werkstattkarte: Rot,
— Unternehmenskarte: Gelb.
235) Zum Schutz vor Fälschung und unbefugten Änderungen
weisen die Fahrtenschreiberkarten mindestens folgende
Merkmale auf:
— ein Sicherheitsuntergrunddesign mit feinen Guillochen
und Irisdruck,
— im Bereich des Lichtbilds eine Überlappung des Sicher­
heitsuntergrunddesigns mit dem Lichtbild,
— mindestens eine zweifarbige Mikrodruckzeile.
► (1) M1
► (2) M3
236) Die Mitgliedstaaten können nach Beratung mit der Kom­
mission unbeschadet der übrigen Bestimmungen dieses An­
hangs Farben oder Markierungen wie Staatssymbole oder
Sicherheitsmerkmale hinzufügen.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 72
237) Befristete Karten nach Artikel 26 Absatz 4 der Verord­
nung (EU) Nr. 165/2014 müssen den Vorschriften dieses
Anhangs entsprechen.
4.2 Sicherheit
Ziel der Systemsicherheit ist der Schutz der Integrität und Authen­
tizität der zwischen den Karten und dem Kontrollgerät ausgetausch­
ten Daten und der von den Karten heruntergeladenen Daten, die
Zulassung bestimmter Schreibvorgänge auf die Karten nur für das
Kontrollgerät, die Entschlüsselung bestimmter Daten, der Aus­
schluss jeder Möglichkeit einer Fälschung der auf den Karten ge­
speicherten Daten, die Verhinderung unbefugter Änderungen sowie
die Feststellung jeglicher Versuche dieser Art.
238) Zur Gewährleistung der Systemsicherheit müssen die Fahr­
tenschreiberkarten die Sicherheitsvorgaben gemäß den An­
lagen 10 und 11 erfüllen.
239) Fahrtenschreiberkarten müssen mit anderen Geräten, wie z.
B. Personalcomputern, lesbar sein.
4.3 Normen
240) Die Fahrtenschreiberkarten müssen den folgenden Normen
entsprechen:
— ISO/IEC 7810 Identification cards — Physical
characteristics,
— ISO/IEC 7816 Identification cards — Integrated circuit
cards:
— Teil 1: Physical characteristics,
— Teil 2: Dimensions and position of the contacts
(ISO/IEC 7816-2:2007),
— Teil 3: Electrical interface and transmission pro­
tocols (ISO/IEC 7816-3:2006),
— Teil 4: Organization, security and commands for
interchange)(ISO/IEC 7816-4:2013 + Cor 1:2014),
— Teil 6: Interindustry data elements for interchange
(ISO/IEC 7816-6:2004 + Cor 1:2006),
— Teil 8: Commands for security operations (ISO/IEC
7816-8:2004).
— Fahrtenschreiberkarten müssen gemäß ISO/IEC 10373-
3:2010 „Identification cards — Test methods — Part 3:
Integrated circuit cards with contacts and related inter­
face devices“ geprüft werden.
4.4 Spezifikationen für Umgebung und Elektrizität
241) Fahrtenschreiberkarten müssen unter allen klimatischen Be­
dingungen, die im Gebiet der Gemeinschaft gewöhnlich
anzutreffen sind, ordnungsgemäß funktionieren können,
mindestens im Temperaturbereich – 25 °C bis + 70 °C
mit gelegentlichen Spitzen bis zu + 85 °C, wobei „gele­
gentlich“ jeweils nicht mehr als 4 Stunden und nicht
mehr als 100mal während der Lebensdauer der Karte
bedeutet.
242) Fahrtenschreiberkarten müssen bei einer Luftfeuchtigkeit
von 10 bis 90 % ordnungsgemäß funktionieren können.
243) Fahrtenschreiberkarten müssen bei Verwendung gemäß den
Spezifikationen für Umgebung und Elektrizität während ei­
ner Dauer von fünf Jahren ordnungsgemäß funktionieren
können.
244) Während des Betriebs müssen die Fahrtenschreiberkarten
hinsichtlich der elektromagnetischen Verträglichkeit der
UN/ECE-Regelung Nr. 10 genügen und gegen elektrostati­
sche Entladungen geschützt sein.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 73
4.5 Datenspeicherung
Im Sinne dieses Absatzes
— erfolgt die Zeitaufzeichnung auf eine Minute genau, sofern nicht
anders angegeben;
— erfolgt die Aufzeichnung des Kilometerstands auf einen Kilo­
meter genau;
— erfolgt die Geschwindigkeitsaufzeichnung auf 1 km/h genau;
— werden Positionen (Längen- und Breitengrade) in Grad und Mi­
nuten mit einer Auflösung von 1/10 Minute aufgezeichnet.
Die Funktionen, Befehle und logischen Strukturen der Fahrten­
schreiberkarten, die der Erfüllung von Anforderungen zur Daten­
speicherung dienen, sind in Anlage 2 spezifiziert.
Sofern nicht anders angegeben muss die Datenspeicherung auf Fahr­
tenschreiberkarten so erfolgen, dass die jeweils ältesten gespeicher­
ten Daten durch neue Daten ersetzt werden, wenn die für diese
Aufzeichnungen vorgesehene Speichergröße erschöpft ist.
245) In diesem Absatz ist die Mindestspeicherkapazität für die
verschiedenen Anwendungsdateien festgelegt. Fahrten­
schreiberkarten müssen dem Kontrollgerät die tatsächliche
Speicherkapazität dieser Dateien anzeigen können.
▼M3
246) Zusätzliche Daten können auf Fahrtenschreiberkarten ge­
speichert werden, sofern die Speicherung dieser Daten
den geltenden Datenschutzvorschriften entspricht.
▼B
247) Jede Wurzel-DF (Master File, MF) einer Fahrtenschreiber­
karte enthält bis zu fünf Elementardateien (Elementary Fi­
les, EF) für die Kartenverwaltung, Anwendungs- und Chip­
kennungen sowie zwei Verzeichnisse (Dedicated Files,
DF):
— DF Tachograph enthält die für Fahrzeugeinheiten der
ersten Generation zugängliche Anwendung, die auch
in Fahrtenschreiberkarten der ersten Generation enthal­
ten ist,
— DF Tachograph_G2 enthält die nur für Fahrzeugeinhei­
ten der zweiten Generation zugängliche Anwendung,
die nur in Fahrtenschreiberkarten der zweiten Genera­
tion enthalten ist.
▼M3
Anmerkung: Version 2 der Karten der zweiten Generation
enthält zusätzliche Elementardateien in DF Tachograph_G2.
▼B
Sämtliche Einzelheiten der Struktur der Fahrtenschreiber­
karten sind in Anlage 2 spezifiziert.
4.5.1 Elementardateien für Kennung und Kartenverwaltung
4.5.2 IS-Kartenkennung
248) Die Fahrtenschreiberkarten müssen die folgenden Chipkar­
tenkenndaten speichern können:
— Clock stop,
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 74
— Seriennummer der Karte (einschließlich Fertigungsanga­
ben),
— Typgenehmigungsnummer der Karte
— Kennung der Karten-Personalisierung (ID),
— Kartenhersteller-ID,
— IS-Bezeichner.
4.5.2.1 C h i p k e n n u n g
249) Die Fahrtenschreiberkarten müssen die folgenden Kenn­
daten des integrierten Schaltkreises (IS) speichern können:
— IS-Seriennummer,
— IS-Fertigungsangaben.
4.5.2.2 D I R ( n u r i n F a h r t e n s c h r e i b e r k a r t e n d e r z w e i t e n
G e n e r a t i o n e n t h a l t e n )
250) Fahrtenschreiberkarten müssen die in Anlage 2 genannten
Datenobjekte zur Anwendungskennung speichern können.
4.5.2.3 A T R - A n g a b e n ( e i n g e s c h r ä n k t , n u r i n F a h r t e n ­
s c h r e i b e r k a r t e n d e r z w e i t e n G e n e r a t i o n e n t h a l ­
t e n )
251) Die Fahrtenschreiberkarten müssen das folgende Daten­
objekt mit der erweiterten Längenangabe speichern können:
— falls die Fahrtenschreiberkarte erweiterte Längenfelder
unterstützt, das in Anlage 2 spezifizierte Datenobjekt
mit der erweiterten Längenangabe.
4.5.2.4 E r w e i t e r t e L ä n g e n a n g a b e ( e i n g e s c h r ä n k t , n u r i n
F a h r t e n s c h r e i b e r k a r t e n d e r z w e i t e n G e n e r a t i o n
e n t h a l t e n )
252) Die Fahrtenschreiberkarten müssen die folgenden Daten­
objekte mit der erweiterten Längenangabe speichern kön­
nen:
— falls die Fahrtenschreiberkarte erweiterte Längenfelder
unterstützt, die in Anlage 2 spezifizierten Datenobjekte
mit der erweiterten Längenangabe.
4.5.3 Fahrerkarte
4.5.3.1 F a h r t e n s c h r e i b e r a n w e n d u n g ( z u g ä n g l i c h f ü r
F a h r z e u g e i n h e i t e n d e r e r s t e n u n d z w e i t e n G e n e ­
r a t i o n )
4.5.3.1.1 Anwendungskennung
253) Die Fahrerkarte muss die folgenden Anwendungskenndaten
speichern können:
— Kennnummer der Fahrtenschreiberanwendung,
— Art der Fahrtenschreiberkartenkennung.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 75
4.5.3.1.2 Schlüssel und Zertifikate
254) Die Fahrtenschreiberkarte muss eine Reihe kryptografischer
Schlüssel und Zertifikate gemäß Anlage 11 Teil A spei­
chern können.
4.5.3.1.3 Kartenkennung
255) Die Fahrerkarte muss die folgenden Kartenkenndaten spei­
chern können:
— Kartennummer,
— ausstellender Mitgliedstaat, Name der ausstellenden Be­
hörde, Ausstellungsdatum,
— gültig ab, gültig bis.
4.5.3.1.4 Karteninhaberkennung
256) Die Fahrerkarte muss die folgenden Karteninhaberkenn­
daten speichern können:
— Name des Karteninhabers,
— Vorname(n) des Karteninhabers,
— Geburtsdatum,
— bevorzugte Sprache.
4.5.3.1.5 Herunterladen von der Karte
257) Die Fahrerkarte muss in Bezug auf das Herunterladen von
der Karte die folgenden Daten speichern können:
— Datum und Uhrzeit des letzten Herunterladens der Da­
ten von der Karte (zu anderen als Kontrollzwecken).
258) Die Fahrerkarte muss einen derartigen Datensatz gespei­
chert halten können.
4.5.3.1.6 Führerscheininformationen
259) Die Fahrerkarte muss die folgenden Führerscheindaten spei­
chern können:
— ausstellender Mitgliedstaat, Name der ausstellenden Be­
hörde,
— Führerscheinnummer (am Ausstellungstag der Karte).
4.5.3.1.7 Ereignisdaten
Im Sinne dieses Absatzes erfolgt die Zeitspeicherung auf 1 Sekunde
genau.
260) Die Fahrerkarte muss Daten in Bezug auf die folgenden,
vom Kontrollgerät bei eingesteckter Karte festgestellten Er­
eignisse speichern können:
— Zeitüberlappung (wenn die Karte Ursache des Ereignis­
ses ist),
— Einstecken der Karte während des Lenkens (wenn die
Karte Gegenstand des Ereignisses ist),
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 76
— Letzter Kartenvorgang nicht korrekt abgeschlossen
(wenn die Karte Gegenstand des Ereignisses ist),
— Unterbrechung der Stromversorgung,
— Datenfehler Weg und Geschwindigkeit,
— Versuch Sicherheitsverletzung.
261) Die Fahrerkarte muss die folgenden Daten für diese Ereig­
nisse speichern können:
— Ereigniscode,
— Datum und Uhrzeit des Ereignisbeginns (oder des Ein­
steckens der Karte, wenn das Ereignis zu diesem Zeit­
punkt andauerte),
— Datum und Uhrzeit des Ereignisendes (oder der Karten­
entnahme, wenn das Ereignis zu diesem Zeitpunkt an­
dauerte),
— amtliches Kennzeichen und zulassender Mitgliedstaat
des Fahrzeugs, in dem das Ereignis eintrat.
Anmerkung: Für das Ereignis „Zeitüberlappung“:
— Datum und Uhrzeit des Ereignisbeginns müssen Datum
und Uhrzeit der Kartenentnahme aus dem vorherigen
Fahrzeug entsprechen,
— Datum und Uhrzeit des Ereignisendes müssen Datum
und Uhrzeit des Einsteckens der Karte in das derzeitige
Fahrzeug entsprechen,
— Fahrzeugdaten müssen dem derzeitigen Fahrzeug ent­
sprechen, das das Ereignis auslöst.
Anmerkung: Für das Ereignis „Letzter Kartenvorgang nicht
korrekt abgeschlossen“:
— Datum und Uhrzeit des Ereignisbeginns müssen Datum
und Uhrzeit des Einsteckens der Karte bei dem nicht
korrekt abgeschlossenen Vorgang entsprechen,
— Datum und Uhrzeit des Ereignisendes müssen Datum
und Uhrzeit des Einsteckens der Karte bei dem Vor­
gang entsprechen, während dessen das Ereignis fest­
gestellt wurde (derzeitiger Vorgang),
— Fahrzeugdaten müssen dem Fahrzeug entsprechen, in
dem der Vorgang nicht korrekt abgeschlossen wurde.
262) Die Fahrerkarte muss Daten für die sechs jüngsten Ereig­
nisse jeder Art (d. h. 36 Ereignisse) speichern können.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 77
4.5.3.1.8 Störungsdaten
Im Sinne dieses Unterabsatzes erfolgt die Zeitspeicherung auf 1
Sekunde genau.
263) Die Fahrerkarte muss Daten in Bezug auf die folgenden,
vom Kontrollgerät bei eingesteckter Karte festgestellten
Störungen speichern können:
▼M1
— Störung Karte (wenn die Karte Gegenstand der Störung
ist),
▼B
— Störung Kontrollgerät.
264) Die Fahrerkarte muss die folgenden Daten für diese Stö­
rungen speichern können:
— Störungscode,
— Datum und Uhrzeit des Störungsbeginns (oder des Ein­
steckens der Karte, wenn die Störung zu diesem Zeit­
punkt andauerte),
— Datum und Uhrzeit des Störungsendes (oder der Karten­
entnahme, wenn die Störung zu diesem Zeitpunkt an­
dauerte),
— amtliches Kennzeichen und zulassender Mitgliedstaat
des Fahrzeugs, in dem die Störung eintrat.
265) Die Fahrerkarte muss Daten für die zwölf jüngsten Störun­
gen jeder Art (d. h. 24 Störungen) speichern können.
4.5.3.1.9 Fahrertätigkeitsdaten
266) Die Fahrerkarte muss für jeden Kalendertag, an dem sie
benutzt wurde oder für den der Fahrer manuell Tätigkeiten
eingegeben hat, die folgenden Daten speichern können:
— Datum,
— Tagesanwesenheitszähler (wird für jeden dieser Kalen­
dertage um den Wert Eins erhöht),
— vom Fahrer an diesem Tag zurückgelegte Gesamtweg­
strecke,
— Fahrerstatus um 0.00 Uhr,
— jedes Mal, wenn der Fahrer die Tätigkeit gewechselt
und/oder den Status der Fahrzeugführung verändert
und/oder seine Karte eingesteckt oder entnommen hat:
— der Status der Fahrzeugführung (TEAM, EIN­
MANNBETRIEB),
— den Steckplatz (FAHRER, BEIFAHRER),
— den Kartenstatus (EINGESTECKT, NICHT EINGE­
STECKT),
— die Tätigkeit (LENKEN, BEREITSCHAFT, AR­
BEIT, UNTERBRECHUNG/RUHE),
— den Zeitpunkt der Veränderung.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 78
267) Der Speicher der Fahrerkarte muss die Fahrertätigkeitsdaten
von mindestens 28 Tagen gespeichert halten können (die
durchschnittliche Tätigkeit eines Fahrers ist mit 93 Tätig­
keitsveränderungen pro Tag definiert).
268) Die in den Randnummern 261, 264 und 266 aufgeführten
Daten werden so gespeichert, dass — auch bei zeitlichen
Überschneidungen — ein Abrufen der Tätigkeiten in der
Reihenfolge ihres Auftretens möglich ist.
4.5.3.1.10 Daten zu gefahrenen Fahrzeugen
269) Die Fahrerkarte muss für jeden Kalendertag, an dem die sie
benutzt wurde, sowie für jeden Betriebszeitraum eines
Fahrzeugs an diesem Tag (ein Betriebszeitraum umfasst
alle aufeinander folgenden Einsteck-/Entnahmevorgänge
der Karte in dem Fahrzeug im Hinblick auf diese Karte)
die folgenden Daten speichern können:
— Datum und Uhrzeit des ersten Einsatzes des Fahrzeugs
(d. h. erstes Karteneinstecken für diesen Betriebszeit­
raum des Fahrzeugs oder 0.00 Uhr, wenn der Betriebs­
zeitraum zu diesem Zeitpunkt andauert),
— Kilometerstand zu diesem Zeitpunkt,
— Datum und Uhrzeit des letzten Einsatzes des Fahrzeugs
(d. h. letzte Kartenentnahme für diesen Betriebszeitraum
des Fahrzeugs oder 23.59 Uhr, wenn der Betriebszeit­
raum zu diesem Zeitpunkt andauert),
— Kilometerstand zu diesem Zeitpunkt,
— amtliches Kennzeichen und zulassender Mitgliedstaat.
270) Die Fahrerkarte muss mindestens 84 derartige Datensätze
speichern können.
4.5.3.1.11 Ort des Beginns und/oder des Endes des Arbeitstages
271) Die Fahrerkarte muss die folgenden vom Fahrer eingegebe­
nen Daten zum Ort des Beginns und/oder des Endes des
Arbeitstages speichern können:
— Datum und Uhrzeit der Eingabe (oder Datum/Uhrzeit
bezogen auf die Eingabe, wenn diese während des ma­
nuellen Eingabevorgangs erfolgt),
— Art der Eingabe (Beginn oder Ende, Eingabebedin­
gung),
— eingegebene(s) Land und Region,
— Kilometerstand.
272) Der Speicher der Fahrerkarte muss mindestens 42 derartige
Datensatzpaare gespeichert halten können.
4.5.3.1.12 Kartenvorgangsdaten
273) Die Fahrerkarte muss Daten in Bezug auf das Fahrzeug
speichern können, in dem der laufende Vorgang eingeleitet
wurde:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 79
— Datum und Uhrzeit der Einleitung des Vorgangs (d. h.
Einstecken der Karte) auf 1 Sekunde genau,
— amtliches Kennzeichen und zulassender Mitgliedstaat.
4.5.3.1.13 Kontrolltätigkeitsdaten
274) Die Fahrerkarte muss in Bezug auf Kontrolltätigkeiten die
folgenden Daten speichern können:
— Datum und Uhrzeit der Kontrolle,
— Kontrollkartennummer und ausstellender Mitgliedstaat,
— Art der Kontrolle (Anzeige und/oder Drucken und/oder
Herunterladen von der Fahrzeugeinheit und/oder Herun­
terladen von der Karte (siehe Anmerkung)),
— heruntergeladener Zeitraum beim Herunterladen,
— amtliches Kennzeichen und zulassender Mitgliedstaat
des kontrollierten Fahrzeugs.
Anmerkung: Ein Herunterladen von der Karte wird nur
aufgezeichnet, wenn dies über ein Kontrollgerät erfolgt.
275) Die Fahrerkarte muss einen derartigen Datensatz gespei­
chert halten können.
4.5.3.1.14 Daten zu spezifischen Bedingungen
276) Die Fahrerkarte muss die folgenden Daten in Bezug auf
spezifische Bedingungen speichern können, die bei einge­
setzter Karte (ungeachtet des Steckplatzes) eingegeben
wurden:
— Datum und Uhrzeit der Eingabe,
— Art der spezifischen Bedingung.
277) Die Fahrerkarte muss mindestens 56 derartige Datensätze
speichern können.
▼M3
4.5.3.2 F a h r t e n s c h r e i b e r a n w e n d u n g d e r z w e i t e n G e n e ­
r a t i o n ( n i c h t z u g ä n g l i c h f ü r F a h r z e u g e i n h e i t e n
d e r e r s t e n G e n e r a t i o n , z u g ä n g l i c h f ü r V e r s i o n 1
u n d V e r s i o n 2 v o n F a h r z e u g e i n h e i t e n d e r z w e i ­
t e n G e n e r a t i o n )
▼B
4.5.3.2.1 Anwendungskennung
278) Die Fahrerkarte muss die folgenden Anwendungskenndaten
speichern können:
— Kennnummer der Fahrtenschreiberanwendung,
— Art der Fahrtenschreiberkartenkennung.
▼M3
4.5.3.2.1.1 Zusätzliche Anwendungskennung (nicht zugänglich für Version 1
von Fahrzeugeinheiten der zweiten Generation)
278a) Die Fahrerkarte muss zusätzliche Anwendungskenndaten
speichern können, die nur für Version 2 anwendbar sind.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 80
4.5.3.2.2 Schlüssel und Zertifikate
279) Die Fahrtenschreiberkarte muss eine Reihe kryptografischer
Schlüssel und Zertifikate gemäß Anlage 11 Teil B spei­
chern können.
4.5.3.2.3 Kartenkennung
280) Die Fahrerkarte muss die folgenden Kartenkenndaten spei­
chern können:
— Kartennummer,
— ausstellender Mitgliedstaat, Name der ausstellenden Be­
hörde, Ausstellungsdatum,
— gültig ab, gültig bis.
4.5.3.2.4 Karteninhaberkennung
281) Die Fahrerkarte muss die folgenden Karteninhaberkenn­
daten speichern können:
— Name des Karteninhabers,
— Vorname(n) des Karteninhabers,
— Geburtsdatum,
— bevorzugte Sprache.
4.5.3.2.5 Herunterladen von der Karte
282) Die Fahrerkarte muss in Bezug auf das Herunterladen von
der Karte die folgenden Daten speichern können:
— Datum und Uhrzeit des letzten Herunterladens der Da­
ten von der Karte (zu anderen als Kontrollzwecken).
283) Die Fahrerkarte muss einen derartigen Datensatz gespei­
chert halten können.
4.5.3.2.6 Führerscheininformationen
284) Die Fahrerkarte muss die folgenden Führerscheindaten spei­
chern können:
— ausstellender Mitgliedstaat, Name der ausstellenden Be­
hörde,
— Führerscheinnummer (am Ausstellungstag der Karte).
4.5.3.2.7 Ereignisdaten
Im Sinne dieses Absatzes erfolgt die Zeitspeicherung auf 1 Sekunde
genau.
285) Die Fahrerkarte muss Daten in Bezug auf die folgenden,
vom Kontrollgerät bei eingesteckter Karte festgestellten Er­
eignisse speichern können:
— Zeitüberlappung (wenn die Karte Ursache des Ereignis­
ses ist),
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 81
— Einstecken der Karte während des Lenkens (wenn die
Karte Gegenstand des Ereignisses ist),
— Letzter Kartenvorgang nicht korrekt abgeschlossen
(wenn die Karte Gegenstand des Ereignisses ist),
— Unterbrechung der Stromversorgung,
— Kommunikationsfehler mit der Fernkommunikations­
ausrüstung,
— Ereignis „Fehlen der Positionsdaten vom GNSS-Emp­
fänger“,
— Ereignis „Kommunikationsfehler mit der externen
GNSS-Ausrüstung“
— Datenfehler Weg und Geschwindigkeit,
— Datenkonflikt Fahrzeugbewegung,
— Versuch Sicherheitsverletzung,
— Zeitkonflikt.
286) Die Fahrerkarte muss die folgenden Daten für diese Ereig­
nisse speichern können:
— Ereigniscode,
— Datum und Uhrzeit des Ereignisbeginns (oder des Ein­
steckens der Karte, wenn das Ereignis zu diesem Zeit­
punkt andauerte),
— Datum und Uhrzeit des Ereignisendes (oder der Karten­
entnahme, wenn das Ereignis zu diesem Zeitpunkt an­
dauerte),
— amtliches Kennzeichen und zulassender Mitgliedstaat
des Fahrzeugs, in dem das Ereignis eintrat.
Anmerkung: Für das Ereignis „Zeitüberlappung“:
— Datum und Uhrzeit des Ereignisbeginns müssen Datum
und Uhrzeit der Kartenentnahme aus dem vorherigen
Fahrzeug entsprechen,
— Datum und Uhrzeit des Ereignisendes müssen Datum
und Uhrzeit des Einsteckens der Karte in das derzeitige
Fahrzeug entsprechen,
— Fahrzeugdaten müssen dem derzeitigen Fahrzeug ent­
sprechen, das das Ereignis auslöst.
Anmerkung: Für das Ereignis „Letzter Kartenvorgang nicht
korrekt abgeschlossen“:
— Datum und Uhrzeit des Ereignisbeginns müssen Datum
und Uhrzeit des Einsteckens der Karte bei dem nicht
korrekt abgeschlossenen Vorgang entsprechen,
— Datum und Uhrzeit des Ereignisendes müssen Datum
und Uhrzeit des Einsteckens der Karte bei dem Vor­
gang entsprechen, während dessen das Ereignis fest­
gestellt wurde (derzeitiger Vorgang),
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 82
— Fahrzeugdaten müssen dem Fahrzeug entsprechen, in
dem der Vorgang nicht korrekt abgeschlossen wurde.
▼M3
287) Die Fahrerkarte muss Daten für die zwölf jüngsten Ereig­
nisse jeder Art (d. h. 132 Ereignisse) speichern können.
▼B
4.5.3.2.8 Störungsdaten
Im Sinne dieses Unterabsatzes erfolgt die Zeitspeicherung auf 1
Sekunde genau.
288) Die Fahrerkarte muss Daten in Bezug auf die folgenden,
vom Kontrollgerät bei eingesteckter Karte festgestellten
Störungen speichern können:
▼M1
— Störung Karte (wenn die Karte Gegenstand der Störung
ist),
▼B
— Störung Kontrollgerät.
289) Die Fahrerkarte muss die folgenden Daten für diese Stö­
rungen speichern können:
— Störungscode,
— Datum und Uhrzeit des Störungsbeginns (oder des Ein­
steckens der Karte, wenn die Störung zu diesem Zeit­
punkt andauerte),
— Datum und Uhrzeit des Störungsendes (oder der Karten­
entnahme, wenn die Störung zu diesem Zeitpunkt an­
dauerte),
— amtliches Kennzeichen und zulassender Mitgliedstaat
des Fahrzeugs, in dem die Störung eintrat.
▼M3
290) Die Fahrerkarte muss Daten für die 24 jüngsten Störungen
jeder Art (d. h. 48 Störungen) speichern können.
▼B
4.5.3.2.9 Fahrertätigkeitsdaten
291) Die Fahrerkarte muss für jeden Kalendertag, an dem sie
benutzt wurde oder für den der Fahrer manuell Tätigkeiten
eingegeben hat, die folgenden Daten speichern können:
— Datum,
— Tagesanwesenheitszähler (wird für jeden dieser Kalen­
dertage um den Wert Eins erhöht),
— vom Fahrer an diesem Tag zurückgelegte Gesamtweg­
strecke,
— Fahrerstatus um 0.00 Uhr,
— jedes Mal, wenn der Fahrer die Tätigkeit gewechselt
und/oder den Status der Fahrzeugführung verändert
und/oder seine Karte eingesteckt oder entnommen hat:
— den Status der Fahrzeugführung (TEAM, EIN­
MANNBETRIEB),
— den Steckplatz (FAHRER, BEIFAHRER),
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 83
— den Kartenstatus (EINGESTECKT, NICHT EINGE­
STECKT),
— die Tätigkeit (LENKEN, BEREITSCHAFT, AR­
BEIT, UNTERBRECHUNG/RUHE).
— Zeitpunkt der Veränderung.
▼M3
292) Der Speicher der Fahrerkarte muss die Fahrertätigkeitsdaten
von 56 Tagen gespeichert halten können (die durchschnitt­
liche Tätigkeit eines Fahrers ist für diese Randnummer mit
117 Tätigkeitsveränderungen pro Tag definiert).
▼B
293) Die in den Randnummern 286, 289 und 291 aufgeführten
Daten werden so gespeichert, dass — auch bei zeitlichen
Überschneidungen — ein Abrufen der Tätigkeiten in der
Reihenfolge ihres Auftretens möglich ist.
4.5.3.2.10 Daten zu gefahrenen Fahrzeugen
294) Die Fahrerkarte muss für jeden Kalendertag, an dem die sie
benutzt wurde, sowie für jeden Betriebszeitraum eines
Fahrzeugs an diesem Tag (ein Betriebszeitraum umfasst
alle aufeinander folgenden Einsteck-/Entnahmevorgänge
der Karte in dem Fahrzeug im Hinblick auf diese Karte)
die folgenden Daten speichern können:
— Datum und Uhrzeit des ersten Einsatzes des Fahrzeugs
(d. h. erstes Karteneinstecken für diesen Betriebszeit­
raum des Fahrzeugs oder 0,00 Uhr, wenn der Betriebs­
zeitraum zu diesem Zeitpunkt andauert),
— Kilometerstand zu diesem Zeitpunkt des ersten Einsat­
zes,
— Datum und Uhrzeit des letzten Einsatzes des Fahrzeugs
(d. h. letzte Kartenentnahme für diesen Betriebszeitraum
des Fahrzeugs oder 23,59 Uhr, wenn der Betriebszeit­
raum zu diesem Zeitpunkt andauert),
— Kilometerstand zu diesem Zeitpunkt des letzten Einsat­
zes,
— amtliches Kennzeichen und zulassender Mitgliedstaat,
— Fahrzeug-Identifizierungsnummer.
▼M3
295) Die Fahrerkarte muss 200 derartige Datensätze speichern
können.
▼B
4.5.3.2.11 Ort und Position des Beginns und/oder des Endes des Arbeitstages
296) Die Fahrerkarte muss die folgenden vom Fahrer eingegebe­
nen Daten zum Ort des Beginns und/oder des Endes des
Arbeitstages speichern können:
— Datum und Uhrzeit der Eingabe (oder Datum/Uhrzeit
bezogen auf die Eingabe, wenn diese während des ma­
nuellen Eingabevorgangs erfolgt),
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 84
— Art der Eingabe (Beginn oder Ende, Eingabebedin­
gung),
— eingegebene(s) Land und Region,
— Kilometerstand,
— Position des Fahrzeugs,
— GNSS-Genauigkeit, Datum und Uhrzeit der Feststellung
der Position.
▼M3
297) Der Speicher der Fahrerkarte muss 112 derartige Datensätze
gespeichert halten können.
▼B
4.5.3.2.12 Kartenvorgangsdaten
298) Die Fahrerkarte muss Daten in Bezug auf das Fahrzeug
speichern können, in dem der laufende Vorgang eingeleitet
wurde:
— Datum und Uhrzeit der Einleitung des Vorgangs (d. h.
Einstecken der Karte) auf 1 Sekunde genau,
— amtliches Kennzeichen und zulassender Mitgliedstaat.
4.5.3.2.13 Kontrolltätigkeitsdaten
299) Die Fahrerkarte muss in Bezug auf Kontrolltätigkeiten die
folgenden Daten speichern können:
— Datum und Uhrzeit der Kontrolle,
— Kontrollkartennummer und ausstellender Mitgliedstaat,
— Art der Kontrolle (Anzeige und/oder Drucken und/oder
Herunterladen von der Fahrzeugeinheit und/oder Herun­
terladen von der Karte (siehe Anmerkung)),
— heruntergeladener Zeitraum beim Herunterladen,
— amtliches Kennzeichen und zulassender Mitgliedstaat
des kontrollierten Fahrzeugs.
Anmerkung: Gemäß Sicherheitsanforderungen wird ein He­
runterladen von der Karte nur aufgezeichnet, wenn dies
über ein Kontrollgerät erfolgt.
300) Die Fahrerkarte muss einen derartigen Datensatz gespei­
chert halten können.
4.5.3.2.14 Daten zu spezifischen Bedingungen
301) Die Fahrerkarte muss die folgenden Daten in Bezug auf
spezifische Bedingungen speichern können, die bei einge­
setzter Karte (ungeachtet des Steckplatzes) eingegeben
wurden:
— Datum und Uhrzeit der Eingabe,
— Art der spezifischen Bedingung.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 85
302) Die Fahrerkarte muss 112 derartige Datensätze speichern
können.
▼B
4.5.3.2.15 Daten zu den genutzten Fahrzeugeinheiten
303) Die Fahrerkarte muss die folgenden Daten in Bezug auf die
verschiedenen Fahrzeugeinheiten, in denen die Karte ge­
nutzt wurde, speichern können:
— Datum und Uhrzeit des Beginns des Nutzungszeitraums
der Fahrzeugeinheit (d. h. erstes Einstecken der Karte in
der Fahrzeugeinheit für den Zeitraum),
— Hersteller der Fahrzeugeinheit,
— Typ der Fahrzeugeinheit,
— Softwareversionsnummer der Fahrzeugeinheit.
▼M3
304) Die Fahrerkarte muss 200 derartige Datensätze speichern
können.
▼M1
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.
▼M3
306) Die Fahrerkarte muss 336 derartige Datensätze speichern
können.
4.5.3.2.17 Authentisierungsstatus für Positionen, die sich auf den Ort des Be­
ginns und/oder des Endes der täglichen Arbeitszeit beziehen (nicht
zugänglich für Version 1 von Fahrzeugeinheiten der zweiten Gene­
ration)
306a) Die Fahrerkarte muss zusätzliche Daten zu Orten des Be­
ginns und/oder des Endes des Arbeitstages speichern kön­
nen, die vom Fahrer gemäß Nummer 4.5.3.2.11 eingegeben
wurden:
— Datum und Uhrzeit des Eintrags, die genau dem Datum
und der Uhrzeit entsprechen, die in EF Places unter DF
Tachograph_G2 gespeichert sind,
— Merker, der angibt, ob die Position authentisiert wurde.
306b) Der Speicher der Fahrerkarte muss 112 derartige Datensätze
gespeichert halten können.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 86
4.5.3.2.18 Authentisierungsstatus für Positionen, an denen die kumulierte
Lenkzeit drei Stunden erreicht (nicht zugänglich für Version 1
von Fahrzeugeinheiten der zweiten Generation)
306c) Die Fahrerkarte muss zusätzliche Daten zur Position des
Fahrzeugs speichern können, wenn die kumulierte Lenkzeit
ein Vielfaches von drei Stunden gemäß Nummer 4.5.3.2.16
erreicht:
— Datum und Uhrzeit, wenn die kumulierte Lenkzeit ein
Vielfaches von drei Stunden erreicht, die genau dem Da­
tum und der Uhrzeit entsprechen, die in EF GNSS_Places
unter DF Tachograph_G2 gespeichert sind,
— Merker, der angibt, ob die Position authentisiert wurde.
306d) Die Fahrerkarte muss 336 derartige Datensätze speichern
können.
4.5.3.2.19 Grenzüberschreitungen (nicht zugänglich für Version 1 von Fahr­
zeugeinheiten der zweiten Generation)
306e) Die Fahrerkarte muss die folgenden Daten im Zusammen­
hang mit Grenzüberschreitungen entweder beim Einstecken
der Karte gemäß Randnummer 147b oder mit bereits einge­
steckter Karte speichern können:
— Land, das das Fahrzeug verlässt,
— Land, in das das Fahrzeug einfährt,
— Datum und Uhrzeit der Grenzüberschreitung des Fahr­
zeugs,
— Position des Fahrzeugs zum Zeitpunkt des Überschrei­
tens der Grenze,
— GNSS-Genauigkeit,
— Merker, der angibt, ob die Position authentisiert wurde,
— Kilometerstand.
306f) Der Speicher der Fahrerkarte muss 1120 derartige Daten­
sätze speichern können.
4.5.3.2.20 Be-/Entladevorgänge (nicht zugänglich für Version 1 von Fahrzeug­
einheiten der zweiten Generation)
306g) Die Fahrerkarte muss die folgenden Daten im Zusammen­
hang mit Be-/Entladevorgängen speichern können:
— Art des Vorgangs (Beladen, Entladen oder gleichzeiti­
ges Be- und Entladen),
— Datum und Uhrzeit der Be-/Entladevorgangs,
— Position des Fahrzeugs,
— GNSS-Genauigkeit, Datum und Uhrzeit der Feststellung
der Position,
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 87
— Merker, der angibt, ob die Position authentisiert wurde,
— Kilometerstand.
306h) Die Fahrerkarte muss 1624 Be-/Entladevorgänge speichern
können.
4.5.3.2.21 Eingaben der Art der Ladung (nicht zugänglich für Version 1 von
Fahrzeugeinheiten der zweiten Generation)
306i) Die Fahrerkarte muss die folgenden Daten im Zusammen­
hang mit der Art der Ladung speichern können, die auto­
matisch durch die Fahrzeugeinheit bei jedem Einstecken der
Karte eingegeben wird:
— die eingegebene Art der Ladung (Güter oder Personen),
— Datum und Uhrzeit der Eingabe.
306j) Die Fahrerkarte muss 336 derartige Datensätze speichern
können.
4.5.3.2.22 Konfigurationen der Fahrzeugeinheit (nicht zugänglich für Version 1
von Fahrzeugeinheiten der zweiten Generation)
306k) Die Fahrerkarte muss die spezifischen Einstellungen des
Fahrtenschreibers des Karteninhabers speichern können.
306l) Die Speicherkapazität der Fahrerkarte für spezifische Ein­
stellungen des Fahrtenschreibers des Karteninhabers muss
3072 Bytes betragen.
▼B
4.5.4 Werkstattkarte
4.5.4.1 F a h r t e n s c h r e i b e r a n w e n d u n g ( z u g ä n g l i c h f ü r
F a h r z e u g e i n h e i t e n d e r e r s t e n u n d z w e i t e n G e n e ­
r a t i o n )
4.5.4.1.1 Anwendungskennung
307) Die Werkstattkarten müssen die folgenden Anwendungs­
kenndaten speichern können:
— Kennnummer der Fahrtenschreiberanwendung,
— Art der Fahrtenschreiberkartenkennung.
4.5.4.1.2 Schlüssel und Zertifikate
308) Die Werkstattkarte muss eine Reihe kryptografischer
Schlüssel und Zertifikate gemäß Anlage 11 Teil A spei­
chern können.
309) Die Werkstattkarte muss einen PIN-Code (Personal Identi­
fication Number) speichern können.
4.5.4.1.3 Kartenkennung
310) Die Werkstattkarte muss die folgenden Kartenkenndaten
speichern können:
— Kartennummer,
— ausstellender Mitgliedstaat, Name der ausstellenden Be­
hörde, Ausstellungsdatum,
— gültig ab, gültig bis.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 88
4.5.4.1.4 Karteninhaberkennung
311) Die Werkstattkarte muss die folgenden Karteninhaberkenn­
daten speichern können:
— Name der Werkstatt,
— Anschrift der Werkstatt.
— Name des Karteninhabers,
— Vorname(n) des Karteninhabers,
— bevorzugte Sprache.
4.5.4.1.5 Herunterladen von der Karte
312) Die Werkstattkarte muss einen von der Karte heruntergela­
denen Datensatz so speichern können wie eine Fahrerkarte.
4.5.4.1.6 Kalibrierungs- und Zeiteinstellungsdaten
313) Die Werkstattkarte muss Datensätze zu Kalibrierungen und/
oder Zeiteinstellungen gespeichert halten können, die aus­
geführt werden, während die Karte in einem Kontrollgerät
eingesteckt ist.
314) In jedem Kalibrierungsdatensatz müssen folgende Daten
enthalten sein:
— Zweck der Kalibrierung (Aktivierung, Ersteinbau, Ein­
bau, regelmäßige Nachprüfung),
— Fahrzeugkennung,
— aktualisierte oder bestätigte Parameter (Wegdrehzahl,
Kontrollgerätkonstante, tatsächlicher Reifenumfang,
Reifengröße, Einstellung des Geschwindigkeitsbegren­
zers, Kilometerstand (alt und neu), Datum und Uhrzeit
(alte und neue Werte),
— Kontrollgerätkennung (VU-Teilnummer, VU-Serien­
nummer, Seriennummer des Bewegungssensors).
315) Die Werkstattkarte muss mindestens 88 derartige Daten­
sätze speichern können.
316) Die Werkstattkarte führt einen Zähler, der die Gesamtzahl
der mit der Karte ausgeführten Kalibrierungen angibt.
317) Die Werkstattkarte führt einen Zähler, der die Anzahl der
seit dem letzten Herunterladen durchgeführten Kalibrierun­
gen angibt.
4.5.4.1.7 Ereignis- und Störungsdaten
318) Die Werkstattkarte muss Ereignis- und Störungsdaten so
speichern können wie eine Fahrerkarte.
319) Die Werkstattkarte muss Daten für die drei jüngsten Ereig­
nisse jeder Art (d. h. 18 Ereignisse) sowie die sechs jüngs­
ten Störungen jeder Art (d. h. 12 Störungen) speichern
können.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 89
4.5.4.1.8 Fahrertätigkeitsdaten
320) Die Werkstattkarte muss Fahrertätigkeitsdaten so speichern
können wie eine Fahrerkarte.
321) Die Werkstattkarte muss Fahrertätigkeitsdaten für mindes­
tens 1 Tag mit durchschnittlicher Tätigkeit eines Fahrers
gespeichert halten können.
4.5.4.1.9 Daten zu gefahrenen Fahrzeugen
322) Die Werkstattkarte muss Datensätze zu gefahrenen Fahr­
zeugen so speichern können wie eine Fahrerkarte.
323) Die Werkstattkarte muss mindestens 4 derartige Datensätze
speichern können.
4.5.4.1.10 Daten zum Beginn und/oder Ende des Arbeitstages
324) Die Werkstattkarte muss Datensätze zum Beginn und/oder
Ende des Arbeitstages so speichern können wie eine Fah­
rerkarte.
325) Die Werkstattkarte muss mindestens 3 derartige Datensatz­
paare gespeichert halten können.
4.5.4.1.11 Kartenvorgangsdaten
326) Die Werkstattkarte muss einen Kartenvorgang so speichern
können wie eine Fahrerkarte.
4.5.4.1.12 Kontrolltätigkeitsdaten
327) Die Werkstattkarte muss einen Kontrolltätigkeitsdatensatz
so speichern können wie eine Fahrerkarte.
4.5.4.1.13 Daten zu spezifischen Bedingungen
328) Die Werkstattkarte muss Daten in Bezug auf spezifische
Bedingungen so wie die Fahrerkarte speichern können.
329) Die Werkstattkarte muss mindestens 2 derartige Datensätze
speichern können.
▼M3
4.5.4.2 F a h r t e n s c h r e i b e r a n w e n d u n g d e r z w e i t e n G e n e ­
r a t i o n ( n i c h t z u g ä n g l i c h f ü r F a h r z e u g e i n h e i t e n
d e r e r s t e n G e n e r a t i o n , z u g ä n g l i c h f ü r V e r s i o n 1
u n d V e r s i o n 2 v o n F a h r z e u g e i n h e i t e n d e r z w e i ­
t e n G e n e r a t i o n )
▼B
4.5.4.2.1 Anwendungskennung
330) Die Werkstattkarten müssen die folgenden Anwendungs­
kenndaten speichern können:
— Kennnummer der Fahrtenschreiberanwendung,
— Art der Fahrtenschreiberkartenkennung.
▼M3
4.5.4.2.1.1 Zusätzliche Anwendungskennung (nicht zugänglich für Version 1
von Fahrzeugeinheiten der zweiten Generation)
330a) Die Werkstattkarte muss zusätzliche Anwendungskenndaten
speichern können, die nur für Version 2 anwendbar sind.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 90
4.5.4.2.2 Schlüssel und Zertifikate
331) Die Werkstattkarte muss eine Reihe kryptografischer
Schlüssel und Zertifikate gemäß Anlage 11 Teil A spei­
chern können.
332) Die Werkstattkarte muss einen PIN-Code (Personal Identi­
fication Number) speichern können.
4.5.4.2.3 Kartenkennung
333) Die Werkstattkarte muss die folgenden Kartenkenndaten
speichern können:
— Kartennummer,
— ausstellender Mitgliedstaat, Name der ausstellenden Be­
hörde, Ausstellungsdatum,
— gültig ab, gültig bis.
4.5.4.2.4 Karteninhaberkennung
334) Die Werkstattkarte muss die folgenden Karteninhaberkenn­
daten speichern können:
— Name der Werkstatt,
— Anschrift der Werkstatt.
— Name des Karteninhabers,
— Vorname(n) des Karteninhabers,
— bevorzugte Sprache.
4.5.4.2.5 Herunterladen von der Karte
335) Die Werkstattkarte muss einen von der Karte heruntergela­
denen Datensatz so speichern können wie eine Fahrerkarte.
4.5.4.2.6 Kalibrierungs- und Zeiteinstellungsdaten
336) Die Werkstattkarte muss Datensätze zu Kalibrierungen und/
oder Zeiteinstellungen gespeichert halten können, die aus­
geführt werden, während die Karte in einem Kontrollgerät
eingesteckt ist.
337) In jedem Kalibrierungsdatensatz müssen folgende Daten
enthalten sein:
— Zweck der Kalibrierung (Aktivierung, Ersteinbau, Ein­
bau, regelmäßige Nachprüfung),
— Fahrzeugkennung,
— aktualisierte oder bestätigte Parameter (Wegdrehzahl,
Kontrollgerätkonstante, tatsächlicher Reifenumfang,
Reifengröße, Einstellung des Geschwindigkeitsbegren­
zers, Kilometerstand (alt und neu), Datum und Uhrzeit
(alte und neue Werte),
— Kontrollgerätkennung (VU-Teilnummer, VU-Serien­
nummer, Seriennummer des Bewegungssensors, Serien­
nummer der Fernkommunikationsausrüstung und Seri­
ennummer der externen GNSS-Ausrüstung, falls zutref­
fend),
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 91
— Typ und Kennung aller vorhandenen Plombierungen,
— Fähigkeit der Fahrzeugeinheit, aktivierte oder nicht ak­
tivierte Fahrtenschreiberkarten der ersten Generation zu
nutzen.
▼M3
338) Die Werkstattkarte muss 255 derartige Datensätze speichern
können.
▼B
339) Die Werkstattkarte führt einen Zähler, der die Gesamtzahl
der mit der Karte ausgeführten Kalibrierungen angibt.
340) Die Werkstattkarte führt einen Zähler, der die Anzahl der
seit dem letzten Herunterladen durchgeführten Kalibrierun­
gen angibt.
4.5.4.2.7 Ereignis- und Störungsdaten
341) Die Werkstattkarte muss Ereignis- und Störungsdaten so
speichern können wie eine Fahrerkarte.
342) Die Werkstattkarte muss Daten für die drei jüngsten Ereig­
nisse jeder Art (d. h. 33 Ereignisse) sowie die sechs jüngs­
ten Störungen jeder Art (d. h. 12 Störungen) speichern
können.
4.5.4.2.8 Fahrertätigkeitsdaten
343) Die Werkstattkarte muss Fahrertätigkeitsdaten so speichern
können wie eine Fahrerkarte.
▼M3
344) Die Werkstattkarte muss Fahrertätigkeitsdaten für 1 Tag mit
240 Tätigkeitsveränderungen gespeichert halten können.
▼B
4.5.4.2.9 Daten zu gefahrenen Fahrzeugen
345) Die Werkstattkarte muss Datensätze zu gefahrenen Fahr­
zeugen so speichern können wie eine Fahrerkarte.
▼M3
346) Die Werkstattkarte muss 8 derartige Datensätze speichern
können.
4.5.4.2.10 Daten der Orte und Positionen, an denen der Arbeitstag beginnt
und/oder endet
347) Die Werkstattkarte muss Orte und Positionen, an denen der
Arbeitstag beginnt und/oder endet, so speichern können wie
eine Fahrerkarte.
348) Die Werkstattkarte muss 4 derartige Datensatzpaare spei­
chern können.
▼B
4.5.4.2.11 Kartenvorgangsdaten
349) Die Werkstattkarte muss einen Kartenvorgang so speichern
können wie eine Fahrerkarte.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 92
4.5.4.2.12 Kontrolltätigkeitsdaten
350) Die Werkstattkarte muss einen Kontrolltätigkeitsdatensatz
so speichern können wie eine Fahrerkarte.
4.5.4.2.13 Daten zu den genutzten Fahrzeugeinheiten
351) Die Werkstattkarte muss die folgenden Daten in Bezug auf
die verschiedenen Fahrzeugeinheiten, in denen die Karte
genutzt wurde, speichern können:
— Datum und Uhrzeit des Beginns des Nutzungszeitraums
der Fahrzeugeinheit (d. h. erstes Einstecken der Karte in
der Fahrzeugeinheit für den Zeitraum),
— Hersteller der Fahrzeugeinheit,
— Typ der Fahrzeugeinheit,
— Softwareversionsnummer der Fahrzeugeinheit.
▼M3
352) Die Werkstattkarte muss 8 derartige Datensätze speichern
können.
▼M1
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.
▼M3
354) Die Werkstattkarte muss 24 derartige Datensätze speichern
können.
▼B
4.5.4.2.15 Daten zu spezifischen Bedingungen
355) Die Werkstattkarte muss Daten in Bezug auf spezifische
Bedingungen so wie die Fahrerkarte speichern können.
▼M3
356) Die Werkstattkarte muss 4 derartige Datensätze speichern
können.
4.5.4.2.16 Authentisierungsstatus für Positionen, die sich auf den Ort des Be­
ginns und/oder des Endes der täglichen Arbeitszeit beziehen (nicht
zugänglich für Version 1 von Fahrzeugeinheiten der zweiten Gene­
ration)
356a) Die Werkstattkarte muss zusätzliche Daten, die sich auf
Orte beziehen, an denen der Arbeitstag beginnt und/oder
endet, so speichern können wie eine Fahrerkarte.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 93
356b) Der Speicher der Werkstattkarte muss 4 derartige Daten­
satzpaare speichern können.
4.5.4.2.17 Authentisierungsstatus für Positionen, an denen die kumulierte
Lenkzeit drei Stunden erreicht (nicht zugänglich für Version 1
von Fahrzeugeinheiten der zweiten Generation)
356c) Die Werkstattkarte muss zusätzliche Daten zur Position des
Fahrzeugs, wenn die kumulierte Lenkzeit ein Vielfaches
von drei Stunden erreicht, so speichern können wie eine
Fahrerkarte.
356d) Die Werkstattkarte muss 24 derartige Datensätze speichern
können.
4.5.4.2.18 Grenzüberschreitungen (nicht zugänglich für Version 1 von Fahr­
zeugeinheiten der zweiten Generation)
356e) Die Werkstattkarte muss Grenzüberschreitungen so spei­
chern können wie eine Fahrerkarte.
356f) Der Speicher der Werkstattkarte muss 4 derartige Daten­
sätze speichern können.
4.5.4.2.19 Be-/Entladevorgänge (nicht zugänglich für Version 1 von Fahrzeug­
einheiten der zweiten Generation)
356g) Die Werkstattkarte muss Be-/Entladevorgänge so speichern
können wie eine Fahrerkarte.
356h) Die Werkstattkarte muss 8 Beladevorgänge, Entladevor­
gänge oder gleichzeitige Be-/Entladevorgänge speichern
können.
4.5.4.2.20 Eingaben der Art der Ladung (nicht zugänglich für Version 1 von
Fahrzeugeinheiten der zweiten Generation)
356i) Die Werkstattkarte muss Eingaben der Art der Ladung so
speichern können wie eine Fahrerkarte.
356j) Die Werkstattkarte muss 4 derartige Datensätze speichern
können.
4.5.4.2.21 Zusätzliche Kalibrierungsdaten (nicht zugänglich für Version 1 von
Fahrzeugeinheiten der zweiten Generation)
356k) Die Werkstattkarte muss zusätzliche Kalibrierungsdaten
speichern können, die nur für Version 2 anwendbar sind:
— das alte Datum und die alte Uhrzeit sowie die Fahr­
zeugidentifizierungsnummer, die genau den Werten ent­
sprechen, die in EF Calibration unter DF Tacho­
graph_G2 gespeichert sind,
— die bei dieser Kalibrierung eingegebene standardmäßige
Art der Ladung,
— das Land, in dem die Kalibrierung durchgeführt wurde,
und das Datum, an dem die Position, die zur Bestim­
mung dieses Landes verwendet wurde, vom GNSS-
Empfänger bereitgestellt wurde.
356l) Die Werkstattkarte muss 255 derartige Datensätze speichern
können.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 94
4.5.4.2.22 Konfigurationen der Fahrzeugeinheit (nicht zugänglich für Version 1
von Fahrzeugeinheiten der zweiten Generation)
356m) Die Werkstattkarte muss die spezifischen Einstellungen des
Fahrtenschreibers des Karteninhabers speichern können.
356n) Die Speicherkapazität der Werkstattkarte für spezifische
Einstellungen des Fahrtenschreibers des Karteninhabers
muss 3072 Bytes betragen.
▼B
4.5.5 Kontrollkarte
4.5.5.1 F a h r t e n s c h r e i b e r a n w e n d u n g ( z u g ä n g l i c h f ü r F a h r ­
z e u g e i n h e i t e n d e r e r s t e n u n d z w e i t e n G e n e r a t i o n )
4.5.5.1.1 Anwendungskennung
357) Die Kontrollkarte muss die folgenden Anwendungskenn­
daten speichern können:
— Kennnummer der Fahrtenschreiberanwendung,
— Art der Fahrtenschreiberkartenkennung.
4.5.5.1.2 Schlüssel und Zertifikate
358) Die Kontrollkarte muss eine Reihe kryptografischer Schlüs­
sel und Zertifikate gemäß Anlage 11 Teil A speichern kön­
nen.
4.5.5.1.3 Kartenkennung
359) Die Kontrollkarte muss die folgenden Kartenkenndaten
speichern können:
— Kartennummer,
— ausstellender Mitgliedstaat, Name der ausstellenden Be­
hörde, Ausstellungsdatum,
— gültig ab, gültig bis (wenn zutreffend).
4.5.5.1.4 Karteninhaberkennung
360) Die Kontrollkarte muss die folgenden Karteninhaberkenn­
daten speichern können:
— Name der Kontrollstelle,
— Anschrift der Kontrollstelle,
— Name des Karteninhabers,
— Vorname(n) des Karteninhabers,
— bevorzugte Sprache.
4.5.5.1.5 Kontrolltätigkeitsdaten
361) Die Kontrollkarte muss die folgenden Daten in Bezug auf
Kontrolltätigkeiten speichern können:
— Datum und Uhrzeit der Kontrolle,
▼M3
— Art der Kontrolle (Anzeigen und/oder Drucken und/
oder Herunterladen von der Fahrzeugeinheit und/oder
Herunterladen von der Karte),
▼B
— heruntergeladener Zeitraum (wenn zutreffend),
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 95
— amtliches Kennzeichen und zulassender Mitgliedstaat
des kontrollierten Fahrzeugs,
— Kartennummer und ausstellender Mitgliedstaat der kon­
trollierten Fahrerkarte.
362) Die Kontrollkarte muss mindestens 230 derartige Daten­
sätze gespeichert halten können.
4.5.5.2 F a h r t e n s c h r e i b e r a n w e n d u n g G 2 ( f ü r F a h r z e u g ­
e i n h e i t e n d e r e r s t e n G e n e r a t i o n n i c h t z u g ä n g ­
l i c h )
4.5.5.2.1 Anwendungskennung
363) Die Kontrollkarte muss die folgenden Anwendungskenn­
daten speichern können:
— Kennnummer der Fahrtenschreiberanwendung,
— Art der Fahrtenschreiberkartenkennung.
▼M3
4.5.5.2.1.1 Zusätzliche Anwendungskennung (nicht zugänglich für Version 1
von Fahrzeugeinheiten der zweiten Generation)
363a) Die Kontrollkarte muss zusätzliche Anwendungskenndaten
speichern können, die nur für Version 2 anwendbar sind.
▼B
4.5.5.2.2 Schlüssel und Zertifikate
364) Die Kontrollkarte muss eine Reihe kryptografischer Schlüs­
sel und Zertifikate gemäß Anlage 11 Teil B speichern kön­
nen.
4.5.5.2.3 Kartenkennung
365) Die Kontrollkarte muss die folgenden Kartenkenndaten
speichern können:
— Kartennummer,
— ausstellender Mitgliedstaat, Name der ausstellenden Be­
hörde, Ausstellungsdatum,
— gültig ab, gültig bis (wenn zutreffend).
4.5.5.2.4 Karteninhaberkennung
366) Die Kontrollkarte muss die folgenden Karteninhaberkenn­
daten speichern können:
— Name der Kontrollstelle,
— Anschrift der Kontrollstelle,
— Name des Karteninhabers,
— Vorname(n) des Karteninhabers,
— bevorzugte Sprache.
4.5.5.2.5 Kontrolltätigkeitsdaten
367) Die Kontrollkarte muss die folgenden Daten in Bezug auf
Kontrolltätigkeiten speichern können:
— Datum und Uhrzeit der Kontrolle,
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 96
— Art der Kontrolle (Anzeige und/oder Drucken und/oder
Herunterladen von der Fahrzeugeinheit und/oder Herun­
terladen von der Karte und/oder straßenseitige Kali­
brierprüfung),
— heruntergeladener Zeitraum (wenn zutreffend),
— amtliches Kennzeichen und zulassender Mitgliedstaat
des kontrollierten Fahrzeugs,
— Kartennummer und ausstellender Mitgliedstaat der kon­
trollierten Fahrerkarte.
368) Die Kontrollkarte muss mindestens 230 derartige Daten­
sätze gespeichert halten können.
▼M3
4.5.5.2.6 Konfigurationen der Fahrzeugeinheit (nicht zugänglich für Version 1
von Fahrzeugeinheiten der zweiten Generation)
368a) Die Kontrollkarte muss die spezifischen Einstellungen des
Fahrtenschreibers des Karteninhabers speichern können.
368b) Die Speicherkapazität der Kontrollkarte für spezifische Ein­
stellungen des Fahrtenschreibers des Karteninhabers muss
3072 Bytes betragen.
▼B
4.5.6 Unternehmenskarte
4.5.6.1 F a h r t e n s c h r e i b e r a n w e n d u n g ( z u g ä n g l i c h f ü r F a h r ­
z e u g e i n h e i t e n d e r e r s t e n u n d z w e i t e n G e n e r a t i o n )
4.5.6.1.1 Anwendungskennung
369) Die Unternehmenskarte muss die folgenden Anwendungs­
kenndaten speichern können:
— Kennnummer der Fahrtenschreiberanwendung,
— Art der Fahrtenschreiberkartenkennung.
4.5.6.1.2 Schlüssel und Zertifikate
370) Die Unternehmenskarte muss eine Reihe kryptografischer
Schlüssel und Zertifikate gemäß Anlage 11 Teil A spei­
chern können.
4.5.6.1.3 Kartenkennung
371) Die Unternehmenskarte muss die folgenden Kartenkenn­
daten speichern können:
— Kartennummer,
— ausstellender Mitgliedstaat, Name der ausstellenden Be­
hörde, Ausstellungsdatum,
— gültig ab, gültig bis (wenn zutreffend).
4.5.6.1.4 Karteninhaberkennung
372) Die Unternehmenskarte muss die folgenden Karteninhaber­
kenndaten speichern können:
— Name des Unternehmens,
— Anschrift des Unternehmens.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 97
4.5.6.1.5 Unternehmensaktivitätsdaten
373) Die Unternehmenskarte muss die folgenden Daten in Bezug
auf Unternehmensaktivitäten speichern können:
— Datum und Uhrzeit der Aktivität,
— Art der Aktivität (Sperren/Entsperren der Fahrzeugein­
heit und/oder Herunterladen von der Fahrzeugeinheit
und/oder Herunterladen von der Karte),
— heruntergeladener Zeitraum (wenn zutreffend),
— amtliches Kennzeichen und Zulassungsbehörde des Mit­
gliedstaates des Fahrzeugs,
— Kartennummer und ausstellender Mitgliedstaat (beim
Herunterladen von der Karte).
374) Die Unternehmenskarte muss mindestens 230 derartige Da­
tensätze gespeichert halten können.
4.5.6.2 F a h r t e n s c h r e i b e r a n w e n d u n g G 2 ( f ü r F a h r z e u g e i n ­
h e i t e n d e r e r s t e n G e n e r a t i o n n i c h t z u g ä n g l i c h )
4.5.6.2.1 Anwendungskennung
375) Die Unternehmenskarte muss die folgenden Anwendungs­
kenndaten speichern können:
— Kennnummer der Fahrtenschreiberanwendung,
— Art der Fahrtenschreiberkartenkennung.
▼M3
4.5.6.2.1.1 Zusätzliche Anwendungskennung (nicht zugänglich für Version 1
von Fahrzeugeinheiten der zweiten Generation)
375a) Die Unternehmenskarte muss zusätzliche Anwendungs­
kenndaten speichern können, die nur für Version 2 anwend­
bar sind.
▼B
4.5.6.2.2 Schlüssel und Zertifikate
376) Die Unternehmenskarte muss eine Reihe kryptografischer
Schlüssel und Zertifikate gemäß Anlage 11 Teil B spei­
chern können.
4.5.6.2.3 Kartenkennung
377) Die Unternehmenskarte muss die folgenden Kartenkenn­
daten speichern können:
— Kartennummer,
— ausstellender Mitgliedstaat, Name der ausstellenden Be­
hörde, Ausstellungsdatum,
— gültig ab, gültig bis (wenn zutreffend).
4.5.6.2.4 Karteninhaberkennung
378) Die Unternehmenskarte muss die folgenden Karteninhaber­
kenndaten speichern können:
— Name des Unternehmens,
— Anschrift des Unternehmens.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 98
4.5.6.2.5 Unternehmensaktivitätsdaten
379) Die Unternehmenskarte muss die folgenden Daten in Bezug
auf Unternehmensaktivitäten speichern können:
— Datum und Uhrzeit der Aktivität,
— Art der Aktivität (Sperren/Entsperren der Fahrzeugein­
heit und/oder Herunterladen von der Fahrzeugeinheit
und/oder Herunterladen von der Karte),
— heruntergeladener Zeitraum (wenn zutreffend),
— amtliches Kennzeichen und Zulassungsbehörde des Mit­
gliedstaates des Fahrzeugs,
— Kartennummer und ausstellender Mitgliedstaat (beim
Herunterladen von der Karte).
380) Die Unternehmenskarte muss mindestens 230 derartige Da­
tensätze gespeichert halten können.
▼M3
4.5.6.2.6 Konfigurationen der Fahrzeugeinheit (nicht zugänglich für Version 1
von Fahrzeugeinheiten der zweiten Generation)
380a) Die Unternehmenskarte muss die spezifischen Einstellun­
gen des Fahrtenschreibers des Karteninhabers speichern
können.
380b) Die Speicherkapazität der Unternehmenskarte für spezi­
fische Einstellungen des Fahrtenschreibers des Karteninha­
bers muss 3072 Bytes betragen.
▼B
5 EINBAU EINES KONTROLLGERÄTS
5.1 Einbau
381) Neue Kontrollgeräte werden in nicht aktiviertem Zustand an
Einbaubetriebe oder Fahrzeughersteller geliefert, wobei alle
in Kapitel 3.21 aufgeführten Kalibrierungsparameter auf
geeignete und gültige Standardwerte eingestellt sind. Liegt
kein bestimmter Wert vor, sind Buchstaben-Parameter auf
Strings mit „?“ und numerische Parameter auf „0“zu setzen.
Die Auslieferung sicherheitsrelevanter Teile des Kontroll­
geräts kann erforderlichenfalls während der Sicherheitszer­
tifizierung eingeschränkt werden.
382) Vor seiner Aktivierung muss das Kontrollgerät den Zugang
zur Kalibrierfunktion gewähren, auch wenn es sich nicht in
der Betriebsart Kalibrierung befindet.
▼M3
383) Vor seiner Aktivierung darf das Kontrollgerät die in den
Randnummern 102 bis 133 genannten Daten weder auf­
zeichnen noch speichern. Das Kontrollgerät darf jedoch
vor seiner Aktivierung Ereignisse eines Versuchs der Si­
cherheitsverletzung gemäß Randnummer 117 und Störun­
gen des Kontrollgeräts gemäß Randnummer 118 aufzeich­
nen und speichern.
▼B
384) Während des Einbaus werden alle bekannten Parameter
vom Fahrzeughersteller voreingestellt.
385) Der Fahrzeughersteller oder Einbaubetrieb aktiviert das ein­
gebaute Kontrollgerät spätestens, bevor das Fahrzeug im
Anwendungsbereich der Verordnung (EG) Nr. 561/2006
betrieben wird.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 99
386) Die Aktivierung des Kontrollgeräts wird durch das erst­
malige Einstecken einer gültigen Werkstattkarte in eine
der beiden Kartenschnittstellen automatisch ausgelöst.
387) Gegebenenfalls erforderliche spezifische Koppelungsopera­
tionen zwischen dem Bewegungssensor und der Fahrzeug­
einheit müssen automatisch vor oder während der Aktivie­
rung stattfinden.
388) Ebenso müssen gegebenenfalls erforderliche spezifische
Kopplungsoperationen zwischen der externen GNSS-Aus­
rüstung und der Fahrzeugeinheit automatisch vor oder wäh­
rend der Aktivierung stattfinden.
389) Nach seiner Aktivierung sorgt das Kontrollgerät für die
vollständige Anwendung aller Funktionen und Daten­
zugriffsrechte.
390) Nach seiner Aktivierung kommuniziert das Kontrollgerät
der Fernkommunikationsausrüstung die gesicherten Daten,
die für die Zwecke der gezielten Straßenkontrollen erfor­
derlich sind.
391) Die Aufzeichnungs- und Speicherfunktion des Kontroll­
geräts muss nach seiner Aktivierung voll wirksam sein.
▼M3
392) Nach dem Einbau erfolgt eine Kalibrierung. Bei der Erst­
kalibrierung wird die Fahrzeugregistrierungskennung (amt­
liches Kennzeichen und Mitgliedstaat) nicht notwendiger­
weise eingegeben, wenn sie der mit der Kalibrierung beauf­
tragten zugelassenen Werkstatt nicht bekannt ist. Unter die­
sen Umständen und nur zu diesem Zeitpunkt muss der
Fahrzeugeigentümer die Möglichkeit haben, unter Verwen­
dung seiner Unternehmenskarte das amtliche Kennzeichen
und den Mitgliedstaat des Fahrzeugs einzugeben (beispiels­
weise mittels Befehlen in einer geeigneten Menüstruktur
der Mensch-Maschine-Schnittstelle der Fahrzeugeinheit),
bevor das Fahrzeug im Geltungsbereich der Verordnung
(EG) Nr. 561/2006 betrieben wird. Eine Aktualisierung
oder Bestätigung dieser Eingabe ist nur unter Verwendung
einer Werkstattkarte möglich.
▼B
393) Der Einbau einer externen GNSS-Ausrüstung erfordert die
Kopplung mit der Fahrzeugeinheit und die nachträgliche
Überprüfung der GNSS-Positionsdaten.
394) Das Kontrollgerät ist im Fahrzeug so anzubringen, dass für
den Fahrer alle notwendigen Funktionen vom Fahrersitz aus
zugänglich sind.
5.2 Einbauplakette
395) ►M3 Nach der Einbauprüfung beim Ersteinbau wird auf
dem Kontrollgerät deutlich sichtbar und leicht zugänglich
eine eingravierte oder dauerhaft aufgedruckte Einbaupla­
kette angebracht. Falls dies nicht möglich ist, wird die Pla­
kette deutlich sichtbar an der B-Säule des Fahrzeugs an­
gebracht. Bei Fahrzeugen ohne B-Säule sollte die Einbau­
plakette am Türrahmen der Fahrerseite des Fahrzeugs an­
gebracht werden und in jedem Fall deutlich sichtbar
sein. ◄
Nach jedem Eingriff eines zugelassenen Einbaubetriebs
oder einer zugelassenen Werkstatt ist die Einbauplakette
durch eine neue Plakette zu ersetzen.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 100
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 Kraftfahr­
zeugs und des tatsächlichen Reifenumfangs,
— Fahrzeugidentifizierungsnummer,
— externe GNSS-Ausrüstung (vorhanden/nicht vorhan­
den),
— ggf. Seriennummer der externen GNSS-Ausrüstung,
▼M3
— ggf. Seriennummer der Fernkommunikationsausrüstung,
▼M1
— Seriennummer aller vorhandenen Plombierungen,
— Fahrzeugteil, in dem der Adapter gegebenenfalls einge­
baut 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.
▼M3
— die dem Fahrzeug zugeordnete standardmäßige Art der
Ladung (Güter oder Personen).
▼B
397) Nur bei Fahrzeugen der Klassen M1 und N1, die gemäß der
Verordnung (EG) Nr. 68/2009 der Kommission ( 1 ) in der
zuletzt geänderten Fassung mit einem Adapter ausgestattet
sind und bei denen nicht alle nötigen Informationen nach
Randnummer 396 aufgenommen werden können, kann eine
zweite, zusätzliche Einbauplakette verwendet werden. In
diesen Fällen muss die zusätzliche Plakette mindestens
die letzten vier in Randnummer 396 aufgeführten Spiegel­
striche enthalten.
▼M1
( 1 ) Verordnung (EG) Nr. 68/2009 der Kommission vom 23. Januar 2009 zur neunten An­
passung der Verordnung (EWG) Nr. 3821/85 des Rates über das Kontrollgerät im Stra­
ßenverkehr an den technischen Fortschritt (ABl. L 21 vom 24.1.2009, S. 3).
02016R0799 — DE — 21.08.2023 — 003.002 — 101
Falls diese zweite, zusätzliche Plakette verwendet wird, ist
sie an oder neben der ersten, in Randnummer 396 beschrie­
benen Hauptplakette anzubringen; sie muss das gleiche
Schutzniveau haben. Daneben muss die zweite Plakette
ebenfalls Name, Anschrift oder Firmenzeichen des zugelas­
senen Einbaubetriebs oder der zugelassenen Werkstatt, der
bzw. die den Einbau vorgenommen hat, sowie das Datum
des Einbaus tragen.
5.3 Plombierung
398) Folgende Geräteteile müssen plombiert werden:
— jeder Anschluss, sofern es bei einer Trennung der Ver­
bindung zu nicht nachweisbaren Änderungen oder nicht
feststellbaren Datenverlusten kommen würde (dies kann
beispielsweise für den Einbau des Bewegungssensors
am Getriebe, den Adapter für Fahrzeuge der Klassen
M1/N1, die externe GNSS-Verbindung oder die Fahr­
zeugeinheit gelten);
— die Einbauplakette, es sei denn, sie ist so angebracht,
dass sie sich nicht ohne Vernichtung der Angaben ent­
fernen lässt.
▼M1
398a) Die vorstehend genannten Plombierungen müssen nach
EN 16882:2016 zertifiziert sein.
▼B
399) Die genannten Plombierungen dürfen entfernt werden:
— in Notfällen,
— um einen Geschwindigkeitsbegrenzer oder ein anderes
der Sicherheit im Straßenverkehr dienendes Gerät ein­
zubauen, zu justieren oder zu reparieren, sofern das
Kontrollgerät auch dann noch zuverlässig und ord­
nungsgemäß arbeitet und von einem zugelassenen Ein­
baubetrieb oder einer zugelassenen Werkstatt (gemäß
Kapitel 6) unmittelbar nach dem Einbau des Geschwin­
digkeitsbegrenzers bzw. eines anderen der Sicherheit im
Straßenverkehr dienenden Gerätes oder andernfalls spä­
testens nach sieben Tagen wieder plombiert wird.
400) Jede Verletzung der Plombierung muss Gegenstand einer
schriftlichen Begründung sein, die der zuständigen Behörde
zur Verfügung zu halten ist.
401) Die Plombierungen müssen eine von ihrem Hersteller zu­
geteilte Kennnummer tragen. Diese Nummer ist einmalig
und unterscheidet sich von allen anderen Plombierungs­
nummern, die von anderen Herstellern zugeteilt wurden.
▼M1
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 Herstel­
lers einmalige alphanumerische Nummer der Plombierung.
▼B
402) Die Plombierungen müssen über eine freie Stelle verfügen,
an der zugelassene Einbaubetriebe, Werkstätten oder Fahr­
zeughersteller ein besonderes Zeichen gemäß Artikel 22
Absatz 3 der Verordnung (EU) Nr. 165/2014 anbringen
können.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 102
Dieses Zeichen darf die Kennnummer der Plombierung
nicht überdecken.
▼M1
403) Die Plombenhersteller werden in einer speziellen Daten­
bank 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.
404) Die zugelassenen Werkstätten und Fahrzeughersteller ver­
wenden 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.
▼B
405) Die Hersteller der Plombierungen und ihre Händler führen um­
fassende Aufzeichnungen zur Rückverfolgbarkeit der zur Ver­
wendung im Rahmen der Verordnung (EU) Nr. 165/2014 ver­
kauften Plombierungen und müssen bereit sein, diese den zu­
ständigen nationalen Behörden erforderlichenfalls vorzulegen.
406) Die einmaligen Identifikationsnummern der Plombierungen
müssen auf der Einbauplakette sichtbar sein.
6 EINBAUPRÜFUNGEN, NACHPRÜFUNGEN UND REPARATU­
REN
Die in Artikel 22 Absatz 5 der Verordnung (EU) Nr. 165/2014 ge­
nannten Umstände, unter denen die Plombierungen entfernt werden
dürfen, sind in Kapitel 5.3 dieses Anhangs festgelegt.
6.1 Zulassung der Einbaubetriebe, Werkstätten und Fahrzeugher­
steller
Die Mitgliedstaaten übernehmen die Zulassung, regelmäßige Kon­
trolle und Zertifizierung der Stellen, die
— den Einbau,
— Einbauprüfungen,
— Nachprüfungen und
— Reparaturen vornehmen.
Werkstattkarten werden, sofern keine entsprechende Begründung
erfolgt, nur an für die Aktivierung und/oder Kalibrierung des Kon­
trollgeräts gemäß diesem Anhang zugelassene Einbaubetriebe und/
oder Werkstätten ausgegeben,
— die keinen Anspruch auf eine Unternehmenskarte haben
— und deren sonstige unternehmerische Tätigkeit keine potenzielle
Gefährdung der Gesamtsicherheit des Systems nach Anlage 10
darstellt.
▼M1
6.2 Prüfung neuer oder reparierter Komponenten
407) Für jedes neue oder reparierte Einzelgerät werden die ord­
nungsgemäße Arbeitsweise und die Genauigkeit der Anzei­
gen und Aufzeichnungen innerhalb der in den Kapi­
teln 3.2.1, 3.2.2, 3.2.3 und 3.3 festgelegten Grenzen ge­
prüft.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 103
6.3 Einbauprüfung
▼M1
408) Beim Einbau in ein Fahrzeug muss die Gesamtanlage (ein­
schließ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äs­
sigen Fehlergrenzen entsprechen. Die Gesamtanlage ist ge­
mäß Kapitel 5.3 zu plombieren und muss eine Kalibrierung
umfassen.
▼B
6.4 Regelmäßige Nachprüfungen
▼M3
409) Regelmäßige Nachprüfungen der im Kraftfahrzeug einge­
bauten Ausrüstung erfolgen nach jeder Reparatur der Aus­
rüstung, jeder Änderung der Wegdrehzahl oder des tatsäch­
lichen Reifenumfangs, wenn die UTC-Zeit von der korrek­
ten Zeit um mehr als 5 Minuten abweicht oder wenn sich
das amtliche Kennzeichen geändert hat, und mindestens
einmal innerhalb von zwei Jahren (24 Monaten) seit der
letzten Nachprüfung.
▼B
410) Überprüft wird zumindest:
— die ordnungsgemäße Arbeitsweise des Kontrollgeräts,
einschließlich der Funktion Datenspeicherung auf Fahr­
tenschreiberkarten und der Kommunikation mit Fern­
abfragegeräten,
— die Einhaltung der Bestimmungen von Kapitel 3.2.1
und 3.2.2 über die zulässigen Fehlergrenzen des Geräts
in eingebautem Zustand,
— die Einhaltung der Bestimmungen von Kapitel 3.2.3
und 3.3,
— das Vorhandensein des Typgenehmigungszeichens auf
dem Kontrollgerät,
— das Vorhandensein der Einbauplakette gemäß Rand­
nummer 396 sowie des Typenschilds gemäß Randnum­
mer 225,
— die Reifengröße und der tatsächliche Umfang der Rad­
reifen.
— dass keine Manipulationsgeräte am Kontrollgerät an­
gebracht sind,
— dass die Plombierungen ordnungsgemäß angebracht
sind, sich in einem guten Zustand befinden, ihre Kenn­
nummern gültig sind (Hersteller der Plombierungen in
der Datenbank der Europäischen Kommission verzeich­
net) und ihre Kennnummern den Angaben auf der Ein­
bauplakette (siehe Randnummer 401) entsprechen.
▼M3
— dass die Versionskennung der gespeicherten digitalen
Karte die aktuellste ist.
410a) Wenn die zuständigen nationalen Behörden eine Manipula­
tion feststellen, kann das Fahrzeug zur Nachkalibrierung
des Kontrollgeräts an eine zugelassene Werkstatt geschickt
werden.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 104
411) Falls sich erweist, dass seit der letzten Nachprüfung eines
der in Kapitel 3.9 (Feststellung von Ereignissen und Stö­
rungen) aufgeführten Ereignisse aufgetreten ist, das von den
Herstellern von Fahrtenschreibern und/oder nationalen Be­
hörden als potenzielle Bedrohung der Sicherheit des Geräts
betrachtet wird, so trifft die Werkstatt folgende Maßnah­
men:
a. Vergleich zwischen den Kenndaten des an das Getriebe
angeschlossenen Bewegungssensors und jenen des ge­
koppelten und in der Fahrzeugeinheit registrierten Bewe­
gungssensors,
b. Überprüfung der Übereinstimmung der Informationen
auf der Einbauplakette mit den in den Aufzeichnungen
der Fahrzeugeinheit enthaltenen Informationen,
c. Vergleich der Seriennummer und der Genehmigungs­
nummer des Bewegungssensors, sofern auf dessen Ge­
häuse aufgedruckt, auf Übereinstimmung mit den im
Massenspeicher des Kontrollgeräts gespeicherten Infor­
mationen.
d. Vergleich der Kenndaten auf dem Typenschild der ex­
ternen GNSS-Ausrüstung, falls vorhanden, mit den im
Massenspeicher der Fahrzeugeinheit gespeicherten Da­
ten.
412) Die Werkstätten halten etwaige Erkenntnisse in Bezug auf
aufgebrochene Plombierungen oder Manipulationsgeräte in
ihren Nachprüfungsberichten fest. Die Werkstätten bewah­
ren diese Berichte mindestens 2 Jahre lang auf und stellen
sie der zuständigen Behörde auf Wunsch zur Verfügung.
413) Diese Nachprüfungen umfassen eine Kalibrierung und ei­
nen vorbeugenden Austausch der Plombierungen, für deren
Einbau die Werkstätten verantwortlich sind..
6.5 Messung der Anzeigefehler
414) Die Messung der Anzeigefehler beim Einbau und während
der Benutzung wird unter folgenden Bedingungen durch­
geführt, die als normale Prüfbedingungen anzusehen sind:
— unbeladenes Fahrzeug in fahrbereitem Zustand,
— Reifendruck gemäß den Angaben des Herstellers,
— Reifenabnutzung innerhalb der nach den nationalen
Rechtsvorschriften zulässigen Grenzen,
— Bewegungen des Fahrzeugs:
— Das Fahrzeug muss sich mit eigener Motorkraft gerad­
linig auf ebenem Gelände und mit einer Geschwindig­
keit von 50 ± 5 km/h fortbewegen. Die Messstrecke
muss mindestens 1 000 m betragen;
— die Prüfung kann auch mit anderen Methoden, so auf
einem geeigneten Prüfstand, durchgeführt werden, so­
fern eine vergleichbare Genauigkeit gewährleistet ist.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 105
6.6 Reparaturen
415) Die Werkstätten müssen Daten vom Kontrollgerät herunter­
laden können, um die Daten dem entsprechenden Trans­
portunternehmen zu übergeben.
416) Die zugelassenen Werkstätten stellen den Transportunter­
nehmen eine Bescheinigung über die Unmöglichkeit des
Herunterladens der Daten aus, wenn das Herunterladen
von aufgezeichneten Daten aufgrund eines Defekts des
Kontrollgeräts auch nach der Reparatur durch diese Werk­
stätten nicht möglich ist. Eine Kopie jeder ausgestellten
Bescheinigung ist von den Werkstätten mindestens 2 Jahre
lang aufzubewahren.
7 KARTENAUSGABE
Die von den Mitgliedstaaten eingerichteten Kartenausgabeverfahren
müssen folgenden Vorschriften entsprechen:
417) Die Kartennummer der Erstausgabe einer Fahrtenschreiber­
karte an einen Antragsteller hat einen fortlaufenden Index
(wenn zutreffend) sowie einen Ersatzindex und einen auf
„0“ gesetzten Erneuerungsindex.
418) Die Kartennummern aller an dieselbe Kontrollstelle oder
dieselbe Werkstatt oder dasselbe Transportunternehmen
ausgegebenen nicht personengebundenen Fahrtenschreiber­
karten weisen die gleichen ersten 13 Stellen sowie einen
unterschiedlichen laufenden Index auf.
419) Eine als Ersatz für eine vorhandene Fahrtenschreiberkarte aus­
gegebene Fahrtenschreiberkarte weist die gleiche Kartennum­
mer auf wie die ersetzte Karte, wobei jedoch der Ersatzindex
um „1“ (in der Reihenfolge 0, … , 9, A, … , Z) erhöht ist.
420) Eine als Ersatz für eine vorhandene Fahrtenschreiberkarte
ausgegebene Fahrtenschreiberkarte weist das gleiche Datum
für den Ablauf der Gültigkeit auf wie die ersetzte Karte.
421) Eine zur Erneuerung einer vorhandenen Fahrtenschreiber­
karte ausgegebene Fahrtenschreiberkarte trägt die gleiche
Kartennummer wie die erneuerte Karte, wobei jedoch der
Ersatzindex auf „0“ zurückgesetzt und der Erneuerungs­
index um „1“ erhöht ist (in der Reihenfolge 0, … , 9, A,
… , Z).
422) Der Austausch einer vorhandenen Fahrtenschreiberkarte
zwecks Änderung von Verwaltungsdaten richtet sich bei
Erneuerung innerhalb desselben Mitgliedstaates nach den
Vorschriften für die Erneuerung und bei Ausführung durch
einen anderen Mitgliedstaat nach den Vorschriften für die
Erstausgabe.
423) In der Rubrik „Name des Karteninhabers“ bei nicht per­
sonengebundenen Werkstatt- oder Kontrollkarten wird der
Name der Werkstatt bzw. der Kontrollstelle oder des Ein­
baubetriebs oder der Name des Kontrolleurs angegeben,
falls die Mitgliedstaaten dies beschließen.
424) Die Mitgliedstaaten tauschen Daten auf elektronischem
Weg aus, um die Einzigkeit der von ihnen ausgestellten
Fahrerkarten gemäß Artikel 31 der Verordnung (EU)
Nr. 165/2014 zu gewährleisten.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 106
8 TYPGENEHMIGUNG VON KONTROLLGERÄTEN UND
FAHRTENSCHREIBERKARTEN
8.1 Allgemeines
▼M1
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 Fahrzeug­
einheit oder der externen Fernkommunikationsausrüstung und der
Fahrzeugeinheit ist keine Typgenehmigung erforderlich. Das zur
Verwendung durch das Kontrollgerät bestimmte Papier ist als Kom­
ponente des Kontrollgeräts zu betrachten.
Jeder Hersteller kann für Komponenten des Kontrollgeräts in Kom­
bination mit jeder anderen Komponente des Kontrollgeräts die Typ­
genehmigung 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 unter­
schiedlich zusammengestellt sein. Unabhängig von der Zusammen­
stellung 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 Fernkommunikations­
ausrüstungen, die über eine Typgenehmigung verfügen, kompatibel
sind.
▼B
425) Kontrollgeräte sind zusammen mit allen integrierten Zusatz­
geräten zur Typgenehmigung vorzulegen.
426) Die Typgenehmigung von Kontrollgeräten und Fahrten­
schreiberkarten beinhaltet Sicherheitsprüfungen, Funktions­
prüfungen und Interoperabilitätsprüfungen. Die positiven
Ergebnisse der einzelnen Prüfungen werden in einem ge­
eigneten Zertifikat ausgewiesen.
▼M1
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 An­
hang erforderlich)
für das Kontrollgerät oder die Fahrtenschreiberkarte, für die
die Typgenehmigung beantragt wurde, vorliegen.
▼B
428) Änderungen an der Software oder Hardware des Geräts
oder an den für seine Herstellung verwendeten Werkstoffen
sind vor ihrer Umsetzung der Behörde zu melden, die die
Typgenehmigung für das Gerät erteilt hat. Diese Behörde
bestätigt dem Hersteller die Erweiterung der Typgenehmi­
gung oder verlangt eine Aktualisierung oder Bestätigung
des entsprechenden Funktions-, Sicherheits- und/oder Inter­
operabilitätszertifikats.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 107
429) Verfahren zur Aktualisierung der Software bereits einge­
bauter Kontrollgeräte sind von der Behörde zu genehmigen,
die die Bauartgenehmigung für das Kontrollgerät erteilt hat.
Durch die Softwareaktualisierung dürfen im Kontrollgerät
gespeicherte Fahrertätigkeitsdaten nicht verändert oder ge­
löscht werden. Die Softwareaktualisierung darf nur unter
der Verantwortung des Geräteherstellers erfolgen.
430) Die Typgenehmigung von Softwareänderungen zur Aktua­
lisierung eines zuvor typgenehmigten Kontrollgeräts darf
nicht verweigert werden, wenn derartige Änderungen nur
für nicht in diesem Anhang aufgeführte Funktionen gelten.
Die Softwareaktualisierung eines Kontrollgeräts kann die
Einführung neuer Zeichensätze ausschließen, wenn dies
technisch nicht machbar ist.
▼B
8.2 Sicherheitszertifikat
431) Das Sicherheitszertifikat wird gemäß den Bestimmungen
von Anlage 10 dieses Anhangs erteilt. Die zu zertifizieren­
den Komponenten des Kontrollgeräts sind Fahrzeugeinheit,
Bewegungssensor, externe GNSS-Ausrüstung und Fahrten­
schreiberkarten.
432) Falls die für die Sicherheitszertifizierung zuständigen Be­
hörden die Zertifizierung eines neuen Geräts ausnahms­
weise wegen überholter Sicherheitsmechanismen verwei­
gern, wird die Typgenehmigung in diesem bestimmten
Ausnahmefall weiterhin erteilt, falls keine der Verordnung
entsprechende Alternativlösung besteht.
433) In diesem Fall unterrichtet der betreffende Mitgliedstaat
unverzüglich die Europäische Kommission, die innerhalb
von zwölf Kalendermonaten nach Erteilung der Typgeneh­
migung ein Verfahren einleitet, um zu gewährleisten, dass
das ursprüngliche Sicherheitsniveau wiederhergestellt wird.
8.3 Funktionszertifikat
434) Jeder Antragsteller einer Typgenehmigung legt der Typge­
nehmigungsbehörde des Mitgliedstaats sämtliche Mate­
rialien und Unterlagen vor, die die Behörde für notwendig
erachtet.
435) Die Hersteller stellen die entsprechenden Muster der Pro­
dukte, für die eine Typgenehmigung beantragt wird, sowie
die zugehörigen Unterlagen, die die mit der Durchführung
von Funktionsprüfungen beauftragten Labors benötigen, in­
nerhalb eines Monats nach diesbezüglichem Ersuchen zur
Verfügung. Die aus diesem Ersuchen erwachsenden Kosten
trägt die ersuchende Stelle. Die Labors behandeln sämtliche
sensiblen Geschäftsinformationen vertraulich.
436) Ein Funktionszertifikat ist dem Hersteller erst zu erteilen,
nachdem mindestens alle Funktionsprüfungen nach Anlage
9 erfolgreich bestanden wurden.
437) Das Funktionszertifikat wird von der Typgenehmigungs­
behörde erteilt. Auf diesem Zertifikat ist neben dem Namen
des Empfängers und der Modellkennung eine ausführliche
Liste der durchgeführten Prüfungen und der erzielten Er­
gebnisse anzuführen.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 108
438) Im Funktionszertifikat für eine Komponente eines Kontroll­
geräts sind auch die Typgenehmigungsnummern sämtlicher
anderen typgenehmigten kompatiblen Kontrollgerätkom­
ponenten anzugeben.
439) Im Funktionszertifikat für eine Komponente eines Kontroll­
geräts ist auch die ISO- oder CEN-Norm anzugeben, an­
hand deren die Funktionale Schnittstelle zertifiziert worden
ist.
8.4 Interoperabilitätszertifikat
440) Interoperabilitätsprüfungen werden von einer einzigen Prüf­
stelle durchgeführt, die der Europäischen Kommission un­
tersteht und sich in ihrer Verantwortung befindet.
441) Die Prüfstelle registriert von den Herstellern gestellte An­
träge auf Interoperabilitätsprüfungen in der Reihenfolge ih­
res Eintreffens.
442) Anträge werden nur dann amtlich registriert, wenn der Prüf­
stelle folgende Unterlagen vorliegen:
— sämtliche Materialien und Dokumente, die für diese
Interoperabilitätsprüfungen erforderlich sind,
— das entsprechende Sicherheitszertifikat,
— das entsprechende Funktionszertifikat.
Das Registrierungsdatum des Antrags wird dem Hersteller
mitgeteilt.
▼M3
443) Für ein Kontrollgerät oder eine Fahrtenschreiberkarte, die
die Schwachstellenanalyse bei der Sicherheitsbewertung
und einer Funktionsbewertung nicht erfolgreich bestanden
haben, werden vom Labor keine Interoperabilitätsprüfungen
durchgeführt, außer in dem in Randnummer 432 genannten
Ausnahmefall.
▼B
444) Jeder Hersteller, der Interoperabilitätsprüfungen beantragt,
verpflichtet sich, der damit beauftragten Prüfstelle sämtliche
Materialien und Dokumente zu überlassen, die er für die
Durchführung der Prüfungen bereitgestellt hat.
445) Die Interoperabilitätsprüfungen werden gemäß den Bestim­
mungen von Anlage 9 dieses Anhangs für jeweils alle Mo­
delle von Kontrollgeräten oder Fahrtenschreiberkarten
durchgeführt,
— deren Typgenehmigung noch gültig ist oder
— für die eine Typgenehmigung beantragt wurde und die
ein gültiges Interoperabilitätszertifikat besitzen.
446) Die Interoperabilitätsprüfungen erstrecken sich auf alle Ge­
nerationen von Kontrollgeräten oder Fahrtenschreiberkarten,
die noch verwendet werden.
▼M3
447) Das Interoperabilitätszertifikat wird erst von der Prüfstelle
für den Hersteller ausgestellt, nachdem alle erforderlichen
Interoperabilitätsprüfungen erfolgreich bestanden wurden
und nachdem der Hersteller nachgewiesen hat, dass sowohl
ein gültiges Funktionszertifikat als auch ein gültiges Sicher­
heitszertifikat für das Produkt erteilt wurden, außer in dem
in Randnummer 432 genannten Ausnahmefall.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 109
448) Sind die Interoperabilitätsprüfungen bei einem oder mehre­
ren Kontrollgeräten oder bei einer oder mehreren Fahrten­
schreiberkarten nicht erfolgreich, wird das Interoperabili­
tätszertifikat erst dann erteilt, wenn der antragstellende Her­
steller die erforderlichen Änderungen vorgenommen und
die Interoperabilitätsprüfungen bestanden hat. Die Prüfstelle
stellt mit Hilfe des von diesem Interoperabilitätsfehler be­
troffenen Herstellers die Ursache des Problems fest und
bemüht sich, den antragstellenden Hersteller bei der Suche
nach einer technischen Lösung zu unterstützen. Hat der
Hersteller sein Produkt verändert, muss er sich bei den
zuständigen Behörden vergewissern, dass das Sicherheits­
zertifikat und die Funktionszertifikate noch gültig sind.
449) Das Interoperabilitätszertifikat ist sechs Monate gültig. Hat
der Hersteller bei Ablauf dieser Frist keine entsprechende
Typgenehmigungsbogen erhalten, wird es ihm wieder ent­
zogen. Das Interoperabilitätszertifikat wird vom Hersteller
an die Typgenehmigungsbehörde des Mitgliedstaats weiter­
geleitet, die das Funktionszertifikat erteilt hat.
450) Ein Element, das möglicherweise einem Interoperabilitäts­
fehler zugrunde liegt, darf nicht gewinnbringend oder zur
Errichtung einer beherrschenden Stellung verwendet
werden.
8.5 Typgenehmigungsbogen
451) Die Typgenehmigungsbehörde des Mitgliedstaates darf den
Typgenehmigungsbogen ausstellen, sobald ihr die drei be­
nötigten Zertifikate vorliegen.
452) Auf dem Typgenehmigungsbogen für eine Komponente ei­
nes Kontrollgeräts sind auch die Typgenehmigungsnum­
mern des anderen typgenehmigten interoperablen Kontroll­
geräts anzugeben.
453) Bei der Erteilung der Typgenehmigung an den Hersteller
fertigt die Typgenehmigungsbehörde eine Kopie des Typ­
genehmigungsbogens für die mit den Interoperabilitätsprü­
fungen betraute Prüfstelle an.
454) Die für Interoperabilitätsprüfungen zuständige Prüfstelle un­
terhält eine öffentliche Website mit einer aktuellen Liste der
Modelle von Kontrollgeräten und Fahrtenschreiberkarten,
— für die ein Antrag auf Interoperabilitätsprüfungen regis­
triert wurde,
— für die ein Interoperabilitätszertifikat (auch ein vorläu­
figes Interoperabilitätszertifikat) erteilt wurde,
— für die ein Typgenehmigungsbogen ausgestellt wurde.
8.6 Ausnahmeverfahren: für die ersten Interoperabilitätszertifikate
für Kontrollgeräte und Fahrtenschreiberkarten der zweiten Ge­
neration
455) Während eines Zeitraums von vier Monaten, nachdem ein
erster Satz von Kontrollgeräten der zweiten Generation und
Fahrtenschreiberkarten der zweiten Generation (Fahrer-,
Werkstatt-, Kontroll- und Unternehmenskarten) als inter­
operabel zertifiziert wurden, gilt jedes Interoperabilitätszer­
tifikat (auch die ersten), das in diesem Zeitraum auf ent­
sprechenden Antrag ausgestellt wird, als vorläufig.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 110
456) Sind am Ende dieses Zeitraums sämtliche betreffenden Pro­
dukte interoperabel, erhalten sämtliche entsprechenden In­
teroperabilitätszertifikate endgültigen Charakter.
457) Werden in diesem Zeitraum Interoperabilitätsfehler fest­
gestellt, ermittelt die mit den Interoperabilitätsprüfungen
betraute Prüfstelle die Ursachen der Probleme mit Hilfe
aller beteiligten Hersteller und fordert diese auf, die erfor­
derlichen Änderungen vorzunehmen.
458) Liegen am Ende dieses Zeitraums weiterhin Interoperabili­
tätsprobleme vor, ermittelt die mit den Interoperabilitätsprü­
fungen betraute Prüfstelle in Zusammenarbeit mit den
betreffenden Herstellern und mit den Typgenehmigungs­
behörden, die die entsprechenden Funktionszertifikate er­
teilt haben, die Ursachen der Interoperabilitätsfehler und
gibt an, welche Änderungen von den einzelnen betroffenen
Herstellern vorzunehmen sind. Die Suche nach technischen
Lösungen dauert maximal zwei Monate; ist nach Ablauf
dieses Zeitraums keine gemeinsame Lösung gefunden wor­
den, entscheidet die Kommission nach Rücksprache mit der
mit den Interoperabilitätsprüfungen betrauten Prüfstelle un­
ter Angabe von Gründen, welchen Geräten und Karten ein
endgültiges Interoperabilitätszertifikat erteilt wird.
459) Anträge auf Interoperabilitätsprüfungen, die von der Prüf­
stelle zwischen dem Ende der Viermonatsfrist nach Ertei­
lung des ersten vorläufigen Interoperabilitätszertifikats und
dem Datum der in Randnummer 455 genannten Entschei­
dung der Kommission registriert werden, sind bis zur Lö­
sung der ursprünglichen Interoperabilitätsprobleme zurück­
zustellen. Anschließend werden diese Anträge in der Rei­
henfolge ihrer Registrierung bearbeitet.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 111
Anlage 1
DATENGLOSSAR
INHALTSVERZEICHNIS
1. EINLEITUNG
1.1. Grundlage für die Definition von Datentypen
1.2. Referenzdokumente
2. DATENTYPDEFINITIONEN
2.1. ActivityChangeInfo
2.2. Address
2.3. AESKey
2.4. AES128Key
2.5. AES192Key
2.6. AES256Key
2.7. BCDString
2.8. CalibrationPurpose
2.9. CardActivityDailyRecord
2.10. CardActivityLengthRange
2.11. CardApprovalNumber
▼M3
2.11a. CardBorderCrossing
2.11b. CardBorderCrossingRecord
▼B
2.12. CardCertificate
2.13. CardChipIdentification
2.14. CardConsecutiveIndex
2.15. CardControlActivityDataRecord
2.16. CardCurrentUse
2.17. CardDriverActivity
2.18. CardDrivingLicenceInformation
2.19. CardEventData
2.20. CardEventRecord
2.21. CardFaultData
2.22. CardFaultRecord
2.23. CardIccIdentification
2.24. CardIdentification
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 112
2.24a. CardLoadTypeEntries
2.24b. CardLoadTypeEntryRecord
2.24c. CardLoadUnloadOperations
2.24d. CardLoadUnloadRecord
▼B
2.25. CardMACertificate
2.26. CardNumber
▼M3
2.26a. CardPlaceAuthDailyWorkPeriod
▼B
2.27. CardPlaceDailyWorkPeriod
2.28. CardPrivateKey
2.29. CardPublicKey
2.30. CardRenewalIndex
2.31. CardReplacementIndex
2.32. CardSignCertificate
2.33. CardSlotNumber
2.34. CardSlotsStatus
2.35. CardSlotsStatusRecordArray
2.36. CardStructureVersion
2.37. CardVehicleRecord
2.38. CardVehiclesUsed
2.39. CardVehicleUnitRecord
2.40. CardVehicleUnitsUsed
2.41. Certificate
2.42. CertificateContent
2.43. CertificateHolderAuthorisation
2.44. CertificateRequestID
2.45. CertificationAuthorityKID
2.46. CompanyActivityData
2.47. CompanyActivityType
2.48. CompanyCardApplicationIdentification
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 113
2.48a. CompanyCardApplicationIdentificationV2
▼B
2.49. CompanyCardHolderIdentification
2.50. ControlCardApplicationIdentification
▼M3
2.50a. ControlCardApplicationIdentificationV2
▼B
2.51. ControlCardControlActivityData
2.52. ControlCardHolderIdentification
2.53. ControlType
2.54. CurrentDateTime
2.55. CurrentDateTimeRecordArray
2.56. DailyPresenceCounter
2.57. Datef
2.58. DateOfDayDownloaded
2.59. DateOfDayDownloadedRecordArray
2.60. Distance
▼M3
2.60a. DownloadInterfaceVersion
▼B
2.61. DriverCardApplicationIdentification
▼M3
2.61a. DriverCardApplicationIdentificationV2
▼B
2.62. DriverCardHolderIdentification
▼M1
2.63. Reserviert für künftige Verwendung
▼B
2.64. EGFCertificate
2.65. EmbedderIcAssemblerId
2.66. EntryTypeDailyWorkPeriod
2.67. EquipmentType
2.68. EuropeanPublicKey
2.69. EventFaultRecordPurpose
2.70. EventFaultType
2.71. ExtendedSealIdentifier
2.72. ExtendedSerialNumber
2.73. FullCardNumber
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 114
2.74. FullCardNumberAndGeneration
2.75. Generation
2.76. GeoCoordinates
2.77. GNSSAccuracy
▼M1
2.78. GNSSAccumulatedDriving
2.79. GNSSAccumulatedDrivingRecord
▼M3
2.79a. GNSSAuthAccumulatedDriving
2.79b. GNSSAuthStatusADRecord
2.79c. GNSSPlaceAuthRecord
▼B
2.80. GNSSPlaceRecord
2.81. HighResOdometer
2.82. HighResTripDistance
2.83. HolderName
▼M3
2.84. Reserviert für künftige Verwendung.
▼B
2.85. K-ConstantOfRecordingEquipment
2.86. KeyIdentifier
2.87. KMWCKey
2.88. Language
2.89. LastCardDownload
▼M3
2.89a. LengthOfFollowingData
▼B
2.90. LinkCertificate
▼M3
2.90a. LoadType
▼B
2.91. L-TyreCircumference
2.92. MAC
2.93. ManualInputFlag
2.94. ManufacturerCode
2.95. ManufacturerSpecificEventFaultData
2.96. MemberStateCertificate
2.97. MemberStateCertificateRecordArray
2.98. MemberStatePublicKey
2.99. Name
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 115
2.100. NationAlpha
2.101. NationNumeric
▼M3
2.101a. NoOfBorderCrossingRecords
▼B
2.102. NoOfCalibrationRecords
2.103. NoOfCalibrationsSinceDownload
2.104. NoOfCardPlaceRecords
2.105. NoOfCardVehicleRecords
2.106. NoOfCardVehicleUnitRecords
2.107. NoOfCompanyActivityRecords
2.108. NoOfControlActivityRecords
2.109. NoOfEventsPerType
2.110. NoOfFaultsPerType
▼M1
2.111. NoOfGNSSADRecords
▼M3
2.111a. NoOfLoadUnloadRecords
▼B
2.112. NoOfSpecificConditionRecords
▼M3
2.112a. NoOfLoadTypeEntryRecords
▼B
2.113. OdometerShort
2.114. OdometerValueMidnight
▼M3
2.114a. OperationType
▼B
2.115. OdometerValueMidnightRecordArray
2.116. OverspeedNumber
▼M3
2.116a. PlaceAuthRecord
2.116b. PlaceAuthStatusRecord
▼B
2.117. PlaceRecord
▼M3
2.117a. PositionAuthenticationStatus
▼B
2.118. PreviousVehicleInfo
2.119. PublicKey
2.120. RecordType
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 116
2.121. RegionAlpha
2.122. RegionNumeric
2.123. RemoteCommunicationModuleSerialNumber
2.124. RSAKeyModulus
2.125. RSAKeyPrivateExponent
2.126. RSAKeyPublicExponent
2.127. RtmData
2.128. SealDataCard
2.129. SealDataVu
2.130. SealRecord
2.131. SensorApprovalNumber
2.132. SensorExternalGNSSApprovalNumber
2.133. SensorExternalGNSSCoupledRecord
2.134. SensorExternalGNSSIdentification
2.135. SensorExternalGNSSInstallation
2.136. SensorExternalGNSSOSIdentifier
2.137. SensorExternalGNSSSCIdentifier
2.138. SensorGNSSCouplingDate
2.139. SensorGNSSSerialNumber
2.140. SensorIdentification
2.141. SensorInstallation
2.142. SensorInstallationSecData
2.143. SensorOSIdentifier
2.144. SensorPaired
2.145. SensorPairedRecord
2.146. SensorPairingDate
2.147. SensorSCIdentifier
2.148. SensorSerialNumber
2.149. Signature
2.150. SignatureRecordArray
2.151. SimilarEventsNumber
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 117
2.152. SpecificConditionRecord
2.153. SpecificConditions
2.154. SpecificConditionType
2.155. Speed
2.156. SpeedAuthorised
2.157. SpeedAverage
2.158. SpeedMax
▼M3
2.158a. TachographCardsGen1Suppression
▼B
2.159. TachographPayload
▼M1
2.160. Reserviert für künftige Verwendung
▼B
2.161. TDesSessionKey
2.162. TimeReal
2.163. TyreSize
2.164. VehicleIdentificationNumber
2.165. VehicleIdentificationNumberRecordArray
2.166. VehicleRegistrationIdentification
▼M3
2.166a. VehicleRegistrationIdentificationRecordArray
▼B
2.167. VehicleRegistrationNumber
2.168. VehicleRegistrationNumberRecordArray
2.169. VuAbility
2.170. VuActivityDailyData
2.171. VuActivityDailyRecordArray
2.172. VuApprovalNumber
2.173. VuCalibrationData
2.174. VuCalibrationRecord
2.175. VuCalibrationRecordArray
2.176. VuCardIWData
2.177. VuCardIWRecord
2.178. VuCardIWRecordArray
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 118
2.179. VuCardRecord
2.180. VuCardRecordArray
2.181. VuCertificate
2.182. VuCertificateRecordArray
2.183. VuCompanyLocksData
2.184. VuCompanyLocksRecord
2.185. VuCompanyLocksRecordArray
▼M3
2.185a. VuConfigurationLengthRange
▼B
2.186. VuControlActivityData
2.187. VuControlActivityRecord
2.188. VuControlActivityRecordArray
2.189. VuDataBlockCounter
2.190. VuDetailedSpeedBlock
2.191. VuDetailedSpeedBlockRecordArray
2.192. VuDetailedSpeedData
▼M3
2.192a. VuDigitalMapVersion
▼B
2.193. VuDownloadablePeriod
2.194. VuDownloadablePeriodRecordArray
2.195. VuDownloadActivityData
2.196. VuDownloadActivityDataRecordArray
2.197. VuEventData
2.198. VuEventRecord
2.199. VuEventRecordArray
2.200. VuFaultData
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 119
2.201. VuFaultRecord
2.202. VuFaultRecordArray
▼M1
2.203. VuGNSSADRecord
▼M3
2.203a. VuBorderCrossingRecord
2.203b. VuBorderCrossingRecordArray
▼M1
2.204. VuGNSSADRecordArray
▼M3
2.204a. VuGnssMaximalTimeDifference
▼B
2.205. VuIdentification
2.206. VuIdentificationRecordArray
2.207. VuITSConsentRecord
2.208. VuITSConsentRecordArray
▼M3
2.208a. VuLoadUnloadRecord
2.208b. VuLoadUnloadRecordArray
▼B
2.209. VuManufacturerAddress
2.210. VuManufacturerName
2.211. VuManufacturingDate
2.212. VuOverSpeedingControlData
2.213. VuOverSpeedingControlDataRecordArray
2.214. VuOverSpeedingEventData
2.215. VuOverSpeedingEventRecord
2.216. VuOverSpeedingEventRecordArray
2.217. VuPartNumber
2.218. VuPlaceDailyWorkPeriodData
2.219. VuPlaceDailyWorkPeriodRecord
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 120
2.220. VuPlaceDailyWorkPeriodRecordArray
2.221. VuPrivateKey
2.222. VuPublicKey
▼M3
2.222a. VuRtcTime
▼B
2.223. VuSerialNumber
2.224. VuSoftInstallationDate
2.225. VuSoftwareIdentification
2.226. VuSoftwareVersion
2.227. VuSpecificConditionData
2.228. VuSpecificConditionRecordArray
2.229. VuTimeAdjustmentData
▼M1
2.230. Reserviert für künftige Verwendung
2.231. Reserviert für künftige Verwendung
▼B
2.232. VuTimeAdjustmentRecord
2.233. VuTimeAdjustmentRecordArray
2.234. WorkshopCardApplicationIdentification
▼M3
2.234a. WorkshopCardApplicationIdentificationV2
2.234b. WorkshopCardCalibrationAddData
2.234c. WorkshopCardCalibrationAddDataRecord
▼B
2.235. WorkshopCardCalibrationData
2.236. WorkshopCardCalibrationRecord
2.237. WorkshopCardHolderIdentification
2.238. WorkshopCardPIN
2.239. W-VehicleCharacteristicConstant
2.240. VuPowerSupplyInterruptionRecord
2.241. VuPowerSupplyInterruptionRecordArray
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 121
2.242. VuSensorExternalGNSSCoupledRecordArray
2.243. VuSensorPairedRecordArray
3. DEFINITIONEN FÜR WERT- UND GRÖSSENBEREICHE
4. ZEICHENSÄTZE
5. KODIERUNG
6. OBJEKTKENNUNGEN UND ANWENDUNGSBEZEICHNER
6.1. Objektkennungen
6.2. Anwendungskennungen
1. EINLEITUNG
Diese Anlage enthält die Spezifizierung der zur Verwendung im Kon­
trollgerät und auf den Fahrtenschreiberkarten vorgesehenen Datenfor­
mate, -elemente und -strukturen.
1.1. Grundlage für die Definition von Datentypen
Die Definition der Datentypen in dieser Anlage beruht auf der Abstract
Syntax Notation One (ASN.1), da es auf diese Weise möglich ist, ein­
fache und strukturierte Daten ohne Implizierung einer spezifischen,
anwendungs- und umgebungsabhängigen Transfersyntax (Kodierungs­
regeln) festzulegen.
Die ASN.1-Typbenennungskonventionen werden gemäß ISO/IEC 8824-
1 verwendet. Das heißt:
— In den gewählten Benennungen ist soweit möglich die Bedeutung
des Datentyps implizit erkennbar.
— Handelt es sich bei einem Datentyp um eine Zusammensetzung aus
anderen Datentypen, ist die Datentypbenennung zwar weiterhin eine
Folge von alphabetischen Zeichen, die mit einem Großbuchstaben
beginnen, doch werden innerhalb der Benennung Großbuchstaben
verwendet, um die entsprechende Bedeutung zu vermitteln.
— Generell stehen die Datentypbenennungen in Beziehung zu den Be­
nennungen der Datentypen, aus denen sie aufgebaut sind, zu dem
Gerät, in denen die Daten gespeichert werden, und zu der mit den
Daten verbundenen Funktion.
Ist ein ASN.1-Typ bereits im Rahmen einer anderen Norm definiert und
für den Gebrauch im Kontrollgerät von Bedeutung, wird dieser ASN.1-
Typ in dieser Anlage definiert.
Um mehrere Arten von Kodierungsregeln zu ermöglichen, sind einige
ASN.1-Typen dieser Anlage mit Wertbereichsbezeichnern versehen, die
in Abschnitt 3 und Anlage 2 definiert sind.
1.2. Referenzdokumente
In dieser Anlage werden folgende Referenzdokumente herangezogen:
ISO 639 Code for the representation of names of languages.
First Edition: 1988.
ISO 3166 Codes for the representation of names of countries
and their subdivisions — Part 1: Country codes,
2013.
ISO 3779 Road vehicles — Vehicle identification number
(VIN) — Content and structure. 2009.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 122
ISO/IEC 7816-5 Identification cards — Integrated circuit cards — Part
5: Registration of application providers.
Second edition: 2004.
ISO/IEC 7816-6 Identification cards — Integrated circuit cards — Part
6: Interindustry data elements for interchange, 2004
+ Technical Corrigendum 1: 2006
ISO/IEC 8824-1 Information technology — Abstract Syntax Notation
One (ASN.1): Specification of basic notation. 2008 +
Technical Corrigendum 1: 2012 and Technical Cor­
rigendum 2: 2014.
ISO/IEC 8825-2 Information technology — ASN.1 encoding rules:
Specification of Packed Encoding Rules (PER). 2008.
ISO/IEC 8859-1 Information technology — 8 bit single-byte coded
graphic character sets — Part 1: Latin alphabet No.1.
First edition: 1998.
ISO/IEC 8859-7 Information technology — 8 bit single-byte coded
graphic character sets — Part 7: Latin/Greek alphabet.
2003.
ISO 16844-3 Road vehicles — Tachograph systems — Motion
Sensor Interface. 2004 + Technical Corrigendum 1:
2006.
TR-03110-3 BSI / ANSSI Technical Guideline TR-03110-3, Ad­
vanced Security Mechanisms for Machine Readable
Travel Documents and eIDAS Token — Part 3 Com­
mon Specifications, Version 2.20, 3. Februar 2015.
2. DATENTYPDEFINITIONEN
▼M3
Sofern nicht anders angegeben, besteht bei allen folgenden Datentypen
der Standardwert für einen „unbekannten“ oder einen „nicht zutreffen­
den“ Inhalt in der Ausfüllung des Datenelements mit hexadezimalen
„FF“-Bytes.
Sofern nicht anders angegeben, werden alle Datentypen für Anwendun­
gen der 1. Generation und 2. Generation verwendet. Datentypen, die nur
für Anwendungen der Version 2 der 2. Generation verwendet werden,
sind mit einem entsprechenden Hinweis versehen.
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.
Kartendatentypen, die nicht für Karten der 1. Generation definiert sind,
werden nicht in der Anwendung der 1. Generation von Karten der
2. Generation gespeichert. Insbesondere gilt:
— In der Anwendung der 1. Generation von Karten der 2. Generation
gespeicherte Typgenehmigungsnummern werden bei Bedarf auf die
acht ersten Zeichen verkürzt.
— Nur der Teil „FÄHRÜBERFAHRT/ZUGFAHRT Anfang“ einer spe­
zifischen Bedingung „FÄHRÜBERFAHRT/ZUGFAHRT“ wird in
der Anwendung der 1. Generation von Karten der 2. Generation
gespeichert.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 123
2.1. ActivityChangeInfo
Mit diesem Datentyp ist es möglich, den Steckplatz- und Fahrerstatus
um 0.00 Uhr und für einen Fahrer oder einen Beifahrer Tätigkeitsände­
rungen und/oder Veränderungen des Status der Fahrzeugführung und/
oder Veränderungen des Kartenstatus innerhalb eines Zwei-Byte-Wortes
zu kodieren. Dieser Datentyp bezieht sich auf Anhang 1C Randnummern
105, 266, 291, 320, 321, 343 und 344.
Wertzuweisung — Oktettanordnung: „scpaattttttttttt“B (16 Bit)
Für Aufzeichnungen im Massenspeicher (oder den Steckplatz-Status):
„s“B Slot:
„0“B: FAHRER,
„1“B: BEIFAHRER,
„c“B Status der Fahrzeugführung:
„0“B: EINMANNBETRIEB,
„1“B: TEAM,
„p“B Status der Fahrerkarte (oder Werkstattkarte) im entspre­
chenden Steckplatz:
„0“B: EINGESTECKT, eine Karte ist eingesteckt,
„1“B: NICHT EINGESTECKT, keine Karte eingesteckt
(oder Karte entnommen),
„aa“B Tätigkeit:
„00“B: UNTERBRECHUNG/RUHE,
„01“B: BEREITSCHAFT,
„10“B: ARBEIT,
„11“B: LENKEN,
„ttttttttttt“B Zeitpunkt der Veränderung: Anzahl der Minuten seit
0.00 Uhr an diesem Tag.
Für Aufzeichnungen auf der Fahrerkarte (oder Werkstattkarte) (und den
Fahrerstatus):
„s“B Steckplatz (nicht von Belang, wenn „p“ = 1. Ausnahme­
bedingung siehe Anmerkung):
„0“B: FAHRER,
„1“B: BEIFAHRER,
„c“B Status der Fahrzeugführung (Fall „p“ = 0) oder
Status der Folgetätigkeit (Fall „p“ = 1):
„0“B: EINMANNBETRIEB,
„0“B: UNBEKANNT
„1“B: TEAM,
„1“B: BEKANNT (= manuell eingegeben)
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 124
„p“B Kartenstatus:
„0“B: EINGESTECKT, Karte ist in ein Kontrollgerät
eingesteckt,
„1“B: NICHT EINGESTECKT, keine Karte eingesteckt
(oder Karte entnommen),
„aa“B Tätigkeit (nicht von Belang, wenn „p“ = 1 und „c“ = 0.
Ausnahmebedingung siehe Anmerkung):
„00“B: UNTERBRECHUNG/RUHE,
„01“B: BEREITSCHAFT,
„10“B: ARBEIT,
„11“B: LENKEN,
„ttttttttttt“B Zeitpunkt der Veränderung: Anzahl der Minuten seit
0.00 Uhr an diesem Tag.
Anmerkung für den Fall „Kartenentnahme“:
Wenn die Karte entnommen wurde, gilt Folgendes:
— „s“ ist relevant und gibt den Steckplatz an, aus dem die Karte ent­
nommen wurde,
— „c“ muss auf 0 gesetzt sein,
— „p“ muss auf 1 gesetzt sein,
— „aa“ muss die zu dieser Zeit gewählte laufende Tätigkeit kodieren.
Infolge eines manuellen Eintrags können die (auf der Karte gespeicher­
ten) Bits „c“ und „aa“ des Worts später zur Berücksichtigung des Ein­
trags überschrieben werden.
2.2. Address
Eine Adresse.
codePage gibt einen in Kapitel 4 definierten Zeichensatz an,
address ist eine mit dem angegebenen Zeichensatz kodierte Adresse.
2.3. AESKey
2. Generation:
Ein AES-Schlüssel mit einer Länge von 128, 192 oder 256 Bit.
Wertzuweisung: nicht näher spezifiziert.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 125
2.4. AES128Key
2. Generation:
Ein AES128-Schlüssel.
length bezeichnet die Länge des AES128-Schlüssel in Oktetten.
aes128Key ist ein AES-Schlüssel mit einer Länge von 128 Bit.
Wertzuweisung:
Der Wert für die Länge beträgt 16.
2.5. AES192Key
2. Generation:
Ein AES192-Schlüssel.
length bezeichnet die Länge des AES192-Schlüssel in Oktetten.
aes192Key ist ein AES-Schlüssel mit einer Länge von 192 Bit.
Wertzuweisung:
Der Wert für die Länge beträgt 24.
2.6. AES256Key
2. Generation:
Ein AES256-Schlüssel.
length bezeichnet die Länge des AES256-Schlüssel in Oktetten.
aes256Key ist ein AES-Schlüssel mit einer Länge von 256 Bit.
Wertzuweisung:
Der Wert für die Länge beträgt 32.
2.7. BCDString
BCDString wird für die Darstellung von binär kodierten Dezimalzahlen
(BCD) angewendet. Dieser Datentyp dient der Darstellung einer Dezi­
malziffer in einer 4-Bit-Gruppe. BCDString basiert auf „CharacterString­
Type“ der ISO/IEC 8824-1.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 126
BCDString verwendet eine „hstring“-Notation. Die äußerste linke Hexa­
dezimalziffer ist die höchstwertige 4-Bit-Gruppe des ersten Oktetts. Um
ein Vielfaches der Oktette zu erhalten, werden nach Bedarf von der
Position der äußersten linken 4-Bit-Gruppe im ersten Oktett 4-Bit-Grup­
pen mit rechtsstehenden Nullen eingefügt.
Zulässige Ziffern: 0, 1, … 9.
2.8. CalibrationPurpose
Code zur Erläuterung, warum ein bestimmter Satz von Kalibierungspara­
metern aufgezeichnet wurde. Dieser Datentyp bezieht sich auf Anhang
1B Randnummern 097 und 098 und Anhang 1C Randnummer 119.
Wertzuweisung:
1. Generation:
„00“H reservierter Wert,
„01“H Aktivierung: Aufzeichnung von bekannten Kali­
brierungsparametern zum Zeitpunkt der VU-Akti­
vierung,
„02“H Ersteinbau: Erste Kalibrierung der VU nach ihrer
Aktivierung,
„03“H Einbau: Erste Kalibrierung der VU im derzeitigen
Fahrzeug,
„04“H Regelmäßige Nachprüfung
2. Generation:
Zusätzlich zur 1. Generation werden folgende Werte genutzt:
„05“H Eingabe des amtlichen Kennzeichens nach Unter­
nehmen,
„06“H Zeitanpassung ohne Kalibrierung,
„07“H bis „7F“H RFU,
„80“H bis „FF“H Herstellerspezifisch.
2.9. CardActivityDailyRecord
Auf einer Karte gespeicherte Informationen zu den Fahrertätigkeiten an
einem bestimmten Kalendertag. Dieser Datentyp bezieht sich auf Anhang
1C Randnummern 266, 291, 320 und 343.
activityPreviousRecordLength — Gesamtlänge des vorherigen Tages­
datensatzes in Byte. Der Höchstwert wird durch die Länge des OCTET
STRING angegeben, der diese Datensätze enthält (siehe CardActivity­
LengthRange, Anlage 2 Abschnitt 4). Ist dieser Datensatz der älteste
Tagesdatensatz, muss der Wert von activityPreviousRecordLength auf
0 gesetzt werden.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 127
activityRecordLength — Gesamtlänge dieses Datensatzes in Byte. Der
Höchstwert wird durch die Länge des OCTET STRING angegeben, der
diese Datensätze enthält.
activityRecordDate — Datum des Datensatzes.
activityDailyPresenceCounter –Tagesanwesenheitszähler für die Karte
an diesem Tag.
activityDayDistance — die an diesem Tag zurückgelegte Gesamtweg­
strecke.
activityChangeInfo –Menge der ActivityChangeInfo-Daten für den Fah­
rer an diesem Tag. Kann maximal 1440 Werte enthalten (1 Tätigkeits­
änderung je Minute). Dieser Datensatz enthält stets auch den
ActivityChangeInfo-Wert für den Fahrerstatus um 0.00 Uhr.
2.10. CardActivityLengthRange
Anzahl der Bytes auf einer Fahrer- oder Werkstattkarte, die für die
Speicherung von Datensätzen zur Fahrertätigkeit zur Verfügung stehen.
Wertzuweisung: siehe Anlage 2.
2.11. CardApprovalNumber
Typgenehmigungsnummer der Karte.
Wertzuweisung:
Die Genehmigungsnummer muss derjenigen entsprechen, die auf der
zugehörigen Website der Europäischen Kommission veröffentlicht ist,
und beispielsweise etwaige Bindestriche berücksichtigen. Die Genehmi­
gungsnummer muss linksbündig ausgerichtet sein.
▼M3
2.11a. CardBorderCrossings
2. Generation, Version 2:
Auf einer Fahrer- oder Werkstattkarte gespeicherte Informationen im
Zusammenhang mit den Grenzüberschreitungen des Fahrzeugs, wenn
das Fahrzeug die Grenze eines Landes überschritten hat (Anhang IC
Randnummern 306f und 356f).
borderCrossingPointerNewestRecord – Index des zuletzt aktualisierten
Grenzüberschreitungsdatensatzes der Karte.
Wertzuweisung – Zahl, die dem Zähler des Grenzüberschreitungsdaten­
satzes der Karte entspricht, beginnend mit „0“ für das erste Auftreten des
Grenzüberschreitungsdatensatzes der Karte in der Struktur.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 128
cardBorderCrossingRecords – Menge der Grenzüberschreitungsdaten­
sätze der Karte.
2.11b. CardBorderCrossingRecord
2. Generation, Version 2:
Auf einer Fahrer- oder Werkstattkarte gespeicherte Informationen im
Zusammenhang mit den Grenzüberschreitungen des Fahrzeugs, wenn
das Fahrzeug die Grenze eines Landes überschritten hat (Anhang IC
Randnummern 147b, 306e und 356e).
countryLeft – Land, das das Fahrzeug verlassen hat, oder „keine Infor­
mationen verfügbar“ gemäß Anhang IC Randnummer 147b. „Übrige
Welt“ (NationNumeric-Code „FF“H) ist zu verwenden, wenn die Fahr­
zeugeinheit nicht in der Lage ist, das Land zu bestimmen, in dem sich
das Fahrzeug befindet (z. B. wenn das aktuelle Land nicht Teil der
gespeicherten digitalen Karten ist).
countryEntered – Land, in das das Fahrzeug eingefahren ist, oder Land,
in dem sich das Fahrzeug zum Zeitpunkt des Einsteckens der Karte
befindet. „Übrige Welt“ (NationNumeric-Code „FF“H) ist zu verwenden,
wenn die Fahrzeugeinheit nicht in der Lage ist, das Land zu bestimmen,
in dem sich das Fahrzeug befindet (z. B. wenn das aktuelle Land nicht
Teil der gespeicherten digitalen Karten ist).
gnssPlaceAuthRecord – Informationen zur Position des Fahrzeugs zu
dem Zeitpunkt, an dem die Fahrzeugeinheit festgestellt hat, dass das
Fahrzeug die Grenze eines Landes überschritten hat, oder „keine Infor­
mationen verfügbar“ gemäß Anhang IC Randnummer 147b, und den
Authentisierungsstatus der Position.
vehicleOdometerValue – Kilometerstand, an dem die Fahrzeugeinheit
festgestellt hat, dass das Fahrzeug die Grenze eines Landes überschritten
hat, oder „keine Informationen verfügbar“ gemäß Anhang IC Randnum­
mer 147b.
▼B
2.12. CardCertificate
1. Generation:
Zertifikat des öffentlichen Schlüssels einer Karte.
2.13. CardChipIdentification
Auf einer Karte gespeicherte Information zur Identifizierung des inte­
grierten Schaltkreises (IS) der Karte (Anhang 1C Randnummer 249).
Anhand der icSerialNumber gemeinsam mit den icManufacturingRefe­
rences wird der Kartenchip eindeutig identifiziert. Mit der icSerialN­
umber allein ist eine eindeutige Identifizierung des Kartenchips nicht
möglich.
icSerialNumber ist die IS-Seriennummer.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 129
icManufacturingReferences ist der spezifische IS-Herstellerbezeichner.
2.14. CardConsecutiveIndex
Fortlaufender Kartenindex (Begriffsbestimmung h)).
Wertzuweisung: (siehe Anlage 1C Kapitel 7)
Reihenfolge für die Erhöhung: „0, …, 9, A, …, Z, a, …, z“
2.15. CardControlActivityDataRecord
Auf einer Fahrer- oder Werkstattkarte gespeicherte Information über die
letzte Kontrolle, welcher der Fahrer unterzogen wurde (Anhang 1C
Randnummern 274, 299, 327 und 350).
controlType — Art der Kontrolle.
controlTime — Datum und Uhrzeit der Kontrolle.
controlCardNumber — FullCardNumber des ausführenden Kontrol­
leurs.
controlVehicleRegistration — amtliches Kennzeichen und zulassender
Mitgliedstaat des Fahrzeugs, in dem die Kontrolle stattfand.
controlDownloadPeriodBegin und controlDownloadPeriodEnd —
übertragener Zeitraum bei Übertragungen.
2.16. CardCurrentUse
Information über die aktuelle Benutzung der Karte (Anhang 1C Rand­
nummern 273, 298, 326 und 349).
sessionOpenTime — Uhrzeit, zu der die Karte für die aktuelle Benut­
zung eingesteckt wird. Bei Kartenentnahme wird dieses Element auf null
gesetzt.
sessionOpenVehicle — Kennung des derzeit gefahrenen Fahrzeugs, ge­
setzt beim Einstecken der Karte. Bei Kartenentnahme wird dieses Ele­
ment auf null gesetzt.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 130
2.17. CardDriverActivity
Auf einer Fahrer- oder Werkstattkarte gespeicherte Information über die
Tätigkeiten des Fahrers (Anhang 1C Randnummern 267, 268, 292, 293,
321 und 344).
activityPointerOldestDayRecord — Angabe des Beginns des Speicher­
ortes (Anzahl der Bytes vom Anfang des Strings) des ältesten vollstän­
digen Tagesdatensatzes im String activityDailyRecords. Der Höchstwert
ist durch die Länge des Strings gegeben.
activityPointerNewestRecord — Angabe des Beginns des Speicherortes
(Anzahl der Bytes vom Anfang des Strings) des jüngsten vollständigen
Tagesdatensatzes im String activityDailyRecords. Der Höchstwert ist
durch die Länge des Strings gegeben.
activityDailyRecords — der für die Fahrertätigkeitsdaten zur Verfügung
stehende Speicherplatz (Datenstruktur: CardActivityDailyRecord) für je­
den Kalendertag, an dem die Karte benutzt wurde.
Wertzuweisung: Dieser Oktettstring wird zyklisch mit CardActivityDai­
lyRecord-Datensätzen gefüllt. Bei der ersten Benutzung beginnt die Spei­
cherung beim ersten Byte des Strings. Alle neuen Datensätze werden am
Ende des vorigen angefügt. Ist der String voll, wird die Speicherung am
ersten Byte des Strings unabhängig davon fortgesetzt, ob es innerhalb
eines Datenelements zu einem Bruch kommt. Bevor (zur Vergrößerung
des aktuellen activityDailyRecord oder zum Einsetzen eines neuen acti­
vityDailyRecord) neue Tätigkeitsdaten in den String gesetzt werden, die
ältere Tätigkeitsdaten ersetzen, muss activityPointerOldestDayRecord ak­
tualisiert werden, um den neuen Platz des ältesten vollständigen Tages­
datensatzes auszuweisen, und activityPreviousRecordLength dieses
(neuen) ältesten vollständigen Tagesdatensatzes muss auf 0 zurückgesetzt
werden.
2.18. CardDrivingLicenceInformation
Auf einer Fahrer- oder Werkstattkarte gespeicherte Information zu den
Führerscheindaten des Karteninhabers (Anhang 1C Randnummern 259
und 284).
drivingLicenceIssuingAuthority — die für die Ausstellung des Führer­
scheins zuständige Behörde.
drivingLicenceIssuingNation — Nationalität der Ausstellungsbehörde
des Führerscheins.
drivingLicenceNumber — Nummer des Führerscheins.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 131
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).
CardEventData — eine nach absteigendem Wert von EventFaultType
geordnete Folge von cardEventRecords (mit Ausnahme von Versuchen
der Sicherheitsverletzung, die in der letzten Gruppe der Folge zusam­
mengefasst 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).
CardEventData — eine nach absteigendem Wert von EventFaultType
geordnete Folge von cardEventRecords (mit Ausnahme von Versuchen
der Sicherheitsverletzung, die in der letzten Gruppe der Folge zusam­
mengefasst sind).
cardEventRecords — Ereignisdatensätze einer bestimmten Ereignisart
(oder Kategorie bei Ereignissen Versuch Sicherheitsverletzung).
▼B
2.20. CardEventRecord
Auf einer Fahrer- oder Werkstattkarte gespeicherte Information zu einem
Ereignis im Zusammenhang mit dem Karteninhaber (Anhang 1C Rand­
nummern 261, 286, 318 und 341).
eventType — Art des Ereignisses.
eventBeginTime — Datum und Uhrzeit des Ereignisbeginns.
eventEndTime — Datum und Uhrzeit des Ereignisendes.
eventVehicleRegistration — amtliches Kennzeichen und zulassender
Mitgliedstaat des Fahrzeugs, in dem das Ereignis eingetreten ist.
▼M1
02016R0799 — DE — 21.08.2023 — 003.002 — 132
2.21. CardFaultData
Auf einer Fahrer- oder Werkstattkarte gespeicherte Information zu den
Störungen im Zusammenhang mit dem Karteninhaber (Anhang 1C
Randnummern 263, 288, 318 und 341).
CardFaultData — eine Folge von Datensätzen mit Kontrollgerätstörun­
gen, gefolgt von Datensätzen mit Kartenfehlfunktionen.
cardFaultRecords — Störungsdatensätze einer bestimmten Störungs­
kategorie (Kontrollgerät oder Karte).
2.22. CardFaultRecord
Auf einer Fahrer- oder Werkstattkarte gespeicherte Information zu einer
Störung im Zusammenhang mit dem Karteninhaber (Anhang 1C Rand­
nummern 264, 289, 318 und 341).
faultType — Art der Störung.
faultBeginTime — Datum und Uhrzeit des Störungsbeginns.
faultEndTime — Datum und Uhrzeit des Störungsendes.
faultVehicleRegistration — amtliches Kennzeichen und zulassender
Mitgliedstaat des Fahrzeugs, in dem die Störung auftrat.
2.23. CardIccIdentification
Auf einer Karte gespeicherte Information zur Identifizierung der Karte
des integrierten Schaltkreises (IS) (Anhang 1C Randnummer 248).
clockStop — Clockstop-Modus laut Definition in Anlage 2.
cardExtendedSerialNumber — eindeutige Seriennummer der IS-Karte
gemäß weiterer Spezifikation durch den Datentyp ExtendedSerialN­
umber.
cardApprovalNumber –Typgenehmigungsnummer der Karte.
cardPersonaliserID — Karten-Personaliser-ID kodiert als Manufacturer­
Code.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 133
embedderIcAssemblerId — enthält Informationen zum Kartenherstel­
ler/IS-Assembler.
icIdentifier — Bezeichner des IS auf der Karte und des IS-Herstellers
laut Definition in ISO/IEC 7816-6.
2.24. CardIdentification
Auf der Karte gespeicherte Information zur Identifikation der Karte (An­
hang 1C Randnummern 255, 280, 310, 333, 359, 365, 371 und 377).
cardIssuingMemberState — Code des Mitgliedstaates, der die Karte
ausgestellt hat.
cardNumber — Kartennummer.
cardIssuingAuthorityName — Name der Behörde, die die Karte aus­
gestellt hat.
cardIssueDate — Datum der Ausstellung der Karte an den derzeitigen
Inhaber.
cardValidityBegin — Datum, an dem die Gültigkeit der Karte beginnt.
cardExpiryDate — Datum, an dem die Gültigkeit der Karte abläuft.
▼M3
2.24a. CardLoadTypeEntries
2. Generation, Version 2:
Auf einer Fahrer- oder Werkstattkarte gespeicherte Informationen zu
Eingaben der Art der Ladung, wenn die Karte in eine Fahrzeugeinheit
eingesteckt wird (Anhang IC Randnummern 306j und 356j).
loadTypeEntryPointerNewestRecord – Index des zuletzt aktualisierten
Datensatzes der Ladungsarteingabe der Karte.
Wertzuweisung: Zahl, die dem Zähler des Datensatzes der Ladungsart­
eingabe der Karte entspricht, beginnend mit „0“ für das erste Auftreten
des Datensatzes der Ladungsarteingabe der Karte in der Struktur.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 134
cardLoadTypeEntryRecords – Datensätze mit Datum und Uhrzeit der
Eingabe und der eingegebenen Art der Ladung.
2.24b. CardLoadTypeEntryRecord
2. Generation, Version 2:
Auf einer Fahrer- oder Werkstattkarte gespeicherte Informationen zu
Eingaben der Änderung der Art der Ladung, wenn die Karte in eine
Fahrzeugeinheit eingesteckt wird (Anhang IC Randnummern 306i
und 356i).
timeStamp – Datum und Uhrzeit der Eingabe der Art der Ladung.
loadTypeEntered – die eingegebene Art der Ladung.
2.24c. CardLoadUnloadOperations
2. Generation, Version 2:
Auf einer Fahrer- oder Werkstattkarte gespeicherte Informationen zu
Be-/Entladevorgängen des Fahrzeugs (Anhang IC Randnummern 306h
und 356h).
loadUnloadPointerNewestRecord – Index des zuletzt aktualisierten
Be-/Entladedatensatzes der Karte.
Wertzuweisung: Zahl, die dem Zähler des Be-/Entladedatensatzes der
Karte entspricht, beginnend mit „0“ für das erste Auftreten des
Be-/Entladedatensatzes der Karte in der Struktur.
cardLoadUnloadRecords – Datensätze mit Angabe der Art des durch­
geführten Vorgangs (Beladen, Entladen oder gleichzeitiges Be- und Ent­
laden), Datum und Uhrzeit der Eingabe des Be-/Entladevorgangs, An­
gaben zur Position des Fahrzeugs und Kilometerstand.
2.24d. CardLoadUnloadRecord
2. Generation, Version 2:
Auf einer Fahrer- oder Werkstattkarte gespeicherte Informationen zu
Be-/Entladevorgängen des Fahrzeugs (Anhang IC Randnummern 306g
und 356g).
timeStamp – Datum und Uhrzeit des Beginns des Be-/Entladevorgangs.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 135
operationType – Art des eingegebenen Vorgangs (Beladen, Entladen
oder gleichzeitiges Be- und Entladen).
gnssPlaceAuthRecord – Informationen zur Position des Fahrzeugs.
vehicleOdometerValue – Kilometerstand bei Beginn des Be-/Entlade­
vorgangs.
▼B
2.25. CardMACertificate
2. Generation:
Zertifikat des öffentlichen Schlüssels der Karte zur gegenseitigen Au­
thentisierung mit einer VU. Die Struktur dieses Zertifikats ist in Anlage
11 spezifiziert.
2.26. CardNumber
Kartennummer nach Begriffsbestimmung g).
driverIdentification — eindeutige Kennung eines Fahrers in einem Mit­
gliedstaat.
ownerIdentification — eindeutige Kennung eines Unternehmens oder
einer Werkstatt oder einer Kontrollstelle in einem Mitgliedstaat.
cardConsecutiveIndex — fortlaufender Kartenindex.
cardReplacementIndex — Kartenersatzindex.
cardRenewalIndex — Kartenerneuerungsindex.
Die erste Folge der Auswahl eignet sich zur Kodierung einer Fahrerkar­
tennummer, die zweite Folge zur Kodierung der Werkstatt-, Kontroll-
und Unternehmenskartennummer.
▼M3
2.26a. CardPlaceAuthDailyWorkPeriod
2. Generation, Version 2:
Auf einer Fahrer- oder Werkstattkarte gespeicherte Informationen, die
den Authentisierungsstatus des Orts des Beginns und/oder des Endes
des Arbeitstages angeben (Anhang IC Randnummern 306b und 356b).
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 136
placeAuthPointerNewestRecord – Index des zuletzt aktualisierten Au­
thentisierungsstatusdatensatzes des Orts.
Wertzuweisung: Zahl, die dem Zähler des Authentisierungsstatusdaten­
satzes des Orts entspricht, beginnend mit „0“ für das erste Auftreten der
Authentisierungsstatusdatensätze des Orts in der Struktur.
placeAuthStatusRecords – Datensätze mit dem Authentisierungsstatus
der eingegebenen Orte.
▼B
2.27. CardPlaceDailyWorkPeriod
Auf einer Fahrer- oder Werkstattkarte gespeicherte Information zum Ort
des Beginns und/oder des Endes des Arbeitstages (Anhang 1C Rand­
nummern 272, 297, 325 und 348).
placePointerNewestRecord — Index des zuletzt aktualisierten Orts­
datensatzes.
Wertzuweisung: Zahl, die dem Zähler des Ortsdatensatzes entspricht,
beginnend mit „0“ für das erste Auftreten der Ortsdatensätze in der
Struktur.
placeRecords — Datensätze mit Informationen zu den eingegebenen
Orten.
2.28. CardPrivateKey
1. Generation:
Der private Schlüssel einer Karte.
2.29. CardPublicKey
Der öffentliche Schlüssel einer Karte.
▼M1
2.30. CardRenewalIndex
Ein Kartenerneuerungsindex (Begriffsbestimmung i)).
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 137
Wertzuweisung: (siehe Kapitel 7 in diesem Anhang).
„0“ Erstausstellung.
Reihenfolge für die Erhöhung: ,0, …, 9, A, …, Z‘
▼B
2.31. CardReplacementIndex
Ein Kartenersatzindex (Begriffsbestimmung j)).
Wertzuweisung: (siehe Kapitel VII in diesem Anhang).
„0“ Originalkarte.
Reihenfolge für die Erhöhung: „0, …, 9, A, …, Z“
2.32. CardSignCertificate
2. Generation:
Zertifikat des öffentlichen Schlüssels einer Karte zur Signatur. Die
Struktur dieses Zertifikats ist in Anlage 11 spezifiziert.
2.33. CardSlotNumber
Code zur Unterscheidung der beiden Steckplätze einer Fahrzeugeinheit.
Wertzuweisung: nicht näher spezifiziert.
2.34. CardSlotsStatus
Code zur Angabe der in den beiden Steckplätzen der Fahrzeugeinheit
eingesteckten Kartenarten.
Wertzuweisung — Oktettanordnung: „ccccdddd“B
„cccc“B Identifizierung der im Steckplatz Beifahrer befindlichen
Kartenart,
„dddd“B Identifizierung der im Steckplatz Fahrer befindlichen
Kartenart,
mit folgenden Codes:
„0000“B keine Karte eingesteckt,
„0001“B Fahrerkarte eingesteckt,
„0010“B Werkstattkarte eingesteckt,
„0011“B Kontrollkarte eingesteckt,
„0100“B Unternehmenskarte eingesteckt.
▼M1
02016R0799 — DE — 21.08.2023 — 003.002 — 138
2.35. CardSlotsStatusRecordArray
2. Generation:
CardSlotsStatus und im Download-Protokoll verwendete Metadaten.
recordType — Art des Datensatzes (CardSlotsStatus). Wertzuweisung:
siehe RecordType
recordSize — die Größe des CardSlotsStatus in Byte.
noOfRecords — Anzahl der Datensätze in der Menge der Datensätze.
records — Menge der CardSlotsStatus-Datensätze.
2.36. CardStructureVersion
Code zur Angabe der Version der auf einer Fahrtenschreiberkarte im­
plementierten Struktur.
Wertzuweisung: „aabb“H:
„aa“H Index für Änderungen der Struktur.
„00“H für Anwendungen der 1. Generation
„01“H für Anwendungen der 2. Generation
▼M3
„bb“H Index für Änderungen im Zusammenhang mit dem Ge­
brauch der Datenelemente, die für die vom oberen Byte
gegebene Struktur definiert sind.
„00“H für Anwendungen der 1. Generation
„00“H für Version 1 von Anwendungen der 2. Genera­
tion
„01“H für Version 2 von Anwendungen der 2. Genera­
tion
▼B
2.37. CardVehicleRecord
Auf einer Fahrer- oder Werkstattkarte gespeicherte Information zur Ein­
satzzeit eines Fahrzeugs an einem Kalendertag (Anhang 1C Randnum­
mern 269, 294, 322 und 345).
1. Generation:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 139
vehicleOdometerBegin — Kilometerstand zu Beginn der Einsatzzeit
des Fahrzeugs.
vehicleOdometerEnd — Kilometerstand am Ende der Einsatzzeit des
Fahrzeugs.
vehicleFirstUse — Datum und Uhrzeit des Beginns der Einsatzzeit des
Fahrzeugs.
vehicleLastUse — Datum und Uhrzeit des Endes der Einsatzzeit des
Fahrzeugs.
vehicleRegistration — amtliches Kennzeichen und zulassender Mit­
gliedstaat des Fahrzeugs.
vuDataBlockCounter — Wert des VuDataBlockCounter beim letzten
Auszug der Einsatzzeit des Fahrzeugs.
2. Generation:
Zusätzlich zur 1. Generation wird folgendes Datenelement verwendet:
VehicleIdentificationNumber — die Fahrzeugidentifizierungsnummer
mit Bezug auf das Fahrzeug insgesamt.
2.38. CardVehiclesUsed
Auf einer Fahrer- oder Werkstattkarte gespeicherte Information zu den
vom Karteninhaber gefahrenen Fahrzeugen (Anhang 1C Randnummern
270, 295, 323 und 346).
vehiclePointerNewestRecord — Index des zuletzt aktualisierten Fahr­
zeugdatensatzes.
Wertzuweisung: Zahl, die dem Zähler des Fahrzeugdatensatzes ent­
spricht, beginnend mit „0“ für das erste Auftreten der Fahrzeugdaten­
sätze in der Struktur.
cardVehicleRecords — Datensätze mit Informationen zu den gefahre­
nen Fahrzeugen.
2.39. CardVehicleUnitRecord
2. Generation:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 140
Auf einer Fahrer- oder Werkstattkarte gespeicherte Information zu der
verwendeten Fahrzeugeinheit (Anhang 1C Randnummern 303 und 351).
timeStamp — Beginn der Einsatzzeit der Fahrzeugeinheit (d. h. erstes
Karteneinstecken in die Fahrzeugeinheit für diesen Zeitraum).
manufacturerCode — Name des Herstellers der Fahrzeugeinheit.
deviceID — Identifizierung des Typs der Fahrzeugeinheit eines Herstel­
lers. Der Wert ist herstellerspezifisch.
vuSoftwareVersion — Softwareversionsnummer der Fahrzeugeinheit.
2.40. CardVehicleUnitsUsed
▼M3
2. Generation:
Auf einer Fahrer- oder Werkstattkarte gespeicherte Informationen zu den
vom Karteninhaber gefahrenen Fahrzeugeinheiten (Anhang IC Rand­
nummern 304 und 352).
▼B
vehicleUnitPointerNewestRecord — Index des zuletzt aktualisierten
Datensatzes für die Fahrzeugeinheit.
Wertzuweisung: Zahl, die dem Zähler des Datensatzes der Fahrzeug­
einheit entspricht, beginnend mit „0“ für das erste Auftreten der Daten­
sätze der Fahrzeugeinheit in der Struktur.
cardVehicleUnitRecords — Datensätze mit Informationen zu den ge­
nutzten Fahrzeugeinheiten.
2.41. Certificate
Das von einer Zertifizierungsstelle ausgestellte Zertifikat eines öffent­
lichen Schlüssels.
1. Generation:
Wertzuweisung: digitale Signatur mit teilweiser Wiederherstellung eines
CertificateContent gemäß Anlage 11 „Gemeinsame Sicherheitsmechanis­
men“: Signature (128 Byte) || Public Key remainder (58 Byte) || Certi­
fication Authority Reference (8 Byte).
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 141
2. Generation:
Wertzuweisung: siehe Anlage 11
2.42. CertificateContent
1. Generation:
Der (Klartext-) Inhalt des Zertifikats eines öffentlichen Schlüssels gemäß
Anlage 11 „Gemeinsame Sicherheitsmechanismen“.
certificateProfileIdentifier — Version des entsprechenden Zertifikats.
Wertzuweisung: „01h“ für diese Version.
certificationAuthorityReference identifiziert die das Zertifikat ausstel­
lende Zertifizierungsstelle. und enthält darüber hinaus einen Verweis auf
den öffentlichen Schlüssel dieser Zertifizierungsstelle.
certificateHolderAuthorisation identifiziert die Rechte des Zertifikats­
inhabers.
certificateEndOfValidity — Datum, an dem die Gültigkeit des Zertifi­
kats administrativ endet.
certificateHolderReference identifiziert den Zertifikatsinhaber. und ent­
hält zugleich einen Verweis auf dessen öffentlichen Schlüssel.
publicKey — der öffentliche Schlüssel, der durch dieses Zertifikat zer­
tifiziert wird.
2.43. CertificateHolderAuthorisation
Identifizierung der Rechte eines Zertifikatsinhabers.
1. Generation:
tachographApplicationID — Anwendungsbezeichner für die Kontroll­
gerätanwendung.
Wertzuweisung: „FFh“ „54h“ „41h“ „43h“ „48h“ „4Fh“. Dieser AID ist
ein proprietärer nichtregistrierter Anwendungsbezeichner gemäß ISO/
IEC 7816-5.
equipmentType ist die Kennung des Gerätetyps, für den das Zertifikat
bestimmt ist.
Wertzuweisung: entsprechend dem Datentyp EquipmentType. 0, wenn
es sich um ein Zertifikat eines Mitgliedstaates handelt.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 142
2. Generation:
tachographApplicationID bezeichnet die 6 höchstwertigen Bytes des
zugehörigen Anwendungsbezeichners (Application Identifier, AID) der
Fahrtenschreiberkarte der 2. Generation. Der AID für die Fahrtenschrei­
berkartenanwendung ist in Kapitel 6.2 spezifiziert.
Wertzuweisung: „FF 53 4D 52 44 54“.
equipmentType — ist die Kennung des für die 2. Generation angege­
benen Gerätetyps, für den das Zertifikat bestimmt ist.
Wertzuweisung: entsprechend dem Datentyp EquipmentType.
2.44. CertificateRequestID
Eindeutige Kennung eines Zertifikatsantrags. Kann auch als Bezeichner
des öffentlichen Schlüssels einer Fahrzeugeinheit verwendet werden,
wenn die Seriennummer der Fahrzeugeinheit, für die der Schlüssel be­
stimmt ist, zum Zeitpunkt der Erzeugung des Zertifikats nicht bekannt ist.
requestSerialNumber — einmalige Seriennummer des Zertifikats­
antrags für den im Folgenden angegebenen Hersteller und Monat.
requestMonthYear — Kennung für den Monat und das Jahr des Zer­
tifikatsantrags.
Wertzuweisung: BCD-Kodierung des Monats (zwei Stellen) und des
Jahres (die beiden letzten Stellen).
crIdentifier — Bezeichner zur Unterscheidung eines Zertifikatsantrags
von einer erweiterten Seriennummer.
Wertzuweisung: „FFh“.
manufacturerCode — numerischer Code des Herstellers, der das Zer­
tifikat beantragt.
2.45. CertificationAuthorityKID
Bezeichner des öffentlichen Schlüssels einer Zertifizierungsstelle (Mit­
gliedstaatliche Stelle oder Europäische Zertifizierungsstelle).
nationNumeric — numerischer Landescode der Zertifizierungsstelle.
nationAlpha — alphanumerischer Landescode der Zertifizierungsstelle.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 143
keySerialNumber — eine Seriennummer zur Unterscheidung der ver­
schiedenen Schlüssel der Zertifizierungsstelle für den Fall des Wechsels
von Schlüsseln.
additionalInfo — 2-Byte-Feld für Zusatzkodierung (je nach Zertifizie­
rungsstelle).
caIdentifier — Bezeichner zur Unterscheidung des Schlüsselbezeichners
einer Zertifizierungsstelle von anderen Schlüsselbezeichnern.
Wertzuweisung: „01h“.
2.46. CompanyActivityData
Auf einer Unternehmenskarte gespeicherte Information zu den mit der
Karte ausgeführten Tätigkeiten (Anhang 1C Randnummern 373 und 379).
companyPointerNewestRecord — Index des zuletzt aktualisierten com­
panyActivityRecord.
Wertzuweisung: Zahl, die dem Zähler des Unternehmenstätigkeitsdaten­
satzes entspricht, beginnend mit „0“ für das erste Auftreten des Unter­
nehmenstätigkeitsdatensatzes in der Struktur.
companyActivityRecords — sämtliche Unternehmenstätigkeitsdaten­
sätze.
companyActivityRecord — Folge von Informationen zu einer Unter­
nehmenstätigkeit.
companyActivityType — Art der Unternehmenstätigkeit.
companyActivityTime — Datum und Uhrzeit der Unternehmenstätig­
keit.
cardNumberInformation — gegebenenfalls Kartennummer und aus­
stellender Mitgliedstaat der heruntergeladenen Karte.
vehicleRegistrationInformation — amtliches Kennzeichen und zulas­
sender Mitgliedstaat des heruntergeladenen bzw. des gesperrten oder
entsperrten Fahrzeugs.
downloadPeriodBegin und downloadPeriodEnd — gegebenenfalls der
von der VU heruntergeladene Zeitraum.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 144
2.47. CompanyActivityType
Code für die von einem Unternehmen unter Nutzung seiner Unterneh­
menskarte ausgeführte Tätigkeit.
2.48. CompanyCardApplicationIdentification
Auf einer Unternehmenskarte gespeicherte Information zur Identifizierung
der Anwendung der Karte (Anhang 1C Randnummern 369 und 375).
typeOfTachographCardId gibt die implementierte Kartenart an.
cardStructureVersion gibt die Version der auf der Karte implementier­
ten Struktur an.
noOfCompanyActivityRecords Anzahl der Unternehmenstätigkeits­
datensätze, die die Karte speichern kann.
▼M3
2.48a. CompanyCardApplicationIdentificationV2
2. Generation, Version 2:
Auf einer Unternehmenskarte gespeicherte Informationen zur Identifizie­
rung der Anwendung der Karte (Anhang IC Randnummer 375a).
lengthOfFollowingData – Anzahl der nachfolgenden Bytes im Daten­
satz.
vuConfigurationLengthRange – Anzahl der Bytes in einer Fahrten­
schreiberkarte, die für die Speicherung von Konfigurationen der Fahr­
zeugeinheit verfügbar sind.
▼B
2.49. CompanyCardHolderIdentification
Auf einer Unternehmenskarte gespeicherte Information zur Identifizie­
rung des Karteninhabers (Anhang 1C Randnummern 372 und 378).
companyName — Name des Unternehmens, dem die Karte gehört.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 145
companyAddress — Anschrift des Unternehmens, dem die Karte ge­
hört.
cardHolderPreferredLanguage — bevorzugte Sprache des Karteninha­
bers.
2.50. ControlCardApplicationIdentification
Auf einer Kontrollkarte gespeicherte Information zur Identifizierung der
Anwendung der Karte (Anhang 1C Randnummern 357 und 363).
typeOfTachographCardId gibt die implementierte Kartenart an.
cardStructureVersion — gibt die Version der auf der Karte implemen­
tierten Version der Struktur an.
noOfControlActivityRecords — Anzahl der Kontrolltätigkeitsdaten­
sätze, die die Karte speichern kann.
▼M3
2.50a. ControlCardApplicationIdentificationV2
2. Generation, Version 2:
Auf einer Kontrollkarte gespeicherte Informationen zur Identifizierung
der Anwendung der Karte (Anhang IC Randnummer 363a).
lengthOfFollowingData – Anzahl der nachfolgenden Bytes im Daten­
satz.
vuConfigurationLengthRange – Anzahl der Bytes in einer Fahrten­
schreiberkarte, die für die Speicherung von Konfigurationen der Fahr­
zeugeinheit verfügbar sind.
▼B
2.51. ControlCardControlActivityData
Auf einer Kontrollkarte gespeicherte Information zur mit der Karte durch­
geführten Kontrolltätigkeit (Anhang 1C Randnummern 361 und 367).
controlPointerNewestRecord — Index des zuletzt aktualisierten Kon­
trolltätigkeitsdatensatzes.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 146
Wertzuweisung: Zahl, die dem Zähler des Kontrolltätigkeitsdatensatzes
entspricht, beginnend mit „0“ für das erste Auftreten des Kontrolltätig­
keitsdatensatzes in der Struktur.
controlActivityRecords — sämtliche Kontrolltätigkeitsdatensätze.
controlActivityRecord — Folge von Informationen zu einer Kontrolle.
controlType — Art der Kontrolle.
controlTime — Datum und Uhrzeit der Kontrolle.
controlledCardNumber — Kartennummer und ausstellender Mitglied­
staat der kontrollierten Karte.
controlledVehicleRegistration — amtliches Kennzeichen und zulassen­
der Mitgliedstaat des Fahrzeugs, in dem die Kontrolle stattfand.
controlDownloadPeriodBegin und controlDownloadPeriodEnd — he­
runtergeladener Zeitraum.
2.52. ControlCardHolderIdentification
Auf einer Kontrollkarte gespeicherte Information zur Identifizierung des
Karteninhabers (Anhang 1C Randnummern 360 und 366).
controlBodyName — Name der Kontrollstelle des Karteninhabers.
controlBodyAddress — Anschrift der Kontrollstelle des Karteninha­
bers.
cardHolderName — Name und Vorname(n) des Inhabers der Kontroll­
karte.
cardHolderPreferredLanguage — bevorzugte Sprache des Karteninha­
bers.
2.53. ControlType
Code zur Angabe der bei einer Kontrolle ausgeführten Aktivitäten. Die­
ser Datentyp bezieht sich auf Anhang 1C Randnummern 126, 274, 299,
327 und 350.
1. Generation:
Wertzuweisung — Oktettanordnung: „cvpdxxxx“B (8 Bit)
„c“B Herunterladen der Karte:
„0“B: Karte bei dieser Kontrollaktivität nicht heruntergela­
den,
„1“B: Karte bei dieser Kontrollaktivität heruntergeladen
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 147
„v“B Herunterladen der VU:
„0“B: VU bei dieser Kontrollaktivität nicht heruntergela­
den,
„1“B: VU bei dieser Kontrollaktivität heruntergeladen
„p“B Drucken:
„0“B: kein Drucken bei dieser Kontrollaktivität,
„1“B: Drucken bei dieser Kontrollaktivität
„d“B Anzeige:
„0“B: keine Anzeige bei dieser Kontrollaktivität verwendet,
„1“B: Anzeige bei dieser Kontrollaktivität verwendet
„xxxx“B Nichtverwendung.
2. Generation:
Wertzuweisung — Oktettanordnung: „cvpdexxx“B (8 Bit)
„c“B Herunterladen der Karte:
„0“B: Karte bei dieser Kontrollaktivität nicht heruntergela­
den,
„1“B: Karte bei dieser Kontrollaktivität heruntergeladen
„v“B Herunterladen der VU:
„0“B: VU bei dieser Kontrollaktivität nicht heruntergela­
den,
„1“B: VU bei dieser Kontrollaktivität heruntergeladen
„p“B Drucken:
„0“B: kein Drucken bei dieser Kontrollaktivität,
„1“B: Drucken bei dieser Kontrollaktivität
„d“B Anzeige:
„0“B: keine Anzeige bei dieser Kontrollaktivität verwendet,
„1“B: Anzeige bei dieser Kontrollaktivität verwendet
„e“B Kalibrierungskontrolle unterwegs:
„0“B: Kalibrierungsparameter bei dieser Kontrollaktivität
nicht überprüft,
„1“B: Kalibrierungsparameter bei dieser Kontrollaktivität
überprüft
„xxx“B RFU.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 148
2.54. CurrentDateTime
Aktuelles Datum und aktuelle Uhrzeit des Kontrollgeräts.
Wertzuweisung: nicht näher spezifiziert.
2.55. CurrentDateTimeRecordArray
2. Generation:
Datum und Uhrzeit plus im Download-Protokoll verwendete Metadaten.
recordType — Art des Datensatzes (CurrentDateTime). Wertzuwei­
sung: siehe RecordType
recordSize — die Größe des CurrentDateTime in Byte.
noOfRecords — Anzahl der Datensätze in der Menge der Datensätze.
records –.Menge der aktuellen Datums- und Uhrzeit-Datensätze.
2.56. DailyPresenceCounter
Auf einer Fahrer- oder Werkstattkarte gespeicherter Zähler, der für jeden
Kalendertag, an dem die Karte in eine VU eingesteckt wurde, um eins
erhöht wird. Dieser Datentyp bezieht sich auf Anhang 1C Randnummern
266, 299, 320 und 343.
Wertzuweisung: Laufende Nummer mit Höchstwert = 9999, danach
wieder bei 0 beginnend. Zum Zeitpunkt des ersten Einsteckens der Karte
ist die Zahl auf 0 gesetzt.
2.57. Datef
Datum in einem leicht ausdruckbaren numerischen Format.
Wertzuweisung:
yyyy Jahr
mm Monat
dd Tag
„00000000“H bezeichnet explizit kein Datum.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 149
2.58. DateOfDayDownloaded
2. Generation:
Datum und Uhrzeit des Downloads.
Wertzuweisung: nicht näher spezifiziert.
2.59. DateOfDayDownloadedRecordArray
2. Generation:
Datum und Uhrzeit des Herunterladens plus im Download-Protokoll
verwendete Metadaten.
recordType — Art des Datensatzes (DateOfDayDownloaded). Wert­
zuweisung: siehe RecordType
recordSize — die Größe des CurrentDateTime in Byte.
noOfRecords — Anzahl der Datensätze in der Menge der Datensätze.
records — Menge der Download-Datensätze von Datum und Uhrzeit.
2.60. Distance
Eine zurückgelegte Wegstrecke (Ergebnis der Differenz von zwei Kilo­
meterständen des Fahrzeugs).
Wertzuweisung: Vorzeichenlose Binärzahl. Wert in km im Betriebs­
bereich 0 bis 9 999 km.
▼M3
2.60a. DownloadInterfaceVersion
2. Generation, Version 2:
Code zur Angabe der Version der Download-Schnittstelle einer Fahr­
zeugeinheit.
Wertzuweisung: „aabb“H:
„aa“H „00“H: nicht verwendet,
„01“H: Fahrzeugeinheit der 2. Generation,
„bb“H „00“H: nicht verwendet,
„01“H: Version 2 der Fahrzeugeinheit der 2. Generation.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 150
2.61. DriverCardApplicationIdentification
Auf einer Fahrerkarte gespeicherte Information zur Identifizierung der
Anwendung der Karte (Anhang 1C Randnummern 253 und 278).
1. Generation:
typeOfTachographCardId gibt die implementierte Kartenart an.
cardStructureVersion gibt die Version der auf der Karte implementier­
ten Struktur an.
noOfEventsPerType — Anzahl der Ereignisse je Ereignisart, die die
Karte speichern kann.
noOfFaultsPerType — Anzahl der Störungen je Störungsart, die die
Karte speichern kann.
activityStructureLength — gibt die Zahl der Bytes an, die für die
Speicherung von Tätigkeitsdatensätzen zur Verfügung stehen.
noOfCardVehicleRecords — Anzahl der Fahrzeugdatensätze, die die
Karte enthalten kann.
noOfCardPlaceRecords — Anzahl der Orte, die die Karte aufzeichnen
kann.
2. Generation:
▼M1
Zusätzlich zur 1. Generation werden folgende Datenelemente verwendet:
noOfGNSSADRecords — Anzahl der kumulierten GNSS-Lenkzeiten­
datensä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.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 151
2.61a. DriverCardApplicationIdentificationV2
2. Generation, Version 2:
Auf einer Fahrerkarte gespeicherte Informationen zur Identifizierung der
Anwendung der Karte (Anhang IC Randnummer 278a).
lengthOfFollowingData – Anzahl der nachfolgenden Bytes im Daten­
satz.
noOfBorderCrossingRecords – Anzahl der Grenzüberschreitungsdaten­
sätze, die die Fahrerkarte speichern kann.
noOfLoadUnloadRecords – Anzahl der Be-/Entladedatensätze, die die
Fahrerkarte speichern kann.
noOfLoadTypeEntryRecords – Anzahl der Ladungsarteingabedaten­
sätze, die die Fahrerkarte speichern kann.
vuConfigurationLengthRange – Anzahl der Bytes in einer Fahrten­
schreiberkarte, die für die Speicherung von Konfigurationen der Fahr­
zeugeinheit verfügbar sind.
▼B
2.62. DriverCardHolderIdentification
Auf einer Fahrerkarte gespeicherte Information zur Identifizierung des
Karteninhabers (Anhang 1C Randnummern 256 und 281).
cardHolderName — Name und Vorname(n) des Inhabers der Fahrer­
karte.
cardHolderBirthDate — Geburtsdatum des Inhabers der Fahrerkarte.
cardHolderPreferredLanguage — bevorzugte Sprache des Karteninha­
bers.
▼M3
2.63. DSRCSecurityData
2. Generation:
Bezüglich der Definition dieses Datentyps siehe Anlage 11.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 152
2.64. EGFCertificate
2. Generation:
Zertifikat des öffentlichen Schlüssels der externen GNSS-Ausrüstung zur
gegenseitigen Authentisierung mit einer VU. Die Struktur dieses Zerti­
fikats ist in Anlage 11 spezifiziert.
2.65. EmbedderIcAssemblerId
Enthält Informationen zum Chipkartenhersteller.
countryCode — der Zweibuchstabencode des Modulintegrators gemäß
ISO 3166.
moduleEmbedder — Kennung des Modulintegrators.
manufacturerInformation — zum internen Gebrauch beim Hersteller.
2.66. EntryTypeDailyWorkPeriod
Code zur Unterscheidung zwischen Beginn und Ende des Eintrags eines
Arbeitstages und Eingabebedingung.
1. Generation
Wertzuweisung: gemäß ISO/IEC 8824-1.
▼M3
2. Generation
Wertzuweisung: gemäß ISO/IEC 8824-1.
▼B
2.67. EquipmentType
Code zur Unterscheidung verschiedener Gerätetypen für die Fahrten­
schreiberanwendung.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 153
1. Generation:
Wertzuweisung: gemäß ISO/IEC 8824-1.
Der Wert 0 ist für die Angabe des Mitgliedstaats oder Europas im
CHA-Feld der Zertifikate reserviert.
2. Generation:
▼M1
Die Werte der 1. Generation werden um Folgendes ergänzt:
Hinweis 1: Die Werte der 2. Generation für Einbauplakette, Adapter und
externen GNSS-Anschluss sowie die Werte der 1. Generation für Fahr­
zeugeinheit 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 Ge­
rätetyp zu verstehen. Zur Angabe des jeweiligen Zertifikats für die Er­
stellung einer digitalen Signatur sind die Werte (17), (18) oder (19) zu
verwenden.
▼B
2.68. EuropeanPublicKey
1. Generation:
Der europäische öffentliche Schlüssel.
2.69. EventFaultRecordPurpose
Code, der erläutert, warum ein Ereignis oder eine Störung aufgezeichnet
wurde.
Wertzuweisung:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 154
eines der 10 jüngsten Ereignisse oder Störungen
das längste Ereignis an einem der letzten 10 Tage des Auftretens
eines der 5 längsten Ereignisse in den letzten 365 Tagen
das letzte Ereignis an einem der letzten 10 Tage des Auftretens
das schwerwiegendste Ereignis an einem der letzten 10 Tage des Auftretens
eines der 5 schwerwiegendsten Ereignisse in den letzten 365 Tagen
das erste Ereignis oder die erste Störung nach der letzten Kalibrierung
ein aktives Ereignis oder eine andauernde Störung
RFU
herstellerspezifisch
2.70. EventFaultType
Code zur näheren Beschreibung eines Ereignisses oder einer Störung.
Wertzuweisung:
1. 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,
DatenfehlerBewegung,
Datenkonflikt Fahrzeugbewegung,
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,
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,
RFU,
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 155
Kartenstörungen,
Keine weiteren Angaben,
RFU,
RFU,
Herstellerspezifisch.
▼M3
2. Generation, Version 1:
▼M1 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,
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 156
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.
▼M3
2. Generation, Version 2:
„0x“H Allgemeine Ereignisse,
„00“H Keine weiteren Angaben,
„01“H Einstecken einer ungültigen Karte,
„02“H Kartenkonflikt,
„03“H Zeitüberlappung,
„04“H Lenken ohne geeignete Karte,
„05“H Einstecken der Karte während des Lenkens,
„06“H Letzter Vorgang nicht korrekt abgeschlossen,
„07“H Geschwindigkeitsüberschreitung,
„08“H Unterbrechung der Stromversorgung,
„09“H Datenfehler Bewegungssensor,
„0A“H Datenkonflikt Fahrzeugbewegung,
„0B“H Zeitkonflikt (zwischen GNSS und Systemuhr der VU),
„0C“H Kommunikationsfehler mit der Fernkommunikati­
onsausrüstung,
„0D“H Fehlende Positionsdaten des GNSS-Empfängers
„0E“H Kommunikationsfehler mit der externen GNSS-
Ausrüstung
„0F“H GNSS-Anomalie,
„1x“H „Versuch Sicherheitsverletzung“ an der Fahrzeug­
einheit,
„10“H Keine weiteren Angaben,
▼M1
02016R0799 — DE — 21.08.2023 — 003.002 — 157
„11“H Fehlgeschlagene Authentisierung des Bewegungs­
sensors,
„12“H Authentisierungsfehler der Fahrtenschreiberkarte,
„13“H Unbefugte Veränderung des Bewegungssensors,
„14“H Integritätsfehler der Kartendateneingabedaten,
„15“H Integritätsfehler der gespeicherten Benutzerdaten,
„16“H Interner Datenübertragungsfehler,
„17“H Unberechtigtes Öffnen des Gehäuses,
„18“H Hardwaremanipulation,
„19“H Manipulationserkennung beim GNSS,
„1 A“H Authentisierungsfehler der externen GNSS-Aus­
rüstung,
„1 B“H Abgelaufenes Zertifikat der externen GNSS-Aus­
rüstung,
„1C“H Inkonsistenz zwischen Bewegungsdaten und ge­
speicherten Fahrertätigkeitsdaten,
„1D“H bis „1F“H RFU,
„2x“H „Versuch Sicherheitsverletzung“ Bewegungssen­
sor,
„20“H Keine weiteren Angaben,
„21“H Fehlgeschlagene Authentisierung,
„22“H Integritätsfehler der gespeicherten Daten,
„23“H Interner Datenübertragungsfehler,
„24“H Unberechtigtes Öffnen des Gehäuses,
„25“H Hardwaremanipulation,
„26“H bis „2F“H RFU,
„3x“H Störungen Kontrollgerät,
„30“H Keine weiteren Angaben,
„31“H Interne Störung Fahrzeugeinheit,
„32“H Druckerstörung,
„33“H Anzeigestörung,
„34“H Störung beim Herunterladen,
„35“H Sensorstörung,
„36“H Interner GNSS-Empfänger,
„37“H Externe GNSS-Ausrüstung,
„38“H Fernkommunikationsausrüstung,
„39“H ITS-Schnittstelle,
„3 A“H Interne Sensorstörung,
„3B“H bis „3F“H RFU,
„4x“H Kartenstörungen,
„40“H Keine weiteren Angaben,
„41“H bis „4F“H RFU,
„50“H bis „7F“H RFU,
„80“H bis „FF“H Herstellerspezifisch.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 158
2.71. ExtendedSealIdentifier
2. Generation:
Der erweiterte Plombenbezeichner dient der eindeutigen Identifizierung
von Plomben (Anhang IC Randnummer 401).
manufacturerCode – ein Code des Plombenherstellers. Wertzuwei­
sung: siehe Registrierung in der Datenbank, die von der Europäischen
Kommission verwaltet wird (siehe https://dtc.jrc.ec.europa.eu).
sealIdentifier – ein Bezeichner für die Plombe, der für den Hersteller
eindeutig sein muss. Wertzuweisung: alphanumerischer Wert, im Her­
stellerbereich eindeutig gemäß [ISO 8859-1].
▼B
2.72. ExtendedSerialNumber
Eindeutige Kennung eines Geräts. Kann auch als Bezeichner des öffent­
lichen Schlüssels eines Geräts verwendet werden.
1. Generation:
serialNumber — einmalige Seriennummer des Geräts in Bezug auf den
Hersteller, den Gerätetyp sowie den Monat und das Jahr (im Folgenden
angegeben).
monthYear — Kennung für den Monat und das Jahr der Herstellung
(oder der Zuweisung der Seriennummer).
Wertzuweisung: BCD-Kodierung des Monats (zwei Stellen) und des
Jahres (die beiden letzten Stellen).
type — Bezeichner des Gerätetyps.
Wertzuweisung — herstellerspezifisch, mit reserviertem Wert „FFh“.
manufacturerCode — numerischer Code des Herstellers eines typge­
nehmigten Geräts.
2. Generation:
serialNumber — siehe 1. Generation
monthYear — siehe 1. Generation
type — Angabe des Gerätetyps
manufacturerCode — siehe 1. Generation
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 159
2.73. FullCardNumber
Code zur vollständigen Identifizierung einer Karte.
cardType — Art der Fahrtenschreiberkarte.
cardIssuingMemberState — Code des Mitgliedstaates, der die Karte
ausgegeben hat.
cardNumber — Kartennummer.
2.74. FullCardNumberAndGeneration
2. Generation:
Code zur vollständigen Identifizierung einer Karte und ihrer Generation.
fullcardNumber — Bezeichner der Fahrtenschreiberkarte.
generation — Angabe der Generation der verwendeten Fahrtenschrei­
berkarte.
2.75. Generation
2. Generation:
Generation des verwendeten Fahrtenschreibers.
Wertzuweisung:
„00“H RFU
„01“H 1. Generation
„02“H 2. Generation
„03“H … „FF“H RFU
2.76. GeoCoordinates
▼M3
2. Generation:
Die Geokoordinaten sind als Integer kodiert. Bei diesen Integern handelt
es sich um Vielfache der Kodierungen ±DDMM.M für die Breite und
±DDDMM.M für die Länge. Hier geben ±DD beziehungsweise ±DDD
die Grade an, MM.M die Minuten. Längengrad und Breitengrad einer
unbekannten Position werden in Hexadezimalnotation als „7FFFFF“ (in
Dezimalnotation als 8388607) dargestellt.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 160
latitude — kodiert als Vielfaches (Faktor 10) der Darstellung
±DDMM.M.
longitude — kodiert als Vielfaches (Faktor 10) der Darstellung
±DDDMM.M.
2.77. GNSSAccuracy
2. Generation:
Die Genauigkeit der GNSS-Positionsdaten (Begriffsbestimmung eee)).
Diese Genauigkeit ist als Integer kodiert, bei dem es sich um ein Viel­
faches (Faktor 10) des durch den GSA-NMEA-Datensatz bereitgestellten
X.Y-Wertes handelt.
▼M1
2.78. GNSSAccumulatedDriving
2. Generation:
Auf einer Fahrer- oder Werkstattkarte gespeicherte Informationen im
Zusammenhang mit der GNSS-Position des Fahrzeugs, wenn die kumu­
lierte Lenkzeit ein Vielfaches von drei Stunden erreicht (Anhang IC
Randnummern 306 und 354).
gnssADPointerNewestRecord — Index des zuletzt aktualisierten kumu­
lierten GNSS-Lenkzeitendatensatzes.
Wertzuweisung — Zahl, die dem Zähler des kumulierten GNSS-Lenk­
zeitendatensatzes entspricht, beginnend mit „0“ für das erste Auftreten
des kumulierten GNSS-Lenkzeitendatensatzes in der Struktur.
gnssAccumulatedDrivingRecords — Datensätze mit Datum und Uhr­
zeit, wann die kumulierte Lenkzeit ein Vielfaches von drei Stunden
erreicht, sowie Informationen zur Position des Fahrzeugs.
2.79. GNSSAccumulatedDrivingRecord
2. Generation:
Auf einer Fahrer- oder Werkstattkarte gespeicherte Informationen im
Zusammenhang mit der GNSS-Position des Fahrzeugs, wenn die kumu­
lierte Lenkzeit ein Vielfaches von drei Stunden erreicht (Anhang IC
Randnummern 305 und 353).
timeStamp — Datum und Uhrzeit, wann die kumulierte Lenkzeit ein
Vielfaches von drei Stunden erreicht.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 161
gnssPlaceRecord — Informationen zur Position des Fahrzeugs.
vehicleOdometerValue — Kilometerstand, wenn die kumulierte Lenk­
zeit ein Vielfaches von drei Stunden erreicht.
▼M3
2.79a. GNSSAuthAccumulatedDriving
2. Generation, Version 2:
Auf einer Fahrer- oder Werkstattkarte gespeicherte Informationen, die
den Authentisierungsstatus von GNSS-Positionen des Fahrzeugs an­
geben, wenn die kumulierte Lenkzeit ein Vielfaches von drei Stunden
erreicht (Anhang IC Randnummern 306d und 356d).
gnssAuthADPointerNewestRecord – Index des zuletzt aktualisierten
Authentisierungsstatusdatensatzes der GNSS-Position.
Wertzuweisung – Zahl, die dem Zähler des Authentisierungsstatusdaten­
satzes der GNSS-Position entspricht, beginnend mit „0“ für das erste
Auftreten des Authentisierungsstatusdatensatzes der GNSS-Position in
der Struktur.
gnssAuthStatusADRecords – Datensätze mit Datum und Uhrzeit, wenn
die kumulierte Lenkzeit ein Vielfaches von drei Stunden erreicht, sowie
Informationen zum Authentisierungsstatus der GNSS-Position.
2.79b. GNSSAuthStatusADRecord
2. Generation, Version 2:
Auf einer Fahrer- oder Werkstattkarte gespeicherte Informationen, die
den Authentisierungsstatus einer GNSS-Position des Fahrzeugs angeben,
wenn die kumulierte Lenkzeit ein Vielfaches von drei Stunden erreicht
(Anhang IC Randnummern 306c und 356c). Weitere Informationen zur
GNSS-Position selbst werden in einem anderen Datensatz gespeichert
(siehe 2.79 GNSSAccumulatedDrivingRecord).
timeStamp – Datum und Uhrzeit, wenn die kumulierte Lenkzeit ein
Vielfaches von drei Stunden erreicht (die genau dem Datum und der
Uhrzeit entsprechen, die im entsprechenden Datensatz GNSSAccumula­
tedDrivingRecord gespeichert sind).
authenticationStatus – Authentisierungsstatus der GNSS-Position, wenn
die kumulierte Lenkzeit ein Vielfaches von drei Stunden erreicht.
▼M1
02016R0799 — DE — 21.08.2023 — 003.002 — 162
2.79c. GNSSPlaceAuthRecord
2. Generation, Version 2:
Informationen zur GNSS-Position des Fahrzeugs (Anhang IC Randnum­
mern 108, 109, 110, 296, 306a, 306c, 306e, 306 g, 356a, 356c, 356e
und 356g).
timeStamp – Datum und Uhrzeit der Bestimmung der GNSS-Position
des Fahrzeugs.
gnssAccuracy – Genauigkeit der GNSS-Positionsdaten.
geoCoordinates – der mittels GNSS aufgezeichnete Standort.
authenticationStatus – der Authentisierungsstatus der GNSS-Position
zum Zeitpunkt ihrer Bestimmung.
▼B
2.80. GNSSPlaceRecord
2. Generation:
Informationen zur GNSS-Position des Fahrzeugs (Anhang 1C Randnum­
mern 108, 109, 110, 296, 305, 347 und 353).
timeStamp — Datum und Uhrzeit, wann die GNSS-Position des Fahr­
zeugs bestimmt wurde.
gnssAccuracy — Genauigkeit der GNSS-Positionsdaten.
geoCoordinates — der mittels GNSS aufgezeichnete Standort.
2.81. HighResOdometer
Kilometerstand des Fahrzeugs: Vom Fahrzeug während des Betriebs ins­
gesamt zurückgelegte Wegstrecke.
Wertzuweisung: Vorzeichenlose Binärzahl. Wert in 1/200 km im Be­
triebsbereich 0 bis 21 055 406 km.
2.82. HighResTripDistance
Während einer Fahrt oder eines Teils einer Fahrt zurückgelegte Weg­
strecke.
Wertzuweisung: Vorzeichenlose Binärzahl. Wert in 1/200 km im Be­
triebsbereich 0 bis 21 055 406 km.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 163
2.83. HolderName
Familienname und Vorname(n) eines Karteninhabers.
holderSurname — Familienname des Inhabers. Ohne Titel.
Wertzuweisung: Handelt es sich nicht um eine auf eine bestimmte
Person ausgestellte Karte, so enthält holderSurname die gleichen Infor­
mationen wie companyName oder workshopName oder controlBody­
Name.
holderFirstNames — Vorname(n) und Initialen des Inhabers.
▼M3
2.84. Reserviert für künftige Verwendung.
▼B
2. Generation:
Information, ob es sich beim GNSS-Empfänger der VU um ein internes
oder externes Gerät handelt. „True“ bedeutet, dass es sich um einen VU-
internen GNSS-Empfänger handelt. „False“ bedeutet, dass der
GNSS-Empfänger extern ist.
2.85. K-ConstantOfRecordingEquipment
Kontrollgerätkonstante (Begriffsbestimmung m)).
Wertzuweisung: Impulse je Kilometer im Betriebsbereich 0 bis 64 255
Imp/km.
▼M1
2.86. KeyIdentifier
Eindeutiger Bezeichner eines öffentlichen Schlüssels zur Herstellung ei­
nes Verweises auf den Schlüssel und für dessen Auswahl. Identifiziert
zugleich den Inhaber des Schlüssels.
Die erste Auswahlmöglichkeit eignet sich zum Verweis auf den öffent­
lichen Schlüssel einer Fahrzeugeinheit, einer Fahrtenschreiberkarte oder
einer externen GNSS-Ausrüstung.
Die zweite Auswahlmöglichkeit eignet sich zum Verweis auf den öffent­
lichen Schlüssel einer Fahrzeugeinheit (falls die Seriennummer der Fahr­
zeugeinheit zum Zeitpunkt der Generierung des Zertifikats nicht bekannt
ist).
Die dritte Auswahlmöglichkeit eignet sich zum Verweis auf den öffent­
lichen Schlüssel eines Mitgliedstaates.
▼B
2.87. KMWCKey
2. Generation:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 164
AES-Schlüssel und zugehörige Schlüsselversion, die für die Kopplung
VU–Bewegungssensor verwendet wird. Zu den Einzelheiten siehe An­
lage 11.
kMWCKey — Länge des AES-Schlüssels, verkettet mit dem Schlüssel,
der für die Kopplung VU–Bewegungssensor verwendet wird.
keyVersion — Schlüsselversion des AES-Schlüssels.
2.88. Language
Code zur Identifizierung einer Sprache.
Wertzuweisung: Kodierung aus zwei Kleinbuchstaben gemäß ISO 639.
2.89. LastCardDownload
Auf der Fahrerkarte gespeicherte(s) Datum und Uhrzeit des letzten He­
runterladens der Daten von der Karte (zu anderen als Kontrollzwecken)
— Anhang 1C Randnummern 257 und 282. Diese Datumsangabe kann
mit einer beliebigen VU oder einem Kartenlesegerät geändert werden.
Wertzuweisung: nicht näher spezifiziert.
▼M3
2.89a. LengthOfFollowingData
2. Generation, Version 2:
Längenindikator für verlängerbare Datensätze.
Wertzuweisung: siehe Anlage 2.
▼B
2.90. LinkCertificate
2. Generation:
Das Linkzertifikat zwischen Schlüsselpaaren der European Root CA.
▼M3
2.90a. LoadType
2. Generation, Version 2:
Code zur Identifizierung einer eingegebenen Art der Ladung.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 165
Wertzuweisung:
„00“H Art der Ladung nicht definiert,
„01“H Güter,
„02“H Personen,
„03“H … „FF“H Personen,
▼B
2.91. L-TyreCircumference
Tatsächlicher Umfang der Fahrzeugreifen (Begriffsbestimmung u)).
Wertzuweisung: Vorzeichenlose Binärzahl, Wert in 1/8 mm im Be­
triebsbereich 0 bis 8 031 mm.
▼M1
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.
▼B
2.93. ManualInputFlag
Code, der angibt, ob ein Karteninhaber beim Einstecken der Karte Fah­
rertätigkeiten manuell eingegeben hat oder nicht (Anhang 1B Randnum­
mer 081 und Anhang 1C Randnummer 102).
Wertzuweisung: nicht näher spezifiziert.
2.94. ManufacturerCode
Code zur Identifizierung des Herstellers typgenehmigter Geräte.
Das für Interoperabilitätsprüfungen zuständige Labor führt die Liste der
Herstellercodes und veröffentlicht sie auf seiner Internetseite (Anhang 1C
Randnummer 454).
ManufacturerCodes werden den Entwicklern von Fahrtenschreibergeräten
auf Antrag beim für Interoperabilitätsprüfungen zuständigen Labor vor­
läufig zugeteilt.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 166
2.95. ManufacturerSpecificEventFaultData
2. Generation:
Herstellerspezifische Fehlercodes vereinfachen die Fehleranalyse sowie
die Instandhaltung von Fahrzeugeinheiten.
manufacturerCode — Name des Herstellers der Fahrzeugeinheit.
manufacturerSpecificErrorCode — ein für den Hersteller spezifischer
Fehlercode.
2.96. MemberStateCertificate
Zertifikat des öffentlichen Schlüssels eines Mitgliedstaates, ausgestellt
von der europäischen Zertifizierungsstelle.
2.97. MemberStateCertificateRecordArray
2. Generation:
Zertifikat des Mitgliedstaats und im Download-Protokoll verwendete Me­
tadaten.
recordType — Art des Datensatzes (MemberStateCertificate). Wert­
zuweisung: siehe RecordType
recordSize — die Größe des MemberStateCertificate in Byte.
noOfRecords — Anzahl der Datensätze in der Menge der Datensätze.
Der Wert muss auf 1 gesetzt werden, da die Zertifikate verschieden lang
sein können.
records –der Satz der Mitgliedstaatzertifikate.
2.98. MemberStatePublicKey
1. Generation:
Der öffentliche Schlüssel eines Mitgliedstaates.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 167
2.99. Name
Ein Name.
codePage gibt einen in Kapitel 4 definierten Zeichensatz an,
name ist ein unter Verwendung des spezifizierten Zeichensatzes kodier­
ter Name.
2.100. NationAlpha
Die alphabetische Bezeichnung eines Staats erfolgt im Einklang mit den
auf Fahrzeugen im grenzüberschreitenden Verkehr gemäß dem Wiener
Übereinkommen über den Straßenverkehr (Vereinte Nationen, 1968) ver­
wendeten Unterscheidungszeichen.
Die Codes NationAlpha und NationNumeric sind in einer Liste auf­
geführt, die von dem gemäß Anhang 1C Randnummer 440 mit der
Durchführung der Interoperabilitätsprüfungen beauftragten Labor auf
dessen Internetseite geführt wird.
2.101. NationNumeric
Numerische Bezeichnung eines Landes.
Wertzuweisung: siehe Datentyp 2.100 (NationAlpha).
Jegliche Änderung oder Aktualisierung der Spezifikationen NationAlpha
oder NationNumeric darf von dem beauftragten Labor nur nach Ein­
holung von Stellungnahmen der Hersteller typgenehmigter digitaler und
intelligenter Fahrtenschreiber-Fahrzeugeinheiten vorgenommen werden.
▼M3
2.101a. NoOfBorderCrossingRecords
2. Generation, Version 2:
Anzahl der Grenzüberschreitungsdatensätze, die eine Fahrer- oder Werk­
stattkarte speichern kann.
Wertzuweisung: siehe Anlage 2.
▼B
2.102. NoOfCalibrationRecords
Anzahl der Kalibrierungsdatensätze, die eine Werkstattkarte speichern
kann.
1. Generation:
Wertzuweisung: siehe Anlage 2.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 168
2. Generation:
Wertzuweisung: siehe Anlage 2.
2.103. NoOfCalibrationsSinceDownload
Zähler zur Angabe der mit einer Werkstattkarte seit dem letzten Herun­
terladen durchgeführten Kalibrierungen (Anhang 1C Randnummern 317
und 340).
Wertzuweisung: nicht näher spezifiziert.
2.104. NoOfCardPlaceRecords
Anzahl der Ortsdatensätze, die eine Fahrer- oder Werkstattkarte spei­
chern kann.
1. Generation:
Wertzuweisung: siehe Anlage 2.
2. Generation:
Wertzuweisung: siehe Anlage 2.
2.105. NoOfCardVehicleRecords
Anzahl der Angaben zu den gefahrenen Fahrzeugen enthaltenden Daten­
sätze, die eine Fahrer- oder Werkstattkarte speichern kann.
Wertzuweisung: siehe Anlage 2.
2.106. NoOfCardVehicleUnitRecords
2. Generation:
Anzahl der Angaben zu dengenutzten Fahrzeugeinheiten enthaltenden
Datensätze, die eine Fahrer- oder Werkstattkarte speichern kann.
Wertzuweisung: siehe Anlage 2.
2.107. NoOfCompanyActivityRecords
Anzahl der Unternehmenstätigkeitsdatensätze, die eine Unternehmens­
karte speichern kann.
Wertzuweisung: siehe Anlage 2.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 169
2.108. NoOfControlActivityRecords
Anzahl der Kontrollaktivitätsdatensätze, die eine Kontrollkarte speichern
kann.
Wertzuweisung: siehe Anlage 2.
2.109. NoOfEventsPerType
Anzahl der Ereignisse je Ereignisart, die eine Karte speichern kann.
Wertzuweisung: siehe Anlage 2.
2.110. NoOfFaultsPerType
Anzahl der Störungen je Störungsart, die eine Karte speichern kann.
Wertzuweisung: siehe Anlage 2.
▼M1
2.111. NoOfGNSSADRecords
2. Generation:
Anzahl der kumulierten GNSS-Lenkzeitendatensätze, die die Karte spei­
chern kann.
Wertzuweisung: siehe Anlage 2.
▼M3
2.111a. NoOfLoadUnloadRecords
2. Generation, Version 2:
Anzahl der Be-/Entladedatensätze, die eine Karte speichern kann.
Wertzuweisung: siehe Anlage 2.
▼B
2.112. NoOfSpecificConditionRecords
2. Generation:
Anzahl der Datensätze mit Bezug auf spezifische Bedingungen, die eine
Karte speichern kann.
Wertzuweisung: siehe Anlage 2.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 170
2.112a. NoOfLoadTypeEntryRecords
2. Generation, Version 2:
Anzahl der Ladungsarteingabedatensätze, die eine Fahrer- oder Werk­
stattkarte speichern kann.
Wertzuweisung: siehe Anlage 2.
▼B
2.113. OdometerShort
Kilometerstand des Fahrzeugs in Kurzform.
Wertzuweisung: Vorzeichenlose Binärzahl. Wert in km im Betriebs­
bereich 0 bis 9 999 999 km.
2.114. OdometerValueMidnight
Kilometerstand des Fahrzeugs um Mitternacht am jeweiligen Tag (An­
hang 1B Randnummer 090 und Anhang 1C Randnummer 113).
Wertzuweisung: nicht näher spezifiziert.
▼M3
2.114a. OperationType
2. Generation, Version 2:
Code zur Identifizierung einer eingegebenen Vorgangsart.
Wertzuweisung:
„00“H RFU,
„01“H Beladevorgang,
„02“H Entladevorgang,
„03“H Gleichzeitiger Be-/Entladevorgang,
„04“H … „FF“H RFU.
▼B
2.115. OdometerValueMidnightRecordArray
2. Generation:
OdometerValueMidnight und im Download-Protokoll verwendete Meta­
daten.
recordType — Art des Datensatzes (OdometerValueMidnight). Wert­
zuweisung: siehe RecordType
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 171
recordSize — die Größe des OdometerValueMidnight in Byte.
noOfRecords — Anzahl der Datensätze in der Menge der Datensätze.
records — Menge der OdometerValueMidnight-Datensätze.
2.116. OverspeedNumber
Anzahl der Geschwindigkeitsüberschreitungen seit der letzten Kontrolle
Geschwindigkeitsüberschreitung.
Wertzuweisung: 0 bedeutet, dass seit der letzten Kontrolle Geschwin­
digkeitsüberschreitung kein Ereignis Geschwindigkeitsüberschreitung
aufgetreten ist, 1 bedeutet, dass 1 derartiges Ereignis seit der letzten
entsprechenden Kontrolle aufgetreten ist, … 255 bedeutet, dass 255
oder mehr derartige Ereignisse seit der letzten entsprechenden Kontrolle
aufgetreten sind.
▼M3
2.116a. PlaceAuthRecord
Informationen zum Ort des Beginns oder Endes des Arbeitstages (An­
hang IC Randnummern 108, 271, 296, 324 und 347).
2. Generation, Version 2:
entryTime – auf die Eingabe bezogene Datums- und Zeitangabe.
entryTypeDailyWorkPeriod – Art der Eingabe.
dailyWorkPeriodCountry – eingegebenes Land.
dailyWorkPeriodRegion – eingegebene Region.
vehicleOdometerValue – Kilometerstand zum Zeitpunkt und am Ort der
Eingabe.
entryGNSSPlaceAuthRecord – aufgezeichneter Standort, GNSS-Au­
thentisierungsstatus und Uhrzeit.
2.116b. PlaceAuthStatusRecord
2. Generation, Version 2:
Auf einer Fahrer- oder Werkstattkarte gespeicherte Informationen, die
den Authentisierungsstatus eines Orts des Beginns oder des Endes des
Arbeitstages angeben (Anhang IC Randnummern 306a und 356a). Wei­
tere Informationen zum Ort selbst werden in einem anderen Datensatz
gespeichert (siehe 2.117 PlaceRecord).
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 172
entryTime – auf die Eingabe bezogene Datums- und Zeitangabe (die
gleich der Datums- und Zeitangabe im entsprechenden Datensatz Place­
Record ist).
authenticationStatus – Authentisierungsstatus der aufgezeichneten
GNSS-Position.
▼B
2.117. PlaceRecord
Informationen zum Ort des Beginns oder Endes des Arbeitstages (An­
hang 1C Randnummern 108, 271, 296, 324 und 347).
1. Generation:
entryTime — auf die Eingabe bezogene Datums- und Zeitangabe.
entryTypeDailyWorkPeriod — Art der Eingabe.
dailyWorkPeriodCountry — eingegebenes Land.
dailyWorkPeriodRegion — eingegebene Region.
vehicleOdometerValue — Kilometerstand zum Zeitpunkt und am Ort
der Eingabe.
2. Generation:
Zusätzlich zur 1. Generation wird folgende Komponente genutzt:
entryGNSSPlaceRecord — die aufgezeichneten Standort- und Zeitanga­
ben.
▼M3
2.117a. PositionAuthenticationStatus
2. Generation, Version 2:
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 173
Wertzuweisung (siehe Anlage 12):
„00“H Nicht authentisiert (siehe Anlage 12 Randnummer
GNS_39),
„01“H Authentisiert (siehe Anlage 12 Randnummer
GNS_39),
„02“H … „FF“H RFU.
▼B
2.118. PreviousVehicleInfo
Information zum zuvor von einem Fahrer gefahrenen Fahrzeug beim
Einstecken seiner Karte in eine Fahrzeugeinheit (Anhang 1B Randnum­
mer 081 und Anhang 1C Randnummer 102).
1. Generation:
vehicleRegistrationIdentification — amtliches Kennzeichen und zulas­
sender Mitgliedstaat des Fahrzeugs.
cardWithdrawalTime — Datum und Uhrzeit der Kartenentnahme.
2. Generation:
Zusätzlich zur 1. Generation wird folgendes Datenelement verwendet:
vuGeneration — Kennzeichnung für die Generation der Fahrzeugein­
heit.
2.119. PublicKey
1. Generation:
Ein öffentlicher RSA-Schlüssel.
rsaKeyModulus — Modulus des Schlüsselpaares.
rsaKeyPublicExponent — öffentlicher Exponent des Schlüsselpaares.
2.120. RecordType
2. Generation:
Bezeichnung eines Datensatztyps. Dieser Datentyp wird in RecordArrays
verwendet.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 174
Wertzuweisung:
► (1) M1
► (2) M3
ActivityChangeInfo,
CardSlotsStatus,
CurrentDateTime,
MemberStateCertificate,
OdometerValueMidnight,
DateOfDayDownloaded,
SensorPaired,
Signature,
SpecificConditionRecord,
VehicleIdentificationNumber,
VehicleRegistrationNumber,
VuCalibrationRecord,
VuCardIWRecord,
VuCardRecord,
VuCertificate,
VuCompanyLocksRecord,
VuControlActivityRecord,
VuDetailedSpeedBlock,
VuDownloadablePeriod,
VuDownloadActivityData,
VuEventRecord,
►M1 VuGNSSADRecord, ◄
VuITSConsentRecord,
VuFaultRecord,
VuIdentification,
VuOverSpeedingControlData,
VuOverSpeedingEventRecord,
VuPlaceDailyWorkPeriodRecord,
VuTimeAdjustmentGNSSRecord,
VuTimeAdjustmentRecord,
VuPowerSupplyInterruptionRecord,
SensorPairedRecord,
SensorExternalGNSSCoupledRecord,
►M3 VuBorderCrossingRecord,
VuLoadUnloadRecord,
VehicleRegistrationIdentification,
RFU, ◄
Herstellerspezifisch.
2.121. RegionAlpha
Alphabetische Angabe einer Region innerhalb eines bestimmten Landes.
1. Generation:
Wertzuweisung:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 175
2. Generation:
Die RegionAlpha-Codes sind in einer Liste aufgeführt, die von dem mit
der Durchführung der Interoperabilitätsprüfungen beauftragten Labor auf
dessen Internetseite geführt wird.
2.122. RegionNumeric
Numerische Angabe einer Region innerhalb eines bestimmten Landes.
1. Generation:
Wertzuweisung:
2. Generation:
Die RegionNumeric-Codes sind in einer Liste aufgeführt, die von dem
mit der Durchführung der Interoperabilitätsprüfungen beauftragten Labor
auf dessen Internetseite geführt wird.
2.123. RemoteCommunicationModuleSerialNumber
2. Generation:
Seriennummer des Fernkommunikationsmoduls.
2.124. RSAKeyModulus
1. Generation:
Der Modulus eines RSA-Schlüsselpaares.
Wertzuweisung: nicht spezifiziert.
2.125. RSAKeyPrivateExponent
1. Generation:
Privater Exponent eines RSA-Schlüsselpaares.
Wertzuweisung: nicht spezifiziert.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 176
2.126. RSAKeyPublicExponent
1. Generation:
Öffentlicher Exponent eines RSA-Schlüsselpaares.
Wertzuweisung: nicht spezifiziert.
2.127. RtmData
2. Generation:
Bezüglich der Definition dieses Datentyps siehe Anlage 14.
2.128. SealDataCard
2. Generation:
Dieser Datentyp speichert Informationen über die an den verschiedenen
Komponenten eines Fahrzeugs angebrachten Plomben und dient der
Speicherung auf einer Karte. Dieser Datentyp bezieht sich auf Anhang
1C Randnummer 337.
noOfSealRecords — Anzahl der in der Menge sealRecords aufgeführten
Datensätze.
sealRecords — Plombendatensatz.
2.129. SealDataVu
2. Generation:
Dieser Datentyp speichert Informationen über die an den verschiedenen
Komponenten eines Fahrzeugs angebrachten Plomben und dient der
Speicherung in einer Fahrzeugeinheit.
sealRecords — Plombendatensatz. Sind weniger als 5 Plomben verfüg­
bar, wird der Wert EquipmentType in allen unbenutzten sealRecords auf
16, d. h. unbenutzt, gesetzt.
2.130. SealRecord
2. Generation:
Dieser Datentyp speichert Informationen zur an einer Komponente an­
gebrachten Plombe. Dieser Datentyp bezieht sich auf Anhang 1C Rand­
nummer 337.
equipmentType — identifiziert den Gerätetyp, an dem die Plombe an­
gebracht ist.
extendedSealIdentifier — bezeichnet die am Gerät angebrachte Plombe.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 177
2.131. SensorApprovalNumber
Typgenehmigungsnummer desBewegungssensors.
1. Generation:
Wertzuweisung: nicht spezifiziert.
2. Generation:
Wertzuweisung:
Die Genehmigungsnummer muss derjenigen entsprechen, die auf der
zugehörigen Website der Europäischen Kommission veröffentlicht ist,
und beispielsweise etwaige Bindestriche berücksichtigen. Die Genehmi­
gungsnummer muss linksbündig ausgerichtet sein.
2.132. SensorExternalGNSSApprovalNumber
2. Generation:
Typgenehmigungsnummer der externen GNSS-Ausrüstung.
Wertzuweisung:
Die Genehmigungsnummer muss derjenigen entsprechen, die auf der
zugehörigen Website der Europäischen Kommission veröffentlicht ist,
und beispielsweise etwaige Bindestriche berücksichtigen. Die Genehmi­
gungsnummer muss linksbündig ausgerichtet sein.
2.133. SensorExternalGNSSCoupledRecord
2. Generation:
In einer Fahrzeugeinheit gespeicherte Information zur Identifizierung der
mit der Fahrzeugeinheit gekoppelten externen GNSS-Ausrüstung (An­
hang 1C Randnummer 100).
sensorSerialNumber — Seriennummer der mit der Fahrzeugeinheit ge­
koppelten externen GNSS-Ausrüstung.
sensorApprovalNumber –Typgenehmigungsnummer dieser externen
GNSS-Ausrüstung.
sensorCouplingDate — Datum der Kopplung dieser externen GNSS-
Ausrüstung mit der Fahrzeugeinheit.
2.134. SensorExternalGNSSIdentification
2. Generation:
Informationen zur Identifizierung der externen GNSS-Ausrüstung (An­
hang 1C Randnummer 98).
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 178
sensorSerialNumber — erweiterte Seriennummer der externen
GNSS-Ausrüstung.
sensorApprovalNumber –Typgenehmigungsnummer der externen
GNSS-Ausrüstung.
sensorSCIdentifier — Bezeichner der Sicherheitskomponente der exter­
nen GNSS-Ausrüstung.
sensorOSIdentifier — Bezeichner des Betriebssystems der externen
GNSS-Ausrüstung.
2.135. SensorExternalGNSSInstallation
2. Generation:
In einer externen GNSS-Ausrüstung gespeicherte Informationen zur In­
stallation der externen GNSS-Ausrüstung (Anhang 1C Randnummer
123).
sensorCouplingDateFirst — Datum der ersten Kopplung der externen
GNSS-Ausrüstung mit einer Fahrzeugeinheit.
firstVuApprovalNumber –Typgenehmigungsnummer der ersten mit der
externen GNSS-Ausrüstung gekoppelten Fahrzeugeinheit.
firstVuSerialNumber — Seriennummer der ersten mit der externen
GNSS-Ausrüstung gekoppelten Fahrzeugeinheit.
sensorCouplingDateCurrent — Datum der aktuellen Kopplung der ex­
ternen GNSS-Ausrüstung mit einer Fahrzeugeinheit.
currentVuApprovalNumber –Typgenehmigungsnummer der derzeit mit
der externen GNSS-Ausrüstung gekoppelten Fahrzeugeinheit.
currentVuSerienNumber — Seriennummer der derzeit mit der externen
GNSS-Ausrüstung gekoppelten Fahrzeugeinheit.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 179
2.136. SensorExternalGNSSOSIdentifier
2. Generation:
Bezeichner des Betriebssystems der externen GNSS-Ausrüstung.
Wertzuweisung: herstellerspezifisch.
2.137. SensorExternalGNSSSCIdentifier
2. Generation:
Dieser Typ dient beispielsweise der Identifizierung des kryptografischen
Moduls der externen GNSS-Ausrüstung.
Bezeichner der Sicherheitskomponente der externen GNSS-Ausrüstung.
Wertzuweisung: Komponente herstellerspezifisch.
2.138. SensorGNSSCouplingDate
2. Generation:
Datum einer Kopplung der externen GNSS-Ausrüstung mit einer Fahr­
zeugeinheit.
Wertzuweisung: nicht spezifiziert.
2.139. SensorGNSSSerialNumber
2. Generation:
Dieser Typ dient der Speicherung der Seriennummer des GNSS-Emp­
fängers sowohl innerhalb als auch außerhalb der VU.
Seriennummer des GNSS-Empfängers.
2.140. SensorIdentification
In einem Bewegungssensor gespeicherte Information zur Identifizierung
des Bewegungssensors (Anhang 1B Randnummer 077 und Anhang 1C
Randnummer 95).
sensorSerialNumber — erweiterte Seriennummer des Bewegungssen­
sors (umfasst Teilnummer und Herstellercode)
sensorApprovalNumber –Typgenehmigungsnummer des Bewegungs­
sensors.
sensorSCIdentifier — Bezeichner der Sicherheitskomponente des Be­
wegungssensors.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 180
sensorOSIdentifier — Bezeichner des Betriebssystems des Bewegungs­
sensors.
2.141. SensorInstallation
In einem Bewegungssensor gespeicherte Information zur Installation des
Bewegungssensors (Anhang 1B Randnummer 099 und Anhang 1C
Randnummer 122).
sensorPairingDateFirst — Datum der ersten Koppelung des Bewe­
gungssensors mit einer Fahrzeugeinheit.
firstVuApprovalNumber –Typgenehmigungsnummer der ersten mit
dem Bewegungssensor gekoppelten Fahrzeugeinheit.
firstVuSerialNumber — Seriennummer der ersten mit dem Bewegungs­
sensor gekoppelten Fahrzeugeinheit.
sensorPairingDateCurrent — Datum der derzeitigen Koppelung des
Bewegungssensors mit der Fahrzeugeinheit.
currentVuApprovalNumber –Typgenehmigungsnummer der derzeit mit
dem Bewegungssensor gekoppelten Fahrzeugeinheit.
currentVUSerialNumber — Seriennummer der derzeit mit dem Bewe­
gungssensor gekoppelten Fahrzeugeinheit.
2.142. SensorInstallationSecData
Auf einer Werkstattkarte gespeicherte Information zu den für die Kop­
pelung von Bewegungssensoren und Fahrzeugeinheiten benötigten Si­
cherheitsdaten (Anhang 1C Randnummern 308 und 331).
1. Generation:
Wertzuweisung: gemäß ISO 16844-3.
2. Generation:
Wie in Anlage 11 beschrieben, muss eine Werkstattkarte bis zu drei
Schlüssel für die Kopplung VU–Bewegungssensor speichern können,
die unterschiedliche Schlüsselversionen haben.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 181
2.143. SensorOSIdentifier
Bezeichner des Betriebssystems des Bewegungssensors.
Wertzuweisung: herstellerspezifisch.
2.144. SensorPaired
1. Generation:
In einer Fahrzeugeinheit gespeicherte Information zur Identifizierung des
mit der Fahrzeugeinheit gekoppelten Bewegungssensors (Anhang 1B
Randnummer 079).
sensorSerialNumber — Seriennummer des derzeit mit der Fahrzeugein­
heit gekoppelten Bewegungssensors.
sensorApprovalNumber –Typgenehmigungsnummer des derzeit mit der
Fahrzeugeinheit gekoppelten Bewegungssensors.
sensorPairingDateFirst — Datum der ersten Koppelung des derzeit mit
der Fahrzeugeinheit gekoppelten Bewegungssensors mit einer Fahrzeug­
einheit.
2.145. SensorPairedRecord
2. Generation:
In einer Fahrzeugeinheit gespeicherte Information zur Identifizierung ei­
nes mit der Fahrzeugeinheit gekoppelten Bewegungssensors (Anhang 1C
Randnummer 97).
sensorSerialNumber — Seriennummer eines mit der Fahrzeugeinheit
gekoppelten Bewegungssensors.
sensorApprovalNumber –Typgenehmigungsnummer dieses Bewe­
gungssensors.
sensorPairingDate — Datum der Koppelung dieses Bewegungssensors
mit der Fahrzeugeinheit.
2.146. SensorPairingDate
Datum einer Koppelung des Bewegungssensors mit einer Fahrzeugein­
heit.
Wertzuweisung: nicht spezifiziert.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 182
2.147. SensorSCIdentifier
Bezeichner der Sicherheitskomponente des Bewegungssensors.
Wertzuweisung: Komponente herstellerspezifisch.
2.148. SensorSerialNumber
Seriennummer des Bewegungssensors.
2.149. Signature
Eine digitale Signatur.
1. Generation:
Wertzuweisung: gemäß Anlage 11, Gemeinsame Sicherheitsmechanis­
men.
2. Generation:
Wertzuweisung: gemäß Anlage 11, Gemeinsame Sicherheitsmechanis­
men.
2.150. SignatureRecordArray
2. Generation:
Satz von Signaturen plus im Download-Protokoll verwendete Metadaten.
recordType — Art des Datensatzes (Signatur). Wertzuweisung: siehe
RecordType
recordSize — die Größe der Signatur in Byte.
noOfRecords — Anzahl der Datensätze in der Menge der Datensätze.
Der Wert muss auf 1 gesetzt werden, da die Signaturen verschieden lang
sein können.
records — der Satz von Signaturen.
2.151. SimilarEventsNumber
Anzahl ähnlicher Ereignisse an einem bestimmten Tag (Anhang 1B
Randnummer 094 und Anhang 1C Randnummer 117).
Wertzuweisung: 0 wird nicht verwendet, 1 bedeutet, dass an diesem
Tag nur ein Ereignis dieser Art aufgetreten und gespeichert wurde, 2
bedeutet, dass 2 Ereignisse dieser Art an diesem Tag aufgetreten sind
(nur eines wurde gespeichert), … 255 bedeutet, dass 255 oder mehr
Ereignisse dieser Art an diesem Tag aufgetreten sind.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 183
2.152. SpecificConditionRecord
Auf einer Fahrerkarte, einer Werkstattkarte oder in einer Fahrzeugeinheit
gespeicherte Information zu einer spezifischen Bedingung (Anhang 1C
Randnummern 130, 276, 301, 328 und 355).
entryTime — Datum und Uhrzeit der Eingabe.
specificConditionType — Code zur Identifizierung der spezifischen Be­
dingung.
2.153. SpecificConditions
Auf einer Fahrerkarte, einer Werkstattkarte oder in einer Fahrzeugeinheit
gespeicherte Information zu einer spezifischen Bedingung (Anhang 1C
Randnummern 131, 277, 302, 329 und 356).
2. Generation:
conditionPointerNewestRecord — Index des zuletzt aktualisierten Da­
tensatzes mit Bezug auf spezifische Bedingungen.
Wertzuweisung: Zahl, die dem Zähler des Datensatzes mit Bezug auf
spezifische Bedingungen entspricht, beginnend mit „0“ für das erste
Auftreten des Datensatzes mit Bezug auf spezifische Bedingungen in
der Struktur.
specificConditionRecords — Datensätze mit Informationen zu den auf­
gezeichneten spezifischen Bedingungen.
2.154. SpecificConditionType
Code zur Identifizierung einer spezifischen Bedingung (Anhang 1B
Randnummern 050b, 105a, 212a und 230a sowie Anhang 1C Randnum­
mer 62).
1. Generation:
Wertzuweisung:
„00“H RFU
„01“H Kontrollgerät nicht erforderlich — Anfang
„02“H Kontrollgerät nicht erforderlich — Ende
„03“H Fährüberfahrt/Zugfahrt
„04“H … „FF“H RFU
2. Generation:
Wertzuweisung:
„00“H RFU
„01“H Kontrollgerät nicht erforderlich — Anfang
„02“H Kontrollgerät nicht erforderlich — Ende
„03“H Fährüberfahrt/Zugfahrt — Anfang
„04“H Fährüberfahrt/Zugfahrt — Ende
„05“H … „FF“H RFU
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 184
2.155. Speed
Fahrzeuggeschwindigkeit (km/h).
Wertzuweisung: Kilometer pro Stunde im Betriebsbereich 0 bis 220
km/h.
2.156. SpeedAuthorised
Zulässige Höchstgeschwindigkeit des Fahrzeugs (Begriffsbestimmung
hh)).
2.157. SpeedAverage
Durchschnittsgeschwindigkeit in einem vorher festgelegten Zeitraum
(km/h).
2.158. SpeedMax
Höchstgeschwindigkeit in einem vorher festgelegten Zeitraum.
▼M3
2.158a. TachographCardsGen1Suppression
2. Generation, Version 2:
Fähigkeit einer Fahrzeugeinheit der zweiten Generation, Fahrer-,
Kontroll- und Unternehmenskarten der ersten Generation zu nutzen
(siehe Anlage 15, MIG_002).
Wertzuweisung:
„0000“H Die Fahrzeugeinheit kann Fahrtenschreiberkarten der
1. Generation verwenden (Standardwert),
„A5E3“H Die Fahrzeugeinheit kann Fahrtenschreiberkarten der
1. Generation nicht verwenden,
Alle anderen Werte
nicht verwendet.
▼B
2.159. TachographPayload
2. Generation:
Zur Definition dieses Datentyps siehe Anlage 14.
▼M1
2.160. Reserviert für künftige Verwendung
▼B
2.161. TDesSessionKey
1. Generation:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 185
Ein Triple-DES-Sitzungsschlüssel.
Wertzuweisung: nicht näher spezifiziert.
▼M1
2.162. TimeReal
Code für ein kombiniertes Datum/Uhrzeit-Feld, in dem Datum und Uhr­
zeit als Sekunden nach dem 1. Januar 1970 00h.00m.00s. UTC aus­
gedrückt sind.
Wertzuweisung — Oktettanordnung: Anzahl der Sekunden seit dem
1. Januar 1970, 0.00 Uhr UTC.
Spätestmögliche(s) Datum/Uhrzeit ist im Jahr 2106.
▼B
2.163. TyreSize
Bezeichnung der Reifenabmessungen.
Wertzuweisung: gemäß Richtlinie 92/23/EWG vom 31.3.1992, ABl. L
129, S.95.
2.164. VehicleIdentificationNumber
Fahrzeugidentifizierungsnummer (VIN) mit Bezug auf das Fahrzeug ins­
gesamt, in der Regel Fahrgestellnummer oder Rahmennummer.
Wertzuweisung: laut Definition in ISO 3779.
2.165. VehicleIdentificationNumberRecordArray
2. Generation:
Fahrzeugidentifizierungsnummer plus im Download-Protokoll verwen­
dete Metadaten.
recordType — Art des Datensatzes (VehicleIdentificationNumber).
Wertzuweisung: siehe RecordType
recordSize — die Größe von VehicleIdentificationNumber in Byte.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 186
noOfRecords — Anzahl der Datensätze in der Menge der Datensätze.
records — der Satz von Fahrzeugidentifizierungsnummern.
2.166. VehicleRegistrationIdentification
Für Europa eindeutige Identifizierung eines Fahrzeugs (amtliches Kenn­
zeichen und Mitgliedstaat).
vehicleRegistrationNation — Land, in dem das Fahrzeug zugelassen ist.
vehicleRegistrationNumber — amtliches Kennzeichen des Fahrzeugs
(VRN).
▼M3
2.166a. VehicleRegistrationIdentificationRecordArray
2. Generation, Version 2:
Die Fahrzeugregistrierungskennung plus Metadaten wie im Download-
Protokoll verwendet.
recordType – Art des Datensatzes (VehicleRegistrationIdentification).
Wertzuweisung: siehe RecordType.
recordSize – Größe von VehicleRegistrationIdentification in Bytes.
noOfRecords – Anzahl der Datensätze in der Menge der Datensätze.
records – der Satz der Fahrzeugregistrierungskennung.
▼B
2.167. VehicleRegistrationNumber
Amtliches Kennzeichen des Fahrzeugs (VRN). Das amtliche Kennzei­
chen wird von der Fahrzeugzulassungsstelle zugewiesen.
codePage gibt einen in Kapitel 4 definierten Zeichensatz an,
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 187
vehicleRegNumber ein unter Verwendung des spezifizierten Zeichen­
satzes kodiertes amtliches Kennzeichen.
Wertzuweisung: länderspezifisch.
2.168. VehicleRegistrationNumberRecordArray
▼M3
2. Generation, Version 1:
▼B
Amtliches Kennzeichen des Fahrzeugs plus im Download-Protokoll ver­
wendete Metadaten.
recordType — Art des Datensatzes (VehicleRegistrationNumber).
Wertzuweisung: siehe RecordType
recordSize — die Größe von VehicleRegistrationNumber in Byte.
noOfRecords — Anzahl der Datensätze in der Menge der Datensätze.
records — der Satz amtlicher Kennzeichen.
2.169. VuAbility
2. Generation:
In einer VU gespeicherte Information darüber, ob bei der VU die Nut­
zung von Fahrtenschreiberkarten der ersten Generation möglich ist (An­
hang 1C Randnummer 121).
Wertzuweisung — Oktettanordnung: „xxxxxxxa“B (8 Bit)
Zur möglichen Unterstützung der 1. Generation:
„a“B Möglichkeit der Unterstützung von Fahrtenschreiberkar­
ten der 1. Generation:
„0“ B 1. Generation unterstützt,
„1“B 1. Generation nicht unterstützt,
„xxxxxxx“B RFU
2.170. VuActivityDailyData
1. Generation:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 188
In einer FE gespeicherte Information zu Tätigkeitsänderungen und/oder
Veränderungen des Status der Fahrzeugführung und/oder Veränderungen
des Kartenstatus für einen bestimmten Kalendertag (Anhang 1B Rand­
nummer 084 und Anhang 1C Randnummer 105, 106, 107) und des
Steckplatzstatus an diesem Tag um 0.00 Uhr.
noOfActivityChanges — Anzahl der ActivityChangeInfo-Wörter in der
activityChangeInfos-Menge.
activityChangeInfos — Datensatz der in der VU für den Tag gespei­
cherten ActivityChangeInfo-Wörter. Er enthält stets zwei ActivityCh­
angeInfo-Wörter für den Status der beiden Steckplätze an diesem Tag
um 0.00 Uhr.
2.171. VuActivityDailyRecordArray
2. Generation:
In einer VU gespeicherte Information zu Tätigkeitsänderungen und/oder
Veränderungen des Status der Fahrzeugführung und/oder Veränderungen
des Kartenstatus für einen bestimmten Kalendertag (Anhang 1C Rand­
nummer 105, 106, 107) und des Steckplatzstatus an diesem Tag um 0.00
Uhr.
recordType — Art des Datensatzes (ActivityChangeInfo). Wertzuwei­
sung: siehe RecordType
recordSize — die Größe von ActivityChangeInfo in Byte.
noOfRecords — Anzahl der Datensätze in der Menge der Datensätze.
records — Datensatz der in der VU für den Tag gespeicherten Activi­
tyChangeInfo-Wörter. Er enthält stets zwei ActivityChangeInfo-Wörter
für den Status der beiden Steckplätze an diesem Tag um 0.00 Uhr.
2.172. VuApprovalNumber
Typgenehmigungsnummer der Fahrzeugeinheit.
1. Generation:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 189
Wertzuweisung: nicht spezifiziert.
2. Generation:
Wertzuweisung:
Die Genehmigungsnummer muss derjenigen entsprechen, die auf der
zugehörigen Website der Europäischen Kommission veröffentlicht ist,
und beispielsweise etwaige Bindestriche berücksichtigen. Die Genehmi­
gungsnummer muss linksbündig ausgerichtet sein.
2.173. VuCalibrationData
1. Generation:
In einer Fahrzeugeinheit gespeicherte Information zu den Kalibrierungen
des Kontrollgeräts (Anhang 1B Randnummer 098).
noOfVuCalibrationRecords — Anzahl der in der vuCalibrationRe­
cords-Menge enthaltenen Datensätze.
vuCalibrationRecords –Menge der Kalibrierungsdatensätze.
2.174. VuCalibrationRecord
In einer Fahrzeugeinheit gespeicherte Information zu einer Kalibrierung
des Kontrollgeräts (Anhang 1B Randnummer 098 sowie Anhang 1C
Randnummern 119 und 120).
1. Generation:
calibrationPurpose — Zweck der Kalibrierung.
workshopName, workshopAddress — Name und Anschrift der Werk­
statt.
workshopCardNumber dient der Identifizierung der zur Kalibrierung
verwendeten Werkstattkarte.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 190
workshopCardExpiryDate — Ablaufdatum der Karte.
vehicleIdentificationNumber — Fahrzeugidentifizierungsnummer
(VIN).
vehicleRegistrationIdentification — enthält das amtliche Kennzeichen
und den zulassenden Mitgliedstaat.
wVehicleCharacteristicConstant Wegdrehzahl des Fahrzeugs.
kConstantOfRecordingEquipment — Kontrollgerätkonstante.
lTyreCircumference — tatsächlicher Reifenumfang.
tyreSize — Bezeichnung der Größe der am Fahrzeug montierten Reifen.
authorisedSpeed — zulässige Geschwindigkeit des Fahrzeugs.
oldOdometerValue, newOdometerValue — alter und neuer Kilometer­
stand.
oldTimeValue, newTimeValue — alter und neuer Wert für Datum und
Uhrzeit.
nextCalibrationDate — Datum der nächsten von der zugelassenen
Prüfstelle durchzuführenden Kalibrierung der in CalibrationPurpose an­
gegebenen Art.
▼M3
2. Generation, Version 1:
▼B
Zusätzlich zur 1. Generation wird folgendes Datenelementverwendet:
sealDataVu — Informationen zu den an den verschiedenen Fahrzeug­
komponenten angebrachten Plomben.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 191
2. Generation, Version 2:
Zusätzlich zur 1. Generation wird folgendes Datenelement verwendet:
sensorSerialNumber – Seriennummer des mit der Fahrzeugeinheit am
Ende der Kalibrierung gekoppelten Bewegungssensors,
sensorGNSSSerialNumber – Seriennummer der externen GNSS-Aus­
rüstung (falls vorhanden), die am Ende der Kalibrierung mit der Fahr­
zeugeinheit gekoppelt ist,
rcmSerialNumber – Seriennummer der Fernkommunikationsausrüstung
(falls vorhanden), die am Ende der Kalibrierung mit der Fahrzeugeinheit
gekoppelt ist,
sealDataVu – Informationen zu den an den verschiedenen Fahrzeug­
komponenten angebrachten Plomben.
byDefaultLoadType – die standardmäßige Art der Ladung des Fahr­
zeugs (nur in Version 2 vorhanden).
calibrationCountry – Land, in dem die Kalibrierung durchgeführt
wurde.
calibrationCountryTimestamp – Datum und Uhrzeit der Bereitstellung
der Position vom GNSS-Empfänger, die zur Bestimmung des Landes
verwendet wurden, in dem die Kalibrierung durchgeführt wurde.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 192
2.175. VuCalibrationRecordArray
2. Generation:
In einer Fahrzeugeinheit gespeicherte Information zu den Kalibrierungen
des Kontrollgeräts (Anhang 1C Randnummern 119 und 120).
recordType — Art des Datensatzes (VuCalibrationRecord). Wertzuwei­
sung: siehe RecordType
recordSize — die Größe von VuCalibrationRecord in Byte.
noOfRecords — Anzahl der Datensätze in der Menge der Datensätze.
records –Menge der Kalibrierungsdatensätze.
2.176. VuCardIWData
1. Generation:
In einer Fahrzeugeinheit gespeicherte Information zu Einsteck- und Ent­
nahmevorgängen von Fahrerkarten oder Werkstattkarten in der Fahr­
zeugeinheit (Anhang 1B Randnummer 081 und Anhang 1C Randnum­
mer 103).
noOfIWRecords — Anzahl der Datensätze in der Menge vuCardIWRe­
cords.
vuCardIWRecords — Datensätze zu Einsteck- und Entnahmevorgän­
gen von Karten.
2.177. VuCardIWRecord
In einer Fahrzeugeinheit gespeicherte Information zu einem Einsteck-
und Entnahmevorgang einer Fahrerkarte oder Werkstattkarte in der Fahr­
zeugeinheit (Anhang 1B Randnummer 081 und Anhang 1C Randnum­
mer 102).
1. Generation:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 193
cardHolderName — Name und Vorname(n) des Inhabers der Fahrer-
oder Werkstattkarte in der auf der Karte gespeicherten Form.
fullCardNumber — Art der Karte, ausstellender Mitgliedstaat und Kar­
tennummer in der auf der Karte gespeicherten Form.
cardExpiryDate — Ablaufdatum der Karte in der auf der Karte gespei­
cherten Form.
cardInsertionTime — Datum und Uhrzeit des Einsteckens.
vehicleOdometerValueAtInsertion — Kilometerstand des Fahrzeugs
beim Einstecken der Karte.
cardSlotNumber — Steckplatz, in dem die Karte eingesteckt ist.
cardWithdrawalTime — Datum und Uhrzeit der Entnahme der Karte.
vehicleOdometerValueAtWithdrawal — Kilometerstand des Fahr­
zeugs bei Kartenentnahme.
previousVehicleInfo enthält Informationen zum zuvor vom Fahrer ge­
fahrenen Fahrzeug in der auf der Karte gespeicherten Form.
manualInputFlag — Merker, der angibt, ob der Karteninhaber beim
Einstecken der Karte Fahrertätigkeiten manuell eingegeben hat.
2. Generation:
Anstelle von fullCardNumber wird in der Datenstruktur der 2. Genera­
tion folgendes Datenelement verwendet:
fullCardNumberAndGeneration — Art der Karte, ausstellender Mit­
gliedstaat, Kartennummer und Generation in der auf der Karte gespei­
cherten Form.
2.178. VuCardIWRecordArray
2. Generation:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 194
In einer Fahrzeugeinheit gespeicherte Information zu Einsteck- und Ent­
nahmevorgängen von Fahrerkarten oder Werkstattkarten in der Fahr­
zeugeinheit (Anhang 1C Randnummer 103).
recordType — Art des Datensatzes (VuCardIWRecord). Wertzuwei­
sung: siehe RecordType
recordSize — die Größe von VuCardIWRecord in Byte.
noOfRecords — Anzahl der Datensätze in der Menge der Datensätze.
records — Datensätze zu Einsteck- und Entnahmevorgängen von Kar­
ten.
▼M1
2.179. VuCardRecord
2. Generation:
In einer Fahrzeugeinheit gespeicherte Information zu einer verwendeten
Fahrtenschreiberkarte (Anhang IC Randnummer 132).
cardNumberAndGenerationInformation — vollständige Kartennum­
mer 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_Applica­
tion_Identification unter DF_Tachograph_G2.
cardNumber — ausgelesen aus der Datei EF_Identification unter
DF_Tachograph_G2.
▼B
2.180. VuCardRecordArray
2. Generation:
In einer Fahrzeugeinheit gespeicherte Information zu den in dieser VU
verwendeten Fahrtenschreiberkarten. Diese Information dient der Analyse
von Problemen zwischen VU und Karte (Anhang 1C Randnummer 132).
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 195
recordType — Art des Datensatzes (VuCardRecord). Wertzuweisung:
siehe RecordType
recordSize — die Größe von VuCardRecord in Byte.
noOfRecords — Anzahl der Datensätze in der Menge der Datensätze.
records — Datensätze zu mit der VU verwendeten Fahrtenschreiberkar­
ten.
2.181. VuCertificate
Zertifikat des öffentlichen Schlüssels einer Fahrzeugeinheit.
2.182. VuCertificateRecordArray
2. Generation:
VU-Zertifikat plus im Download-Protokoll verwendete Metadaten.
recordType — Art des Datensatzes (VuCertificate). Wertzuweisung:
siehe RecordType
recordSize — die Größe von VuCertificate in Byte.
noOfRecords — Anzahl der Datensätze in der Menge der Datensätze.
Der Wert muss auf 1 gesetzt werden, da die Zertifikate verschieden lang
sein können.
records — Satz von VU-Zertifikaten.
2.183. VuCompanyLocksData
1. Generation:
In einer Fahrzeugeinheit gespeicherte Information zu Unternehmenssper­
ren (Anhang 1B Randnummer 104).
noOfLocks — Anzahl der in vuCompanyLocksRecords aufgeführten
Sperren.
vuCompanyLocksRecords — Datensätze mit Informationen zur Unter­
nehmenssperre.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 196
2.184. VuCompanyLocksRecord
In einer Fahrzeugeinheit gespeicherte Information zu einer Unterneh­
menssperre (Anhang 1B Randnummer 104 und Anhang 1C Randnum­
mer 128).
1. Generation:
lockInTime, lockOutTime — Datum und Uhrzeit der Sperrung und
Entsperrung.
companyName, companyAddress — Name und Anschrift des Unter­
nehmens, auf das sich die Sperrung bezieht.
companyCardNumber — Identifizierung der bei der Sperrung verwen­
deten Karte.
2. Generation:
Anstelle von companyCardNumber wird in der Datenstruktur der 2.
Generation folgendes Datenelement verwendet:
companyCardNumberAndGeneration — Identifizierung der bei der
Sperrung verwendeten Karte und ihrer Generation.
2.185. VuCompanyLocksRecordArray
2. Generation:
In einer Fahrzeugeinheit gespeicherte Information zu Unternehmenssper­
ren (Anhang 1C Randnummer 128).
recordType — Art des Datensatzes (VuCompanyLocksRecord). Wert­
zuweisung: siehe RecordType
recordSize — die Größe von VuCompanyLocksRecord in Byte.
noOfRecords — Anzahl der Datensätze in der Menge der Datensätze.
Wert 0 … 255.
records — Datensätze mit Informationen zur Unternehmenssperre.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 197
2.185a. VuConfigurationLengthRange
2. Generation, Version 2:
Anzahl der Bytes in einer Fahrtenschreiberkarte, die für die Speicherung
von Konfigurationen der Fahrzeugeinheit verfügbar sind.
Wertzuweisung: siehe Anlage 2.
▼B
2.186. VuControlActivityData
1. Generation:
In einer Fahrzeugeinheit gespeicherte Information zu unter Verwendung
dieser VU ausgeführten Kontrollen (Anhang 1B Randnummer 102).
noOfControls — Anzahl der in vuControlActivityRecords aufgeführten
Kontrollen.
vuControlActivityRecords — Kontrollaktivitätsdatensätze.
2.187. VuControlActivityRecord
In einer Fahrzeugeinheit gespeicherte Information zu einer unter Ver­
wendung dieser VU ausgeführten Kontrolle (Anhang 1B Randnummer
102 und Anhang 1C Randnummer 126).
1. Generation:
controlType — Art der Kontrolle.
controlTime — Datum und Uhrzeit der Kontrolle.
controlCardNumber — Identifizierung der für die Kontrolle verwen­
deten Kontrollkarte.
downloadPeriodBeginTime — Anfangszeit des heruntergeladenen Zeit­
raums beim Herunterladen.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 198
downloadPeriodEndTime — Endzeit des heruntergeladenen Zeitraums
beim Herunterladen.
2. Generation:
Anstelle von controlCardNumber wird in der Datenstruktur der 2. Ge­
neration folgendes Datenelement verwendet:
controlCardNumberAndGeneration — Identifizierung der für die
Kontrolle verwendeten Kontrollkarte und ihrer Generation.
2.188. VuControlActivityRecordArray
2. Generation:
In einer Fahrzeugeinheit gespeicherte Information zu unter Verwendung
dieser VU ausgeführten Kontrollen (Anhang 1C Randnummer 126).
recordType — Art des Datensatzes (VuControlActivityRecord). Wert­
zuweisung: siehe RecordType
recordSize — die Größe von VuControlActivityRecord in Byte.
noOfRecords — Anzahl der Datensätze in der Menge der Datensätze.
records –die Menge an VU-Kontrolltätigkeitsdatensätzen.
2.189. VuDataBlockCounter
Auf einer Karte gespeicherter Zähler, der sequenziell die Einsteck- und
Entnahmevorgänge der Karte in Fahrzeugeinheiten angibt.
Wertzuweisung: Laufende Nummer mit Höchstwert 9999, danach wie­
der Beginn bei 0.
2.190. VuDetailedSpeedBlock
In einer Fahrzeugeinheit gespeicherte Information zur genauen Ge­
schwindigkeit des Fahrzeugs während einer Minute, in der sich das
Fahrzeug bewegt hat (Anhang 1B Randnummer 093 und Anhang 1C
Randnummer 116).
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 199
speedBlockBeginDate — Datum und Uhrzeit des ersten Geschwindig­
keitswertes innerhalb des Blocks.
speedsPerSecond — chronologische Reihenfolge der gemessenen Ge­
schwindigkeiten zu jeder Sekunde der Minute, beginnend mit speed­
BlockBeginDate.
2.191. VuDetailedSpeedBlockRecordArray
2. Generation:
In einer Fahrzeugeinheit gespeicherte Information zur genauen Ge­
schwindigkeit des Fahrzeugs.
recordType — Art des Datensatzes (VuDetailedSpeedBlock). Wert­
zuweisung: siehe RecordType
recordSize — die Größe von VuDetailedSpeedBlock in Byte.
noOfRecords — Anzahl der Datensätze in der Menge der Datensätze.
records — Menge der genauen Geschwindigkeitsblöcke.
2.192. VuDetailedSpeedData
1. Generation:
In einer Fahrzeugeinheit gespeicherte Information zur genauen Ge­
schwindigkeit des Fahrzeugs.
noOfSpeedBlocks — Anzahl der Geschwindigkeitsblöcke in der Menge
vuDetailedSpeedBlocks.
vuDetailedSpeedBlocks — Menge der genauen Geschwindigkeitsblö­
cke.
▼M3
2.192a. VuDigitalMapVersion
2. Generation, Version 2:
Version der digitalen Karte, die in der Fahrzeugeinheit gespeichert ist
(Anhang IC Randnummer 133j).
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 200
Wertzuweisung: entsprechend der Angabe auf der von der Europäi­
schen Kommission bereitgestellten gesicherten Website (Anhang IC
Randnummer 133k).
▼B
2.193. VuDownloadablePeriod
Ältestes und jüngstes Datum, für das eine Fahrzeugeinheit Daten zu
Fahrertätigkeiten enthält (Anhang 1B Randnummern 081, 084 oder
087 und Anhang 1C Randnummern 102, 105, 108).
minDownloadableTime — ältestes in der VU gespeichertes Datum des
Einsteckens der Karte, einer Tätigkeitsänderung oder einer Ortseingabe
und Angabe der entsprechenden Uhrzeit.
maxDownloadableTime — jüngstes in der VU gespeichertes Datum
des Einsteckens der Karte, einer Tätigkeitsänderung oder einer Ortsein­
gabe und Angabe der entsprechenden Uhrzeit.
2.194. VuDownloadablePeriodRecordArray
2. Generation:
VUDownloadablePeriod und im Download-Protokoll verwendete Meta­
daten.
recordType — Art des Datensatzes (VuDownloadablePeriod). Wert­
zuweisung: siehe RecordType
recordSize — die Größe von VuDownloadablePeriod in Byte.
noOfRecords — Anzahl der Datensätze in der Menge der Datensätze.
records –Menge der VuDownloadablePeriod-Datensätze.
2.195. VuDownloadActivityData
In einer Fahrzeugeinheit gespeicherte Information zu ihrem letzten He­
runterladen (Anhang 1B Randnummer 105 und Anhang 1C Randnum­
mer 129).
1. Generation:
downloadingTime — Datum und Uhrzeit des Herunterladens.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 201
fullCardNumber — identifiziert die zur Genehmigung des Herunter­
ladens verwendete Karte.
companyOrWorkshopName — Name des Unternehmens oder der
Werkstatt.
2. Generation:
Anstelle von fullCardNumber wird in der Datenstruktur der 2. Genera­
tion folgendes Datenelement verwendet:
fullCardNumberAndGeneration — identifiziert die zur Genehmigung
des Herunterladens verwendete Karte und ihre Generation.
2.196. VuDownloadActivityDataRecordArray
2. Generation:
Information zum letzten VU-Download (Anhang 1C Randnummer 129).
recordType — Art des Datensatzes (VuDownloadActivityData). Wert­
zuweisung: siehe RecordType
recordSize — die Größe von VuDownloadActivityData in Byte.
noOfRecords — Anzahl der Datensätze in der Menge der Datensätze.
records — die Menge an Datensätzen zum Herunterladen.
2.197. VuEventData
1. Generation:
In einer Fahrzeugeinheit gespeicherte Information zu Ereignissen (An­
hang 1B Randnummer 094, mit Ausnahme Ereignis Geschwindigkeits­
überschreitung).
noOfVuEvents — Anzahl der in den vuEventRecords aufgeführten Er­
eignisse.
vuEventRecords — Ereignisdatensätze.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 202
2.198. VuEventRecord
In einer Fahrzeugeinheit gespeicherte Information zu einem Ereignis
(Anhang 1B Randnummer 094 und Anhang 1C Randnummer 117, mit
Ausnahme Ereignis Geschwindigkeitsüberschreitung).
1. Generation:
eventType — Art des Ereignisses.
eventRecordPurpose — Zweck der Aufzeichnung dieses Ereignisses.
eventBeginTime — Datum und Uhrzeit des Ereignisbeginns.
eventEndTime — Datum und Uhrzeit des Ereignisendes.
cardNumberDriverSlotBegin identifiziert die zu Beginn des Ereignis­
ses im Steckplatz Fahrer eingesteckte Karte.
cardNumberCodriverSlotBegin identifiziert die zu Beginn des Ereig­
nisses im Steckplatz Beifahrer eingesteckte Karte.
cardNumberDriverSlotEnd identifiziert die am Ende des Ereignisses
im Steckplatz Fahrer eingesteckte Karte.
cardNumberCodriverSlotEnd identifiziert die am Ende des Ereignisses
im SteckplatzBeifahrer eingesteckte Karte.
similarEventsNumber — Anzahl ähnlicher Ereignisse an diesem Tag.
Diese Folge kann für alle Ereignisse mit Ausnahme von Geschwindig­
keitsüberschreitungen verwendet werden.
2. Generation:
Zusätzlich zur 1. Generation werden folgende Datenelemente verwendet:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 203
manufacturerSpecificEventFaultData — zusätzliche, herstellerspezi­
fische Informationen zum Ereignis.
Anstelle von cardNumberDriverSlotBegin, cardNumberCodriverSlot­
Begin, cardNumberDriverSlotEnd und cardNumberCodriverSlotEnd wer­
den in der Datenstruktur der 2. Generation folgende Datenelemente
verwendet:
cardNumberAndGenDriverSlotBegin identifiziert die zu Beginn des
Ereignisses im Steckplatz Fahrer eingesteckte Karte und ihre Generation.
cardNumberAndGenCodriverSlotBegin identifiziert die zu Beginn des
Ereignisses im Steckplatz Beifahrer eingesteckte Karte und ihre Genera­
tion.
cardNumberAndGenDriverSlotEnd identifiziert die am Ende des Er­
eignisses im Steckplatz Fahrer eingesteckte Karte und ihre Generation.
cardNumberAndGenCodriverSlotEnd identifiziert die am Ende des
Ereignisses im Steckplatz Beifahrer eingesteckte Karte und ihre Genera­
tion.
Falls es sich bei dem Ereignis um einen Zeitkonflikt handelt, sind event­
BeginTime und eventEndTime folgendermaßen zu interpretieren:
eventBeginTime — Datum und Uhrzeit des Kontrollgeräts.
eventEndTime — GNSS-Datum und -Uhrzeit.
2.199. VuEventRecordArray
2. Generation:
In einer Fahrzeugeinheit gespeicherte Information zu Ereignissen (An­
hang 1C Randnummer 117, mit Ausnahme Ereignis Geschwindigkeits­
überschreitung).
recordType — Art des Datensatzes (VuEventRecord). Wertzuweisung:
siehe RecordType
recordSize — die Größe von VuEventRecord in Byte.
noOfRecords — Anzahl der Datensätze in der Menge der Datensätze.
records — Menge der Ereignisdatensätze.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 204
2.200. VuFaultData
1. Generation:
In einer Fahrzeugeinheit gespeicherte Information zu Störungen (Anhang
1B Randnummer 096).
noOfVuFaults — Anzahl der in der Menge vuFaultRecords aufgeführ­
ten Störungen.
vuFaultRecords — Störungsdatensätze.
2.201. VuFaultRecord
In einer Fahrzeugeinheit gespeicherte Information zu einer Störung (An­
hang 1B Randnummer 096 und Anhang 1C Randnummer 118).
1. Generation:
faultType — Art der Kontrollgerätstörung.
faultRecordPurpose — Zweck der Aufzeichnung dieser Störung.
faultBeginTime — Datum und Uhrzeit des Störungsbeginns.
faultEndTime — Datum und Uhrzeit des Störungsendes.
cardNumberDriverSlotBegin identifiziert die zu Beginn der Störung im
Steckplatz Fahrer eingesteckte Karte.
cardNumberCodriverSlotBegin identifiziert die zu Beginn der Störung
im Steckplatz Beifahrer eingesteckte Karte.
cardNumberDriverSlotEnd identifiziert die zum Zeitpunkt des Endes
der Störung im Steckplatz Fahrer eingesteckte Karte.
cardNumberCodriverSlotEnd identifiziert die zum Zeitpunkt des En­
des der Störung im Steckplatz Beifahrer eingesteckte Karte.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 205
2. Generation:
Zusätzlich zur 1. Generation wird folgendes Datenelement verwendet:
manufacturerSpecificEventFaultData — zusätzliche, herstellerspezi­
fische Informationen zur Störung.
Anstelle von cardNumberDriverSlotBegin, cardNumberCodriverSlot­
Begin, cardNumberDriverSlotEnd und cardNumberCodriverSlotEnd wer­
den in der Datenstruktur der 2. Generation folgende Datenelemente
verwendet:
cardNumberAndGenDriverSlotBegin identifiziert die zu Beginn der
Störung im Steckplatz Fahrer eingesteckte Karte und ihre Generation.
cardNumberAndGenCodriverSlotBegin identifiziert die zu Beginn der
Störung im Steckplatz Beifahrer eingesteckte Karte und ihre Generation.
cardNumberAndGenDriverSlotEnd identifiziert die am Ende der Stö­
rung im Steckplatz Fahrer eingesteckte Karte und ihre Generation.
cardNumberAndGenCodriverSlotEnd identifiziert die am Ende der
Störung im Steckplatz Beifahrer eingesteckte Karte und ihre Generation.
2.202. VuFaultRecordArray
2. Generation:
In einer Fahrzeugeinheit gespeicherte Information zu Störungen (Anhang
1C Randnummer 118).
recordType — Art des Datensatzes (VuFaultRecord). Wertzuweisung:
siehe RecordType
recordSize — die Größe von VuFaultRecord in Byte.
noOfRecords — Anzahl der Datensätze in der Menge der Datensätze.
records –Störungsdatensätze.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 206
2.203. VuGNSSADRecord
▼M3
2. Generation, Version 1:
▼M1
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).
timeStamp — Datum und Uhrzeit, wann die kumulierte Lenkzeit ein
Vielfaches von drei Stunden erreicht.
cardNumberAndGenDriverSlot — identifiziert die im Steckplatz Fah­
rer 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 Lenk­
zeit ein Vielfaches von drei Stunden erreicht.
▼M3
2. Generation, Version 2:
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).
In Version 2 der 2. Generation wird anstelle von gnssPlaceRecord der
Datensatz gnssPlaceAuthRecord verwendet, der zusätzlich den GNSS-
Authentisierungsstatus enthält.
2.203a. VuBorderCrossingRecord
2. Generation, Version 2:
In einer Fahrzeugeinheit gespeicherte Informationen im Zusammenhang
mit Grenzüberschreitungen des Fahrzeugs, wenn das Fahrzeug die
Grenze eines Landes überschritten hat (Anhang IC Randnummern 133a
und 133b).
▼M1
02016R0799 — DE — 21.08.2023 — 003.002 — 207
cardNumberAndGenDriverSlot – identifiziert die im Steckplatz Fahrer
eingesteckte Karte und ihre Generation.
cardNumberAndGenCodriverSlot – identifiziert die im Steckplatz Bei­
fahrer eingesteckte Karte und ihre Generation.
countryLeft – das Land, das das Fahrzeug auf der Grundlage der letzten
verfügbaren Position vor der Feststellung der Grenzüberschreitung ver­
lassen hat „Übrige Welt“ (NationNumeric-Code „FF“H) ist zu verwen­
den, wenn die Fahrzeugeinheit nicht in der Lage ist, das Land zu be­
stimmen, in dem sich das Fahrzeug befindet (z. B. wenn das aktuelle
Land nicht Teil der gespeicherten digitalen Karten ist).
countryEntered – das Land, in das das Fahrzeug eingefahren ist. „Üb­
rige Welt“ (NationNumeric-Code „FF“H) ist zu verwenden, wenn die
Fahrzeugeinheit nicht in der Lage ist, das Land zu bestimmen, in dem
sich das Fahrzeug befindet (z. B. wenn das aktuelle Land nicht Teil der
gespeicherten digitalen Karten ist).
gnssPlaceAuthRecord – Informationen zur Position des Fahrzeugs zum
Zeitpunkt der Feststellung der Grenzüberschreitung, sowie Authentisie­
rungsstatus der Position.
vehicleOdometerValue – Kilometerstand, an dem die Fahrzeugeinheit
festgestellt hat, dass das Fahrzeug die Grenze eines Landes überschritten
hat.
2.203b. VuBorderCrossingRecordArray
2. Generation, Version 2:
In einer Fahrzeugeinheit gespeicherte Informationen zu Grenzüberschrei­
tungen des Fahrzeugs (Anhang IC Randnummer 133c).
recordType – Art des Datensatzes (VuBorderCrossingRecord). Wert­
zuweisung: siehe RecordType.
recordSize Größe des Datensatzes VuBorderCrossingRecord in Bytes.
noOfRecords – Anzahl der Datensätze in der Menge der Datensätze.
records –Menge der Grenzüberschreitungsdatensätze.
▼M1
2.204. VuGNSSADRecordArray
2. Generation:
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 208
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).
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.
▼M3
2.204a. VuGnssMaximalTimeDifference
2. Generation, Version 2:
Die maximale Differenz zwischen der tatsächlichen Zeit und der Zeit der
Echtzeituhr der Fahrzeugeinheit auf der Grundlage der maximalen Zeit­
abweichung gemäß Anhang IC Randnummer 41, die von der Fahrzeug­
einheit an eine externe GNSS-Ausrüstung übermittelt wird (siehe An­
lage 12 Randnummer GNS_3g).
▼B
2.205. VuIdentification
In einer Fahrzeugeinheit gespeicherte Information zur Identifizierung der
Fahrzeugeinheit (Anhang 1B Randnummer 075 und Anhang 1C Rand­
nummern 93 und 121).
1. Generation:
vuManufacturerName — Name des Herstellers der Fahrzeugeinheit.
vuManufacturerAddress — Anschrift des Herstellers der Fahrzeugein­
heit.
vuPartNumber — Teilnummer der Fahrzeugeinheit.
vuSerialNumber — Seriennummer der Fahrzeugeinheit.
▼M1
02016R0799 — DE — 21.08.2023 — 003.002 — 209
vuSoftwareIdentification identifiziert die in der Fahrzeugeinheit imple­
mentierte Software.
vuManufacturingDate — Herstellungsdatum der Fahrzeugeinheit.
vuApprovalNumber –Typgenehmigungsnummer der Fahrzeugeinheit.
▼M3
2. Generation:
Zusätzlich zur 1. Generation werden folgende Datenelemente verwendet:
vuGeneration – identifiziert die Generation der Fahrzeugeinheit.
vuAbility – enthält Informationen darüber, ob die Fahrzeugeinheit Fahr­
tenschreiberkarten der 1. Generation unterstützt.
vuDigitalMapVersion – die Version der digitalen Karte, die in der
Fahrzeugeinheit gespeichert ist (nur in Version 2 vorhanden).
▼B
2.206. VuIdentificationRecordArray
2. Generation:
VuIdentification und im Download-Protokoll verwendete Metadaten.
recordType — Art des Datensatzes (VuIdentification). Wertzuweisung:
siehe RecordType
recordSize — die Größe von VuIdentification in Byte.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 210
noOfRecords — Anzahl der Datensätze in der Menge der Datensätze.
records — Menge der VuIdentification-Datensätze.
2.207. VuITSConsentRecord
2. Generation:
In einer Fahrzeugeinheit gespeicherte Informationen zur Zustimmung
eines Fahrers, intelligente Verkehrssysteme zu nutzen.
cardNumberAndGen — identifiziert die Karte und ihre Generation. Bei
dieser muss es sich um eine Fahrer- oder Werkstattkarte handeln.
consent — Merker, der angibt, ob der Fahrer der Verwendung intelli­
genter Verkehrssysteme mit diesem Fahrzeug/dieser Fahrzeugeinheit zu­
gestimmt hat.
Wertzuweisung:
TRUE zeigt die Zustimmung des Fahrers zur Verwendung intelli­
genter Verkehrssysteme an
FALSE zeigt die Ablehnung des Fahrers betreffend die Verwen­
dung intelligenter Verkehrssysteme an
2.208. VuITSConsentRecordArray
2. Generation:
In einer Fahrzeugeinheit gespeicherte Information bezüglich der Zustim­
mung des Fahrers zur Verwendung intelligenter Verkehrssysteme (An­
hang 1C Randnummer 200).
recordType — Art des Datensatzes (VuITSConsentRecord). Wert­
zuweisung: siehe RecordType
recordSize — die Größe von VuITSConsentRecord in Byte.
noOfRecords — Anzahl der Datensätze in der Menge der Datensätze.
records — Datensätze mit Informationen zur ITS-Zustimmung.
▼M3
2.208a. VuLoadUnloadRecord
2. Generation, Version 2:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 211
In der Fahrzeugeinheit gespeicherte Informationen zu einem eingegebe­
nen Be-/Entladevorgang (Anhang IC Randnummern 133e, 133f
und 133g).
timeStamp – Datum und Uhrzeit der Eingabe des Be-/Entladevorgangs.
operationType – Art des eingegebenen Vorgangs (Beladen, Entladen
oder gleichzeitiges Be- und Entladen).
cardNumberAndGenDriverSlot – identifiziert die im Steckplatz Fahrer
eingesteckte Karte und ihre Generation.
cardNumberAndGenCodriverSlot – identifiziert die im Steckplatz Bei­
fahrer eingesteckte Karte und ihre Generation.
gnssPlaceAuthRecord – Informationen zur Position des Fahrzeugs so­
wie Authentisierungsstatus der Position.
vehicleOdometerValue – Kilometerstand bei Beginn des Be-/Entlade­
vorgangs.
2.208b. VuLoadUnloadRecordArray
2. Generation, Version 2:
In einer Fahrzeugeinheit gespeicherte Informationen zu einem einge­
gebenen Be-/Entladevorgang des Fahrzeugs (Anhang IC Randnum­
mer 133h).
recordType – Art des Datensatzes (VuLoadUnloadRecord). Wertzuwei­
sung: Siehe Art des Datensatzes.
recordSize – Größe des Datensatzes VuLoadUnloadRecord in Bytes.
noOfRecords – Anzahl der Datensätze in der Menge der Datensätze.
records –Menge der Be-/Entladevorgangsdatensätze.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 212
2.209. VuManufacturerAddress
Anschrift des Herstellers der Fahrzeugeinheit.
Wertzuweisung: nicht spezifiziert.
2.210. VuManufacturerName
Name des Herstellers der Fahrzeugeinheit.
Wertzuweisung: nicht spezifiziert.
2.211. VuManufacturingDate
Herstellungsdatum der Fahrzeugeinheit.
Wertzuweisung: nicht spezifiziert.
2.212. VuOverSpeedingControlData
In einer Fahrzeugeinheit gespeicherte Information zum Ereignis Ge­
schwindigkeitsüberschreitung seit der letzten Kontrolle Geschwindig­
keitsüberschreitung (Anhang 1B Randnummer 095 und Anhang 1C
Randnummer 117).
lastOverspeedControlTime — Datum und Uhrzeit der letzten Kontrolle
Geschwindigkeitsüberschreitung.
firstOverspeedSince — Datum und Uhrzeit der ersten Geschwindig­
keitsüberschreitung nach dieser Kontrolle Geschwindigkeitsüberschrei­
tung.
numberOfOverspeedSince –Anzahl der Ereignisse Geschwindigkeits­
überschreitung seit der letzten Kontrolle Geschwindigkeitsüberschrei­
tung.
2.213. VuOverSpeedingControlDataRecordArray
2. Generation:
VuOverSpeedingControlData und im Download-Protokoll verwendete
Metadaten.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 213
recordType — Art des Datensatzes (VuOverSpeedingControlData).
Wertzuweisung: siehe RecordType
recordSize — die Größe von VuOverSpeedingControlData in Byte.
noOfRecords — Anzahl der Datensätze in der Menge der Datensätze.
records — Kontrolldatensätze Geschwindigkeitsüberschreitung.
2.214. VuOverSpeedingEventData
1. Generation:
In einer Fahrzeugeinheit gespeicherte Information zum Ereignis Ge­
schwindigkeitsüberschreitung (Anhang 1B Randnummer 094).
noOfVuOverSpeedingEvents — Anzahl der in der Menge vuOver­
SpeedingEventRecords aufgeführten Ereignisse.
vuOverSpeedingEventRecords — Ereignisdatensätze Geschwindig­
keitsüberschreitung.
2.215. VuOverSpeedingEventRecord
1. Generation:
In einer Fahrzeugeinheit gespeicherte Information zu Ereignissen Ge­
schwindigkeitsüberschreitung (Anhang 1B Randnummer 094 und An­
hang 1C Randnummer 117).
eventType — Art des Ereignisses.
eventRecordPurpose — Zweck der Aufzeichnung dieses Ereignisses.
eventBeginTime — Datum und Uhrzeit des Ereignisbeginns.
eventEndTime — Datum und Uhrzeit des Ereignisendes.
maxSpeedValue — die während des Ereignisses gemessene Höchst­
geschwindigkeit.
averageSpeedValue — die während des Ereignisses gemessene arith­
metische Durchschnittsgeschwindigkeit.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 214
cardNumberDriverSlotBegin identifiziert die zu Beginn des Ereignis­
ses im Steckplatz Fahrer eingesteckte Karte.
similarEventsNumber — Anzahl ähnlicher Ereignisse an diesem Tag.
2. Generation:
In einer Fahrzeugeinheit gespeicherte Information zu Ereignissen Ge­
schwindigkeitsüberschreitung (Anhang 1B Randnummer 094 und An­
hang 1C Randnummer 117).
Anstelle von cardNumberDriverSlotBegin wird in der Datenstruktur der
2. Generation folgendes Datenelement verwendet:
cardNumberAndGenDriverSlotBegin identifiziert die zu Beginn des
Ereignisses im Steckplatz Fahrer eingesteckte Karte und ihre Generation.
2.216. VuOverSpeedingEventRecordArray
2. Generation:
In einer Fahrzeugeinheit gespeicherte Information zum Ereignis Ge­
schwindigkeitsüberschreitung (Anhang 1C Randnummer 117).
recordType — Art des Datensatzes (VuOverSpeedingEventRecord).
Wertzuweisung: siehe RecordType
recordSize — die Größe von VuOverSpeedingEventRecord in Byte.
noOfRecords — Anzahl der Datensätze in der Menge der Datensätze.
records — Ereignisdatensätze Geschwindigkeitsüberschreitung.
2.217. VuPartNumber
Teilnummer der Fahrzeugeinheit.
Wertzuweisung: VU-Herstellerspezifisch
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 215
2.218. VuPlaceDailyWorkPeriodData
1. Generation:
In einer Fahrzeugeinheit gespeicherte Information zum Ort des Beginns
und/oder Endes des Arbeitstages (Anhang 1B Randnummer 087 und
Anhang 1C Randnummern 108 und 110).
noOfPlaceRecords — Anzahl der in der Menge vuPlaceDailyWorkPe­
riodRecords aufgeführten Datensätze.
vuPlaceDailyWorkPeriodRecords — ortsbezogene Datensätze.
2.219. VuPlaceDailyWorkPeriodRecord
1. Generation:
In einer Fahrzeugeinheit gespeicherte Information zu einem Ort des
Beginns oder Endes des Arbeitstages eines Fahrers (Anhang 1B Rand­
nummer 087 und Anhang 1C Randnummern 108 und 110).
fullCardNumber — Art der Karte des Fahrers, ausstellender Mitglied­
staat und Kartennummer.
placeRecord enthält die Informationen zum eingegebenen Ort.
▼M3
2. Generation, Version 1:
▼B
In einer Fahrzeugeinheit gespeicherte Information zu einem Ort des
Beginns oder Endes des Arbeitstages eines Fahrers (Anhang 1B Rand­
nummer 087 und Anhang 1C Randnummern 108 und 110).
Anstelle von fullCardNumber wird in der Datenstruktur der 2. Genera­
tion folgendes Datenelement verwendet:
fullCardNumberAndGeneration — Art der Karte, ausstellender Mit­
gliedstaat, Kartennummer und Generation in der auf der Karte gespei­
cherten Form.
▼M3
2. Generation, Version 2:
In einer Fahrzeugeinheit gespeicherte Informationen zu einem Ort des
Beginns oder Endes des Arbeitstages eines Fahrers (Anhang 1B Rand­
nummer 087 und Anhang 1C Randnummern 108 und 110).
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 216
Anstelle von placeRecord wird in der Datenstruktur der Version 2 der
2. Generation folgendes Datenelement verwendet:
placeAuthRecord – Eingegebener Ort, aufgezeichnete Position, GNSS-
Authentisierungsstatus und Positionsbestimmungszeit.
▼B
2.220. VuPlaceDailyWorkPeriodRecordArray
2. Generation:
In einer Fahrzeugeinheit gespeicherte Information zum Ort des Beginns
und/oder Endes des Arbeitstages (Anhang 1C Randnummern 108 und
110).
recordType — Art des Datensatzes (VuPlaceDailyWorkPeriodRecord).
Wertzuweisung: siehe RecordType
recordSize — die Größe von VuPlaceDailyWorkPeriodRecord in Byte.
noOfRecords — Anzahl der Datensätze in der Menge der Datensätze.
records — ortsbezogene Datensätze.
2.221. VuPrivateKey
1. Generation:
Der private Schlüssel einer Fahrzeugeinheit.
2.222. VuPublicKey
1. Generation:
Der öffentliche Schlüssel einer Fahrzeugeinheit.
▼M3
2.222a. VuRtcTime
2. Generation, Version 2:
Zeit der Echtzeituhr der Fahrzeugeinheit, die von der Fahrzeugeinheit an
eine externe GNSS-Ausrüstung übermittelt wird (siehe Anlage 12 Rand­
nummer GNS_3f).
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 217
2.223. VuSerialNumber
Seriennummer der Fahrzeugeinheit (Anhang 1B Randnummer 075 sowie
Anhang 1C Randnummer 93).
2.224. VuSoftInstallationDate
Installationsdatum der VU-Softwareversion.
Wertzuweisung: nicht spezifiziert.
2.225. VuSoftwareIdentification
In einer Fahrzeugeinheit gespeicherte Information zur installierten Soft­
ware.
vuSoftwareVersion — Softwareversionsnummer der Fahrzeugeinheit.
vuSoftInstallationDate — Installationsdatum der Softwareversion.
2.226. VuSoftwareVersion
Softwareversionsnummer der Fahrzeugeinheit.
Wertzuweisung: nicht spezifiziert.
2.227. VuSpecificConditionData
1. Generation:
In einer Fahrzeugeinheit gespeicherte Information zu spezifischen Be­
dingungen.
noOfSpecificConditionRecords — Anzahl der in der Menge specific­
ConditionRecords aufgeführten Datensätze.
specificConditionRecords — Datensätze mit Bezug auf spezifische Be­
dingungen.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 218
2.228. VuSpecificConditionRecordArray
2. Generation:
In einer Fahrzeugeinheit gespeicherte Information zu spezifischen Be­
dingungen (Anhang 1C Randnummer 130).
recordType — Art des Datensatzes (SpecificConditionRecord). Wert­
zuweisung: siehe RecordType
recordSize — die Größe von SpecificConditionRecord in Byte.
noOfRecords — Anzahl der Datensätze in der Menge der Datensätze.
records — Datensätze mit Bezug auf spezifische Bedingungen.
2.229. VuTimeAdjustmentData
1. Generation:
In einer Fahrzeugeinheit gespeicherte Information zu Zeiteinstellungen
außerhalb einer normalen Kalibrierung (Anhang 1B Randnummer 101).
noOfVuTimeAdjRecords — Anzahl der in der Menge vuTimeAdjust­
mentRecords aufgeführten Datensätze.
vuTimeAdjustmentRecords — Zeiteinstellungsdatensätze.
▼M1
2.230. Reserviert für künftige Verwendung
2.231. Reserviert für künftige Verwendung
▼B
2.232. VuTimeAdjustmentRecord
In einer Fahrzeugeinheit gespeicherte Information zu einer Zeiteinstel­
lung außerhalb einer normalen Kalibrierung (Anhang 1B Randnummer
101 und Anhang 1C Randnummern 124 und 125).
1. Generation:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 219
oldTimeValue, newTimeValue — alter und neuer Wert für Datum und
Uhrzeit.
workshopName, workshopAddress — Name und Anschrift der Werk­
statt.
workshopCardNumber — identifiziert die für die Durchführung der
Zeiteinstellung verwendete Werkstattkarte.
2. Generation:
Anstelle von workshopCardNumber wird in der Datenstruktur der 2.
Generation folgendes Datenelement verwendet:
workshopCardNumberAndGeneration identifiziert die für die Durch­
führung der Zeiteinstellung verwendete Werkstattkarte und ihre Genera­
tion.
2.233. VuTimeAdjustmentRecordArray
2. Generation:
In einer Fahrzeugeinheit gespeicherte Information zu Zeiteinstellungen
außerhalb einer normalen Kalibrierung (Anhang 1C Randnummern 124
und 125).
recordType — Art des Datensatzes (VuTimeAdjustmentRecord). Wert­
zuweisung: siehe RecordType
recordSize — die Größe von VuTimeAdjustmentRecord in Byte.
noOfRecords — Anzahl der Datensätze in der Menge der Datensätze.
records — Zeiteinstellungsdatensätze.
2.234. WorkshopCardApplicationIdentification
Auf einer Werkstattkarte gespeicherte Information zur Identifizierung der
Anwendung der Karte (Anhang 1C Randnummern 307 und 330).
1. Generation:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 220
typeOfTachographCardId gibt die implementierte Kartenart an.
cardStructureVersion gibt die Version der auf der Karte implementier­
ten Struktur an.
noOfEventsPerType — Anzahl der Ereignisse je Ereignisart, die die
Karte speichern kann.
noOfFaultsPerType — Anzahl der Störungen je Störungsart, die die
Karte speichern kann.
activityStructureLength — gibt die Zahl der Bytes an, die für die
Speicherung von Tätigkeitsdatensätzen zur Verfügung stehen.
noOfCardVehicleRecords — Anzahl der Fahrzeugdatensätze, die die
Karte enthalten kann.
noOfCardPlaceRecords — Anzahl der Orte, die die Karte aufzeichnen
kann.
noOfCalibrationRecords — Anzahl der Kalibrierungsdatensätze, die
die Karte speichern kann.
2. Generation:
▼M1
Zusätzlich zur 1. Generation werden folgende Datenelemente verwendet:
noOfGNSSADRecords — Anzahl der kumulierten GNSS-Lenkzeiten­
datensä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 Informa­
tionen zu den genutzten Fahrzeugeinheiten, die die Karte speichern
kann.
▼M3
2.234a. WorkshopCardApplicationIdentificationV2
2. Generation, Version 2:
Auf einer Werkstattkarte gespeicherte Informationen zur Identifizierung
der Anwendung der Karte (Anhang IC Randnummer 330a).
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 221
lengthOfFollowingData – Anzahl der nachfolgenden Bytes im Daten­
satz.
noOfBorderCrossingRecords – Anzahl der Grenzüberschreitungsdaten­
sätze, die die Werkstattkarte speichern kann.
noOfLoadUnloadRecords – Anzahl der Be-/Entladedatensätze, die die
Werkstattkarte speichern kann.
noOfLoadTypeEntryRecords – Anzahl der Ladungsarteingabedaten­
sätze, die die Werkstattkarte speichern kann.
vuConfigurationLengthRange – Anzahl der Bytes in einer Fahrten­
schreiberkarte, die für die Speicherung von Konfigurationen der Fahr­
zeugeinheit verfügbar sind.
2.234b. WorkshopCardCalibrationAddData
2. Generation, Version 2:
Auf einer Werkstattkarte gespeicherte Informationen zu zusätzlichen Da­
ten (z. B. standardmäßige Art der Ladung), die bei einer Kalibrierung
eingegeben wurden (Anhang IC Randnummer 356l).
calibrationPointerNewestRecord – Index des zuletzt aktualisierten Da­
tensatzes zusätzlicher Kalibrierungsdaten.
Wertzuweisung – Zahl, die dem Zähler des Datensatzes zusätzlicher
Kalibrierungsdaten entspricht, beginnend mit „0“ für das erste Auftreten
des Datensatzes zusätzlicher Kalibrierungsdaten in der Struktur.
workshopCardCalibrationAddDataRecords – Datensätze mit dem al­
ten Datums- und Uhrzeitwert, dem Fahrzeugidentifizierungswert und der
standardmäßigen Art der Ladung des Fahrzeugs.
2.234c. WorkshopCardCalibrationAddDataRecord
2. Generation, Version 2:
Auf einer Werkstattkarte gespeicherte Informationen zur standardmäßi­
gen Art der Ladung, die bei einer Kalibrierung eingegeben wurden (An­
hang IC Randnummer 356k).
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 222
oldTimeValue – alter Datums- und Uhrzeitwert im entsprechenden Da­
tensatz WorkshopCardCalibrationRecord.
vehicleIdentificationNumber – Fahrzeugidentifizierungsnummer des
Fahrzeugs, die ebenfalls im entsprechenden Datensatz WorkshopCard­
CalibrationRecord enthalten ist.
byDefaultLoadType – die standardmäßige Art der Ladung des Fahr­
zeugs (nur in Version 2 vorhanden).
calibrationCountry – Land, in dem die Kalibrierung durchgeführt
wurde.
calibrationCountryTimestamp – Datum und Uhrzeit der Bereitstellung
der Position vom GNSS-Empfänger, die zur Bestimmung des Landes
verwendet wurden.
▼B
2.235. WorkshopCardCalibrationData
Auf einer Werkstattkarte gespeicherte Information zur mit der Karte
durchgeführten Werkstatttätigkeit (Anhang 1C Randnummern 314,
316, 337 und 339).
calibrationTotalNumber — Gesamtzahl der mit der Karte durchgeführ­
ten Kalibrierungen.
calibrationPointerNewestRecord — Index des zuletzt aktualisierten
Kalibrierungsdatensatzes.
Wertzuweisung: Zahl, die dem Zähler des Kalibrierungsdatensatzes ent­
spricht, beginnend mit „0“ für das erste Auftreten der Kalibrierungs­
datensätze in der Struktur.
calibrationRecords — Datensätze mit Informationen zu Kalibrierung
und/oder Zeiteinstellung.
2.236. WorkshopCardCalibrationRecord
Auf einer Werkstattkarte gespeicherte Information zu einer mit der Karte
durchgeführten Kalibrierung (Anhang 1C Randnummern 314 und 337).
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 223
1. Generation:
calibrationPurpose — Zweck der Kalibrierung.
vehicleIdentificationNumber — Fahrzeugidentifizierungsnummer
(VIN).
vehicleRegistration enthält das amtliche Kennzeichen und den zulassen­
den Mitgliedstaat.
wVehicleCharacteristicConstant — Wegdrehzahl des Fahrzeugs.
kConstantOfRecordingEquipment — Kontrollgerätkonstante.
lTyreCircumference — tatsächlicher Reifenumfang.
tyreSize — Bezeichnung der Größe der am Fahrzeug montierten Reifen.
authorisedSpeed — zulässige Höchstgeschwindigkeit des Fahrzeugs.
oldOdometerValue, newOdometerValue — alter und neuer Kilometer­
stand.
oldTimeValue, newTimeValue — alter und neuer Wert für Datum und
Uhrzeit.
nextCalibrationDate — Datum der nächsten von der zugelassenen
Prüfstelle durchzuführenden Kalibrierung der in CalibrationPurpose an­
gegebenen Art.
vuPartNumber, vuSerialNumber und sensorSerialNumber — Daten­
elemente zur Identifizierung des Kontrollgeräts.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 224
2. Generation:
Zusätzlich zur 1. Generation werden folgende Datenelementeverwendet:
sensorGNSSSerialNumber — identifiziert eine externe GNSS-Ausrüs­
tung.
rcmSerialNumber — identifiziert das Fernkommunikationsmodul.
sealDataCard — Informationen zu den an den verschiedenen Fahrzeug­
komponenten angebrachten Plomben.
2.237. WorkshopCardHolderIdentification
Auf einer Werkstattkarte gespeicherte Information zur Identifizierung
des Karteninhabers (Anhang 1C Randnummern 311 und 334).
workshopName — Name der Werkstatt des Karteninhabers.
workshopAddress — Anschrift der Werkstatt des Karteninhabers.
cardHolderName — Name und Vorname(n) des Inhabers (z. B. Name
des Mechanikers).
cardHolderPreferredLanguage — bevorzugte Sprache des Karteninha­
bers.
2.238. WorkshopCardPIN
PIN-Code (Personal Identification Number) der Werkstattkarte (Anhang
1C Randnummern 309 und 332).
Wertzuweisung: Der dem Karteninhaber bekannte PIN-Code, nach
rechts mit „FF“-Bytes bis zu 8 Bytes aufgefüllt.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 225
2.239. W-VehicleCharacteristicConstant
Wegdrehzahl des Fahrzeugs (Begriffsbestimmung k)).
Wertzuweisung: Impulse je Kilometer im Betriebsbereich 0 bis 64 255
Imp/km.
2.240. VuPowerSupplyInterruptionRecord
2. Generation:
In einer Fahrzeugeinheit gespeicherte Information zum Ereignis Unter­
brechung der Stromversorgung (Anhang 1C Randnummer 117).
eventType — Art des Ereignisses.
eventRecordPurpose — Zweck der Aufzeichnung dieses Ereignisses.
eventBeginTime — Datum und Uhrzeit des Ereignisbeginns.
eventEndTime — Datum und Uhrzeit des Ereignisendes.
cardNumberAndGenDriverSlotBegin identifiziert die zu Beginn des
Ereignisses im Steckplatz Fahrer eingesteckte Karte und ihre Generation.
cardNumberAndGenDriverSlotEnd identifiziert die am Ende des Er­
eignisses im Steckplatz Fahrer eingesteckte Karte und ihre Generation.
cardNumberAndGenCodriverSlotBegin identifiziert die zu Beginn des
Ereignisses im Steckplatz Beifahrer eingesteckte Karte und ihre Genera­
tion.
cardNumberAndGenCodriverSlotBegin identifiziert die am Ende des
Ereignisses im Steckplatz Beifahrer eingesteckte Karte und ihre Genera­
tion.
similarEventsNumber — Anzahl ähnlicher Ereignisse an diesem Tag.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 226
2.241. VuPowerSupplyInterruptionRecordArray
2. Generation:
In einer Fahrzeugeinheit gespeicherte Information zum Ereignis Unter­
brechung der Stromversorgung (Anhang 1C Randnummer 117).
recordType — Art des Datensatzes (VuPowerSupplyInterruptionRe­
cord). Wertzuweisung: siehe RecordType
recordSize — die Größe von VuPowerSupplyInterruptionRecord in
Byte.
noOfRecords — Anzahl der Datensätze in der Menge der Datensätze.
records –Ereignisdatensätze Unterbrechung der Stromversorgung.
2.242. VuSensorExternalGNSSCoupledRecordArray
2. Generation:
Satz von SensorExternalGNSSCoupledRecord plus im Download-Pro­
tokoll verwendete Metadaten.
recordType — Art des Datensatzes (SensorExternalGNSSCoupledRe­
cord). Wertzuweisung: siehe RecordType
recordSize — die Größe von SensorExternalGNSSCoupledRecord in
Byte.
noOfRecords — Anzahl der Datensätze in der Menge der Datensätze.
records –Datensätze Kopplung des -externen GNSS mit dem Sensor.
2.243. VuSensorPairedRecordArray
2. Generation:
Satz von SensorPairedRecord plus im Download-Protokoll verwendete
Metadaten.
recordType — Art des Datensatzes (SensorPairedRecord). Wertzuwei­
sung: siehe RecordType
recordSize — die Größe von SensorPairedRecord in Byte.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 227
noOfRecords — Anzahl der Datensätze in der Menge der Datensätze.
records — Sensorkoppelungsdatensätze.
3. DEFINITIONEN FÜR WERT- UND GRÖSSENBEREICHE
Definition variabler Werte, die für die Definitionen in Abschnitt 2 ver­
wendet werden.
4. ZEICHENSÄTZE
In den IA5Strings werden die ASCII-Zeichen laut Definition in ISO/IEC
8824-1 verwendet. Aus Gründen der Lesbarkeit und zur Bezugnahme ist
die Wertzuweisung nachfolgend angegeben. Bei Diskrepanzen mit dieser
zu Informationszwecken aufgeführten Angabe gilt stets die Norm ISO/
IEC 8824-1.
Andere Zeichenfolgen (Anschrift, Name, VehicleRegistrationNumber)
verwenden darüber hinaus die Zeichen der Dezimalzeichencodes 161 bis
255 der folgenden 8-Bit-Standardzeichensätze, spezifiziert durch die
Codeseiten-Nummern:
Standardzeichensatz
Codeseite
(Dezimal)
ISO/IEC 8859-1 Latin-1 Westeuropäisch 1
ISO/IEC 8859-2 Latin-2 Mitteleuropäisch 2
ISO/IEC 8859-3 Latin-3 Südeuropäisch 3
ISO/IEC 8859-5 Latin/Kyrillisch 5
ISO/IEC 8859-7 Latin/Griechisch 7
ISO/IEC 8859-9 Latin-5 Türkisch 9
ISO/IEC 8859-13 Latin-7 Baltisch 13
ISO/IEC 8859-15 Latin-9 15
ISO/IEC 8859-16 Latin-10 Südosteuropäisch 16
KOI8-R Latin/Kyrillisch 80
KOI8-U Latin/Kyrillisch 85
5. KODIERUNG
Bei Kodierung anhand der ASN.1-Kodierungsregeln werden alle Daten­
typen gemäß ISO/IEC 8825-2 (ausgerichtet) kodiert.
6. OBJEKTKENNUNGEN UND ANWENDUNGSBEZEICHNER
6.1. Objektkennungen
Die in diesem Kapitel aufgeführten Objektkennungen (OID) sind nur für
die 2. Generation von Bedeutung. Diese OID werden in TR-03110-3
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 228
definiert und hier der Vollständigkeit halber wiederholt. Die betreffenden
OID sind im bsi-de-Teilbaum enthalten:
Protokollkennungen für die VU-Authentisierung
Beispiel: Wenn die VU-Authentisierung mit SHA-384 erfolgen
muss, lautet die zu verwendende Objektkennung (in ASN.
1-Notation) .
Der Wert dieser Objektkennung in Punktnotation lautet
.
Do tnotation Byte notation
„04 00 7F 00 07 02 02 02 02 03“
„04 00 7F 00 07 02 02 02 02 04“
„04 00 7F 00 07 02 02 02 02 05“
Protokollkennungen für die Chip-Authentisierung
Beispiel: Es wird davon ausgegangen, dass die Chip-Authentisierung per
ECDH-Algorithmus erfolgen soll, was zu einer Länge des
AES-Sitzungsschlüssels von 128 Bits führt. Dieser Sitzungsschlüssel wird
anschließend im CBC-Betriebsmodus verwendet, um den Datenschutz zu
gewährleisten, sowie mit dem CMAC-Algorithmus zur Gewährleistung der
Datenauthentizität. Somit lautet die zu verwendende Objektkennung (in
ASN.1-Notation) .
Der Wert dieser Objektkennung in Punktnotation lautet
.
Punktnotation Byte-Notation
„04 00 7F 00 07 02 02 03 02 02“
„04 00 7F 00 07 02 02 03 02 03“
„04 00 7F 00 07 02 02 03 02 04“
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 229
6.2. Anwendungskennungen
2. Generation:
Die Anwendungskennung (AID) für die externe GNSS-Ausrüstung (2.
Generation) ist durch „FF 44 54 45 47 4D“ gegeben. Dies ist eine
proprietäre AID gemäß ISO/IEC 7816-4.
Hinweis: Die letzten 5 Bytes kodieren DTEGM für die externe GNSS-
Ausrüstung des intelligenten Fahrtenschreibers.
Die Anwendungskennung für die Fahrtenschreiberanwendung der 2. Ge­
neration ist durch „FF 53 4D 52 44 54“ gegeben. Dies ist eine pro­
prietäre AID gemäß ISO/IEC 7816-4.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 230
Anlage 2
SPEZIFIKATION DER FAHRTENSCHREIBERKARTEN
INHALTSVERZEICHNIS
1. EINLEITUNG
1.1. Abkürzungen
1.2. Referenzdokumente
2. ELEKTRISCHE UND PHYSIKALISCHE EIGENSCHAF­
TEN
2.1. Versorgungsspannung und Stromverbrauch
2.2. Programmierspannung V pp
2.3. Taktversorgung und -frequenz
2.4. E/A-Kontakt
2.5. Kartenzustände
3. HARDWARE UND DATENAUSTAUSCH
3.1. Einleitung
3.2. Übertragungsprotokoll
3.2.1 Protokolle
3.2.2 ATR
3.2.3 PTS
3.3. Zugriffsregeln
3.4. Befehle und Fehlercodes — Übersicht
3.5. Beschreibung der Befehle
3.5.1 SELECT
3.5.2 READ BINARY
3.5.3 UPDATE BINARY
3.5.4 GET CHALLENGE
3.5.5 VERIFY
3.5.6 GET RESPONSE
3.5.7 PSO: VERIFY CERTIFICATE
3.5.8 INTERNAL AUTHENTICATE
3.5.9 EXTERNAL AUTHENTICATE
3.5.10 GENERAL AUTHENTICATE
3.5.11 MANAGE SECURITY ENVIRONMENT
3.5.12 PSO: HASH
3.5.13 PERFORM HASH of FILE
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 231
3.5.14 PSO: COMPUTE DIGITAL SIGNATURE
3.5.15 PSO: VERIFY DIGITAL SIGNATURE
3.5.16 PROCESS DSRC MESSAGE
4. STRUKTUR DER FAHRTENSCHREIBERKARTEN
4.1. Wurzelverzeichnis (MF)
4.2. Fahrerkartenanwendungen
4.2.1 Fahrerkartenanwendung der 1. Generation
4.2.2 Fahrerkartenanwendung der 2. Generation
4.3. Werkstattkartenanwendungen
4.3.1 Werkstattkartenanwendung der 1. Generation
4.3.2 Werkstattkartenanwendung der 2. Generation
4.4. Kontrollkartenanwendungen
4.4.1 Kontrollkartenanwendung der 1. Generation
4.4.2 Kontrollkartenanwendung der 2. Generation
4.5. Unternehmenskartenanwendungen
4.5.1 Unternehmenskartenanwendung der 1. Generation
4.5.2 Unternehmenskartenanwendung der 2. Generation
1. EINLEITUNG
1.1. Abkürzungen
Im Sinne dieser Anlage gelten folgende Abkürzungen.
AC Access conditions (Zugriffsbedingungen)
AES Advanced Encryption Standard
AID Application Identifier (Anwendungskennung)
ALW Always (immer)
APDU Application Protocol Data Unit (Befehlsstruktur)
ATR Aswer To Reset (Antwort auf Zurücksetzen)
AUT Authenticated (authentisiert)
C6, C7 Kontakte Nr. 6 und 7 der Karte laut Beschreibung in
ISO/IEC 7816-2
cc Taktgeberzyklen
▼M1
CHA Certificate Holder Authorisation (Autorisierung des Zerti­
fikatsinhabers)
▼B
CHV Card holder Verification Information (Information zur
Überprüfung des Karteninhabers)
CLA Klassenbyte eines APDU-Befehls
▼M1
DO Datenobjekt
▼B
DSRC Dedicated Short Range Communication (Dedizierte Nah­
bereichskommunikation)
DF Dedicated File (Verzeichnis). Ein DF kann andere Da­
teien enthalten (EF oder DF)
ECC Elliptic Curve Cryptography (Elliptische-Kurven-Krypto­
grafie)
EF Elementary File (Elementardatei)
etu elementary time unit (Elementarzeiteinheit)
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 232
G1 1. Generation
G2 2. Generation
IC Integrated Circuit (Integrierter Schaltkreis)
ICC Integrated Circuit Card (Chipkarte)
ID Identifier (Bezeichner, Kennung)
IFD Interface Device (Schnittstellengerät, Kartenterminal)
IFS Information Field Size (Informationsfeldgröße)
IFSC Informationsfeldgröße der Karte
IFSD Informationsfeldgröße des Schnittstellengeräts, Terminals
INS Befehlsbyte eines APDU-Befehls
Lc Länge der Eingabedaten für einen APDU-Befehl
Le Länge der erwarteten Daten (Ausgabedaten für einen Be­
fehl)
MF Master File (Wurzel-DF)
NAD Knotenadresse, verwendet im Protokoll T=1
NEV Never (nie)
P1-P2 Parameterbytes
PIN Persönliche Geheimzahl (Personal Identification Number)
PRO SM Mit Secure Messaging geschützt
PTS Protocol Transmission Selection (Auswahl der Protokoll­
übertragung)
RFU Reserved for Future Use (für künftige Anwendungen re­
serviert)
RST Zurücksetzen (der Karte)
SFID Kurz-Elementardateikennung
SM Secure Messaging
SW1-SW2 Statusbytes
TS ATR-Anfangszeichen
VPP Programmierspannung
VU Fahrzeugeinheit
XXh Wert XX in Hexadezimalnotation
„XXh“ Wert XX in Hexadezimalnotation
|| Verkettungssymbol 03||04=0304
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 233
1.2. Referenzdokumente
In dieser Anlage werden folgende Referenzdokumente herangezogen:
ISO/IEC 7816-2 Identification cards — Integrated circuit cards —
Part 2: Dimensions and location of the contacts.
ISO/IEC 7816-2:2007.
ISO/IEC 7816-3 Identification cards — Integrated circuit cards —
Part 3: Electrical interface and transmission pro­
tocols. ISO/IEC 7816-3:2006.
ISO/IEC 7816-4 Identification cards — Integrated circuit cards —
Part 4: Organization, security and commands for
interchange. ISO/IEC 7816-4:2013 + Berichtigung
1: 2014.
ISO/IEC 7816-6 Identification cards — Integrated circuit cards —
Part 6: Interindustry data elements for interchange.
ISO/IEC 7816-6:2004 + Cor 1: 2006.
ISO/IEC 7816-8 Identification cards — Integrated circuit cards —
Part 8: Commands for security operations. ISO/IEC
7816-8:2004.
ISO/IEC 9797-2 Information technology — Security techniques —
Message Authentication Codes (MACs) — Part 2:
Mechanisms using a dedicated hash-function. ISO/
IEC 9797-2:2011
2. ELEKTRISCHE UND PHYSIKALISCHE EIGENSCHAFTEN
TCS_01 Sofern nicht anderweitig spezifiziert, erfüllen alle elektro­
nischen Signale die Norm ISO/IEC 7816-3.
TCS_02 Maße und Anordnung der Kartenkontakte erfüllen die
Norm ISO/IEC 7816-2.
2.1. Versorgungsspannung und Stromverbrauch
TCS_03 Die Karte arbeitet gemäß Spezifikation innerhalb der Gren­
zen für die Leistungsaufnahme nach ISO/IEC 7816-3.
TCS_04 Die Karte arbeitet mit Vcc = 3 V (± 0,3 V) oder mit Vcc =
5 V (± 0,5 V).
Die Spannungswahl erfolgt gemäß ISO/IEC 7816-3.
2.2. Programmierspannung V pp
TCS_05 Die Karte benötigt am Kontakt C6 keine Programmierspan­
nung. Es wird davon ausgegangen, dass Kontakt C6 in
einem Schnittstellengerät nicht angeschlossen ist. Der Kon­
takt C6 kann an V cc auf der Karte angeschlossen sein, aber
nicht an Masse. Auf jeden Fall ist diese Spannung nicht zu
interpretieren.
2.3. Taktversorgung und -frequenz
TCS_06 Die Karte arbeitet im Frequenzbereich von 1 bis 5 MHz
und kann unter Umständen höhere Frequenzen unterstützen.
Innerhalb eines Kartenvorgangs darf die Taktfrequenz um
± 2 % schwanken. Die Taktfrequenz wird von der Fahr­
zeugeinheit und nicht von der Karte selbst erzeugt. Für den
Arbeitszyklus ist eine Schwankung zwischen 40 und 60 %
zulässig.
TCS_07 Unter den in der Kartendatei EF ICC enthaltenen Bedin­
gungen kann der externe Taktgeber angehalten werden. Das
erste Byte des Hauptteils der EF ICC-Datei kodiert die
Bedingungen für den Clockstop-Modus:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 234
L-Pegel H-Pegel
Bit 3 Bit 2 Bit 1
0 0 1 Clockstop zulässig, kein Vorzugspegel
0 1 1 Clockstop zulässig, Vorzugspegel: H
1 0 1 Clockstop zulässig, Vorzugspegel: L
0 0 0 Clockstop nicht zulässig
0 1 0 Clockstop nur bei H-Pegel zulässig
1 0 0 Clockstop nur bei L-Pegel zulässig
Bits 4 bis 8 werden nicht genutzt.
2.4. E/A-Kontakt
TCS_08 Der E/A-Kontakt C7 wird für den Empfang von Daten vom
Schnittstellengerät und das Senden von Daten zum Schnitt­
stellengerät verwendet. Während des Betriebs befindet sich
entweder die Karte oder das Schnittstellengerät im Sende­
modus. Sollten sich beide Einheiten im Sendemodus befin­
den, darf die Karte dadurch nicht beschädigt werden. So­
fern die Karte nicht sendet, tritt sie in den Empfangsmodus.
2.5. Kartenzustände
TCS_09 Bei angelegter Versorgungsspannung arbeitet die Karte in
zwei Zuständen:
▼M3
im Betriebszustand während der Ausführung von Befehlen
oder während der Verbindung zur Fahrzeugeinheit,
▼B
im Ruhezustand zu allen anderen Zeiten; in diesem Zustand
bleiben alle Daten auf der Karte erhalten.
3. HARDWARE UND DATENAUSTAUSCH
3.1. Einleitung
Dieser Abschnitt beschreibt die für die Fahrtenschreiberkarten und
Fahrzeugeinheit (VU) erforderliche Mindestfunktionalität, mit der
ein korrekter Betrieb und Interoperabilität gewährleistet werden.
Fahrtenschreiberkarten erfüllen so weit wie möglich die geltenden
ISO/IEC-Normen (insbesondere ISO/IEC 7816). Befehle und Pro­
tokolle werden jedoch vollständig beschrieben, um gegebenenfalls
bestimmte eingeschränkte Verwendungen oder Unterschiede heraus­
zustellen. Die spezifizierten Befehle entsprechen, sofern nicht anders
angegeben, in vollem Umfang den angeführten Normen.
3.2. Übertragungsprotokoll
TCS_10 Das Übertragungsprotokoll entspricht den Festlegungen von
ISO/IEC 7816-3 für T = 0 und T = 1. Insbesondere erkennt
die VU von der Karte gesendete Wartezeitverlängerungen.
3.2.1 Protokolle
TCS_11 Die Karte unterstützt sowohl Protokoll T=0 als auch Pro­
tokoll T=1. Darüber hinaus kann die Karte weitere kontakt­
orientierte Protokolle unterstützen.
TCS_12 T=0 ist das Standardprotokoll; zum Wechsel auf das Pro­
tokoll T=1 ist daher ein PTS-Befehl erforderlich.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 235
TCS_13 Die Geräte unterstützen in beiden Protokollen die „direct
convention“, die somit für die Karte obligatorisch ist.
TCS_14 Das Byte für die Informationsfeldgröße der Karte wird
im ATR im Zeichen TA3 dargestellt. Dieser Wert beträgt
mindestens „F0h“ (= 240 Bytes).
Für die Protokolle gelten die folgenden Einschränkungen:
TCS_15 T=0
— Das Schnittstellengerät unterstützt eine Antwort bei E/A
nach der ansteigenden Flanke des Signals bei RST von
400 cc.
— Das Schnittstellengerät muss Zeichen im Abstand von
12 etu lesen können.
— Das Schnittstellengerät liest ein fehlerhaftes Zeichen
und dessen Wiederholung, wenn der Abstand 13 etu
beträgt. Wird ein fehlerhaftes Zeichen festgestellt,
kann das Fehlersignal bei E/A zwischen 1 etu und 2
etu auftreten. Das Gerät unterstützt eine Verzögerung
von 1 etu.
— Das Schnittstellengerät akzeptiert ein ATR von 33
Bytes (TS+32).
— Befindet sich TC1 im ATR, ist für vom Schnittstellen­
gerät gesendete Zeichen die Extra Guard Time vorhan­
den, obwohl von der Karte gesendete Zeichen weiterhin
mit 12 etu getrennt werden können. Dies gilt auch für
das von der Karte gesendete ACK-Zeichen nach Aus­
sendung eines P3-Zeichens vom Schnittstellengerät.
— Das Schnittstellengerät berücksichtigt ein von der Karte
ausgesendetes NUL-Zeichen.
— Das Schnittstellengerät akzeptiert den Ergänzungs­
modus für ACK.
— Der Befehl GET RESPONSE kann im Verkettungs­
modus nicht zum Einholen von Daten verwendet wer­
den, deren Länge 255 Bytes übersteigen könnte.
TCS_16 T=1
— NAD-Byte: nicht verwendet (NAD ist auf „00“ gesetzt).
— S-Block ABORT: nicht verwendet.
— S-Block VPP-Zustandsfehler: nicht verwendet.
▼M3
__________
▼B
— Die Information Field Size Device (IFSD) wird vom
Schnittstellengerät unmittelbar nach dem ATR ange­
zeigt: Das Schnittstellengerät überträgt die S-Block
IFS-Anforderung nach dem ATR, und die Karte sendet
S-Block IFS zurück. Der empfohlene Wert für IFSD ist
254 Bytes.
— Die Karte fordert keine IFS-Nachkorrektur an.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 236
3.2.2 ATR
TCS_17 Das Gerät überprüft ATR-Bytes gemäß ISO/IEC 7816-3.
Es erfolgt keine Überprüfung von historischen ATR-Zei­
chen.
Beispiel für ein Zweiprotokoll-Basis-ATR gemäß ISO/IEC
7816-3
Zeichen Wert Bemerkungen
TS „3Bh“ Anzeiger für „direct convention“.
T0 „85h“ TD1 vorhanden; 5 historische Bytes vorhanden
TD1 „80h“ TD2 vorhanden; T=0 verwenden
TD2 „11h“ TA3 vorhanden; T=1 verwenden
TA3 „XXh“ (mind. „F0h“) Informationsfeldgröße der Karte (IFSC)
TH1 bis TH5 „XXh“ Historische Zeichen
TCK „XXh“ Prüfzeichen (ohne OR)
TCS_18 Nach der Antwort auf das Zurücksetzen (ATR) wird das
Wurzelverzeichnis (MF) implizit ausgewählt und zum ak­
tuellen Verzeichnis.
3.2.3 PTS
TCS_19 Das Standardprotokoll ist T=0. Zur Einstellung des Pro­
tokolls T=1 muss ein PTS (auch PPS genannt) vom Gerät
gesendet werden.
TCS_20 Da für die Karte beide Protokolle, T=0 und T=1, obliga­
torisch sind, ist das Basis-PTS für die Protokollumschal­
tung ebenfalls obligatorisch.
Wie in ISO/IEC 7816-3 angegeben, kann das PTS zur
Umschaltung auf höhere Übertragungsraten als die von
der Karte im ATR vorgeschlagene Geschwindigkeit ver­
wendet werden (TA(1) Byte).
Höhere Übertragungsraten sind für die Karte fakultativ.
TCS_21 Wird keine andere Übertragungsrate als die Standard­
geschwindigkeit unterstützt (oder wird die ausgewählte
Übertragungsrate nicht unterstützt), antwortet die Karte
auf das PTS korrekt gemäß ISO/IEC 7816-3 durch Weg­
lassen des PPS1-Byte.
Beispiele für ein Basis-PTS zur Protokollwahl:
Zeichen Wert Bemerkungen
PPSS „FFh“ Startzeichen
PPS0 „00h“ oder „01h“ PPS1 bis PPS3 nicht vorhanden; „00h“ zur Auswahl von
T0, „01h“ zur Auswahl von T1.
PK „XXh“ Prüfzeichen: „XXh“ = „FFh“ wenn PPS0 = „00h“,
„XXh“ = „FEh“ wenn PPS0 = „01h“,
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 237
3.3. Zugriffsregeln
TCS_22 Eine Zugriffsregel legt für einen Zugriffsmodus, d. h. Be­
fehl, die zugehörigen Sicherheitsbedingungen fest. Sind
diese Sicherheitsbedingungen erfüllt, wird der entspre­
chende Befehl verarbeitet.
TCS_23 Für die Fahrtenschreiberkarte werden folgende Sicherheits­
bedingungen genutzt:
Abkürzung Bedeutung
ALW Die Aktion ist immer möglich und kann ohne Einschränkung ausgeführt
werden. Befehls- und Antwort-APDU werden als Klartext übermittelt, d. h.
ohne Secure Messaging.
NEV Die Aktion ist nie möglich.
PLAIN-C Die Befehls-APDU werden als Klartext übermittelt, d. h. ohne Secure Mes­
saging.
PWD Die Aktion wird nur ausgeführt, wenn die PIN der Werkstattkarte erfolgreich
verifiziert wurde, d. h. der interne Sicherheitsstatus der Karte auf „PIN_Ve­
rified“ gesetzt ist. Der Befehl muss ohne Secure Messaging übertragen
werden.
EXT-AUT-G1 Die Aktion kann nur ausgeführt werden, wenn der Befehl External Authen­
ticate für die Authentisierung der 1. Generation (siehe auch Anlage 11 Teil A)
erfolgreich ausgeführt wurde.
SM-MAC-G1 Die (Befehls- und Antwort-) APDU muss mit Secure Messaging der 1. Ge­
neration im reinen Authentisierungsmodus angewandt werden (siehe Anlage
11 Teil A).
SM-C-MAC-G1 Die (Befehls-)APDU muss mit Secure Messaging der 1. Generation im reinen
Authentisierungsmodus angewandt werden (siehe Anlage 11 Teil A).
SM-R-ENC-G1 Die Antwort-APDU muss mit Secure Messaging der 1. Generation im Ver­
schlüsselungsmodus angewandt werden (siehe Anlage 11 Teil A), d. h. so,
dass kein Code für die Nachrichtenauthentisierung zurückgesendet wird.
SM-R-ENC-
MAC-G1
Die (Antwort-) APDU muss mit Secure Messaging der 1. Generation im
Verschlüsselungs-dann-Authentisierungsmodus angewandt werden (siehe An­
lage 11 Teil A).
SM-MAC-G2 Die (Befehls- und Antwort-) APDU muss mit Secure Messaging der 2. Ge­
neration im reinen Authentisierungsmodus angewandt werden (siehe Anlage
11 Teil B).
SM-C-MAC-G2 Die (Befehls-) APDU muss mit Secure Messaging der 2. Generation im reinen
Authentisierungsmodus angewandt werden (siehe Anlage 11 Teil B).
SM-R-ENC-
MAC-G2
Die (Antwort-) APDU muss mit Secure Messaging der 2. Generation im
Verschlüsselungs-dann-Authentisierungsmodus angewandt werden (siehe An­
lage 11 Teil B).
▼M1
TCS_24 Diese Sicherheitsbedingungen können folgendermaßen ver­
knü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 verblei­
benden Befehle sind in den folgenden Tabellen beschrie­
ben. 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.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 238
TCS_25 In der Anwendung DF Tachograph der 1. Generation kom­
men folgende Zugriffsregeln zum Einsatz:
▼M1
Befehl Fahrerkarte Werkstattkarte Kontrollkarte
Unternehmens­
karte
External Authenticate
— Zur Authentisierung für die
1. Generation
ALW ALW ALW ALW
— Zur Authentisierung für die
2. Generation
ALW PWD ALW ALW
Internal Authenticate ALW PWD ALW ALW
General Authenticate ALW ALW ALW ALW
Get Challenge ALW ALW ALW ALW
MSE:SET AT ALW ALW ALW ALW
MSE:SET DST ALW ALW ALW ALW
Process DSRC Message Nicht zutref­
fend
Nicht zutref­
fend
Nicht zutref­
fend
Nicht zutref­
fend
PSO: Compute Digital Signature ALW OR
SM-MAC-
G2
ALW OR
SM-MAC-
G2
Nicht zutref­
fend
Nicht zutref­
fend
PSO: Hash Nicht zutref­
fend
Nicht zutref­
fend
ALW Nicht zutref­
fend
PERFORM HASH OF FILE ALW OR
SM-MAC-
G2
ALW OR
SM-MAC-
G2
Nicht zutref­
fend
Nicht zutref­
fend
PSO: Verify Certificate ALW ALW ALW ALW
PSO: Verify Digital Signature Nicht zutref­
fend
Nicht zutref­
fend
ALW Nicht zutref­
fend
Verify Nicht zutref­
fend
ALW Nicht zutref­
fend
Nicht zutref­
fend
▼B
TCS_26 In der Anwendung DF Tachograph der 2. Generation kom­
men folgende Zugriffsregeln zum Einsatz:
▼M1
Befehl Fahrerkarte Werkstattkarte Kontrollkarte
Unternehmens­
karte
External Authenticate
— Zur Authentisierung für die
1. Generation
Nicht zutref­
fend
Nicht zutref­
fend
Nicht zutref­
fend
Nicht zutref­
fend
— Zur Authentisierung für die
2. Generation
ALW PWD ALW ALW
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 239
Befehl Fahrerkarte Werkstattkarte Kontrollkarte
Unternehmens­
karte
Internal Authenticate Nicht zutref­
fend
Nicht zutref­
fend
Nicht zutref­
fend
Nicht zutref­
fend
General Authenticate ALW ALW ALW ALW
Get Challenge ALW ALW ALW ALW
MSE:SET AT ALW ALW ALW ALW
MSE:SET DST ALW ALW ALW ALW
Process DSRC Message Nicht zutref­
fend
ALW ALW Nicht zutref­
fend
PSO: Compute Digital Signature ALW OR
SM-MAC-
G2
ALW OR
SM-MAC-
G2
Nicht zutref­
fend
Nicht zutref­
fend
PSO: Hash Nicht zutref­
fend
Nicht zutref­
fend
ALW Nicht zutref­
fend
PERFORM HASH OF FILE ALW OR
SM-MAC-
G2
ALW OR
SM-MAC-
G2
Nicht zutref­
fend
Nicht zutref­
fend
PSO: Verify Certificate ALW ALW ALW ALW
PSO: Verify Digital Signature Nicht zutref­
fend
Nicht zutref­
fend
ALW Nicht zutref­
fend
Verify Nicht zutref­
fend
ALW Nicht zutref­
fend
Nicht zutref­
fend
▼B
TCS_27 In MF kommen folgende Zugriffsregeln zum Einsatz:
▼M1
Befehl Fahrerkarte Werkstattkarte Kontrollkarte
Unternehmens­
karte
External Authenticate
— Zur Authentisierung für die
1. Generation
Nicht zutref­
fend
Nicht zutref­
fend
Nicht zutref­
fend
Nicht zutref­
fend
— Zur Authentisierung für die
2. Generation
ALW PWD ALW ALW
Internal Authenticate Nicht zutref­
fend
Nicht zutref­
fend
Nicht zutref­
fend
Nicht zutref­
fend
General Authenticate ALW ALW ALW ALW
Get Challenge ALW ALW ALW ALW
MSE:SET AT ALW ALW ALW ALW
MSE:SET DST ALW ALW ALW ALW
▼M1
02016R0799 — DE — 21.08.2023 — 003.002 — 240
Befehl Fahrerkarte Werkstattkarte Kontrollkarte
Unternehmens­
karte
Process DSRC Message Nicht zutref­
fend
Nicht zutref­
fend
Nicht zutref­
fend
Nicht zutref­
fend
PSO: Compute Digital Signature Nicht zutref­
fend
Nicht zutref­
fend
Nicht zutref­
fend
Nicht zutref­
fend
PSO: Hash Nicht zutref­
fend
Nicht zutref­
fend
Nicht zutref­
fend
Nicht zutref­
fend
PERFORM HASH OF FILE Nicht zutref­
fend
Nicht zutref­
fend
Nicht zutref­
fend
Nicht zutref­
fend
PSO: Verify Certificate ALW ALW ALW ALW
PSO: Verify Digital Signature Nicht zutref­
fend
Nicht zutref­
fend
Nicht zutref­
fend
Nicht zutref­
fend
Verify Nicht zutref­
fend
ALW Nicht zutref­
fend
Nicht zutref­
fend
▼B
TCS_28 Eine Fahrtenschreiberkarte kann unter Umständen Befehle
eines Sicherheitsniveaus akzeptieren, das über dem in den
Sicherheitsbedingungen festgelegten Niveau liegt, d. h. bei
den Sicherheitsbedingungen ALW (oder PLAIN-C) kann
die Karte Befehle mit Secure Messaging (Verschlüsselungs-
und/oder Authentisierungsmodus) akzeptieren. Falls die Si­
cherheitsbedingungen Secure Messaging mit Authentisie­
rungsmodus voraussetzen, kann die Fahrtenschreiberkarte
Befehle mit Secure Messaging der gleichen Generation
im Authentisierungs- und Verschlüsselungsmodus akzeptie­
ren.
Hinweis: Die Beschreibung der Befehle liefert weitere In­
formationen zur Unterstützung der Befehle für die verschie­
denen Fahrtenschreiberkartentypen und DF.
3.4. Befehle und Fehlercodes — Übersicht
Befehle und Dateiorganisation sind von der ISO/IEC 7816-4 abge­
leitet und erfüllen diese Norm.
Dieser Abschnitt beschreibt die folgenden APDU-Befehl-Antwort-
Paare. Die durch die Anwendungen der 1. und 2. Generation unter­
stützten Befehlsvarianten sind in der zugehörigen Befehlsbeschreibung
angegeben.
Befehl INS
SELECT „A4h“
READ BINARY „B0h“, „B1h“
UPDATE BINARY „D6h“, „D7h“
GET CHALLENGE „84h“
VERIFY „20h“
GET RESPONSE „C0h“
▼M1
02016R0799 — DE — 21.08.2023 — 003.002 — 241
Befehl INS
PERFORM SECURITY OPERA­
TION
„2Ah“
— VERIFY CERTIFICATE
— COMPUTE DIGITAL SIG­
NATURE
— VERIFY DIGITAL SIG­
NATURE
— HASH
— PERFORM HASH OF FILE
— PROCESS DSRC MESSAGE
INTERNAL AUTHENTICATE „88h“
EXTERNAL AUTHENTICATE „82h“
MANAGE SECURITY ENVIRON­
MENT
„22h“
— SET DIGITAL SIGNATURE
TEMPLATE
— SET AUTHENTICATION TEM­
PLATE
GENERAL AUTHENTICATE „86h“
▼M1
TCS_29 In jeder Antwortnachricht werden die Statusbytes SW1
SW2 zurückgesendet, die den Verarbeitungszustand des
Befehls bezeichnen.
SW1 SW2 Bedeutung
90 00 Normale Verarbeitung
61 XX Normale Verarbeitung XX = Zahl der verfügbaren Antwortbytes
62 81 Verarbeitungswarnung. Ein Teil der zurückgesendeten Daten
kann beschädigt sein.
63 00 Authentisierung fehlgeschlagen (Warnung)
63 CX Falsche CHV (PIN). Zähler für verbleibende Versuche „X“.
64 00 Ausführungsfehler — Zustand des nichtflüchtigen Speichers un­
verändert. Integritätsfehler.
65 00 Ausführungsfehler — Zustand des nichtflüchtigen Speichers ver­
ändert.
65 81 Ausführungsfehler — Zustand des nichtflüchtigen Speichers ver­
ändert – Speicherfehler.
66 88 Sicherheitsfehler: falsche kryptografische Prüfsumme (bei Se­
cure Messaging) oder
falsches Zertifikat (bei Zertifikatsverifizie­
rung) oder
falsches Kryptogramm (bei externer Authenti­
sierung) oder
falsche Signatur (bei Signaturverifizierung)
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 242
SW1 SW2 Bedeutung
67 00 Falsche Länge (falsche Lc oder Le)
68 83 Letzter Befehl der Kette erwartet
69 00 Verbotener Befehl (keine Antwort verfügbar in T=0)
69 82 Sicherheitsstatus nicht erfüllt
69 83 Authentisierungsverfahren blockiert
69 85 Nutzungsbedingungen nicht erfüllt
69 86 Befehl nicht zulässig (keine aktuelle EF)
69 87 Erwartete Secure-Messaging-Datenobjekte fehlen
69 88 Inkorrekte Secure-Messaging-Datenobjekte
6A 80 Falsche Parameter im Datenfeld
6A 82 Datei nicht gefunden
6A 86 Falsche Parameter P1-P2
6A 88 Bezugsdaten nicht gefunden
6B 00 Falsche Parameter (Offset außerhalb der EF)
6C XX Falsche Länge, SW2 gibt die genaue Länge an. Kein Datenfeld
wird zurückgesendet
6D 00 Befehlscode nicht unterstützt oder ungültig
6E 00 Klasse nicht unterstützt
6F 00 — Sonstige Prüffehler
Weitere in ISO/IEC 7816-4 definierte Statusbytes können
zurückgesendet werden, wenn ihr Verhalten in dieser An­
lage 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
▼B
TCS_30 Erfüllt ein einzelner APDU-Befehl mehr als eine Fehler­
bedingung, kann die Karte beliebige der zugehörigen Sta­
tusbytes zurücksenden.
3.5. Beschreibung der Befehle
In diesem Kapitel werden die obligatorischen Befehle für die Fahrten­
schreiberkarten beschrieben.
Weitere sachdienliche Einzelheiten zu kryptografischen Operationen
sind in Anlage 11, Gemeinsame Sicherheitsmechanismen für Fahrten­
schreiber der 1. und 2. Generation, aufgeführt.
Alle Befehle werden unabhängig vom verwendeten Protokoll (T=0
oder T=1) beschrieben. Die APDU-Bytes CLA, INS, P1, P2, Lc
und Le werden immer angegeben. Wird Lc oder Le für den beschrie­
benen Befehl nicht benötigt, bleiben die entsprechende Länge, der
Wert und die Beschreibung leer.
▼M1
02016R0799 — DE — 21.08.2023 — 003.002 — 243
TCS_31 Werden beide Längenbytes (Lc und Le) angefordert, ist der
Befehl in zwei Teile aufzuspalten, wenn das IFD das Pro­
tokoll T=0 verwendet: Das IFD sendet den Befehl wie
beschrieben mit P3=Lc + Daten und sendet dann einen
GET RESPONSE-Befehl (siehe Abschnitt 3.5.6) bei
P3=Le.
TCS_32 Wenn beide Längenbytes angefordert werden und wenn
Le=0 (Secure Messaging) gilt Folgendes:
— Bei Verwendung von Protokoll T=1 antwortet die Karte
auf Le=0 mit dem Senden aller verfügbaren Ausgabe­
daten.
— Bei Verwendung von Protokoll T=0 sendet das IFD den
ersten Befehl mit P3=Lc + Daten und die Karte antwor­
tet auf dieses implizierte Le=0 mit den Statusbytes
„61La“, wobei La die Anzahl der verfügbaren Antwort­
bytes ist. Daraufhin generiert das IFD einen GET
RESPONSE-Befehl mit P3=La zum Lesen der Daten.
TCS_33 Optional kann eine Fahrtenschreiberkarte erweiterte Län­
genfelder gemäß ISO/IEC 7816-4 unterstützen. Eine Fahr­
tenschreiberkarte, die erweiterte Längenfelder unterstützt,
— gibt die Unterstützung erweiterter Längenfelder in der
ATR an
— gibt die unterstützten Puffergrößen durch erweiterte
Längenangabe in der EF ATR/INFO an, siehe TCS_146
— gibt die Unterstützung erweiterter Längenfelder für T =
1 und/oder T = 0 in der EF Extended Length an, siehe
TCS_147
— unterstützt erweiterte Längenfelder für die Fahrten­
schreiberanwendung der 1. und 2. Generation.
Hinweise:
Sämtliche Befehle sind für kurze Längenfelder spezifiziert.
Die Verwendung von APDU erweiterter Länge ergibt sich
aus ISO/IEC 7816-4.
Generell sind die Befehle für den Klarmodus spezifiziert, d.
h. ohne Secure Messaging, da die Secure-Messaging-
Schicht in Anlage 11 beschrieben wird. Aus den Zugriffs­
regeln für einen Befehl ergibt sich, ob der Befehl Secure
Messaging unterstützt und ob sich die Unterstützung auf
Secure Messaging der 1. und/oder 2. Generation bezieht.
Einige Befehlsvarianten werden mit Secure Messaging be­
schrieben, um die Verwendung dieser Funktion zu
veranschaulichen.
TCS_34 Die VU führt für eine Sitzung das gesamte Protokoll zur
gegenseitigen Authentisierung von VU der 2. Generation
und Karte aus, einschließlich (erforderlichenfalls) der Zer­
tifikatsverifizierung entweder im DF Tachograph, dem DF
Tachograph_G2 oder in MF.
3.5.1 SELECT
Dieser Befehl entspricht den Festlegungen von ISO/IEC 7816-4, seine
Verwendung ist jedoch im Vergleich zu dem in der Norm definierten
Befehl eingeschränkt.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 244
Der Befehl SELECT wird verwendet:
— zur Auswahl eines Applikations-DF (Auswahl nach Namen ob­
ligatorisch)
— zur Auswahl einer Elementardatei, die der vorgelegten Datei-ID
entspricht.
3.5.1.1 A u s w a h l n a c h N a m e n ( A I D )
Dieser Befehl ermöglicht die Auswahl eines Applikations-DF auf der
Karte.
TCS_35 Dieser Befehl kann von jeder beliebigen Stelle in der Da­
teistruktur aus ausgeführt werden (nach dem ATR oder
jederzeit).
TCS_36 Bei Auswahl einer Anwendung wird die derzeitige Sicher­
heitsumgebung zurückgesetzt. Nach Auswahl der Anwen­
dung wird kein aktueller öffentlicher Schlüssel mehr aus­
gewählt. Die Zugriffsbedingung EXT-AUT-G1 geht eben­
falls verloren. Wurde der Befehl ohne Secure Messaging
ausgeführt, stehen die früheren Sitzungsschlüssel nicht
mehr für das Secure Messaging zur Verfügung.
TCS_37 Befehlsnachricht
Byte Länge Wert Beschreibung
CLA 1 „00h“
INS 1 „A4h“
P1 1 „04h“ Auswahl nach Namen (AID)
P2 1 „0Ch“ Keine Antwort erwartet
Lc 1 „NNh“ Anzahl der an die Karte gesendeten Bytes (Länge der
AID):
„06h“ für die Fahrtenschreiberanwendung
#6-#(5+NN) NN „XX..XXh“ AID: „FF 54 41 43 48 4F“ für die Fahrtenschreiber­
anwendung der 1. Generation
AID: „FF 53 4D 52 44 54“ für die Fahrtenschreiber­
anwendung der 2. Generation
Es wird keine Antwort auf den Befehl SELECT benötigt
(Le fehlt in T=1 oder keine Antwort angefordert in T=0).
TCS_38 Antwortnachricht (keine Antwort angefordert)
Byte Länge Wert Beschreibung
SW 2 „XXXXh“ Statusbytes (SW1, SW2)
— Ist der Befehl erfolgreich, sendet die Karte „9000“ zu­
rück.
— Wird die der AID entsprechende Anwendung nicht ge­
funden, lautet der zurückgesendete Verarbeitungsstatus
„6A82“.
— Bei Vorhandensein des Byte Le lautet in T=1 der zu­
rückgesendete Status „6700“.
— Wenn nach dem Befehl SELECT eine Antwort ange­
fordert wird, lautet in T=0 der zurückgesendete Status
„6900“.
▼M1
— Wird die ausgewählte Anwendung als verfälscht be­
trachtet (weil in den Dateiattributen ein Integritätsfehler
festgestellt wurde), lautet der zurückgesendete Verarbei­
tungsstatus „6400“ oder „6500“.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 245
3.5.1.2 A u s w a h l e i n e r E l e m e n t a r d a t e i a n h a n d i h r e r D a ­
t e i k e n n u n g
TCS_39 Befehlsnachricht
TCS_40 Die Fahrtenschreiberkarte muss Secure Messaging der 2.
Generation gemäß Anlage 11 Teil B für diese Befehlsvari­
anten unterstützen.
Byte Länge Wert Beschreibung
CLA 1 „00h“
INS 1 „A4h“
P1 1 „02h“ Auswahl einer EF unter dem aktuellen DF
P2 1 „0Ch“ Keine Antwort erwartet
Lc 1 „02h“ Anzahl der an die Karte gesendeten Bytes
#6-#7 2 „XXXXh“ Dateikennung
Es wird keine Antwort auf den Befehl SELECT benötigt
(Le fehlt in T=1 oder keine Antwort angefordert in T=0).
TCS_41 Antwortnachricht (keine Antwort angefordert)
Byte Länge Wert Beschreibung
SW 2 „XXXXh“ Statusbytes (SW1, SW2)
— Ist der Befehl erfolgreich, sendet die Karte „9000“ zu­
rück.
— Wird die der Dateikennung entsprechende Datei nicht
gefunden, lautet der zurückgesendete Verarbeitungssta­
tus „6A82“.
— Bei Vorhandensein des Byte Le lautet in T=1 der zu­
rückgesendete Status „6700“.
— Wenn nach dem Befehl SELECT eine Antwort ange­
fordert wird, lautet in T=0 der zurückgesendete Status
„6900“.
▼M1
— Wird die ausgewählte Datei als verfälscht betrachtet
(weil in den Dateiattributen ein Integritätsfehler fest­
gestellt wurde), lautet der zurückgesendete Verarbei­
tungsstatus „6400“ oder „6500“.
▼B
3.5.2 READ BINARY
Dieser Befehl entspricht den Festlegungen von ISO/IEC 7816-4, seine
Verwendung ist jedoch im Vergleich zu dem in der Norm definierten
Befehl eingeschränkt.
Der Befehl READ BINARY wird zum Auslesen von Daten aus einer
transparenten Datei verwendet.
Die Antwort der Karte besteht im Zurücksenden der gelesenen Daten,
die optional in einer Secure-Messaging-Struktur eingekapselt werden
können.
3.5.2.1 B e f e h l m i t O f f s e t i n P 1 - P 2
Dieser Befehl ermöglicht dem IFD das Lesen von Daten aus der zu
dem entsprechenden Zeitpunkt ausgewählten EF ohne Secure Messa­
ging.
Hinweis: Dieser Befehl ohne Secure Messaging kann nur genutzt
werden, um eine Datei auszulesen, die die ALW-Sicherheitsbedingung
für den Lese-Zugriffsmodus unterstützt.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 246
TCS_42 Befehlsnachricht
Byte Länge Wert Beschreibung
CLA 1 „00h“
INS 1 „B0h“ Read Binary
P1 1 „XXh“ Offset in Bytes vom Dateianfang: höchstwertiges Byte
P2 1 „XXh“ Offset in Bytes vom Dateianfang: niedrigstwertiges Byte
Le 1 „XXh“ Erwartete Datenlänge. Anzahl der zu lesenden Bytes.
Hinweis: Bit 8 von P1 muss auf 0 gesetzt sein.
TCS_43 Antwortnachricht
Byte Länge Wert Beschreibung
#1-#X X „XX..XXh“ Gelesene Daten
SW 2 „XXXXh“ Statusbytes (SW1, SW2)
— Ist der Befehl erfolgreich, sendet die Karte „9000“ zu­
rück.
— Ist keine EF ausgewählt, lautet der zurückgesendete
Verarbeitungsstatus „6986“.
— Sind die Sicherheitsbedingungen der ausgewählten Da­
tei nicht erfüllt, wird der Befehl mit „6982“ abgebro­
chen.
— Ist das Offset nicht mit der Größe der EF kompatibel
(Offset > EF-Größe), lautet der zurückgesendete Ver­
arbeitungsstatus „6B00“.
— Ist die Größe der auszulesenden Daten nicht mit der
Größe der EF kompatibel (Offset + Le > EF-Größe),
lautet der zurückgesendete Verarbeitungsstatus „6700“
oder „6Cxx“, wobei „xx“ die genaue Länge angibt.
▼M1
— Wird in den Dateiattributen ein Integritätsfehler fest­
gestellt, so betrachtet die Karte die Datei als beschädigt
und nicht wieder herstellbar und der zurückgesendete
Verarbeitungsstatus lautet „6400“ oder „6500“.
▼B
— Wird in den gespeicherten Daten ein Integritätsfehler
festgestellt, so gibt die Karte die angeforderten Daten
aus und der zurückgesendete Verarbeitungsstatus lautet
„6281“.
3.5.2.1.1 B e f e h l m i t S e c u r e M e s s a g i n g ( B e i s p i e l e )
Dieser Befehl ermöglicht dem IFD das Lesen von Daten aus der zu
dem entsprechenden Zeitpunkt ausgewählten EF mit Secure Messa­
ging, um die Integrität der empfangenen Daten zu überprüfen und die
Vertraulichkeit der Daten bei als verschlüsselt gekennzeichneter
SM-R-ENC-MAC-G1 (1. Generation) oder SM-R-ENC-MAC-G2 (2.
Generation) zu schützen.
TCS_44 Befehlsnachricht
Byte Länge Wert Beschreibung
CLA 1 „0Ch“ Secure Messaging angefordert
INS 1 „B0h“ Read Binary
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 247
Byte Länge Wert Beschreibung
P1 1 „XXh“ P1 (Offset in Bytes vom Dateianfang): höchstwertiges
Byte
P2 1 „XXh“ P2 (Offset in Bytes vom Dateianfang): niedrigstwertiges
Byte
Lc 1 „XXh“ Länge der Eingabedaten für Secure Messaging
#6 1 „97h“ T LE : Tag zur Spezifikation der erwarteten Länge
#7 1 „01h“ L LE : Erwartete Länge
#8 1 „NNh“ Spezifikation der erwarteten Länge (Original Le): Anzahl
der zu lesenden Bytes
#9 1 „8Eh“ T CC : Tag für kryptografische Prüfsumme
#10 1 „XXh“ L CC : 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. Gene­
ration (siehe Anlage 11 Teil B)
#11-#(10+L) L „XX..XXh“ Kryptografische Prüfsumme
Le 1 „00h“ Gemäß ISO/IEC 7816-4
TCS_45 Antwortnachricht, wenn SM-R-ENC-MAC-G1 (1. Gene­
ration)/SM-R-ENC-MAC-G2 (2. Generation) nicht erfor­
derlich und Secure-Messaging-Eingabeformat korrekt:
▼M1
Byte Länge Wert Beschreibung
#1 1 „81h“ T PV : Tag für Klarwertdaten
#2 L „NNh“ oder
‚81 NNh‘
L PV : Länge der zurückgesendeten Daten
(= Original Le).
L gleich 2 Bytes, wenn L PV > 127 Bytes
#(2+L) - #(1+L+NN) NN „XX..XXh“ Klardatenwert
#(2+L+NN) 1 „99h“ Tag für Verarbeitungsstatus (SW1-SW2) —
optional für Secure Messaging der 1. Gene­
ration
#(3+L+NN) 1 „02h“ Länge des Verarbeitungsstatus — optional
für Secure Messaging der 1. Generation
#(4+L+NN) - #(5+L+NN) 2 „XX XXh“ Verarbeitungsstatus der ungeschützten
APDU-Antwort — optional für Secure Mes­
saging der 1. Generation
#(6+L+NN) 1 „8Eh“ TCC: Tag für kryptografische Prüfsumme
#(7+L+NN) 1 „XXh“ LCC: Länge der folgenden kryptografischen
Prüfsumme
„04h“ für Secure Messaging der 1. Genera­
tion (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 An­
lage 11 Teil B)
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 248
Byte Länge Wert Beschreibung
#(8+L+NN) -
#(7+M+L+NN)
M „XX..XXh“ Kryptografische Prüfsumme
SW 2 „XXXXh“ Statusbytes (SW1, SW2)
▼B
TCS_46 Antwortnachricht, wenn SM-R-ENC-MAC-G1 (1. Gene­
ration)/SM-R-ENC-MAC-G2 (2. Generation) erforder­
lich und Secure-Messaging-Eingabeformat korrekt:
▼M1
Byte Länge Wert Beschreibung
#1 1 „87h“ T PI CG : Tag für verschlüsselte Daten (Kryp­
togramm)
#2 L „MMh“ oder
‚81 MMh‘
L PI CG : Länge der zurückgesendeten ver­
schlüsselten Daten (wegen Auffüllung an­
ders als Original-Le des Befehls).
L gleich 2 Bytes, wenn LPI CG > 127
Bytes.
#(2+L)-#(1+L+MM) MM „01XX..XXh“ Verschlüsselte Daten: Auffüllindikator und
Kryptogramm
#(2+L+MM) 1 „99h“ Tag für Verarbeitungsstatus (SW1-SW2) —
optional für Secure Messaging der 1. Gene­
ration
#(3+L+MM) 1 „02h“ Länge des Verarbeitungsstatus — optional
für Secure Messaging der 1. Generation
#(4+L+MM) - #(5+L+MM) 2 „XX XXh“ Verarbeitungsstatus der ungeschützten
APDU-Antwort – optional für Secure Mes­
saging der 1. Generation
#(6+L+MM) 1 „8Eh“ TCC: Tag für kryptografische Prüfsumme
#(7+L+MM) 1 „XXh“ LCC: Länge der folgenden kryptografischen
Prüfsumme
„04h“ für Secure Messaging der 1. Genera­
tion (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 An­
lage 11 Teil B)
#(8+L+MM) -
#(7+N+L+MM)
N „XX..XXh“ Kryptografische Prüfsumme
SW 2 „XXXXh“ Statusbytes (SW1, SW2)
▼B
Der Befehl READ BINARY kann die regulären Verarbei­
tungszustände, die in TCS_43 unter Tag „99h“ aufgelistet
und in TCS_59 beschrieben sind, mittels Secure-Messa­
ging-Antwortstruktur zurücksenden.
Darüber hinaus können einige Fehler speziell im Zusam­
menhang mit Secure Messaging auftreten. In diesem Fall
wird der Verarbeitungsstatus einfach ohne Secure-Messa­
ging-Struktur zurückgesendet:
▼M1
02016R0799 — DE — 21.08.2023 — 003.002 — 249
TCS_47 Antwortnachricht bei inkorrektem Secure-Messaging-
Eingabeformat
Byte Länge Wert Beschreibung
SW 2 „XXXXh“ Statusbytes (SW1, SW2)
— Ist kein aktueller Sitzungsschlüssel vorhanden, wird der
Verarbeitungsstatus „6A88“ zurückgesendet. Dies ge­
schieht entweder, wenn der Sitzungsschlüssel noch
nicht erzeugt wurde oder wenn seine Gültigkeit abge­
laufen ist (in diesem Fall muss das IFD erneut eine
gegenseitige Authentisierung durchführen, um einen
neuen Sitzungsschlüssel zu setzen).
— Wenn im Secure-Messaging-Format einige erwartete
Datenobjekte (siehe oben) fehlen, wird der Verarbei­
tungsstatus „6987“ zurückgesendet. Dieser Fehler tritt
auf, wenn ein erwartetes Tag fehlt oder wenn der Be­
fehlskörper nicht den Anforderungen entsprechend auf­
gebaut ist.
— Sind Datenobjekte nicht korrekt, lautet der zurück­
gesendete Verarbeitungsstatus „6988“. Dieser Fehler
tritt auf, wenn zwar alle benötigten Tags vorhanden
sind, einige Längen sich jedoch von den erwarteten
unterscheiden.
— Schlägt die Überprüfung der kryptografischen Prüf­
summe fehl, lautet der zurückgesendete Verarbeitungs­
status „6688“.
3.5.2.2 B e f e h l m i t K u r z - E l e m e n t a r d a t e i k e n n u n g
Mit dieser Befehlsvariante kann das IFD eine EF mithilfe einer
Kurz-Elementardateikennung auswählen und Daten aus dieser EF
lesen.
TCS_48 Eine Fahrtenschreiberkarte unterstützt diese Befehlsvariante
für alle Elementardateien mit angegebener Kurz-Elementar­
dateikennung. Diese Kurz-Elementardateikennungen sind in
Kapitel 4 angegeben.
TCS_49 Befehlsnachricht
Byte Länge Wert Beschreibung
CLA 1 „00h“
INS 1 „B0h“ Read Binary
P1 1 „XXh“ Bit 8 auf 1 gesetzt
Bit 7 und 6 auf 00 gesetzt
Bit 5 — 1 kodieren die Kurz-Elementardateikennung der
entsprechenden EF
P2 1 „XXh“ Kodiert ein Offset von 0 bis 255 Bytes in der durch P1
angegebenen EF
Le 1 „XXh“ Erwartete Datenlänge. Anzahl der zu lesenden Bytes.
Hinweis: Die für die Fahrtenschreiberanwendung der 2.
Generation verwendeten Kurz-Elementardateikennungen
sind in Kapitel 4 angegeben.
Wenn P1 eine Kurz-Elementardateikennung kodiert und der
Befehl erfolgreich ist, wird die angegebene EF zur derzeit
ausgewählten EF (aktuelle EF).
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 250
TCS_50 Antwortnachricht
Byte Länge Wert Beschreibung
#1-#L L „XX..XXh“ Gelesene Daten
SW 2 „XXXXh“ Statusbytes (SW1, SW2)
— Ist der Befehl erfolgreich, sendet die Karte „9000“ zu­
rück.
— Wird die der Kurz-Elementardateikennung entspre­
chende Datei nicht gefunden, lautet der zurückgesen­
dete Verarbeitungsstatus „6A82“.
— Sind die Sicherheitsbedingungen der ausgewählten Da­
teien nicht erfüllt, wird der Befehl mit „6982“
abgebrochen.
— Ist das Offset nicht mit der Größe der EF kompatibel
(Offset > EF-Größe), lautet der zurückgesendete Ver­
arbeitungsstatus „6B00“.
— Ist die Größe der auszulesenden Daten nicht mit der
Größe der EF kompatibel (Offset + Le > EF-Größe),
lautet der zurückgesendete Verarbeitungsstatus „6700“
oder „6Cxx“, wobei „xx“ die genaue Länge angibt.
▼M1
— Wird in den Dateiattributen ein Integritätsfehler fest­
gestellt, so betrachtet die Karte die Datei als beschädigt
und nicht wieder herstellbar und der zurückgesendete
Verarbeitungsstatus lautet „6400“ oder „6500“.
▼B
— Wird in den gespeicherten Daten ein Integritätsfehler
festgestellt, so gibt die Karte die angeforderten Daten
aus und der zurückgesendete Verarbeitungsstatus lautet
„6281“.
3.5.2.3 B e f e h l m i t u n g e r a d e m B e f e h l s b y t e
Mit dieser Befehlsvariante kann das IFD Daten aus einer EF mit
32 768 Bytes oder mehr lesen.
TCS_51 Eine Fahrtenschreiberkarte, die EF mit 32 768 Bytes oder
mehr unterstützt, unterstützt diese Befehlsvariante für diese
EF. Eine Fahrtenschreiberkarte kann diese Befehlsvariante
ggf. für andere EF unterstützen, ausgenommen die EF Sen­
sor_Installation_Data (siehe TCS_156 und TCS_160).
TCS_52 Befehlsnachricht
Byte Länge Wert Beschreibung
CLA 1 „00h“
INS 1 „B1h“ Read Binary
P1 1 „00h“ Aktuelle EF
P2 1 „00h“
Lc 1 „NNh“ Lc = Länge des Datenobjekts „offset“.
#6-#(5+NN) NN „XX..XXh“ Datenobjekt „offset“:
Tag „54h“
Länge „01h“ oder „02h“
Wert offset
▼M1
Le 1 ‚XXh‘ Gemäß ISO/IEC 7816-4
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 251
Das IFD kodiert die Länge des Datenobjekts „offset“ mit
einer minimal möglichen Anzahl an Oktetten, d. h. bei der
Verwendung des Längenbytes „01h“ kodiert das IFD ein
Offset zwischen 0 und 255 und bei der Verwendung des
Längenbytes „02h“ ein Offset zwischen 256 und 65 535
Bytes.
▼M1
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‘.
▼B
TCS_53 Antwortnachricht
Byte Länge Wert Beschreibung
#1-#L L „XX..XXh“ Lesen von Daten, die in einem beliebigen Datenobjekt
mit Tag „53h“ eingekapselt sind.
SW 2 „XXXXh“ Statusbytes (SW1, SW2)
— Ist der Befehl erfolgreich, sendet die Karte „9000“ zu­
rück.
— Ist keine EF ausgewählt, lautet der zurückgesendete
Verarbeitungsstatus „6986“.
— Sind die Sicherheitsbedingungen der ausgewählten Da­
teien nicht erfüllt, wird der Befehl mit „6982“
abgebrochen.
— Ist das Offset nicht mit der Größe der EF kompatibel
(Offset > EF-Größe), lautet der zurückgesendete Ver­
arbeitungsstatus „6B00“.
— Ist die Größe der auszulesenden Daten nicht mit der
Größe der EF kompatibel (Offset + Le > EF-Größe),
lautet der zurückgesendete Verarbeitungsstatus „6700“
oder „6Cxx“, wobei „xx“ die genaue Länge angibt.
▼M1
— Wird in den Dateiattributen ein Integritätsfehler fest­
gestellt, so betrachtet die Karte die Datei als beschädigt
und nicht wieder herstellbar und der zurückgesendete
Verarbeitungsstatus lautet ‚6400‘ oder ‚6500‘.
▼B
— Wird in den gespeicherten Daten ein Integritätsfehler
festgestellt, so gibt die Karte die angeforderten Daten
aus und der zurückgesendete Verarbeitungsstatus lautet
„6281“.
3.5.2.3.1 B e f e h l m i t S e c u r e M e s s a g i n g ( B e i s p i e l )
Im folgenden Beispiel wird die Verwendung von Secure Messaging
dargestellt, wenn die Sicherheitsbedingung SM-MAC-G2 gilt.
TCS_54 Befehlsnachricht
Byte Länge Wert Beschreibung
CLA 1 „0Ch“ Secure Messaging angefordert
INS 1 „B1h“ Read Binary
P1 1 „00h“ Aktuelle EF
P2 1 „00h“
Lc 1 „XXh“ Länge des gesicherten Datenfelds
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 252
Byte Länge Wert Beschreibung
#6 1 „B3h“ Tag für in BER-TLV kodierte Klarwertdaten
#7 1 „NNh“ L PV : Länge der übermittelten Daten
#(8)-#(7+NN) NN „XX..XXh“ In BER-TLV kodierte Klardaten, d. h. das Datenobjekt
„offset“ mit Tag „54“
#(8+NN) 1 „97h“ T LE : Tag zur Spezifikation der erwarteten Länge
#(9+NN) 1 „01h“ L LE : Erwartete Länge
#(10+NN) 1 „XXh“ Spezifikation der erwarteten Länge (Original Le): Anzahl
der zu lesenden Bytes
#(11+NN) 1 „8Eh“ T CC : Tag für kryptografische Prüfsumme
#(12+NN) 1 „XXh“ L CC : Länge der folgenden kryptografischen Prüfsumme
„08h“, „0Ch“ oder „10h“ in Abhängigkeit von der
AES-Schlüssellänge für Secure Messaging der 2. Gene­
ration (siehe Anlage 11 Teil B)
#(13+NN)-
#(12+M+NN)
M „XX..XXh“ Kryptografische Prüfsumme
Le 1 „00h“ Gemäß ISO/IEC 7816-4
TCS_55 Antwortnachricht bei erfolgreichem Befehl
Byte Länge Wert Beschreibung
#1 1 „B3h“ In BER-TLV kodierte Klarwertdaten
#2 L „NNh“ oder
„81 NNh“
L PV : Länge der zurückgesendeten Daten (= Original Le).
L gleich 2 Bytes, wenn L PV > 127 Bytes
#(2+L)-
#(1+L+NN)
NN „XX..XXh“ In BER-TLV kodierter Klarwertdaten, d. h. Lesen von
Daten, die in einem beliebigen Datenobjekt mit Tag
„53h“ eingekapselt sind.
#(2+L+NN) 1 „99h“ Verarbeitungsstatus der ungeschützten APDU-Antwort
#(3+L+NN) 1 „02h“ Länge des Verarbeitungsstatus
#(4+L+NN) —
#(5+L+NN)
2 „XX XXh“ Verarbeitungsstatus der ungeschützten APDU-Antwort
#(6+L+NN) 1 „8Eh“ T CC : Tag für kryptografische Prüfsumme
#(7+L+NN) 1 „XXh“ L CC : Länge der folgenden kryptografischen Prüfsumme
„08h“, „0Ch“ oder „10h“ in Abhängigkeit von der
AES-Schlüssellänge für Secure Messaging der 2. Gene­
ration (siehe Anlage 11 Teil B)
#(8+L+NN)-
#(7+M+L+
NN)
M „XX..XXh“ Kryptografische Prüfsumme
SW 2 „XXXXh“ Statusbytes (SW1, SW2)
3.5.3 UPDATE BINARY
Dieser Befehl entspricht den Festlegungen von ISO/IEC 7816-4, seine
Verwendung ist jedoch im Vergleich zu dem in der Norm definierten
Befehl eingeschränkt.
Die Befehlsnachricht UPDATE BINARY initiiert die Aktualisierung
(erase + write) der bereits in einer EF-Binärzahl vorhandenen Bits mit
den im APDU-Befehl gegebenen Bits.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 253
3.5.3.1 B e f e h l m i t O f f s e t i n P 1 - P 2
Dieser Befehl ermöglicht dem IFD das Schreiben von Daten in die zu
dem entsprechenden Zeitpunkt ausgewählte EF, ohne dass die Karte
die Integrität der empfangenen Daten überprüft.
Hinweis: Dieser Befehl ohne Secure Messaging kann nur genutzt
werden, um eine Datei zu aktualisieren, die die ALW-Sicherheits­
bedingung für den Aktualisierungs-Zugriffsmodus unterstützt.
TCS_56 Befehlsnachricht
Byte Länge Wert Beschreibung
CLA 1 „00h“
INS 1 „D6h“ Update Binary
P1 1 „XXh“ Offset in Bytes vom Dateianfang: höchstwertiges Byte
P2 1 „XXh“ Offset in Bytes vom Dateianfang: niedrigstwertiges Byte
Lc 1 „NNh“ Lc = Länge des zu aktualisierenden Datenobjekts. An­
zahl der zu schreibenden Bytes
#6-#(5+NN) NN „XX..XXh“ Zu schreibende Daten
Hinweis: Bit 8 von P1 muss auf 0 gesetzt sein.
TCS_57 Antwortnachricht
Byte Länge Wert Beschreibung
SW 2 „XXXXh“ Statusbytes (SW1, SW2)
— Ist der Befehl erfolgreich, sendet die Karte „9000“ zu­
rück.
— Ist keine EF ausgewählt, lautet der zurückgesendete
Verarbeitungsstatus „6986“.
— Sind die Sicherheitsbedingungen der ausgewählten Da­
teien nicht erfüllt, wird der Befehl mit „6982“
abgebrochen.
— Ist das Offset nicht mit der Größe der EF kompatibel
(Offset > EF-Größe), lautet der zurückgesendete Ver­
arbeitungsstatus „6B00“.
— Ist die Größe der zu schreibenden Daten nicht mit der
Größe der EF kompatibel (Offset + Le > EF-Größe),
lautet der zurückgesendete Verarbeitungsstatus „6700“.
— Wird in den Dateiattributen ein Integritätsfehler fest­
gestellt, so betrachtet die Karte die Datei als beschädigt
und nicht wiederherstellbar und der zurückgesendete
Verarbeitungsstatus lautet „6400“ oder „6500“.
— Schlägt der Schreibvorgang fehl, so lautet der zurück­
gesendete Verarbeitungsstatus „6581“.
3.5.3.1.1 B e f e h l m i t S e c u r e M e s s a g i n g ( B e i s p i e l e )
Dieser Befehl ermöglicht dem IFD das Schreiben von Daten in die zu
dem entsprechenden Zeitpunkt ausgewählte EF, wobei die Karte die
Integrität der empfangenen Daten überprüft. Da keine Vertraulichkeit
erforderlich ist, werden die Daten nicht verschlüsselt.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 254
TCS_58 Befehlsnachricht
Byte Länge Wert Beschreibung
CLA 1 „0Ch“ Secure Messaging angefordert
INS 1 „D6h“ Update Binary
P1 1 „XXh“ Offset in Bytes vom Dateianfang:
höchstwertiges Byte
P2 1 „XXh“ Offset in Bytes vom Dateianfang:
niedrigstwertiges Byte
Lc 1 „XXh“ Länge des gesicherten Datenfelds
#6 1 „81h“ T PV : Tag für Klarwertdaten
#7 L „NNh“ oder
„81 NNh“
L PV : Länge der übermittelten Daten.
L gleich 2 Bytes, wenn L PV > 127 Bytes
#(7+L)-
#(6+L+NN)
NN „XX..XXh“ Klardatenwert (zu schreibende Daten)
#(7+L+NN) 1 „8Eh“ T CC : Tag für kryptografische Prüfsumme
#(8+L+NN) 1 „XXh“ L CC : 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. Gene­
ration (siehe Anlage 11 Teil B)
#(9+L+NN)-
#(8+M+L+
NN)
M „XX..XXh“ Kryptografische Prüfsumme
Le 1 „00h“ Gemäß ISO/IEC 7816-4
TCS_59 Antwortnachricht bei korrektem Secure-Messaging-Ein­
gabeformat
Byte Länge Wert Beschreibung
#1 1 „99h“ T SW : Tag für Statusbytes (durch CC zu schützen)
#2 1 „02h“ L SW : Länge der zurückgesendeten Statusbytes
#3-#4 2 „XXXXh“ Verarbeitungsstatus der ungeschützten APDU-Antwort
#5 1 „8Eh“ T CC : Tag für kryptografische Prüfsumme
#6 1 „XXh“ L CC : 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. Gene­
ration (siehe Anlage 11 Teil B)
#7-#(6+L) L „XX..XXh“ Kryptografische Prüfsumme
SW 2 „XXXXh“ Statusbytes (SW1, SW2)
Die für den Befehl UPDATE BINARY ohne Secure Mes­
saging beschriebenen „regulären“ Verarbeitungszustände
(siehe Abschnitt 3.5.3.1) können unter Verwendung der
oben aufgeführten Antwortnachrichtstrukturen zurückgesen­
det werden.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 255
Darüber hinaus können einige Fehler speziell im Zusam­
menhang mit Secure Messaging auftreten. In diesem Fall
wird der Verarbeitungsstatus einfach ohne Secure-Messa­
ging-Struktur zurückgesendet:
TCS_60 Antwortnachricht bei Fehler im Secure Messaging
Byte Länge Wert Beschreibung
SW 2 „XXXXh“ Statusbytes (SW1, SW2)
— Ist kein aktueller Sitzungsschlüssel vorhanden, wird der
Verarbeitungsstatus „6A88“ zurückgesendet.
— Wenn im Secure-Messaging-Format einige erwartete
Datenobjekte (siehe oben) fehlen, wird der Verarbei­
tungsstatus „6987“ zurückgesendet. Dieser Fehler tritt
auf, wenn ein erwartetes Tag fehlt oder wenn der Be­
fehlskörper nicht den Anforderungen entsprechend auf­
gebaut ist.
— Sind Datenobjekte nicht korrekt, lautet der zurück­
gesendete Verarbeitungsstatus „6988“. Dieser Fehler
tritt auf, wenn zwar alle benötigten Tags vorhanden
sind, einige Längen sich jedoch von den erwarteten
unterscheiden.
— Schlägt die Überprüfung der kryptografischen Prüf­
summe fehl, lautet der zurückgesendete Verarbeitungs­
status „6688“.
3.5.3.2 B e f e h l m i t K u r z - E l e m e n t a r d a t e i k e n n u n g
Mit dieser Befehlsvariante kann das IFD eine EF mithilfe einer
Kurz-Elementardateikennung auswählen und Daten aus dieser EF
schreiben.
TCS_61 Eine Fahrtenschreiberkarte sollte die Befehlsvariante für
alle Elementardateien mit angegebener Kurz-Elementarda­
teikennung unterstützen. Diese Kurz-Elementardateikennun­
gen sind in Kapitel 4 angegeben.
TCS_62 Befehlsnachricht
Byte Länge Wert Beschreibung
CLA 1 „00h“
INS 1 „D6h“ Update Binary
P1 1 „XXh“ Bit 8 auf 1 gesetzt
Bit 7 und 6 auf 00 gesetzt
Bit 5 — 1 kodieren die Kurz-Elementardateikennung der
entsprechenden EF
P2 1 „XXh“ Kodiert ein Offset von 0 bis 255 Bytes in der durch P1
angegebenen EF
Lc 1 „NNh“ Lc = Länge der zu aktualisierenden Daten. Anzahl der zu
schreibenden Bytes
#6-#(5+NN) NN „XX..XXh“ Zu schreibende Daten
TCS_63 Antwortnachricht
Byte Länge Wert Beschreibung
SW 2 „XXXXh“ Statusbytes (SW1, SW2)
Hinweis: Die für die Fahrtenschreiberanwendung der 2.
Generation verwendeten Kurz-Elementardateikennungen
sind in Kapitel 4 angegeben.
Wenn P1 eine Kurz-Elementardateikennung kodiert und der
Befehl erfolgreich ist, wird die angegebene EF zur derzeit
ausgewählten EF (aktuelle EF).
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 256
— Ist der Befehl erfolgreich, sendet die Karte „9000“ zu­
rück.
— Wird die der Kurz-Elementardateikennung entspre­
chende Datei nicht gefunden, lautet der zurückgesen­
dete Verarbeitungsstatus „6A82“.
— Sind die Sicherheitsbedingungen der ausgewählten Da­
teien nicht erfüllt, wird der Befehl mit „6982“
abgebrochen.
— Ist das Offset nicht mit der Größe der EF kompatibel
(Offset > EF-Größe), lautet der zurückgesendete Ver­
arbeitungsstatus „6B00“.
— Ist die Größe der zu schreibenden Daten nicht mit der
Größe der EF kompatibel (Offset + Le > EF-Größe),
lautet der zurückgesendete Verarbeitungsstatus „6700“.
▼M1
— Wird in den Dateiattributen ein Integritätsfehler fest­
gestellt, so betrachtet die Karte die Datei als beschädigt
und nicht wieder herstellbar und der zurückgesendete
Verarbeitungsstatus lautet ‚6400‘ oder ‚6500‘.
▼B
— Schlägt der Schreibvorgang fehl, so lautet der zurück­
gesendete Verarbeitungsstatus „6581“.
3.5.3.3 B e f e h l m i t u n g e r a d e m B e f e h l s b y t e
Mit dieser Befehlsvariante kann das IFD Daten in eine EF mit 32 768
Bytes oder mehr schreiben.
TCS_64 Eine Fahrtenschreiberkarte, die EF mit 32 768 Bytes oder
mehr unterstützt, unterstützt diese Befehlsvariante für diese
EF. Eine Fahrtenschreiberkarte kann diese Befehlsvariante
für andere EF ggf. unterstützen.
TCS_65 Befehlsnachricht
Byte Länge Wert Beschreibung
CLA 1 „00h“
INS 1 „D7h“ Update Binary
P1 1 „00h“ Aktuelle EF
P2 1 „00h“
Lc 1 „NNh“ Lc Länge der Daten im Befehlsdatenfeld
#6-#(5+NN) NN „XX..XXh“ Datenobjekt „offset“ mit Tag „54h“ || Beliebiges Daten­
objekt mit Tag „53h“, das die zu schreibenden Daten
einkapselt
Das IFD kodiert die Länge des Datenobjekts „offset“ und
des beliebigen Datenobjekts mit einer minimal möglichen
Anzahl an Oktetten, d. h. bei der Verwendung des Längen­
bytes „01h“ kodiert das IFD ein Offset/eine Länge zwi­
schen 0 und 255 und bei der Verwendung des Längenbytes
„02h“ ein Offset/eine Länge zwischen 256 und 65 535
Bytes.
TCS_66 Antwortnachricht
Byte Länge Wert Beschreibung
SW 2 „XXXXh“ Statusbytes (SW1, SW2)
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 257
— Ist der Befehl erfolgreich, sendet die Karte „9000“ zu­
rück.
— Ist keine EF ausgewählt, lautet der zurückgesendete
Verarbeitungsstatus „6986“.
— Sind die Sicherheitsbedingungen der ausgewählten Da­
teien nicht erfüllt, wird der Befehl mit „6982“
abgebrochen.
— Ist das Offset nicht mit der Größe der EF kompatibel
(Offset > EF-Größe), lautet der zurückgesendete Ver­
arbeitungsstatus „6B00“.
— Ist die Größe der zu schreibenden Daten nicht mit der
Größe der EF kompatibel (Offset + Le > EF-Größe),
lautet der zurückgesendete Verarbeitungsstatus „6700“.
— Wird in den Dateiattributen ein Integritätsfehler fest­
gestellt, so betrachtet die Karte die Datei als beschädigt
und nicht wiederherstellbar und der zurückgesendete
Verarbeitungsstatus lautet ‚6400‘ oder ‚6500‘.
— Schlägt der Schreibvorgang fehl, so lautet der zurück­
gesendete Verarbeitungsstatus ‚6581‘.
3.5.3.3.1 B e f e h l m i t S e c u r e M e s s a g i n g ( B e i s p i e l )
Im folgenden Beispiel wird die Verwendung von Secure Messaging
dargestellt, wenn die Sicherheitsbedingung SM-MAC-G2 gilt.
TCS_67 Befehlsnachricht
Byte Länge Wert Beschreibung
CLA 1 „0Ch“ Secure Messaging angefordert
INS 1 „D7h“ Update Binary
P1 1 „00h“ Aktuelle EF
P2 1 „00h“
Lc 1 „XXh“ Länge des gesicherten Datenfelds
#6 1 „B3h“ Tag für in BER-TLV kodierte Klarwertdaten
#7 L „NNh“ oder
„81 NNh“
L PV : Länge der übermittelten Daten.
L gleich 2 Bytes, wenn L PV > 127 Bytes
#(7+L)-
#(6+L+NN)
NN „XX..XXh“ In BER-TLV kodierte Klardaten, d. h. Datenobjekt „off­
set“ mit Tag „54h“ || Beliebiges Datenobjekt mit Tag
„53h“, das die zu schreibenden Daten einkapselt
#(7+L+NN) 1 „8Eh“ T CC : Tag für kryptografische Prüfsumme
#(8+L+NN) 1 „XXh“ L CC : Länge der folgenden kryptografischen Prüfsumme
„08h“, „0Ch“ oder „10h“ in Abhängigkeit von der
AES-Schlüssellänge für Secure Messaging der 2. Gene­
ration (siehe Anlage 11 Teil B)
#(9+L+NN)-
#(8+M+L+
NN)
M „XX..XXh“ Kryptografische Prüfsumme
Le 1 „00h“ Gemäß ISO/IEC 7816-4
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 258
TCS_68 Antwortnachricht bei erfolgreichem Befehl
Byte Länge Wert Beschreibung
#1 1 „99h“ T SW : Tag für Statusbytes (durch CC zu schützen)
#2 1 „02h“ L SW : Länge der zurückgesendeten Statusbytes
#3-#4 2 „XXXXh“ Verarbeitungsstatus der ungeschützten APDU-Antwort
#5 1 „8Eh“ T CC : Tag für kryptografische Prüfsumme
#6 1 „XXh“ L CC : Länge der folgenden kryptografischen Prüfsumme
„08h“, „0Ch“ oder „10h“ in Abhängigkeit von der
AES-Schlüssellänge für Secure Messaging der 2. Gene­
ration (siehe Anlage 11 Teil B)
#7-#(6+L) L „XX..XXh“ Kryptografische Prüfsumme
SW 2 „XXXXh“ Statusbytes (SW1, SW2)
3.5.4 GET CHALLENGE
Dieser Befehl entspricht den Festlegungen von ISO/IEC 7816-4, seine
Verwendung ist jedoch im Vergleich zu dem in der Norm definierten
Befehl eingeschränkt.
Der Befehl GET CHALLENGE fordert die Karte zur Ausgabe einer
Zufallszahl aus, damit diese in einem sicherheitsbezogenen Verfahren
verwendet werden kann, bei dem ein Kryptogramm oder chiffrierte
Daten an die Karte gesendet werden.
TCS_69 Die von der Karte ausgegebene Zufallszahl ist nur für den
nächsten Befehl gültig, der eine an die Karte gesendete
Zufallszahl verwendet.
TCS_70 Befehlsnachricht
Byte Länge Wert Beschreibung
CLA 1 „00h“
INS 1 „84h“ INS
P1 1 „00h“ P1
P2 1 „00h“ P2
Le 1 „08h“ Le (Länge der erwarteten Zufallszahl).
TCS_71 Antwortnachricht
Byte Länge Wert Beschreibung
#1-#8 8 „XX..XXh“ Zufallszahl
SW 2 „XXXXh“ Statusbytes (SW1, SW2)
— Ist der Befehl erfolgreich, sendet die Karte „9000“ zu­
rück.
— Unterscheidet sich Le von „08h“, ist der Verarbeitungs­
status „6700“.
— Sind die Parameter P1-P2 inkorrekt, ist der Verarbei­
tungsstatus „6A86“.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 259
3.5.5 VERIFY
Dieser Befehl entspricht den Festlegungen von ISO/IEC 7816-4, seine
Verwendung ist jedoch im Vergleich zu dem in der Norm definierten
Befehl eingeschränkt.
Nur die Werkstattkarte muss diesen Befehl unterstützen.
Andere Arten von Fahrtenschreiberkarten können diesen Befehl ggf.
unterstützen; für diese Karten wird allerdings keine Bezugs-CHV per­
sonalisiert. Aus diesem Grund können diese Karten diesen Befehl
nicht erfolgreich ausführen. Für andere Arten von Fahrtenschreiber­
karten als Werkstattkarten ist dieses Verhalten, d. h. der zurückgesen­
dete Fehlercode, beim Senden dieses Befehls nicht erforderlich.
Der Befehl Verify leitet auf der Karte den Vergleich der vom Befehl
gesendeten CHV (PIN)-Daten mit der auf der Karte gespeicherten
Bezugs-CHV ein.
▼M1
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).
▼B
TCS_73 Die Fahrtenschreiberanwendungen der 1. und 2. Generation
verwenden die gleiche Bezugs-CHV.
TCS_74 Die Fahrtenschreiberkarte überprüft, ob der Befehl richtig
kodiert ist. Wenn der Befehl nicht richtig kodiert ist, darf
die Karte die CHV-Werte nicht vergleichen, den Zähler für
die verbleibenden CHV-Versuche nicht herabsetzen und
den Sicherheitsstatus „PIN_Verified“ nicht zurücksetzen,
sondern muss den Befehl abbrechen. Ein Befehl ist richtig
kodiert, wenn die Bytes CLA, INS, P1, P2, Lc die ange­
gebenen Werte aufweisen, Le nicht vorhanden ist und das
Befehlsdatenfeld die richtige Länge aufweist.
TCS_75 Ist der Befehl erfolgreich, wird der Zähler für die verblei­
benden CHV-Versuche reinitialisiert. Der Anfangswert des
Zählers für die verbleibenden CHV-Versuche ist 5. Ist der
Befehl erfolgreich, setzt die Karte den internen Sicherheits­
status auf „PIN_Verified“. Die Karte diesen Sicherheitssta­
tus zurücksetzen, wenn die Karte zurückgesetzt ist oder der
im Befehl übertragene CHV-Code nicht mit dem gespei­
cherten Bezugs-CHV übereinstimmt.
Hinweis: Durch die Verwendung des gleichen Bezugs-
CHV und eines globalen Sicherheitsstatus wird verhindert,
dass ein Mitarbeiter der Werkstatt nach Auswahl eines an­
deren Fahrtenschreiberanwendung-DF die PIN neu einge­
ben muss.
TCS_76 Ein fehlgeschlagener Vergleich wird auf der Karte gespei­
chert, d. h., dass der Zähler für die verbleibenden CHV-
Versuche um eins herabgesetzt wird, um die Anzahl wei­
terer Versuche, die Bezugs-CHV zu verwenden, zu
begrenzen.
TCS_77 Befehlsnachricht
Byte Länge Wert Beschreibung
CLA 1 „00h“
INS 1 „20h“ INS
P1 1 „00h“ P1
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 260
Byte Länge Wert Beschreibung
P2 1 „00h“ P2 (die verifizierte CHV ist implizit bekannt)
Lc 1 „08h“ Länge des übermittelten CHV-Codes
#6-#13 8 „XX..XXh“ CHV
TCS_78 Antwortnachricht
Byte Länge Wert Beschreibung
SW 2 „XXXXh“ Statusbytes (SW1, SW2)
— Ist der Befehl erfolgreich, sendet die Karte „9000“ zu­
rück.
— Wird die Bezugs-CHV nicht gefunden, lautet der zu­
rückgesendete Verarbeitungsstatus „6A88“.
— Ist die CHV blockiert (der Zähler für verbleibende Ver­
suche steht auf null), lautet der zurückgesendete Ver­
arbeitungsstatus „6983“. Wenn dieser Zustand erreicht
ist, kann die CHV nie wieder erfolgreich präsentiert
werden.
— Ist der Vergleich erfolglos, wird der Zähler für die ver­
bleibenden Versuche herabgesetzt und der Status
„63CX“ zurückgesendet (X > 0, und X ist gleich
dem Zähler für verbleibende CHV-Versuche.
— Wird die Bezugs-CHV als verfälscht betrachtet, lautet
der zurückgesendete Verarbeitungsstatus „6400“ oder
„6581“.
— Unterscheidet sich Lc von „08h“, ist der Verarbeitungs­
status „6700“.
3.5.6 GET RESPONSE
Dieser Befehl entspricht den Festlegungen von ISO/IEC 7816-4.
Dieser (nur für das Protokoll T=0 notwendige und verfügbare) Befehl
wird zur Übertragung vorbereiteter Daten von der Karte zum Schnitt­
stellengerät verwendet (wenn ein Befehl sowohl Lc als auch Le ent­
halten hat).
Der Befehl GET RESPONSE muss sofort nach dem Befehl zur Vor­
bereitung der Daten ausgegeben werden, sonst gehen die Daten ver­
loren. Nach der Ausführung des Befehls GET RESPONSE (außer bei
Auftreten der Fehler „61xx“ oder „6Cxx“, siehe unten) stehen die
zuvor vorbereiteten Daten nicht mehr zur Verfügung.
TCS_79 Befehlsnachricht
Byte Länge Wert Beschreibung
CLA 1 „00h“
INS 1 „C0h“
P1 1 „00h“
P2 1 „00h“
Le 1 „XXh“ Anzahl der erwarteten Bytes
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 261
TCS_80 Antwortnachricht
Byte Länge Wert Beschreibung
#1-#X X „XX..XXh“ Daten
SW 2 „XXXXh“ Statusbytes (SW1, SW2)
— Ist der Befehl erfolgreich, sendet die Karte „9000“ zu­
rück.
— Wurden von der Karte keine Daten vorbereitet, lautet
der zurückgesendete Verarbeitungsstatus „6900“ oder
„6F00“.
— Übersteigt Le die Anzahl der verfügbaren Bytes oder ist
Le gleich null, lautet der zurückgesendete Verarbei­
tungsstatus „6Cxx“, wobei „xx“ die genaue Anzahl
der verfügbaren Bytes bezeichnet. In diesem Fall stehen
die vorbereiteten Daten für einen weiteren Befehl GET
RESPONSE zur Verfügung.
— Ist Le nicht null und kleiner als die Anzahl der ver­
fügbaren Bytes, werden die angeforderten Daten normal
von der Karte gesendet. Der zurückgesendete Verarbei­
tungsstatus lautet „61xx“, wobei „xx“ die Anzahl der
zusätzlichen Bytes angibt, die noch für einen nachfol­
genden Befehl GET RESPONSE zur Verfügung stehen.
— Wird der Befehl nicht unterstützt (Protokoll T=1), sen­
det die Karte „6D00“ zurück.
3.5.7 PSO: VERIFY CERTIFICATE
Dieser Befehl entspricht den Festlegungen von ISO/IEC 7816-8, seine
Verwendung ist jedoch im Vergleich zu dem in der Norm definierten
Befehl eingeschränkt.
Der Befehl VERIFY CERTIFICATE wird von der Karte zur Ein­
holung eines öffentlichen Schlüssels von außen und zur Prüfung sei­
ner Gültigkeit verwendet.
3.5.7.1 B e f e h l - A n t w o r t - P a a r d e r 1 . G e n e r a t i o n
TCS_81 Diese Befehlsvariante wird lediglich durch eine Fahrten­
schreiberanwendung der 1. Generation unterstützt.
TCS_82 Ist der Befehl VERIFY CERTIFICATE erfolgreich, wird
der öffentliche Schlüssel zur künftigen Verwendung in
der Sicherheitsumgebung gespeichert. Dieser Schlüssel
wird explizit zur Verwendung in sicherheitsbezogenen Be­
fehlen (INTERNAL AUTHENTICATE, EXTERNAL AU­
THENTICATE oder VERIFY CERTIFICATE) durch den
Befehl MSE (siehe Abschnitt 3.5.11) unter Verwendung
seines Schlüsselbezeichners gesetzt.
TCS_83 Auf jeden Fall verwendet der Befehl VERIFY CERTIFI­
CATE den zuvor vom Befehl MSE zur Eröffnung des Zer­
tifikats ausgewählten öffentlichen Schlüssel. Dabei muss es
sich um den öffentlichen Schlüssel eines Mitgliedstaates
oder Europas handeln.
TCS_84 Befehlsnachricht
Byte Länge Wert Beschreibung
CLA 1 „00h“
INS 1 „2Ah“ Perform Security Operation
P1 1 „00h“ P1
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 262
Byte Länge Wert Beschreibung
P2 1 „AEh“ P2: nicht BER-TLV kodierte Daten (Verkettung von Da­
tenelementen)
Lc 1 „C2h“ Lc: Länge des Zertifikats, 194 Bytes
#6-#199 194 „XX..XXh“ Zertifikat: Verkettung von Datenelementen (gemäß Be­
schreibung in Anlage 11)
TCS_85 Antwortnachricht
Byte Länge Wert Beschreibung
SW 2 „XXXXh“ Statusbytes (SW1, SW2)
— Ist der Befehl erfolgreich, sendet die Karte „9000“ zu­
rück.
— Schlägt die Zertifikatsverifizierung fehl, lautet der zu­
rückgesendete Verarbeitungsstatus „6688“. Das Prü­
fungs- und Entpackungsverfahren für das Zertifikat
wird für G1 und G2 in Anlage 11 beschrieben.
— Ist kein öffentlicher Schlüssel in der Sicherheitsumge­
bung vorhanden, wird „6A88“ zurückgesendet.
— Wird der (zum Entpacken des Zertifikats verwendete)
ausgewählte öffentliche Schlüssel als verfälscht betrach­
tet, lautet der zurückgesendete Verarbeitungsstatus
„6400“ oder „6581“.
— Nur 1. Generation: Weist der (zum Entpacken des Zer­
tifikats verwendete) öffentliche Schlüssel ein CHA.LSB
( )
mit einem anderen Wert als „00“ auf (d. h., es ist der
Schlüssel eines Mitgliedstaates oder Europas), so lautet
der zurückgesendete Verarbeitungsstatus „6985“.
3.5.7.2 B e f e h l - A n t w o r t - P a a r d e r 2 . G e n e r a t i o n
Je nach Kurvengröße können ECC-Zertifikate so lang sein, dass sie
sich nicht in einem einzigen APDU übermitteln lassen. In einem
solchen Fall muss eine Befehlsverkettung gemäß ISO/IEC 7816-4
erfolgen und das Zertifikat in zwei aufeinander folgenden PSO: Verify
Certificate APDU-Befehlen übermittelt werden.
Zertifikatstruktur und Domänenparameter werden in Anlage 11
definiert.
▼M3
TCS_86 Der Befehl kann in MF, DF Tachograph und DF Tacho­
graph_G2 ausgeführt werden, siehe auch TCS_34.
▼B
TCS_87 Befehlsnachricht
Byte Länge Wert Beschreibung
CLA 1 „X0h“ CLA-Byte zur Angabe einer Befehlsverkettung:
„00h“ als einziger oder letzter Befehl der Kette
„10h“ nicht als letzter Befehl einer Kette
INS 1 „2Ah“ Perform Security Operation
P1 1 „00h“
P2 1 „BEh“ Selbstbeschreibendes Zertifikat verifizieren
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 263
Byte Länge Wert Beschreibung
Lc 1 „XXh“ Länge des Befehlsdatenfelds, siehe TCS_88 und
TCS_89.
#6-#5+L L „XX..XXh“ DER-TLV-kodierte Daten: Datenobjekt „ECC Certificate
Body“ als erstes Datenobjekt, verkettet mit dem Daten­
objekt „ECC Certificate Signature“ als zweites Daten­
objekt oder als Teil dieser Verkettung. Der Tag „7F21“
und die damit einhergehende Länge sind nicht zu über­
mitteln.
Die Reihenfolge dieser Datenobjekte ist fest.
▼M3
TCS_88 Für APDU mit kurzen Längenfeldern gilt Folgendes: Das
IFD verwendet die Mindestanzahl an APDU, die erforder­
lich sind, um die Befehlsdaten zu übermitteln und die
Höchstzahl an Bytes im ersten APDU-Befehl zu übermit­
teln. Es muss jedoch jeder Wert „Lc“ bis zu 255 Bytes von
der Karte unterstützt werden.
TCS_89 Für APDU mit erweiterten Längenfeldern gilt Folgendes:
Passt das Zertifikat nicht in eine einzige APDU, so unter­
stützt die Karte die Befehlsverkettung. Das IFD verwendet
die Mindestanzahl an APDU, die erforderlich sind, um die
Befehlsdaten zu übermitteln und die Höchstzahl an Bytes
im ersten APDU-Befehl zu übermitteln. Ist eine Verkettung
erforderlich, so muss der Wert „Lc“ bis zur angegebenen
maximalen erweiterten Länge von der Karte unterstützt
werden.
Hinweis: Gemäß Anlage 11 speichert die Karte das Zerti­
fikat oder die relevanten Inhalte des Zertifikats und aktua­
lisiert ihren Wert currentAuthenticatedTime.
Struktur und Statusbytes der Antwortnachricht entsprechen
der Definition in TCS_85.
▼B
TCS_90 Zusätzlich zu den in TCS_85 aufgeführten Fehlercodes
kann die Karte die folgenden Fehlercodes zurücksenden:
— Weist der (zum Entpacken des Zertifikats verwendete)
ausgewählte öffentliche Schlüssel einen CHA.LSB
(CertificateHolderAuthorisation.equipmentType) auf,
der nicht für die Verifizierung des Zertifikats gemäß
Anlage 11 geeignet ist, lautet der zurückgesendete Ver­
arbeitungsstatus „6985“.
— Weist der Wert currentAuthenticatedTime der Karte ei­
nen späteren Zeitpunkt als das Ablaufdatum des Zerti­
fikats auf, lautet der zurückgesendete Verarbeitungssta­
tus „6985“.
— Wird der letzte Befehl der Kette erwartet, sendet die
Karte „6883“ zurück.
— Werden im Befehlsdatenfeld falsche Parameter gesen­
det, sendet die Karte „6A80“ zurück (wird auch ver­
wendet, wenn die Datenobjekte nicht in der festgelegten
Reihenfolge gesendet werden).
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 264
3.5.8 INTERNAL AUTHENTICATE
Dieser Befehl entspricht den Festlegungen von ISO/IEC 7816-4.
TCS_91 Alle Fahrtenschreiberkarten müssen diesen Befehl in DF
Tachograph der 1. Generation verwenden. Der Befehl
kann in MF und/oder DF Tachograph_G2 gegebenenfalls
zur Verfügung stehen. In einem solchen Fall muss der
Befehl mit einem geeigneten Fehlercode enden, da der pri­
vate Schlüssel der Karte (Card.SK) für das Authentisie­
rungsprotokoll der 1. Generation nur in DF_Tachograph
der 1. Generation zugreifbar ist.
Mit Hilfe des Befehls INTERNAL AUTHENTICATE kann
das IFD die Karte authentisieren. Der Authentisierungsvor­
gang wird in Anlage 11 beschrieben. Er beinhaltet folgende
Aussagen:
TCS_92 Der Befehl INTERNAL AUTHENTICATE verwendet den
(implizit ausgewählten) privaten Kartenschlüssel zum Sig­
nieren von Authentisierungsdaten einschließlich K1 (erstes
Element für die Sitzungsschlüsselvereinbarung) und RND1
und verwendet den aktuell (durch den letzten MSE-Befehl)
ausgewählten öffentlichen Schlüssel zur Verschlüsselung
der Signatur und zur Bildung des Authentisierungstokens
(nähere Angaben in Anlage 11).
TCS_93 Befehlsnachricht
Byte Länge Wert Beschreibung
CLA 1 „00h“ CLA
INS 1 „88h“ INS
P1 1 „00h“ P1
P2 1 „00h“ P2
Lc 1 „10h“ Länge der an die Karte gesendeten Daten
#6 — #13 8 „XX..XXh“ Zur Authentisierung der Karte verwendete Zufallszahl
#14 -#21 8 „XX..XXh“ VU.CHR (siehe Anlage 11)
Le 1 „80h“ Länge der von der Karte erwarteten Daten
TCS_94 Antwortnachricht
Byte Länge Wert Beschreibung
#1-#128 128 „XX..XXh“ Token zur Authentisierung der Karte (siehe Anlage 11)
SW 2 „XXXXh“ Statusbytes (SW1, SW2)
— Ist der Befehl erfolgreich, sendet die Karte „9000“ zu­
rück.
— Ist in der Sicherheitsumgebung kein öffentlicher Schlüs­
sel vorhanden, lautet der zurückgesendete Verarbei­
tungsstatus „6A88“.
— Ist in der Sicherheitsumgebung kein privater Schlüssel
vorhanden, lautet der zurückgesendete Verarbeitungs­
status „6A88“.
— Stimmt VU.CHR nicht mit dem aktuellen Bezeichner
des öffentlichen Schlüssels überein, lautet der zurück­
gesendete Verarbeitungsstatus „6A88“.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 265
— Wird der ausgewählte private Schlüssel als verfälscht
betrachtet, lautet der zurückgesendete Verarbeitungssta­
tus „6400“ oder „6581“.
▼M1
TCS_95 Ist der Befehl INTERNAL AUTHENTICATE erfolgreich,
wird der aktuelle Sitzungsschlüssel der 1. Generation, so­
fern vorhanden, gelöscht und ist nicht mehr verfügbar. Um
einen neuen Sitzungsschlüssel der 1. Generation zur Ver­
fügung zu haben, muss der Befehl EXTERNAL AUTHEN­
TICATE für den Authentisierungsmechanismus der 1. Ge­
neration erfolgreich ausgeführt werden.
Hinweis: Für Sitzungsschlüssel der 2. Generation siehe
Anlage 11 CSM_193 und CSM_195. Werden Sitzungs­
schlüssel der 2. Generation erstellt und erhält die Fahrten­
schreiberkarte den APDU-Klartextbefehl INTERNAL AU­
THENTICATE, bricht sie die Secure-Messaging-Sitzung
der 2. Generation ab und vernichtet die Sitzungsschlüssel
der 2. Generation.
▼B
3.5.9 EXTERNAL AUTHENTICATE
Dieser Befehl entspricht den Festlegungen von ISO/IEC 7816-4.
Mit Hilfe des Befehls EXTERNAL AUTHENTICATE kann die Karte
das IFD authentisieren. Das Authentisierungsverfahren wird in Anlage
11 für die Fahrtenschreiber der 1. und 2. Generation beschrieben (VU-
Authentisierung).
TCS_96 Die Befehlsvariante für den Mechanismus zur gegenseiti­
gen Authentisierung der 1. Generation wird nur von einer
Fahrtenschreiberanwendung der 1. Generation unterstützt.
▼M1
TCS_97 Die Befehlsvariante für die gegenseitige VU-Karten-Au­
thentisierung der 2. Generation kann in MF, DF Tacho­
graph und DF Tachograph_G2 erfolgen (siehe auch
TCS_34). Ist der Befehl EXTERNAL AUTHENTICATE
der 2. Generation erfolgreich, wird der aktuelle Sitzungs­
schlü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 Sitzungs­
schlüssel der 2. Generation erstellt und erhält die Fahrten­
schreiberkarte den APDU-Klartextbefehl EXTERNAL AU­
THENTICATE, bricht sie die Secure-Messaging-Sitzung
der 2. Generation ab und vernichtet die Sitzungsschlüssel
der 2. Generation.
▼B
TCS_98 Befehlsnachricht
Byte Länge Wert Beschreibung
CLA 1 „00h“ CLA
INS 1 „82h“ INS
P1 1 „00h“ Schlüssel und Algorithmen implizit bekannt
P2 1 „00h“
Lc 1 „XXh“ Lc (Länge der an die Karte gesendeten Daten)
#6-#(5+L) L „XX..XXh“ Authentisierung der 1. Generation: Kryptogramm (siehe
Anlage 11 Teil A)
Authentisierung der 2 Generation: Vom IFD erstellte
Signatur (siehe Anlage 11 Teil B)
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 266
TCS_99 Antwortnachricht
Byte Länge Wert Beschreibung
SW 2 „XXXXh“ Statusbytes (SW1, SW2)
— Ist der Befehl erfolgreich, sendet die Karte „9000“ zu­
rück.
— Ist die CHA des derzeit gesetzten Schlüssels nicht die
Verkettung der AID der Fahrtenschreiberanwendung
und eines VU-Gerätetyps, lautet der zurückgesendete
Verarbeitungsstatus „6F00“.
— Geht dem Befehl nicht unmittelbar ein GET CHAL­
LENGE-Befehl voraus, lautet der zurückgesendete Ver­
arbeitungsstatus „6985“.
Die Fahrtenschreiberanwendung der 1. Generation kann
gegebenenfalls die folgenden Fehlercodes zurücksenden:
— Ist kein öffentlicher Schlüssel in der Sicherheitsumge­
bung vorhanden, wird „6A88“ zurückgesendet.
— Ist in der Sicherheitsumgebung kein privater Schlüssel
vorhanden, lautet der zurückgesendete Verarbeitungs­
status „6A88“.
— Schlägt die Prüfung des Kryptogramms fehl, lautet der
zurückgesendete Verarbeitungsstatus „6688“.
— Wird der ausgewählte private Schlüssel als verfälscht
betrachtet, lautet der zurückgesendete Verarbeitungssta­
tus „6400“ oder „6581“.
Die Befehlsvariante für die Authentisierung der 2. Genera­
tion kann gegebenenfalls die folgenden Fehlercodes zurück­
senden:
— Schlägt die Verifizierung der Signatur fehl, sendet die
Karte „6300“ zurück.
3.5.10 GENERAL AUTHENTICATE
Dieser Befehl wird für das Chip-Authentisierungsprotokoll der 2. Ge­
neration gemäß Anlage 11 Teil B verwendet und entspricht den Fest­
legungen von ISO/IEC 7816-4.
TCS_100 Der Befehl kann in MF, DF Tachograph und DF Tacho­
graph_G2 ausgeführt werden, siehe auch TCS_34.
TCS_101 Befehlsnachricht
Byte Länge Wert Beschreibung
CLA 1 „00h“
INS 1 „86h“
P1 1 „00h“ Schlüssel und Protokoll implizit bekannt
P2 1 „00h“
Lc 1 „NNh“ Lc: Länge des folgenden Datenfelds
#6-#(5+L) L „7Ch“ + L 7C +
„80h“ + L 80 +
„XX..XXh“
DER-TLV-kodierter Wert des flüchtigen öffentlichen
Schlüssels (siehe Anlage 11)
Die VU sendet die Datenobjekte in dieser Reihen­
folge.
▼M3
Le 1 „00h“ Gemäß ISO/IEC 7816-4
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 267
TCS_102 Antwortnachricht
Byte Länge Wert Beschreibung
#1-#L L „7Ch“ + L 7C + „81h“
+ „08h“ +
„XX..XXh“ + „82h“
+ L 82 + „XX..XXh“
DER-TLV-kodierte Dynamic Authentication
Data: Nonce und Authentisierungstoken (siehe
Anlage 11)
SW 2 „XXXXh“ Statusbytes (SW1, SW2)
— Ist der Befehl erfolgreich, sendet die Karte „9000“ zu­
rück.
— Bei falschen Parametern im Datenfeld sendet die Karte
„6A80“ zurück.
— Wurde der Befehl External Authenticate nicht erfolg­
reich ausgeführt, sendet die Karte „6982“ zurück.
Das Datenobjekt Dynamic Authentication — 7Chv
— muss bei erfolgreicher Ausführung vorhanden sein, d.
h. die Statusbytes lauten „9000“,
— muss bei einem Ausführungs- oder Prüffehler fehlen, d.
h. wenn die Statusbytes im Bereich „6400“ — „6FFF“
liegen, und
— muss bei einer Warnung fehlen, d. h. wenn die Status­
bytes im Bereich „6200“ — „63FF“ liegen.
3.5.11 MANAGE SECURITY ENVIRONMENT
Dieser Befehl wird zum Setzen eines öffentlichen Schlüssels zu Au­
thentisierungszwecken verwendet.
3.5.11.1 B e f e h l - A n t w o r t - P a a r d e r 1 . G e n e r a t i o n
Dieser Befehl entspricht den Festlegungen von ISO/IEC 7816-4. Die
Verwendung des Befehls ist jedoch im Vergleich zur entsprechenden
Norm eingeschränkt.
TCS_103 Dieser Befehl wird lediglich durch eine Fahrtenschreiber­
anwendung der 1. Generation unterstützt.
TCS_104 Der Schlüssel, auf den im MSE-Datenfeld verwiesen wird,
bleibt der aktuelle öffentliche Schlüssel, bis der nächste
korrekte MSE-Befehl eingeht, ein DF ausgewählt wird
oder die Karte zurückgesetzt wird.
TCS_105 Ist der Schlüssel, auf den verwiesen wird, (noch) nicht in
der Karte vorhanden, bleibt die Sicherheitsumgebung un­
verändert.
TCS_106 Befehlsnachricht
Byte Länge Wert Beschreibung
CLA 1 „00h“ CLA
INS 1 „22h“ INS
P1 1 „C1h“ P1: Schlüssel, auf den verwiesen wird, gültig für alle
kryptografischen Operationen
P2 1 „B6h“ P2 (mit Verweis versehene Daten zur digitalen Signatur)
Lc 1 „0Ah“ Lc: Länge des folgenden Datenfelds
#6 1 „83h“ Tag zum Verweis auf einen öffentlichen Schlüssel in
asymmetrischen Fällen
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 268
Byte Länge Wert Beschreibung
#7 1 „08h“ Länge des Schlüsselverweises (Schlüsselbezeichner)
#8-#15 8 „XX..XXh“ Schlüsselbezeichner laut Anlage 11
TCS_107 Antwortnachricht
Byte Länge Wert Beschreibung
SW 2 „XXXXh“ Statusbytes (SW1, SW2)
— Ist der Befehl erfolgreich, sendet die Karte „9000“ zu­
rück.
— Ist der Schlüssel, auf den verwiesen wird, auf der Karte
nicht vorhanden, lautet der zurückgesendete Verarbei­
tungsstatus „6A88“.
— Fehlen einige erwartete Datenobjekte im Secure-Messa­
ging-Format, wird „6987“ zurückgesendet. Dies kann
der Fall sein, wenn der Tag „83h“ fehlt.
— Sind einige Datenobjekte inkorrekt, lautet der zurück­
gesendete Verarbeitungsstatus „6988“. Dies kann der
Fall sein, wenn der Schlüsselbezeichner nicht „08h“ ist.
— Wird der ausgewählte Schlüssel als verfälscht betrach­
tet, lautet der zurückgesendete Verarbeitungsstatus
„6400“ oder „6581“.
3.5.11.2 B e f e h l - A n t w o r t - P a a r e d e r 2 . G e n e r a t i o n
Für die Authentisierung der 2. Generation unterstützt die Fahrten­
schreiberkarte folgenden MSE: Befehlsvarianten zum Setzen, die
den Festlegungen von ISO/IEC 7816-4 entsprechen. Diese Befehls­
varianten werden bei der Authentisierung der 1. Generation nicht
unterstützt.
3.5.11.2.1 M S E : S E T A T f ü r d i e C h i p - A u t h e n t i s i e r u n g
Mit Hilfe des folgenden Befehls MSE:SET AT werden die Parameter
für die Chip-Authentisierung ausgewählt, die durch einen nachfolgen­
den Befehl General Authenticate durchgeführt wird.
TCS_108 Der Befehl kann in MF, DF Tachograph und DF Tacho­
graph_G2 ausgeführt werden, siehe auch TCS_34.
TCS_109 MSE:SET AT Befehlsnachricht für die Chip-Authenti­
sierung
Byte Länge Wert Beschreibung
CLA 1 „00h“
INS 1 „22h“
P1 1 „41h“ Zur internen Authentisierung gesetzt
P2 1 „A4h“ Authentisierung
Lc 1 „NNh“ Lc: Länge des folgenden Datenfelds
#6-#(5+L) L „80h“ +
0Ah +
„XX..XXh“
DER-TLV-kodierter Verweis zu kryptografischen Me­
chanismen: Objektkennung der Chip-Authentisierung
(nur Wert, Tag „06h“ wird weggelassen).
Für die Werte der Objektkennungen siehe Anlage 1; es
wird die Byte-Notation verwendet. Anleitungen zur Aus­
wahl einer dieser Objektkennungen befinden sich in An­
lage 11.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 269
3.5.11.2.2 M S E : S E T A T f ü r d i e V U - A u t h e n t i s i e r u n g
Mit Hilfe des folgenden Befehls MSE:SET AT werden die Parameter
und Schlüssel für die VU-Authentisierung ausgewählt, die durch einen
nachfolgenden Befehl External Authenticate durchgeführt wird.
TCS_110 Der Befehl kann in MF, DF Tachograph und DF Tacho­
graph_G2 ausgeführt werden, siehe auch TCS_34.
TCS_111 MSE:SET AT Befehlsnachricht für die VU-Authentisie­
rung
Byte Länge Wert Beschreibung
CLA 1 „00h“
INS 1 „22h“
P1 1 „81h“ Zur externen Authentisierung gesetzt
P2 1 „A4h“ Authentisierung
Lc 1 „NNh“ Lc: Länge des folgenden Datenfelds
#6-#(5+L) L „80h“ +
0Ah +
„XX..XXh“
DER-TLV-kodierter Verweis zu kryptografischen Me­
chanismen: Objektkennung der VU-Authentisierung
(nur Wert, Tag „06h“ wird weggelassen).
Für die Werte der Objektkennungen siehe Anlage 1; es
wird die Byte-Notation verwendet. Anleitungen zur Aus­
wahl einer dieser Objektkennungen befinden sich in An­
lage 11.
„83h“ +
08h +
„XX..XXh“
DER-TLV-kodierter Verweis auf den öffentlichen
Schlüssel der FE durch die im Zertifikat erwähnte Refe­
renz des Zertifikatinhabers.
„91h“ +
L 91 +
„XX..XXh“
DER-TLV-kodierte komprimierte Darstellung des flüch­
tigen öffentlichen Schlüssels der VU, die während der
Chip-Authentisierung verwendet wird (siehe Anlage 11)
3.5.11.2.3 M S E : S E T D S T
Der folgende Befehls MSE:SET AT wird verwendet, um einen öffent­
lichen Schlüssel entweder
— zur Verifizierung einer Signatur, die in einem nachfolgenden Be­
fehl PSO: Verify Digital Signature bereitgestellt wird, oder
— zur Verifizierung der Signatur eines Zertifikats, das in einem nach­
folgenden Befehl PSO: Verify Certificate bereitgestellt wird, zu
setzen.
TCS_112 Der Befehl kann in MF, DF Tachograph und DF Tacho­
graph_G2 ausgeführt werden, siehe auch TCS_33.
TCS_113 MSE:SET DST Befehlsnachricht
Byte Länge Wert Beschreibung
CLA 1 „00h“
INS 1 „22h“
P1 1 „81h“ Zur Verifizierung gesetzt
P2 1 „B6h“ Digitale Signatur
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 270
Byte Länge Wert Beschreibung
Lc 1 „NNh“ Lc: Länge des folgenden Datenfelds
#6-#(5+L) L „83h“ + „08h“
+ „XX...XXh“
DER-TLV-kodierter Verweis auf einen öffentlichen
Schlüssel, d. h. die Referenz des Zertifikatinhabers im
Zertifikat eines öffentlichen Schlüssels (siehe Anlage 11)
Für sämtliche Befehlsversionen werden Struktur und Statusbytes der
Antwortnachricht bereitgestellt durch:
TCS_114 Antwortnachricht
Byte Länge Wert Beschreibung
SW 2 „XXXXh“ Statusbytes (SW1, SW2)
— Ist der Befehl erfolgreich, sendet die Karte „9000“ zu­
rück. Das Protokoll wurde ausgewählt und initialisiert.
— „6A80“ kennzeichnet fehlerhafte Parameter im Befehls­
datenfeld.
— „6A88“ gibt an, dass Daten, auf die verwiesen wird (d.
h. ein Schlüssel, auf den verwiesen wird), nicht verfüg­
bar sind.
▼M1
— Weist der Wert currentAuthenticatedTime der Karte ei­
nen späteren Zeitpunkt als das Ablaufdatum des aus­
gewählten öffentlichen Schlüssels auf, lautet der zu­
rü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 Be­
fehlsdatenfeld 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 Fahrzeugein­
heit verfügbar ist. Siehe die Definition des CHA-Felds in
Anlage 11 sowie des Datentyps EquipmentType in An­
lage 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 Kon­
trollkarte den relevanten öffentlichen Schlüssel EQT_Sign
immer gespeichert. In manchen Fällen kann die Kontroll­
karte 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.
▼B
3.5.12 PSO: HASH
Dieser Befehl dient dazu, Ergebnisse der Hashwertberechnung für
bestimmte Daten an die Karte zu übertragen. Dieser Befehl wird zur
Verifizierung digitaler Signaturen verwendet. Der Hashwert wird tem­
porär gespeichert für den folgenden Befehl PSO: Verify Digital Sig­
nature
Dieser Befehl entspricht den Festlegungen von ISO/IEC 7816-8. Die
Verwendung des Befehls ist jedoch im Vergleich zur entsprechenden
Norm eingeschränkt.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 271
Nur die Kontrollkarte wird benötigt, um diesen Befehl in DF Tacho­
graph und DF Tachograph_G2 zu unterstützen.
Andere Arten von Fahrtenschreiberkarten können diesen Befehl gege­
benenfalls implementieren. Der Befehl kann in MF gegebenenfalls zur
Verfügung stehen.
Die Kontrollkartenanwendung der 1. Generation unterstützt nur
SHA-1.
TCS_115 Der vorübergehend gespeicherte Hashwert ist zu löschen,
wenn mithilfe des Befehls PSO: HASH ein neuer Hashwert
berechnet wird, wenn ein DF ausgewählt wird und wenn
die Fahrtenschreiberkarte zurückgesetzt wird.
TCS_116 Befehlsnachricht
Byte Länge Wert Beschreibung
CLA 1 „00h“ CLA
INS 1 „2Ah“ Perform Security Operation
P1 1 „90h“ Hashcode zurücksenden
P2 1 „A0h“ Tag: Datenfeld enthält für Hashing relevante DO
Lc 1 „XXh“ Länge Lc des nachfolgenden Datenfelds
#6 1 „90h“ Tag für den Hashcode
#7 1 „XXh“ Länge L des Hashcodes:
„14h“ in Anwendung der 1. Generation (siehe Anlage 11
Teil A)
„20h“, „30h“ oder „40h“ in Anwendung der 2. Genera­
tion (siehe Anlage 11 Teil B)
#8-#(7+L) L „XX..XXh“ Hashcode
TCS_117 Antwortnachricht
Byte Länge Wert Beschreibung
SW 2 „XXXXh“ Statusbytes (SW1, SW2)
— Ist der Befehl erfolgreich, sendet die Karte „9000“ zu­
rück.
— Fehlen einige der erwarteten Datenobjekte (siehe oben),
wird der Verarbeitungsstatus „6987“ zurückgesendet.
Dies kann der Fall sein, wenn der Tag „90h“ fehlt.
— Sind einige Datenobjekte inkorrekt, lautet der zurück­
gesendete Verarbeitungsstatus „6988“. Dieser Fehler
tritt auf, wenn der erforderliche Tag zwar vorhanden
ist, aber eine andere Länge als „14h“ für SHA-1, „20h“
für SHA-256, „30h“ für SHA-384, „40h“ für SHA-512
(Anwendung der 2. Generation) aufweist.
3.5.13 PERFORM HASH of FILE
Dieser Befehl entspricht nicht den Festlegungen von ISO/IEC 7816-8.
Das CLA-Byte dieses Befehls gibt daher an, dass eine proprietäre
Verwendung von PERFORM SECURITY OPERATION/HASH
erfolgt.
Nur die Fahrer- und die Werkstattkarte müssen diesen Befehl in DF
Tachograph und DF Tachograph_G2 unterstützen.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 272
Andere Arten von Fahrtenschreiberkarten können diesen Befehl gege­
benenfalls implementieren. Wenn eine Unternehmens- oder Kontroll­
karte diesen Befehl implementiert, muss dies gemäß den Angaben
dieses Kapitels erfolgen.
Der Befehl kann in der MF gegebenenfalls zur Verfügung stehen.
Wenn ja, muss er gemäß den Angaben dieses Kapitels implementiert
werden, d. h. der Befehl darf nicht die Berechnung eines Hashwerts
zulassen, sondern muss mit einem geeigneten Fehlercode abschließen.
TCS_118 Der Befehl PERFORM HASH of FILE wird zur Hashwert­
berechnung des Datenbereichs der zu dem entsprechenden
Zeitpunkt ausgewählten transparenten EF verwendet.
TCS_119 Eine Fahrtenschreiberkarte darf diesen Befehl nur für die
im Kapitel 4 aufgeführten EF im Rahmen von DF_Tacho­
graph und DF_Tachograph_G2 unterstützen, mit folgender
Ausnahme. Eine Fahrtenschreiberkarte darf den Befehl
nicht für den EF Sensor_Installation_Data von DF Tacho­
graph_G2 unterstützen.
TCS_120 Das Ergebnis der Hash-Operation wird auf der Karte tem­
porär gespeichert. Es kann dann zur Einholung einer digi­
talen Signatur der Datei mit Hilfe des Befehls PSO: COM­
PUTE DIGITAL SIGNATURE verwendet werden.
▼M1
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 zu­
rückgesetzt wird.
▼B
TCS_122 Die Fahrtenschreiberanwendung der 1. Generation muss
SHA-1 unterstützen.
▼M1
TCS_123 Die Fahrtenschreiberanwendung der 2. Generation muss den
Algorithmus SHA-2, SHA-256, SHA-384 oder SHA-512 un­
terstützen, der durch die Cipher Suite in Anlage 11 Teil B für
den Kartensignaturschlüssel Card_Sign spezifiziert wird.
▼B
TCS_124 Befehlsnachricht
▼M1
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
▼B
TCS_125 Antwortnachricht
Byte Länge Wert Beschreibung
SW 2 „XXXXh“ Statusbytes (SW1, SW2)
— Ist der Befehl erfolgreich, sendet die Karte „9000“ zurück.
— Lässt die aktuelle EF diesen Befehl (EF Sensor_Instal­
lation_Data in DF Tachograph_G2) nicht zu, wird der
Verarbeitungsstatus „6985“ zurückgesendet.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 273
— Wird die ausgewählte EF als verfälscht betrachtet (we­
gen Integritätsfehlern in den Dateiattributen oder den
gespeicherten Daten), lautet der zurückgesendete Ver­
arbeitungsstatus „6400“ oder „6581“.
— Ist die ausgewählte Datei keine transparente Datei oder
gibt es keine aktuelle EF, wird der Verarbeitungsstatus
„6986“ zurückgesendet.
3.5.14 PSO: COMPUTE DIGITAL SIGNATURE
▼M1
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 gege­
benenfalls 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 geeig­
neten 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.
▼B
TCS_126 Dieser Befehl darf keine digitale Signatur eines zuvor mit
dem Befehl PSO: HASH berechneten Hashcodes
verarbeiten.
TCS_127 Zur Berechnung der digitalen Signatur wird der private
Schlüssel der Karte, der der Karte implizit bekannt ist,
herangezogen.
TCS_128 Die Fahrtenschreiberanwendung der 1. Generation führt
eine digitale Signatur mit Hilfe einer Auffüllmethode ge­
mäß PKCS1 aus (Einzelheiten siehe Anlage 11).
TCS_129 Die Fahrtenschreiberanwendung der 2. Generation berech­
net eine auf elliptischen Kurven basierende digitale Sig­
natur (Einzelheiten siehe Anlage 11).
TCS_130 Befehlsnachricht
Byte Länge Wert Beschreibung
CLA 1 „00h“ CLA
INS 1 „2Ah“ Perform Security Operation
P1 1 „9Eh“ Zurückzusendende digitale Signatur
P2 1 „9Ah“ Tag: Datenfeld enthält zu signierende Daten. Da kein
Datenfeld vorhanden ist, wird davon ausgegangen, dass
die Daten bereits in der Karte vorhanden sind (Hash of
File).
Le 1 „NNh“ Länge der erwarteten Signatur
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 274
TCS_131 Antwortnachricht
Byte Länge Wert Beschreibung
#1-#L L „XX..XXh“ Signatur des zuvor berechneten Hash
SW 2 „XXXXh“ Statusbytes (SW1, SW2)
— Ist der Befehl erfolgreich, sendet die Karte „9000“ zu­
rück.
— Wird der implizit ausgewählte private Schlüssel als ver­
fälscht betrachtet, lautet der zurückgesendete Verarbei­
tungsstatus „6400“ oder „6581“.
— Ist der in einem vorherigen „Perform Hash of File“-
Befehl berechnete Hash nicht verfügbar, wird der Ver­
arbeitungsstatus „6985“ zurückgesendet.
3.5.15 PSO: VERIFY DIGITAL SIGNATURE
Dieser Befehl wird zur Verifizierung der als Eingabe bereitgestellten
digitalen Signatur verwendet, deren Hash der Karte bekannt ist. Der
Signaturalgorithmus ist der Karte implizit bekannt.
Dieser Befehl entspricht den Festlegungen von ISO/IEC 7816-8. Die
Verwendung des Befehls ist jedoch im Vergleich zur entsprechenden
Norm eingeschränkt.
Nur die Kontrollkarte wird benötigt, um diesen Befehl in DF Tacho­
graph und DF Tachograph_G2 zu unterstützen.
Andere Arten von Fahrtenschreiberkarten können diesen Befehl gege­
benenfalls implementieren. Der Befehl kann in MF gegebenenfalls zur
Verfügung stehen.
TCS_132 Der Befehl VERIFY DIGITAL SIGNATURE verwendet
stets den vom vorhergehenden Befehl Manage Security
Environment MSE: Set DST ausgewählten öffentlichen
Schlüssel sowie den von einem PSO: HASH- Befehl einge­
gebenen Hashcode.
TCS_133 Befehlsnachricht
▼M1
Byte Länge Wert Beschreibung
CLA 1 ‚00h‘ CLA
INS 1 ‚2Ah‘ Perform Security Operation
P1 1 ‚00h‘
P2 1 ‚A8h‘ Tag: Datenfeld enthält für die Verifizierung relevante
DO
Lc 1 ‚XXh‘ Länge Lc des nachfolgenden Datenfelds
#6 1 ‚9Eh‘ Tag für digitale Signatur
#7 oder
#7 – #8
L ‚NNh‘ oder
‚81 NNh‘
Länge der digitalen Signatur (L gleich 2 Bytes, wenn die
Länge der digitalen Signatur mehr als 127 Bytes be­
trägt):
128 Bytes, kodiert gemäß Anlage 11 Teil A für Fahrten­
schreiberanwendung der 1. Generation.
Je nach der für die Fahrtenschreiberanwendung der 2. Ge­
neration ausgewählten Kurve (siehe Anlage 11 Teil B).
#(7+L) –
#(6+L+NN)
NN ‚XX..XXh‘ Inhalt der digitalen Signatur
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 275
TCS_134 Antwortnachricht
Byte Länge Wert Beschreibung
SW 2 „XXXXh“ Statusbytes (SW1, SW2)
— Ist der Befehl erfolgreich, sendet die Karte „9000“ zu­
rück.
— Schlägt die Verifizierung der Signatur fehl, lautet der
zurückgesendete Verarbeitungsstatus „6688“. Der Veri­
fizierungsvorgang wird in Anlage 11 beschrieben.
— Ist kein öffentlicher Schlüssel ausgewählt, lautet der
zurückgesendete Verarbeitungsstatus „6A88“.
— Fehlen einige der erwarteten Datenobjekte (siehe oben),
wird der Verarbeitungsstatus „6987“ zurückgesendet.
Das kann der Fall sein, wenn der erforderliche Tag
fehlt.
— Ist kein Hash-Code zur Verarbeitung des Befehls ver­
fügbar (im Ergebnis eines PSO: Hash-Befehls), lautet
der zurückgesendete Verarbeitungsstatus „6985“.
— Sind einige Datenobjekte inkorrekt, lautet der zurück­
gesendete Verarbeitungsstatus „6988“. Dies kann der
Fall sein, wenn eine Länge der erforderlichen Daten­
objekte inkorrekt ist.
— Wird der ausgewählte öffentliche Schlüssel als ver­
fälscht betrachtet, lautet der zurückgesendete Verarbei­
tungsstatus „6400“ oder „6581“.
▼M1
— Weist der (zur Verifizierung der digitalen Signatur ver­
wendete) ausgewählte öffentliche Schlüssel einen
CHA.LSB (CertificateHolderAuthorisation.equipment­
Type) auf, der nicht für die Verifizierung der digitalen
Signatur gemäß Anlage 11 geeignet ist, lautet der zu­
rückgesendete Verarbeitungsstatus ‚6985‘.
▼B
3.5.16 PROCESS DSRC MESSAGE
Dieser Befehl wird verwendet, um die Integrität und Authentizität der
DSRC-Nachricht zu verifizieren und um die von einer VU per
DSRC-Link an eine Kontrollbehörde oder eine Werkstatt gesendeten
Daten zu entschlüsseln. Die Karte leitet den zur Sicherung der
DSRC-Nachricht gemäß Anlage 11 Teil B Kapitel 13 verwendeten
Kodierungsschlüssel samt MAC-Schlüssel ab.
Nur die Kontroll- und die Werkstattkarte müssen diesen Befehl in DF
Tachograph_G2 unterstützen.
Andere Arten von Fahrtenschreiberkarten können diesen Befehl gege­
benenfalls implementieren, dürfen aber nicht über einen DSRC-Haupt­
schlüssel verfügen. Aus diesem Grund können diese Karten den Be­
fehl nicht erfolgreich ausführen, sondern schließen mit einem geeig­
neten Fehlercode ab.
Der Befehl kann in MF und/oder DF Tachograph gegebenenfalls zur
Verfügung stehen. Wenn ja, muss der Befehl mit einem geeigneten
Fehlercode abschließen.
TCS_135 Der DSRC-Hauptschlüssel ist nur in DF Tachograph_G2
zugreifbar, d. h. Kontroll- und Werkstattkarte unterstützen
die erfolgreiche Ausführung des Befehls lediglich in DF
Tachograph_G2.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 276
TCS_136 Der Befehl darf lediglich die DSRC-Daten entschlüsseln
und die kryptografische Prüfsumme verifizieren, nicht
aber die Eingabedaten interpretieren.
TCS_137 Die Reihenfolge der Datenobjekte im Befehlsdatenfeld ist
durch diese Spezifikation festgelegt.
TCS_138 Befehlsnachricht
Byte Länge Wert Beschreibung
CLA 1 „80h“ Proprietäres CLA
INS 1 „2Ah“ Perform Security Operation
P1 1 „80h“ Antwortdaten: Klarwert
P2 1 „B0h“ Befehlsdaten: in BER-TLV kodierter Klarwert mit SM
DO
Lc 1 „NNh“ Länge Lc des nachfolgenden Datenfelds
#6-#(5+L) L „87h“ + L 87 +
„XX..XXh“
DER-TLV-kodiertes Padding-Content Indicator-Byte, ge­
folgt von den verschlüsselten Fahrtenschreiberdaten. Für
das Padding-Content Indicator-Byte ist der Wert „00h“
(„keine weitere Angabe“ gemäß ISO/IEC 7816-4:2013
Tabelle 52) zu verwenden. Zur Verschlüsselung siehe
Anlage 11 Teil B Kapitel 13.
Zulässige Werte für die Länge L 87 sind Vielfache der
AES-Blocklänge zuzüglich 1 für das Padding-Content
Indicator-Byte, d. h. von 17 Bytes bis einschließlich
193 Bytes.
Hinweis: Siehe ISO/IEC 7816-4:2013 Tabelle 49 für das
SM-Datenobjekt mit Tag „87h“.
„81h“ + „10h“ DER-TLV-kodiertes Control Reference Template for
Confidentiality, das die Verkettung der folgenden Daten­
elemente gewährleistet (siehe Anlage 1 DSRCSecurity­
Data und Anlage 11 Teil B Kapitel 13):
— 4-Byte-Zeitstempel
— 3-Byte-Zähler
— 8-Byte-VU-Seriennummer
— 1-Byte-DSRC-Hauptschlüsselversion
Hinweis: Siehe ISO/IEC 7816-4:2013 Tabelle 49 für das
SM-Datenobjekt mit Tag „81h“.
„8Eh“ + L 8E +
„XX..XXh“
DER-TLV-kodiertes MAC über der DSRC-Nachricht. Zu
MAC-Algorithmus und Berechnung siehe Anlage 11 Teil
B Kapitel 13.
Hinweis: Siehe ISO/IEC 7816-4:2013 Tabelle 49 für das
SM-Datenobjekt mit Tag „8Eh“.
▼M3
Le 1 „00h“ Gemäß ISO/IEC 7816-4
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 277
TCS_139 Antwortnachricht
Byte Länge Wert Beschreibung
#1-#L L „XX..XXh“ Fehlende (im Falle eines Fehlers) oder entschlüsselte
Daten (Auffüllung entfernt)
SW 2 „XXXXh“ Statusbytes (SW1, SW2)
— Ist der Befehl erfolgreich, sendet die Karte „9000“ zu­
rück.
— „6A80“ gibt fehlerhafte Parameter im Befehlsdatenfeld
an (auch verwendet, wenn die Datenobjekte nicht in der
angegebenen Reihenfolge gesendet werden).
— „6A88“ gibt an, dass Daten, auf die verwiesen wird,
nicht verfügbar sind (d. h. der DSRC-Hauptschlüssel,
auf den verwiesen wird, ist nicht verfügbar).
— „6900“ gibt an, dass die Verifizierung der kryptogra­
fischen Prüfsumme oder die Entschlüsselung der Daten
fehlgeschlagen ist.
▼M1
— „6985“ gibt an, dass der 4-Byte-Zeitstempel im Be­
fehlsdatenfeld vor dem Zeitpunkt cardValidityBegin
oder nach dem cardExpiryDate liegt.
▼B
4. STRUKTUR DER FAHRTENSCHREIBERKARTEN
In diesem Abschnitt werden die Dateistrukturen, die auf den Fahrten­
schreiberkarten der Speicherung zugänglicher Daten dienen,
spezifiziert.
Nicht spezifiziert werden vom Kartenhersteller abhängige interne Struk­
turen, wie z. B. Dateianfangskennsätze oder die Speicherung und Ver­
arbeitung von Datenelementen, die nur für den internen Gebrauch benö­
tigt werden, z. B. , ,­
oder .
TCS_140 Eine Fahrtenschreiberkarte der 2. Generation muss das
Wurzelverzeichnis (MF) und eine Fahrtenschreiberanwen­
dung gleichen Typs der 1. und 2. Generation aufnehmen
(z. B. Fahrerkartenanwendungen).
TCS_141 Eine Fahrtenschreiberkarte muss zumindest die Mindestzahl
der für die entsprechenden Anwendungen angegebenen Da­
tensätze unterstützen und darf nicht mehr als die Höchst­
zahl der für die entsprechenden Anwendungen angegebe­
nen Datensätze unterstützen.
▼M3
Die Höchst- und die Mindestzahl an Datensätzen sind in
diesem Kapitel für die unterschiedlichen Anwendungen an­
gegeben. In Version 2 von Fahrer- und Werkstattkarten der
2. Generation muss die Anwendung der 1. Generation die
Höchstzahl der Datensätze gemäß TCS_150 und TCS_158
unterstützen.
▼B
Zu den Sicherheitsbedingungen, die in den in diesem Ka­
pitel verwendeten Zugriffsregeln verwendet werden, siehe
Kapitel 3.3. Generell bezeichnet der Zugriffsmodus „Le­
sen“ den Befehl READ BINARY mit geradem und bei
entsprechender Unterstützung mit ungeradem INS-Byte,
ausgenommen die EF Sensor_Installation_Data auf der
Werkstattkarte, siehe TCS_156 und TCS_160. Der Zu­
griffsmodus „Aktualisieren“ bezeichnet den Befehl Update
Binary mit geraden und bei entsprechender Unterstützung
mit ungeradem INS-Byte und der Zugriffsmodus „Auswäh­
len“ den Befehl SELECT.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 278
4.1. Wurzelverzeichnis (MF)
TCS_142 Nach der Personalisierung weist das Wurzelverzeichnis (MF)
folgende permanente Dateistruktur und Dateizugriffsregeln auf:
Hinweis: Die Kurz-Elementardateikennung SFID wird als
Dezimalzahl ausgedrückt; beispielsweise entspricht der
Wert 30 dem Binärwert 11110.
In dieser Tabelle wird die folgende Abkürzung für die
Sicherheitsbedingung verwendet:
SC1 ALW ODER SM-MAC-G2
TCS_143 Die Strukturen aller EF sind transparent.
TCS_144 Das Wurzelverzeichnis (MF) hat folgende Datenstruktur:
TCS_145 Die Elementardatei EF DIR muss die folgenden anwen­
dungsbezogenen Datenobjekte enthalten: „61 08 4F 06
FF 54 41 43 48 4F 61 08 4F 06 FF 53 4D 52 44 54“
TCS_146 Die Elementardatei EF ATR/INFO muss vorhanden sein,
wenn die Fahrtenschreiberkarte in ihrer ATR angibt, dass
sie erweiterte Längenfelder unterstützt. In diesem Fall muss
EF ATR/INFO das Datenobjekt mit der erweiterten Län­
genangabe (DO„7F66“) gemäß ISO/IEC 7816-4:2013
Punkt 12.7.1 enthalten.
TCS_147 Die Elementardatei EF Extended_Length muss vorhanden sein,
wenn die Fahrtenschreiberkarte in ihrer ATR angibt, dass sie
erweiterte Längenfelder unterstützt. In diesem Fall muss die
Elementardatei das folgende Datenobjekt enthalten: „02 01
xx“, wobei der Wert „xx“ angibt, ob erweiterte Längenfelder
für das Protokoll T = 1 und/oder T = 0 unterstützt werden.
Der Wert „01“ zeigt die Unterstützung erweiterter Längen­
felder für das Protokoll T = 1 an.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 279
Der Wert „10“ zeigt die Unterstützung erweiterter Längen­
felder für das Protokoll T = 0 an.
Der Wert „11“ zeigt die Unterstützung erweiterter Längen­
felder für das Protokoll T = 1 und T = 0 an.
4.2. Fahrerkartenanwendungen
4.2.1 Fahrerkartenanwendung der 1. Generation
TCS_148 Nach der Personalisierung weist die Fahrerkartenanwen­
dung der 1. Generation folgende permanente Dateistruktur
und Dateizugriffsregeln auf:
In dieser Tabelle werden die folgenden Abkürzungen für
die Sicherheitsbedingung verwendet:
SC1 ALW ODER SM-MAC-G2
SC2 ALW ODER SM-MAC-G1 ODER SM-MAC-G2
SC3 SM-MAC-G1 ODER SM-MAC-G2
TCS_149 Die Strukturen aller EF sind transparent.
TCS_150 Die Fahrerkartenanwendung der 1. Generation hat folgende
Datenstruktur:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 280
► (1) (2) M3
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 281
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 282
TCS_151 Die folgenden, in der vorstehenden Tabelle zur Größen­
angabe herangezogenen Werte sind die Mindest- und die
Höchstwerte für die Anzahl der Datensätze, die die Daten­
struktur der Fahrerkarte für eine Anwendung der 1. Gene­
ration verwenden muss:
4.2.2 Fahrerkartenanwendung der 2. Generation
▼M3
TCS_152 Nach der Personalisierung weist die Fahrerkartenanwen­
dung der 2. Generation folgende permanente Dateistruktur
und Dateizugriffsregeln auf:
Hinweise:
— Die Kurz-Elementardateikennung SFID wird als Dezi­
malzahl ausgedrückt; beispielsweise entspricht der Wert
30 dem Binärwert 11110.
— EF Application_Identification_V2, EF Places_Authenti­
cation, EF GNSS_Places_Authentication, EF Bor­
der_Crossings, EF Load_Unload_Operations, EF
VU_Configuration und EF Load_Type_Entries sind
nur in Version 2 der Fahrerkarte der 2. Generation
vorhanden.
— cardStructureVersion in EF Application_Identification
ist für Version 2 der Fahrerkarte der 2. Generation
gleich {01 01}, während dieser Wert für Version 1
der Fahrerkarte der 2. Generation gleich {01 00} war.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 283
In dieser Tabelle werden die folgenden Abkürzungen für
die Sicherheitsbedingung verwendet:
SC1 ALW ODER SM-MAC-G2
SC5 Für den Befehl Read Binary mit geradem INS-Byte:
SM-C-MAC-G2 UND SM-R-ENC-MAC-G2
Für den Befehl Read Binary mit ungeradem INS-
Byte (falls unterstützt): NEV
▼B
TCS_153 Die Strukturen aller EF sind transparent.
▼M3
TCS_154 Die Fahrerkartenanwendung der 2. Generation hat folgende
Datenstruktur:
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 284
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 285
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 286
TCS_155 Die folgenden, in der vorstehenden Tabelle zur Größen­
angabe herangezogenen Werte sind die Mindest- und die
Höchstwerte für die Anzahl der Datensätze, die die Daten­
struktur der Fahrerkarte für eine Anwendung der 2. Gene­
ration verwenden muss:
▼M3
Min. Max.
n 1 NoOfEventsPerType 12 12
n 2 NoOfFaultsPerType 24 24
n 3 NoOfCardVehicleRecords 200 200
n 4 NoOfCardPlaceRecords 112 112
n 6 CardActivityLengthRange 13776 Bytes
(56 Tage * 117 Tätig­
keitsveränderungen)
13776 Bytes
(56 Tage * 117 Tätig­
keitsveränderungen)
n 7 NoOfCardVehicleUnitRecords 200 200
n 8 NoOfGNSSADRecords 336 336
n 9 NoOfSpecificConditionRecords 112 112
n 10 NoOfBorderCrossingRecords 1120 1120
n 11 NoOfLoadUnloadRecords 1624 1624
n 12 NoOfLoadTypeEntryRecords 336 336
n 13 VuConfigurationLengthRange 3072 Bytes 3072 Bytes
▼B
4.3. Werkstattkartenanwendungen
4.3.1 Werkstattkartenanwendung der 1. Generation
TCS_156 Nach der Personalisierung weist die Werkstattkartenanwen­
dung der 1. Generation folgende permanente Dateistruktur
und Dateizugriffsregeln auf:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 287
In dieser Tabelle werden die folgenden Abkürzungen für
die Sicherheitsbedingung verwendet:
SC1 ALW ODER SM-MAC-G2
SC2 ALW ODER SM-MAC-G1 ODER SM-MAC-G2
SC3 SM-MAC-G1 ODER SM-MAC-G2
▼M1
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
▼B
TCS_157 Die Strukturen aller EF sind transparent.
TCS_158 Die Werkstattkartenanwendung der 1. Generation hat fol­
gende Datenstruktur:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 288
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 289
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 290
TCS_159 Die folgenden, in der vorstehenden Tabelle zur Größen­
angabe herangezogenen Werte sind die Mindest- und die
Höchstwerte für die Anzahl der Datensätze, die die Daten­
struktur der Werkstattkarte für eine Anwendung der 1. Ge­
neration verwenden muss:
4.3.2 Werkstattkartenanwendung der 2. Generation
▼M3
TCS_160 Nach der Personalisierung weist die Werkstattkartenanwen­
dung der 2. Generation folgende permanente Dateistruktur
und Dateizugriffsregeln auf:
Hinweise:
— Die Kurz-Elementardateikennung SFID wird als Dezi­
malzahl ausgedrückt; beispielsweise entspricht der Wert
30 dem Binärwert 11110.
— EF Application_Identification_V2, EF Places_Authenti­
cation, EF GNSS_Places_Authentication, EF Bor­
der_Crossings, EF Load_Unload_Operations, EF
Load_Type_Entries, EF VU_Configuration und EF Ca­
libration_Add_Data sind nur in Version 2 der Werk­
stattkarte der 2. Generation vorhanden.
— cardStructureVersion in EF Application_Identification
ist für Version 2 der Werkstattkarte der 2. Generation
gleich {01 01}, während dieser Wert für Version 1 der
Werkstattkarte der 2. Generation gleich {01 00} ist.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 291
In dieser Tabelle werden die folgenden Abkürzungen für
die Sicherheitsbedingung verwendet:
SC1 ALW ODER SM-MAC-G2
SC5 Für den Befehl Read Binary mit geradem INS-Byte:
SM-C-MAC-G2 UND SM-R-ENC-MAC-G2
Für den Befehl Read Binary mit ungeradem
INS-Byte (falls unterstützt): NEV
▼B
TCS_161 Die Strukturen aller EF sind transparent.
TCS_162 Die Werkstattkartenanwendung der 2. Generation hat fol­
gende Datenstruktur:
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 292
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 293
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 294
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 295
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 296
TCS_163 Die folgenden, in der vorstehenden Tabelle zur Größen­
angabe herangezogenen Werte sind die Mindest- und die
Höchstwerte für die Anzahl der Datensätze, die die Daten­
struktur der Werkstattkarte für eine Anwendung der 2. Ge­
neration verwenden muss:
▼M3
Min. Max.
n 1 NoOfEventsPerType 3 3
n 2 NoOfFaultsPerType 6 6
n 3 NoOfCardVehicleRecords 8 8
n 4 NoOfCardPlaceRecords 8 8
n 5 NoOfCalibrationRecords 255 255
n 6 CardActivityLengthRange 492 Bytes (1 Tag *
240 Tätigkeitsverände­
rungen)
492 Bytes (1 Tag *
240 Tätigkeitsverände­
rungen)
n 7 NoOfCardVehicleUnitRecords 8 8
n 8 NoOfGNSSADRecords 24 24
n 9 NoOfSpecificConditionRecords 4 4
n 10 NoOfBorderCrossingRecords 4 4
n 11 NoOfLoadUnloadRecords 8 8
n 12 NoOfLoadTypeEntryRecords 4 4
n 13 VuConfigurationLengthRange 3072 Bytes 3072 Bytes
▼B
4.4. Kontrollkartenanwendungen
4.4.1 Kontrollkartenanwendung der 1. Generation
TCS_164 Nach der Personalisierung weist die Kontrollkartenanwen­
dung der 1. Generation folgende permanente Dateistruktur
und Dateizugriffsregeln auf:
In dieser Tabelle werden die folgenden Abkürzungen für
die Sicherheitsbedingung verwendet:
SC1 ALW ODER SM-MAC-G2
SC2 ALW ODER SM-MAC-G1 ODER SM-MAC-G2
SC3 SM-MAC-G1 ODER SM-MAC-G2
SC6 EXT-AUT-G1 ODER SM-MAC-G1 ODER
SM-MAC-G2
TCS_165 Die Strukturen aller EF sind transparent.
TCS_166 Die Kontrollkartenanwendung der 1. Generation hat fol­
gende Datenstruktur:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 297
TCS_167 Die folgenden, in der vorstehenden Tabelle zur Größen­
angabe herangezogenen Werte sind die Mindest- und die
Höchstwerte für die Anzahl der Datensätze, die die Daten­
struktur der Kontrollkarte für eine Anwendung der 1. Ge­
neration verwenden muss:
4.4.2 Kontrollkartenanwendung der 2. Generation
▼M3
TCS_168 Nach der Personalisierung weist die Kontrollkartenanwen­
dung der 2. Generation folgende permanente Dateistruktur
und Dateizugriffsregeln auf.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 298
Hinweise:
— Die Kurz-Elementardateikennung SFID wird als Dezi­
malzahl ausgedrückt; beispielsweise entspricht der Wert
30 dem Binärwert 11110.
— EF Application_Identification_V2 und EF VU_Configu­
ration sind nur in Version 2 der Kontrollkarte der 2. Ge­
neration vorhanden.
— cardStructureVersion in EF Application_Identification
ist für Version 2 der Kontrollkarte der 2. Generation
gleich {01 01}, während dieser Wert für Version 1 der
Kontrollkarte der 2. Generation gleich {01 00} war.
In dieser Tabelle werden die folgenden Abkürzungen für
die Sicherheitsbedingung verwendet:
SC1 ALW ODER SM-MAC-G2
SC5 Für den Befehl Read Binary mit geradem
INS-Byte: SM-C-MAC-G2 UND SM-R-ENC-
MAC-G2
Für den Befehl Read Binary mit ungeradem
INS-Byte (falls unterstützt): NEV
▼B
TCS_169 Die Strukturen aller EF sind transparent.
TCS_170 Die Kontrollkartenanwendung der 2. Generation hat fol­
gende Datenstruktur:
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 299
▼B
TCS_171 Die folgenden, in der vorstehenden Tabelle zur Größen­
angabe herangezogenen Werte sind die Mindest- und die
Höchstwerte für die Anzahl der Datensätze, die die Daten­
struktur der Kontrollkarte für eine Anwendung der 2. Ge­
neration verwenden muss:
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 300
Min. Max.
n 7 NoOfControlActivityRecords 230 520
n 13 VuConfigurationLengthRange 3072 Bytes 3072 Bytes
▼B
4.5. Unternehmenskartenanwendungen
4.5.1 Unternehmenskartenanwendung der 1. Generation
TCS_172 Nach der Personalisierung weist die Unternehmenskarten­
anwendung der 1. Generation folgende permanente Datei­
struktur und Dateizugriffsregeln auf:
In dieser Tabelle werden die folgenden Abkür­
zungen für die Sicherheitsbedingung verwendet:
SC1 ALW ODER SM-MAC-G2
SC2 ALW ODER SM-MAC-G1 ODER
SM-MAC-G2
SC3 SM-MAC-G1 ODER SM-MAC-G2
SC6 EXT-AUT-G1 ODER SM-MAC-G1
ODER SM-MAC-G2
TCS_173 Die Strukturen aller EF sind transparent.
TCS_174 Die Unternehmenskartenanwendung der 1. Generation hat
folgende Datenstruktur:
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 301
TCS_175 Die folgenden, in der vorstehenden Tabelle zur Größen­
angabe herangezogenen Werte sind die Mindest- und die
Höchstwerte für die Anzahl der Datensätze, die die Daten­
struktur der Unternehmenskarte für eine Anwendung der 1.
Generation verwenden muss:
4.5.2 Unternehmenskartenanwendung der 2. Generation
▼M3
TCS_176 Nach der Personalisierung weist die Unternehmenskarten­
anwendung der 2. Generation folgende permanente Datei­
struktur und Dateizugriffsregeln auf:
Hinweise:
— Die Kurz-Elementardateikennung SFID wird als Dezi­
malzahl ausgedrückt; beispielsweise entspricht der Wert
30 dem Binärwert 11110.
— EF Application_Identification_V2 und EF VU_Configu­
ration sind nur in Version 2 der Unternehmenskarte der
2. Generation vorhanden.
— cardStructureVersion in EF Application_Identification
ist für Version 2 der Unternehmenskarte der 2. Genera­
tion gleich {01 01}, während dieser Wert für Version 1
der Unternehmenskarte der 2. Generation gleich {01 00}
war.
In dieser Tabelle werden die folgenden Abkürzungen für
die Sicherheitsbedingung verwendet:
SC1 ALW ODER SM-MAC-G2
SC5 Für den Befehl Read Binary mit geradem
INS-Byte: SM-C-MAC-G2 UND SM-R-ENC-
MAC-G2
Für den Befehl Read Binary mit ungeradem
INS-Byte (falls unterstützt): NEV
▼B
TCS_177 Die Strukturen aller EF sind transparent.
TCS_178 Die Unternehmenskartenanwendung der 2. Generation hat
folgende Datenstruktur:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 302
▼B
TCS_179 Die folgenden, in der vorstehenden Tabelle zur Größen­
angabe herangezogenen Werte sind die Mindest- und die
Höchstwerte für die Anzahl der Datensätze, die die Daten­
struktur der Unternehmenskarte für eine Anwendung der 2.
Generation verwenden muss:
▼M3
Min. Max.
n 8 NoOfCompanyActivityRecords 230 520
n 13 VuConfigurationLengthRange 3072 Bytes 3072 Bytes
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 303
Anlage 3
PIKTOGRAMME
PIC_001 Vom Fahrtenschreiber können fakultativ folgende Piktogramme und
Piktogrammkombinationen (oder Piktogramme und Kombinationen,
die hinreichend ähnlich sind, um eindeutig als diese erkannt zu wer­
den) verwendet werden:
1. EINZELPIKTOGRAMME
Personen Maßnahmen Betriebsarten
Unternehmen Betriebsart Unternehmen
Kontrolleur Kontrolle Betriebsart Kontrolle
Fahrer Lenken Betriebsart Betrieb
Werkstatt/Prüfstelle Überprüfung/Kalibrierung Betriebsart Kalibrierung
Hersteller
Tätigkeiten Dauer
Bereitschaft Laufende Bereitschaftszeit
Lenken Kontinuierliche Lenkzeit
Ruhe Laufende Ruhezeit
Sonstige Arbeit Laufende Arbeitszeit
Unterbrechung Kumulative Pausenzeit
Unbekannt
Geräte Funktionen
Steckplatz Fahrer
Steckplatz Beifahrer
Karte
Uhr
Anzeige Anzeigen
Externe Speicherung Herunterladen
Stromversorgung
Drucker/Ausdruck Drucken
Sensor
Reifengröße
Fahrzeug/Fahrzeugeinheit
GNSS-Ausrüstung
Ausrüstung zur Fernkommuni­
kation
ITS-Schnittstelle
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 304
Spezifische Bedingungen, manuelle Eingaben
Kontrollgerät nicht erforderlich
Fährüberfahrt/Zugfahrt
Beladevorgang
Entladevorgang
Gleichzeitiger Be-/Entladevorgang
Art der Ladung: Personen
Art der Ladung: Güter
Art der Ladung: Art der Ladung nicht definiert
▼B
Verschiedenes
Ereignisse Störungen
Beginn des Arbeitstages Ende des Arbeitstages
Ort
Manuelle Eingabe der Fahrertätigkeiten
▼M3
Sicherheit/authentisierte Daten/Plomben
▼B
Geschwindigkeit
Zeit
Gesamt/Zusammenfassung
▼M3
Digitale Karte/Grenzüberschreitung
▼B
Qualifikatoren
24h täglich
wöchentlich
zwei Wochen
von oder bis
2. PIKTOGRAMMKOMBINATIONEN
Verschiedenes
Kontrollort
Ort des Beginns des Arbeitstages Ort des Endes des Arbeitstages
▼M1
Position nach 3 Stunden kumulierter
Lenkzeit
▼B
Anfangszeit Endzeit
von Fahrzeug
Kontrollgerät nicht erforderlich — Be­
ginn
Kontrollgerät nicht erforderlich
— Ende
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 305
Position, an der das Fahrzeug die Grenze
eines Landes überschritten hat
Position, an der ein Beladevorgang statt­
gefunden hat
Position, an der ein Entladevorgang statt­
gefunden hat
Position, an der ein gleichzeitiger Be-/
Entladevorgang stattgefunden hat
▼B
Karten
Fahrerkarte
Unternehmenskarte
Kontrollkarte
Werkstattkarte
Keine Karte
Lenken
Team
Lenkzeit für eine Woche
Lenkzeit für zwei Wochen
Ausdrucke
Täglicher Ausdruck Fahrertätigkeiten von der Karte
Täglicher Ausdruck Fahrertätigkeiten von der VU
Ausdruck Ereignisse und Störungen von der Karte
Ausdruck Ereignisse und Störungen von der VU
Ausdruck Technische Daten
Ausdruck Geschwindigkeitsüberschreitung
▼M3
Ausdruck Historie der eingesteckten Karten
▼B
Ereignisse
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
Sicherheitsverletzung
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 306
Zeitkonflikt oder Zeiteinstellung (durch Werkstatt)
▼B
Kontrolle Geschwindigkeitsüberschreitung
▼M1
Fehlende Positionsdaten des GNSS-Empfängers oder Kommunikationsfeh­
ler mit der externen GNSS-Ausrüstung
Kommunikationsfehler mit der Fernkommunikationsausrüstung
▼M3
GNSS-Anomalie
▼B
Störungen
Kartenfehlfunktion (Steckplatz Fahrer)
Kartenfehlfunktion (Steckplatz Beifahrer)
Anzeigestörung
Störung beim Herunterladen
Druckerstörung
Sensorstörung
Interne VU-Störung
GNSS-Störung
Störung der Fernabfrage
Manueller Eingabevorgang
Weiterhin derselbe Arbeitstag?
Ende des vorherigen Arbeitstages?
Bestätigung oder Eingabe Ort des Arbeitstagendes
Eingabe Anfangszeit
Eingabe Ort des Arbeitstagbeginns.
Anmerkung: Weitere Piktogrammkombinationen als Block- oder Da­
tensatzbezeichner auf Ausdrucken sind in Anlage 4 festgelegt.
▼M1
02016R0799 — DE — 21.08.2023 — 003.002 — 307
Anlage 4
AUSDRUCKE
INHALTSVERZEICHNIS
1. ALLGEMEINES
2. SPEZIFIKATION DER DATENBLÖCKE
3. SPEZIFIKATION DER AUSDRUCKE
3.1. Tagesausdruck Fahrertätigkeiten von der Karte
3.2. Tagesausdruck Fahrertätigkeiten von der Fahrzeugeinheit (VU)
3.3. Ausdruck Ereignisse und Störungen von der Karte
3.4. Ausdruck Ereignisse und Störungen von der VU
3.5. Ausdruck Technische Daten
3.6. Ausdruck Geschwindigkeitsüberschreitung
3.7. Historie der eingesteckten Karten
1. ALLGEMEINES
Jeder Ausdruck besteht aus einer Aneinanderreihung verschiedener Da­
tenblöcke, die durch einen Blockbezeichner ausgewiesen werden kön­
nen.
Ein Datenblock enthält einen oder mehrere Datensätze, die durch einen
Datensatzbezeichner ausgewiesen werden können.
PRT_001 Steht ein Blockbezeichner unmittelbar vor einem Datensatz­
bezeichner, wird der Datensatzbezeichner nicht gedruckt.
PRT_002 Ist eine Datenangabe unbekannt oder darf aus datenzugriffs­
rechtlichen Gründen nicht gedruckt werden, werden stattdes­
sen Leerzeichen ausgedruckt.
PRT_003 Ist der Inhalt einer ganzen Zeile unbekannt oder braucht nicht
gedruckt zu werden, wird die gesamte Zeile weggelassen.
PRT_004 Nummerische Datenfelder werden rechtsbündig, mit einer
Leerstelle zur Abtrennung von Tausendern und Millionen
und ohne Führungsnullen gedruckt.
▼M3
PRT_005 Datenfelder mit Zeichenfolgen werden linksbündig gedruckt
und nach Bedarf bis zur Datenelementlänge mit Leerzeichen
aufgefüllt oder auf Datenelementlänge abgeschnitten. Namen
und Anschriften können in zwei Zeilen gedruckt werden.
▼B
PRT_006 Bei einem Zeilenumbruch aufgrund eines langen Textes muss
die neue Zeile mit einem Sonderzeichen (Punkt auf Mitte der
Zeilenhöhe, „•“) beginnen.
2. SPEZIFIKATION DER DATENBLÖCKE
In diesem Kapitel wurden folgende Konventionen für die Notation
verwendet:
— Zeichen in Fettdruck stehen für zu druckenden Klartext (im Aus­
druck erscheinen die Zeichen unformatiert).
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 308
— Unformatierte Zeichen stehen für Variablen (Piktogramme oder Da­
ten), die beim Ausdrucken durch ihre Werte ersetzt werden.
— Bezeichnungen von Variablen wurden mit Unterstrichen ergänzt, um
die für die Variable verfügbare Datenelementlänge sichtbar zu
machen.
— Datumsangaben sind im Format „TT/MM/JJJJ“ (Tag, Monat, Jahr)
spezifiziert. Verwendet werden kann auch das Format „TT.MM.JJJJ“.
— Die „Kartenkennung“ setzt sich aus folgenden Elementen zusam­
men: Angabe der Kartenart durch entsprechende Piktogrammkom­
bination, Code des ausstellenden Mitgliedstaates, Schrägstrich und
Kartennummer mit durch Leerstelle abgetrenntem Ersatzindex und
Erneuerungsindex:
P x x x / x x x x x x x x x x x x x x x x
K
ar
te
n-
P
ik
to
-
gr
am
m
ko
m
bi
na
ti
on

C
od
e
de
s
au
ss
te
l-

le
nd
en
M
it
gl
ie
d-

st
aa
te
s
Erste 14 Zeichen der Kartennummer
(möglichst mit einem fortlaufenden Index)
E
rs
at
zi
nd
ex

E
rn
eu
er
un
gs
in
de
x
▼M3
— In einem Datenblock bezieht sich der Text nach „pi =“ auf das
entsprechende Piktogramm oder die entsprechende Piktogrammkom­
bination gemäß Anlage 3.
— Wenn das Piktogramm nach dem Längen- und Breitengrad einer
aufgezeichneten Position oder nach dem Zeitstempel des Zeitpunkts
der Positionsbestimmung gedruckt wurde, gibt dieses Piktogramm
an, dass diese Position aus authentisierten Navigationsmeldungen
berechnet wurde.
— * Daten nur in GEN2-Fahrtenschreibern verfügbar (alle Versionen),
— ** Daten nur in GEN2-Fahrtenschreibern Version 2 verfügbar.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 309
PRT_007 Ausdrucke verwenden die folgenden Datenblöcke und/oder Datensätze
in der jeweiligen Bedeutung und Form:
► (1) (2) (3) (4) (5) M3
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 310
► (1) (2) (3) M3
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 311
► (1) (2) M3
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 312
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 313
► (1) (2) (3) (4) M3
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 314
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 315
► (1) M3
3. SPEZIFIKATION DER AUSDRUCKE
In diesem Kapitel werden die folgenden Konventionen für die Notation
verwendet:
N Nummer N des Druckblocks oder -datensatzes
N
Nummer N des Druckblocks oder -datensatzes, Wiederholung so oft
wie nötig
X/Y
Druckblöcke oder Datensätze X und/oder Y nach Bedarf, Wieder­
holung so oft wie nötig
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 316
3.1. Tagesausdruck Fahrertätigkeiten von der Karte
▼M3
PRT_008 Der tägliche Ausdruck Fahrertätigkeiten von der Karte hat
folgendes Format:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 317
3.2. Tagesausdruck Fahrertätigkeiten von der Fahrzeugeinheit (VU)
▼M3
PRT_009 Der Tagesausdruck Fahrertätigkeiten von der VU hat folgen­
des Format:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 318
3.3. Ausdruck Ereignisse und Störungen von der Karte
PRT_010 Der Ausdruck Ereignisse und Störungen von der Karte hat
folgendes Format:
1 Datum und Uhrzeit des Ausdrucks
2 Art des Ausdrucks
3 Angaben zum Kontrolleur (bei in VU eingesteckter Kontrollkarte +
GEN)
3 Angaben zum Fahrer (von der Karte, auf die der Ausdruck sich
bezieht)
4 Fahrzeugkennung (Fahrzeug, von dem der Ausdruck erstellt wird)
12.2 Begrenzungszeichen Ereignisse
12.4 Ereignisdatensätze (alle auf der Karte gespeicherten Ereignisse)
12.3 Begrenzungszeichen Störungen
12.4
Störungsdatensätze (alle auf der Karte gespeicherten Ereignisse)
22.1 Ort der Kontrolle
22.2 Unterschrift des Kontrolleurs
22.5 Unterschrift des Fahrers
3.4. Ausdruck Ereignisse und Störungen von der VU
PRT_011 Der Ausdruck Ereignisse und Störungen von der VU hat
folgendes Format:
1 Datum und Uhrzeit des Ausdrucks
2 Art des Ausdrucks
3
Angaben zum Karteninhaber (für alle in die VU eingesteckten Kar­
ten + GEN)
4 Fahrzeugkennung (Fahrzeug, von dem der Ausdruck erstellt wird)
13.2 Begrenzungszeichen Ereignisse
13.4
Ereignisdatensätze (alle in der VU gespeicherten oder andauernden
Ereignisse)
13.3 Begrenzungszeichen Störungen
13.4
Störungsdatensätze (alle in der VU gespeicherten oder andauernden
Störungen)
22.1 Ort der Kontrolle
22.2 Unterschrift des Kontrolleurs
22.5 Unterschrift des Fahrers
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 319
3.5. Ausdruck Technische Daten
▼M3
PRT_012 Der Ausdruck Technische Daten hat folgendes Format:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 320
3.6. Ausdruck Geschwindigkeitsüberschreitung
PRT_013 Der Ausdruck Geschwindigkeitsüberschreitung hat folgendes
Format:
1 Datum und Uhrzeit des Ausdrucks
2 Art des Ausdrucks
3
Angaben zum Karteninhaber (für alle in die VU eingesteckten Kar­
ten + GEN)
4 Fahrzeugkennung (Fahrzeug, von dem der Ausdruck erstellt wird)
20 Angaben zur Kontrolle Geschwindigkeitsüberschreitung
21.1 Kennung Daten Geschwindigkeitsüberschreitung
21.4/21.5 Erste Geschwindigkeitsüberschreitung nach der letzten Kalibrierung
21.2 Kennung Daten Geschwindigkeitsüberschreitung
21.4/21.5
Die 5 schwersten GÜ in den letzten 365 Tagen
21.3 Kennung Daten Geschwindigkeitsüberschreitung
21.4/21.5 Die schwersten GÜ der letzten 10 Tage mit derartigen Ereignissen
22.1 Ort der Kontrolle
22.2 Unterschrift des Kontrolleurs
22.5 Unterschrift des Fahrers
3.7. Historie der eingesteckten Karten
▼M3
PRT_014 Der Ausdruck Historie der eingesteckten Karten hat folgen­
des Format:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 321
Anlage 5
ANZEIGE
In dieser Anlage werden folgende Konventionen für die Notation verwendet:
— Zeichen in Fettdruck stehen für anzuzeigenden Klartext (in der Anzeige
erscheinen die Zeichen unformatiert).
— Unformatierte Zeichen stehen für Variablen (Piktogramme oder Daten), die in
der Anzeige durch ihre Werte ersetzt werden:
— TT MM JJJJ: Tag, Monat, Jahr,
— hh: Stunden,
— mm: Minuten,
— D: Piktogramm Dauer,
— EF: Piktogrammkombination Ereignis oder Störung,
— O: Piktogramm Betriebsart.
DIS_001 Die Anzeige von Daten durch den Fahrtenschreiber erfolgt in folgen­
dem Format:
Daten Format
Standardanzeige
Ortszeit
Betriebsart
Informationen zum Fahrer
Information zum Beifahrer
Betriebsart „Kontrollgerät nicht erforderlich“ eingeschaltet
Warnanzeige
Überschreitung der ununterbrochenen Lenkzeit
Ereignis oder Störung
Sonstige Anzeigen
UTC-Datum
Uhrzeit
Ununterbrochene Lenkzeit und kumulative Pausenzeit des
Fahrers
Ununterbrochene Lenkzeit und kumulative Pausenzeit des
Beifahrers
Kumulierte Lenkzeit des Fahrers für die Vorwoche und die
laufende Woche
Kumulierte Lenkzeit des Beifahrers für die Vorwoche und
die laufende Woche
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 322
Anlage 6
STECKANSCHLUSS AN DER VORDERSEITE FÜR KALIBRIERUNG
UND HERUNTERLADEN
INHALTSVERZEICHNIS
1. HARDWARE
1.1. Steckanschluss
1.2. Belegung der Kontakte
1.3. Blockschaltbild
2. SCHNITTSTELLE ZUM HERUNTERLADEN
3. KALIBRIERUNGSSCHNITTSTELLE
1. HARDWARE
1.1. Steckanschluss
INT_001 Das Herunterladen/Kalibrieren erfolgt über eine sechspolige
Steckverbindung, die an der Frontplatte zugänglich ist, ohne
dass ein Teil des Fahrtenschreibers abgetrennt werden muss.
Sie ist entsprechend der folgenden Abbildung auszulegen (sämt­
liche Maßangaben in mm):
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 323
Die folgende Abbildung zeigt einen typischen sechspoligen Ste­
cker:
1.2. Belegung der Kontakte
INT_002 Die Kontakte sind entsprechend der nachstehenden Tabelle zu
belegen:
Stift Beschreibung Anmerkung
1 Batterie minus Zum Minuspol der Fahrzeugbatterie
2 Datenkommunikation K-Leitung (ISO 14230-1)
3 RxD — Herunterladen Dateneingang Fahrtenschreiber
4 Eingabe-/Ausgabesignal Kalibrierung
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 324
Stift Beschreibung Anmerkung
5 Dauerausgangsleistung Zur Berücksichtigung des Spannungsabfalls am Schutz­
stromkreis entspricht der Spannungsbereich dem des Fahr­
zeugs minus 3 V
Ausgangsleistung: 40 mA
6 TxD — Herunterladen Datenausgang Fahrtenschreiber
1.3. Blockschaltbild
INT_003 Folgendes Blockschaltbild ist vorgegeben:
2. SCHNITTSTELLE ZUM HERUNTERLADEN
INT_004 Die Schnittstelle zum Herunterladen entspricht den RS232-Spe­
zifikationen.
INT_005 Die Schnittstelle zum Herunterladen verwendet ein Startbit, 8
Datenbits mit dem niedrigstwertigen Bit an erster Stelle, ein
Bit geradzahliger Parität und 1 Stoppbit.
Aufbau der Datenbytes
Startbit: Ein Bit mit dem Logikpegel 0
Datenbits: An erster Stelle Übertragung des niedrigstwertigen Bits
Paritätsbit: Gerade Parität
Stoppbit: Ein Bit mit dem Logikpegel 1
Bei der Übermittlung nummerischer Daten, die aus mehr als einem Byte
bestehen, wird das höchstwertige Byte an erster Stelle und das niedrigst­
wertige Byte an letzter Stelle übertragen.
INT_006 Die Baudrate bei der Übertragung ist zwischen 9 600 und
115 200 bit/s einstellbar. Die Übertragung hat mit der höchst­
möglichen Übertragungsgeschwindigkeit zu erfolgen, wobei die
anfängliche Bitgeschwindigkeit nach dem Aufbau der Verbin­
dung auf 9 600 bit/s gesetzt wird.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 325
3. KALIBRIERUNGSSCHNITTSTELLE
INT_007 Die Datenkommunikation erfolgt nach ISO 14230-1 Straßenfahr­
zeuge — Diagnosesysteme — Schlüsselwort 2000 — Teil 1:
Bitübertragungsschicht, Erste Ausgabe: 1999.
INT_008 Das Eingabe-/Ausgabesignal entspricht den folgenden elektri­
schen Spezifikationen:
Parameter Minimum Typisch Maximum Anmerkung
U L-Pegel (Eingang) 1,0 V I = 750 μA
U H-Pegel (Eingang) 4 V I = 200 μA
Frequenz 4 kHz
U L-Pegel (Ausgang) 1,0 V I = 1 mA
U H-Pegel (Ausgang) 4 V I = 1 mA
INT_009 Für das Eingabe-/Ausgabesignal gelten die folgenden Zeitdia­
gramme:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 326
Anlage 7
PROTOKOLLE ZUM HERUNTERLADEN DER DATEN
INHALTSVERZEICHNIS
1. EINLEITUNG
1.1. Geltungsbereich
1.2. Akronyme und Notationen
2. HERUNTERLADEN VON DATEN VON DER FAHRZEUGEINHEIT
2.1. Download-Verfahren
2.2. Datendownload-Protokoll
2.2.1 Nachrichtenstruktur
2.2.2 Nachrichtentypen
2.2.2.1 Start Communication Request (SID 81)
2.2.2.2 Positive Response Start Communication (SID C1)
2.2.2.3 Start Diagnostic Session Request (SID 10)
2.2.2.4 Positive Response Start Diagnostic (SID 50)
2.2.2.5 Link Control Service (SID 87)
2.2.2.6 Link Control Positive Response (SID C7)
2.2.2.7 Request Upload (SID 35)
2.2.2.8 Positive Response Request Upload (SID 75)
2.2.2.9 Transfer Data Request (SID 36)
2.2.2.10 Positive Response Transfer Data (SID 76)
2.2.2.11 Request Transfer Exit (SID 37)
2.2.2.12 Positive Response Request Transfer Exit (SID 77)
2.2.2.13 Stop Communication Request (SID 82)
2.2.2.14 Positive Response Stop Communication (SID C2)
2.2.2.15 Acknowledge Sub Message (SID 83)
2.2.2.16 Negative Response (SID 7F)
2.2.3 Nachrichtenfluss
2.2.4 Timing
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 327
2.2.5 Fehlerbehandlung
2.2.5.1 Start Communication-Phase
2.2.5.2 Communication-Phase
2.2.6 Inhalt der Antwortnachricht
▼M3
2.2.6.1 Positive Response Transfer Data Download Interface Version (Positive
Antwort Datenübertragung, Version der Download-Schnittstelle)
2.2.6.2 Positive Response Transfer Data Overview (Positive Antwort Daten­
übertragung, Überblick)
2.2.6.3 Positive Response Transfer Data Activities (Positive Antwort Daten­
übertragung, Tätigkeiten)
2.2.6.4 Positive Response Transfer Data Events and Faults (Positive Antwort
Datenübertragung, Ereignisse und Störungen)
2.2.6.5 Positive Response Transfer Data Detailed Speed (Positive Antwort Da­
tenübertragung, genaue Geschwindigkeitsangaben)
2.2.6.6 Positive Response Transfer Data Technical Data (Positive Antwort Da­
tenübertragung, Technische Daten)
▼B
2.3. ESM-Datenspeicherung
3. PROTOKOLL FÜR DAS HERUNTERLADEN VON DATEN VON
FAHRTENSCHREIBERKARTEN
3.1. Geltungsbereich
3.2. Begriffsbestimmungen
3.3. Herunterladen von der Karte
3.3.1 Initialisierungssequenz
3.3.2 Sequenz für unsignierte Dateien
3.3.3 Sequenz für signierte Dateien
3.3.4 Sequenz für das Zurücksetzen des Kalibrierungszählers
3.4. Datenspeicherungsformat
3.4.1 Einleitung
3.4.2 Dateiformat
4. HERUNTERLADEN VON DER FAHRTENSCHREIBERKARTE
ÜBER EINE FAHRZEUGEINHEIT
1. EINLEITUNG
Diese Anlage enthält die Spezifizierung der Verfahren für die verschie­
denen Arten der Übertragung der Daten von der Karte auf ein externes
Speichermedium (ESM) sowie die Protokolle, die zur Sicherung der
korrekten Datenübertragung und der vollständigen Kompatibilität des
heruntergeladenen Datenformats zu implementieren sind, damit ein
Kontrolleur diese Daten inspizieren und vor ihrer Analyse ihre Echtheit
und Integrität kontrollieren kann.
▼M1
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 Kartenschnitt­
stellengerät (IFD) ausgestattetes IDE,
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 328
— 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 ge­
speicherten 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 Sicher­
heitszertifikate (Mitgliedstaatszertifikat und Gerätezertifikat). Der Prüfer
der Daten muss einen zuverlässigen europäischen öffentlichen Schlüs­
sel besitzen.
Daten, die von einer VU heruntergeladen werden, werden gemäß An­
lage 11 (Gemeinsame Sicherheitsmechanismen Teil B, Fahrtenschrei­
bersystem der 2. Generation) unterzeichnet, außer wenn Fahrer von
einer Nicht-EU-Kontrollbehörde mit einer Kontrollkarte der 1. Genera­
tion 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. Ge­
neration und Unterzeichnung gemäß Anlage 11 Gemeinsame Si­
cherheitsmechanismen Teil B,
— VU-Datendownload der 1. Generation mit Datenstruktur der 1. Ge­
neration und Unterzeichnung gemäß Anlage 11 Gemeinsame Si­
cherheitsmechanismen Teil A.
Ebenso gibt es, wie in den Abschnitten 3 und 4 dieser Anlage aus­
geführt, zwei Arten von Datendownloads von in VU eingesetzten Fah­
rerkarten der 2. Generation.
▼B
1.2. Akronyme und Notationen
In dieser Anlage werden folgende Akronyme verwendet:
AID Application Identifier (Anwendungskennung)
ATR Answer To Reset (Antwort auf Zurücksetzen)
CS Checksum Byte (Prüfsummenbyte)
DF Dedicated File (Verzeichnis)
DS_ Diagnostic Session (Diagnosevorgang)
EF Elementary File (Elementardatei)
ESM External Storage Medium (externes Speichermedium)
FID File Identifier (File ID, Dateikennung)
FMT Formatbyte (erstes Byte eines Nachrichtenkopfes)
ICC Integrated Circuit Card (Chipkarte)
IDE Intelligent Dedicated Equipment: Gerät, das zum Herunterladen
von Daten auf das ESM verwendet wird (z. B. Personalcom­
puter)
IFD Interface Device (Schnittstellengerät, Kartenterminal)
KWP Keyword Protocol 2000
LEN Length Byte (Längenbyte, letztes Byte eines Nachrichtenkop­
fes)
PPS Protocol Parameter Selection (Auswahl der Protokollparameter)
PSO Perform Security Operation (Sicherheitsoperation ausführen)
SID Service Identifier (Dienstkennung)
SRC Source Byte (Quellbyte)
TGT Target Byte (Zielbyte)
▼M1
02016R0799 — DE — 21.08.2023 — 003.002 — 329
TLV Tag Length Value (Taglängenwert)
TREP Transfer Response Parameter (Antwortübertragungsparameter)
TRTP Transfer Request Parameter (Anfrageübertragungsparameter)
VU Fahrzeugeinheit (Vehicle Unit)
2. HERUNTERLADEN VON DATEN VON DER FAHRZEUGEIN­
HEIT
2.1. Download-Verfahren
Zur Durchführung eines VU-Datendownloads muss der Bediener fol­
gende Arbeitsschritte ausführen:
— Einführen seiner Kontrollgerätkarte in einen Steckplatz der VU (*);
— Anschließen des IDE an den VU-Anschluss zum Herunterladen;
— Herstellen der Verbindung zwischen IDE und VU;
— Auswählen der herunterzuladenden Daten auf dem IDE und Senden
der Anforderung an die VU;
— Beenden des Download-Vorgangs.
2.2. Datendownload-Protokoll
Das Protokoll ist auf Master/Slave-Basis aufgebaut, wobei das IDE den
Master und die VU den Slave bildet.
Nachrichtenstruktur, -typ und -fluss beruhen prinzipiell auf dem Key­
word Protocol 2000 (KWP) (ISO 14230-2 Road vehicles — Diagnostic
systems — Keyword protocol 2000 — Part2: Data link layer). (Stra­
ßenfahrzeuge — Diagnosesysteme — Schlüsselwort 2000 — Teil 2:
Sicherungsschicht).
Die Anwendungsschicht beruht grundsätzlich auf dem aktuellen Norm­
entwurf ISO 14229-1 (Road vehicles — Diagnostic systems — Part 1:
Diagnostic services (Straßenfahrzeuge — Diagnosesysteme — Teil 1:
Diagnosedienste), Version 6 vom 22. Februar 2001).
2.2.1 Nachrichtenstruktur
DDP_002 Alle zwischen dem IDE und der VU ausgetauschten Nach­
richten sind mit einer dreiteiligen Struktur formatiert, die
sich zusammensetzt aus
— dem Kopf, bestehend aus einem Formatbyte (FMT), ei­
nem Zielbyte (TGT), einem Quellbyte (SRC) und mög­
licherweise einem Längenbyte (LEN),
— dem Datenfeld, bestehend aus einem Service-Identifier-
Byte (SID) und einer variablen Anzahl von Datenbytes,
z. B. ein optionales Diagnostic-Session-Byte (DS_) oder
ein optionales Transfer-Parameter-Byte (TRTP oder
TREP),
— der Prüfsumme, bestehend aus einem Prüfsummenbyte
(CS).
Kopf Datenfeld Prüfsumme
FMT TGT SRC LEN SID DATA … … … CS
4 Bytes Max. 255 Bytes 1 Byte
TGT- und SRC-Byte stellen die physische Adresse des
Empfängers und des Absenders der Nachricht dar. Die
Werte sind F0 Hex für das IDE und EE Hex für die VU.
Das LEN-Byte ist die Länge des Datenfeldteils.
▼B
(*) Die eingesetzte Karte löst die erforderlichen Zugriffsrechte für die Herunterladefunktion
und die Daten aus. Das Herunterladen von Daten von einer in einen der Steckplätze der
VU eingeführten Fahrerkarte ist auch möglich, wenn in den anderen Steckplatz kein
anderer Kartentyp eingeführt ist.
02016R0799 — DE — 21.08.2023 — 003.002 — 330
Das Prüfsummenbyte ist die 8-Bit-Summenreihe modulo
256 aller Bytes der Nachricht außer CS selbst.
Die Bytes FMT, SID, DS_, TRTP und TREP werden an
anderer Stelle dieses Dokuments definiert.
DDP_003 Sind die von der Nachricht aufzunehmenden Daten länger
als der im Datenfeldteil zur Verfügung stehende Platz, wird
die Nachricht in mehreren Teilnachrichten gesendet. Jede
Teilnachricht hat einen Kopf, die gleiche SID, TREP sowie
einen 2-Byte-Teilnachrichtenzähler, der die Teilnachricht­
nummer innerhalb der Gesamtnachricht angibt. Damit Feh­
lerprüfung und Abbruch möglich sind, bestätigt das IDE
jede Teilnachricht. Das IDE kann die Teilnachricht anneh­
men, ihre erneute Übertragung anfordern sowie die VU zum
Neubeginn oder zum Abbruch der Übertragung auffordern.
DDP_004 Enthält die letzte Teilnachricht genau 255 Bytes im Daten­
feld, muss eine abschließende Teilnachricht mit leerem Da­
tenfeld (außer SID, TREP und Teilnachrichtenzähler) ange­
fügt werden, die das Ende der Nachricht anzeigt.
Beispiel:
Kopf SID TREP Nachricht CS
4 Bytes Länger als 255 Bytes
wird übertragen als:
Kopf SID TREP 00 01 Teilnachricht 1 CS
4 Bytes 255 Bytes
Kopf SID TREP 00 02 Teilnachricht 2 CS
4 Bytes 255 Bytes
…
Kopf SID TREP xx yy Teilnachricht n CS
4 Bytes Weniger als 255 Bytes
oder als:
Kopf SID TREP 00 01 Teilnachricht 1 CS
4 Bytes 255 Bytes
Kopf SID TREP 00 02 Teilnachricht 2 CS
4 Bytes 255 Bytes
…
Kopf SID TREP xx yy Teilnachricht n CS
4 Bytes 255 Bytes
Kopf SID TREP xx yy + 1 CS
4 Bytes 4 Bytes
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 331
2.2.2 Nachrichtentypen
Das Kommunikationsprotokoll für das Herunterladen von Daten zwi­
schen der VU und dem IDE verlangt den Austausch von 8 verschie­
denen Nachrichtentypen.
In der folgenden Tabelle sind diese Nachrichten zusammengefasst.
▼M3
Nachrichtenstruktur Max. 4 Bytes Max. 255 Bytes 1 Byte
Kopf Daten Prüfsumme
IDE ->
Anforderung Beginn Kommunikation 81 EE F0 81 E0
Positive Antwort Beginn Kommuni­
kation
80 F0 EE 03 C1 EA, 8F 9B
Anforderung Beginn Diagnosevorgang 80 EE F0 02 10 81 F1
Positive Antwort Beginn Diagnose 80 F0 EE 02 50 81 31
Verbindungssteuerungsdienst
Baud-Rate überprüfen (Stufe 1)
9 600 Baud 80 EE F0 04 87 01 01,01 EC
19 200 Baud 80 EE F0 04 87 01 01,02 ED
38 400 Baud 80 EE F0 04 87 01 01,03 EE
57 600 Baud 80 EE F0 04 87 01 01,04 EF
115 200 Baud 80 EE F0 04 87 01 01,05 F0
Positive Antwort Baud-Rate überprü­
fen
80 F0 EE 02 C7 01 28
Übergang Baud-Rate (Stufe 2) 80 EE F0 03 87 02 03 ED
Anforderung Upload 80 EE F0 0A 35 00,00,00,00,
00,FF,FF,
FF,FF
99
Positive Antwort Anforderung Upload 80 F0 EE 03 75 00,FF D5
Anforderung Datenübertragung
Download-Schnittstellenversion 80 EE F0 02 36 00 96
Überblick 80 EE F0 02 36 01, 21 oder 31 CS
Tätigkeiten 80 EE F0 06 36 02, 22 oder 32 Datum CS
Ereignisse & Störungen 80 EE F0 02 36 03, 23 oder 33 Datum CS
Genaue Geschwindigkeitsangaben 80 EE F0 02 36 04 oder 24 Datum CS
Technische Daten 80 EE F0 02 36 05, 25 oder 35 Datum CS
Download von der Karte 80 EE F0 02 oder 03 36 06 Steckplatz CS
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 332
Nachrichtenstruktur Max. 4 Bytes Max. 255 Bytes 1 Byte
Kopf Daten Prüfsumme
IDE ->
Positive Antwort Datenübertragung 80 F0 EE Len 76 TREP Daten CS
Anforderung Übertragung beenden 80 EE F0 01 37 96
Positive Antwort Anforderung Über­
tragung beenden
80 F0 EE 01 77 D6
Anforderung Kommunikation beenden 80 EE F0 01 82 E1
Positive Antwort Kommunikation be­
enden
80 F0 EE 01 C2 21
Teilnachricht bestätigen 80 EE F0 Len 83 Daten CS
Negative Antworten
Aktion nicht möglich 80 F0 EE 03 7F Sid Req 10 CS
Dienst wird nicht unterstützt 80 F0 EE 03 7F Sid Req 11 CS
Untervariable wird nicht unterstützt 80 F0 EE 03 7F Sid Req 12 CS
Länge der Nachricht nicht korrekt 80 F0 EE 03 7F Sid Req 13 CS
Bedingungen nicht korrekt oder Se­
quenzfehler in der Anforderung
80 F0 EE 03 7F Sid Req 22 CS
Anforderung außerhalb des Bereichs 80 F0 EE 03 7F Sid Req 31 CS
Upload nicht akzeptiert 80 F0 EE 03 7F Sid Req 50 CS
Aktion nicht abgeschlossen 80 F0 EE 03 7F Sid Req 78 CS
Daten nicht verfügbar 80 F0 EE 03 7F Sid Req FA CS
Hinweise:
— Sid Req = Sid der entsprechenden Anforderung.
— TREP = der TRTP der entsprechenden Anforderung.
— Geschwärzte Felder zeigen an, dass nichts übertragen wird.
— Der Ausdruck „Upload“ (von der IDE aus gesehen) wird in Anleh­
nung an die ISO 14229 verwendet. Er bedeutet dasselbe wie
„Download“ (von der VU aus gesehen).
— Mögliche 2-Byte-Teilnachrichtenzähler sind in dieser Tabelle nicht
aufgeführt.
— „Steckplatz“ bezeichnet die Steckplatznummer, entweder „1“ (Karte
im Steckplatz Fahrer) oder „2“ (Karte im Steckplatz Beifahrer).
— Falls der Steckplatz nicht angegeben ist, muss die VU Steckplatz 1
auswählen, wenn in diesen Steckplatz eine Karte eingesteckt wird,
und Steckplatz 2 nur dann, wenn dies vom Benutzer ausdrücklich
ausgewählt wird.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 333
— TRTP 24 wird für VU-Datendownload-Anforderungen der 2. Gene­
ration, Version 1 und Version 2, verwendet.
— TRTP 00, 31, 32, 33 und 35 werden für VU-Datendownload-An­
forderungen der 2. Generation, Version 2, verwendet.
— TRTP 21, 22, 23 und 25 werden für VU-Datendownload-Anforde­
rungen der 2. Generation, Version 1, verwendet.
— TRTP 01 bis 05 werden für VU-Datendownload-Anforderungen der
1. Generation verwendet. Sie können optional von VU der 2. Gene­
ration akzeptiert werden, jedoch nur, wenn Fahrer von einer
Nicht-EU-Kontrollbehörde mit einer Kontrollkarte der 1. Generation
kontrolliert werden.
— TRTP 11 bis 1F sind für herstellerspezifische Download-Anforde­
rungen reserviert.
▼B
2.2.2.1 S t a r t C o m m u n i c a t i o n R e q u e s t ( S I D 8 1 )
DDP_005 Diese Nachricht wird vom IDE zum Aufbau der Kommuni­
kationsverbindung mit der VU ausgegeben. Der Verbin­
dungsaufbau und die Kommunikation erfolgt anfangs stets
mit einer Datenrate von 9 600 Baud (solange die Übertra­
gungsgeschwindigkeit nicht durch einen Link Control Ser­
vice (Verbindungssteuerungsdienst) geändert wird).
2.2.2.2 P o s i t i v e R e s p o n s e S t a r t C o m m u n i c a t i o n ( S I D C 1 )
DDP_006 Diese Nachricht wird von der VU als positive Antwort auf
einen Start Communication Request ausgegeben. Sie enthält
die beiden Schlüsselbytes „EA“ „8F“ als Hinweis darauf,
dass die Einheit das Protokoll mit Kopf einschließlich
Ziel-, Quell- und Längeninformation unterstützt.
2.2.2.3 S t a r t D i a g n o s t i c S e s s i o n R e q u e s t ( S I D 1 0 )
DDP_007 Die Nachricht Start Diagnostic Session Request wird vom
IDE ausgegeben, um einen neuen Diagnosevorgang mit der
VU zu beginnen. Die Untervariable „default session“ (81
Hex) zeigt an, dass ein Standard-Diagnosevorgang eingelei­
tet werden soll.
2.2.2.4 P o s i t i v e R e s p o n s e S t a r t D i a g n o s t i c ( S I D 5 0 )
DDP_008 Die Nachricht Positive Response Start Diagnostic wird von
der VU als positive Antwort auf einen Diagnostic Session
Request gesendet.
2.2.2.5 L i n k C o n t r o l S e r v i c e ( S I D 8 7 )
DDP_052 Mit Hilfe des Link Control Service (Verbindungssteuerungs­
dienst) leitet die IDE einen Wechsel der Übertragungs­
geschwindigkeit (Baudrate) ein. Dies erfolgt in zwei Schrit­
ten. Zunächst schlägt die IDE einen Wechsel vor und gibt
dazu die neue Baudrate an. Nach einer positiven Antwort
der VU sendet die IDE dann im zweiten Schritt eine Be­
stätigung des Geschwindigkeitswechsels an die VU und geht
danach zur neuen Baudrate über. Nach Erhalt der Bestäti­
gung geht auch die VU zur neuen Baudrate über.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 334
2.2.2.6 L i n k C o n t r o l P o s i t i v e R e s p o n s e ( S I D C 7 )
DDP_053 Die Nachricht Link Control Positive Response wird von der
VU als positive Antwort auf einen Link Control Service
Request (Schritt 1) gesendet. Die Bestätigungsmeldung
(Schritt 2) wird dagegen nicht beantwortet.
2.2.2.7 R e q u e s t U p l o a d ( S I D 3 5 )
DDP_009 Die Nachricht Request Upload wird vom IDE als Mitteilung
an die VU ausgegeben, dass eine Download-Operation an­
gefordert wird. In Übereinstimmung mit der ISO 14229
umfasst diese Anforderung stets Angaben zu Adresse,
Größe und Format der angeforderten Daten. Da diese An­
gaben der IDE jedoch vor dem Herunterladen nicht bekannt
sind, wird die Speicheradresse auf „0“, das Format auf „ver­
schlüsselt und unkomprimiert“ und die Speichergröße auf
den Höchstwert gesetzt.
2.2.2.8 P o s i t i v e R e s p o n s e R e q u e s t U p l o a d ( S I D 7 5 )
DDP_010 Die Nachricht Positive Response Request Upload wird von
der VU gesendet, um dem IDE anzuzeigen, dass die VU
zum Herunterladen der Daten bereit ist. In Übereinstimmung
mit der ISO 14229 enthält diese Positive-Response-Nach­
richt auch Daten, mit denen der IDE mitgeteilt wird, dass
spätere Nachrichten Positive Response Transfer Data höchs­
tens 00FF Hex Bytes umfassen werden.
2.2.2.9 T r a n s f e r D a t a R e q u e s t ( S I D 3 6 )
▼M1
DDP_011 Die Nachricht Transfer Data Request wird vom IDE gesen­
det und spezifiziert der VU den herunterzuladenden Daten­
typ. Mit dem Byte Transfer Request Parameter (TRTP) wird
die Übertragungsart angegeben.
▼M3
Es gibt sieben 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, Version 1
TRTP-Wert für
VU-Datendownloads
der 2. Generation, Version 2
Download-Schnittstellenver­
sion
Nicht verwendet Nicht verwendet 00
Überblick 01 21 31
Tätigkeiten eines bestimmten
Tages
02 22 32
Ereignisse und Störungen 03 23 33
Genaue Geschwindigkeits­
angaben
04 24 24
Technische Daten 05 25 35
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 335
Datenübertra­
gungsart
TRTP-Wert
Kartendownload 06
▼M3
DDP_054 Die IDE muss beim Herunterladen eine Überblicks-Daten­
übertragung (TRTP 01, 21 oder 31) anfordern, da nur so die
VU-Zertifikate in der heruntergeladenen Datei gespeichert
werden (und die digitale Signatur geprüft werden kann).
Im dritten Fall (TRTP 02, 22 oder 32) schließt die Nachricht Transfer
Data Request die Angabe des herunterzuladenden Kalendertags (Format
TimeReal) ein.
▼B
2.2.2.10 P o s i t i v e R e s p o n s e T r a n s f e r D a t a ( S I D 7 6 )
DDP_012 Die Nachricht Positive Response Transfer Data wird von der
VU als Antwort auf die Transfer Data Request gesendet. Sie
enthält die angeforderten Daten, wobei die Transfer Re­
sponse Parameter (TREP) der TRTP der Anforderung
entspricht.
▼M3
DDP_055 Im ersten Fall (TREP 01, 21 oder 31) sendet die VU Daten,
die es dem IDE-Bediener erleichtern, die von ihm herunter­
zuladenden Daten auszuwählen. Diese Nachricht enthält fol­
gende Informationen:
▼M1
— 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.
▼B
2.2.2.11 R e q u e s t T r a n s f e r E x i t ( S I D 3 7 )
DDP_013 Mit der Nachricht Request Transfer Exit teilt das IDE der
VU mit, dass der Download-Vorgang beendet ist.
2.2.2.12 P o s i t i v e R e s p o n s e R e q u e s t T r a n s f e r E x i t ( S I D 7 7 )
DDP_014 Die Nachricht Positive Response Request Transfer Exit wird
von der VU zur Quittierung der Request Transfer Exit
gesendet.
▼M1
02016R0799 — DE — 21.08.2023 — 003.002 — 336
2.2.2.13 S t o p C o m m u n i c a t i o n R e q u e s t ( S I D 8 2 )
DDP_015 Die Nachricht Stop Communication Request wird vom IDE
gesendet, um die Kommunikationsverbindung mit der VU
zu trennen.
2.2.2.14 P o s i t i v e R e s p o n s e S t o p C o m m u n i c a t i o n ( S I D C 2 )
DDP_016 Mit der Nachricht Positive Response Stop Communication
quittiert die VU die Nachricht Stop Communication Re­
quest.
2.2.2.15 A c k n o w l e d g e S u b M e s s a g e ( S I D 8 3 )
DDP_017 Mit der Nachricht Acknowledge Sub Message bestätigt das
IDE den Empfang der einzelnen Teile einer Nachricht, die
in mehreren Teilnachrichten gesendet wird. Das Datenfeld
enthält die von der VU empfangene SID sowie einen 2-
Byte-Code wie folgt:
— MsgC + 1 quittiert den korrekten Empfang der Teilnach­
richt Nummer MsgC.
Anforderung vom IDE an die VU zur Sendung der
nächsten Teilnachricht.
— MsgC zeigt ein Problem beim Empfang der Teilnach­
richt Nummer MsgC an.
Anforderung von IDE an die VU zur erneuten Sendung
der Teilnachricht.
— FFFF fordert zur Beendigung der Nachricht auf.
Kann vom IDE zur Beendigung der Übertragung der
VU-Nachricht aus irgendeinem Grund verwendet
werden.
Die letzte Teilnachricht einer Nachricht (LEN-Byte
kann unter Verwendung eines dieser Codes oder gar nicht
quittiert werden.
Folgende VU-Antwort besteht aus mehreren Teilnachrich­
ten:
— Positive Response Transfer Data (SID 76)
2.2.2.16 N e g a t i v e R e s p o n s e ( S I D 7 F )
DDP_018 Die Nachricht Negative Response wird von der VU als Ant­
wort auf die oben genannten Anforderungsnachrichten ge­
sendet, wenn sie die Anforderung nicht erfüllen kann. Die
Datenfelder der Nachricht enthalten die SID der Antwort
(7F), die SID der Anforderung sowie einen Code zur An­
gabe des Grundes der negativen Antwort. Folgende Codes
stehen zur Verfügung:
— 10 general reject
Aktion kann aus einem im Folgenden nicht aufgeführten
Grund nicht ausgeführt werden.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 337
— 11 service not supported
Die SID der Anforderung wird nicht verstanden.
— 12 sub function not supported
Die DS_ oder TRTP der Anforderung wird nicht ver­
standen, oder es sind keine weiteren Teilnachrichten zu
übertragen.
— 13 incorrect message length
Die Länge der erhaltenen Nachricht ist nicht korrekt.
— 22 conditions not correct or request sequence error
Der angeforderte Dienst ist nicht aktiv oder die Reihen­
folge der Anforderungsnachrichten ist nicht korrekt.
— 31 Request out of range
Der Parameterdatensatz der Anforderung (Datenfeld) ist
ungültig.
— 50 upload not accepted
Die Anforderung kann nicht ausgeführt werden (VU in
einem nicht geeigneten Modus oder interne Störung der
VU).
— 78 response pending
Die angeforderte Aktion kann nicht rechtzeitig abge­
schlossen werden, und die VU ist nicht bereit, eine wei­
tere Anforderung anzunehmen.
▼M1
— 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, …).
▼B
2.2.3 Nachrichtenfluss
Ein typischer Nachrichtenfluss während einer normalen Daten­
download-Prozedur sieht folgendermaßen aus:
IDE VU
Start Communication Request ⇨
⇦ Positive Response
Start Diagnostic Service Request ⇨
⇦ Positive Response
Request Upload ⇨
⇦ Positive Response
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 338
IDE VU
Transfer Data Request Overview ⇨
⇦ Positive Response
Transfer Data Request #2 ⇨
⇦ Positive Response #1
Acknowledge Sub Message #1 ⇨
⇦ Positive Response #2
Acknowledge Sub Message #2 ⇨
⇦ Positive Response #m
Acknowledge Sub Message #m ⇨
⇦ Positive Response (Data Field
Acknowledge Sub Message (optional) ⇨
…
Transfer Data Request #n ⇨
⇦ Positive Response
Request Transfer Exit ⇨
⇦ Positive Response
Stop Communication Request ⇨
⇦ Positive Response
2.2.4 Timing
DDP_019 Während des normalen Betriebs sind die in der folgenden
Abbildung dargestellten Timing-Parameter relevant:
Abbildung 1
Nachrichtenfluss, Timing
Hierbei sind:
P1 = Zeit zwischen den Bytes bei VU-Antwort.
P2 = Zeit zwischen dem Ende der IDE-Anforderung und
dem Beginn der VU-Antwort bzw. zwischen dem
Ende der IDE-Quittung und dem Beginn der nächsten
VU-Antwort.
P3 = Zeit zwischen dem Ende der VU-Antwort und dem
Beginn der neuen IDE-Anforderung bzw. zwischen
dem Ende der VU-Antwort und dem Beginn der
IDE-Quittung bzw. zwischen dem Ende der
IDE-Anforderung und dem Beginn der neuen
IDE-Anforderung, wenn VU nicht antwortet.
P4 = Zeit zwischen den Bytes bei IDE-Anforderung.
P5 = Erweiterter Wert von P3 für das Herunterladen der
Karte.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 339
Die zulässigen Werte für die Timing-Parameter sind in der
folgenden Tabelle aufgeführt (KWP — erweiterter Timing-
Parametersatz, verwendet bei physischer Adressierung
zwecks schnellerer Kommunikation).
Timing-Parameter
Unterer Grenzwert
(ms)
Oberer Grenzwert
(ms)
P1 0 20
P2 20 1 000 (*)
P3 10 5 000
P4 5 20
P5 10 20 Minuten
(*) Wenn die VU mit einer negativen Antwort reagiert, die einen Code mit der Bedeutung „Anforderung korrekt
empfangen, Antwort kommt“ enthält, wird dieser Wert auf den gleichen oberen Grenzwert erweitert wie P3.
2.2.5 Fehlerbehandlung
Tritt während des Nachrichtenaustauschs ein Fehler auf, erfolgt eine
Modifizierung des Nachrichtenflusses in Abhängigkeit von dem Gerät,
das den Fehler erkannt hat, sowie von der Nachricht, die den Fehler
hervorgerufen hat.
In Abbildung 2 und 3 sind die Fehlerbehandlungsprozeduren für die
VU bzw. für das IDE dargestellt.
2.2.5.1 S t a r t C o m m u n i c a t i o n - P h a s e
DDP_020 Erkennt das IDE einen Fehler während der Start Communi­
cation-Phase entweder durch Timing oder durch den Bit­
strom, wartet es P3min bis zur erneuten Ausgabe der An­
forderung.
DDP_021 Erkennt die VU einen Fehler in der vom IDE eingehenden
Folge, sendet sie keine Antwort und wartet innerhalb des
Zeitraums P3max auf eine weitere Nachricht Start Commu­
nication Request.
2.2.5.2 C o m m u n i c a t i o n - P h a s e
Es lassen sich zwei verschiedene Fehlerbehandlungsbereiche definieren:
1. Die VU erkennt einen IDE-Übertragungsfehler.
DDP_022 Die VU prüft jede empfangene Nachricht auf Timing-
Fehler, Byteformatfehler (z. B. Start- und Stoppbitverlet­
zungen) sowie Datenpaketfehler (falsche Byteanzahl emp­
fangen, falsches Prüfsummenbyte).
DDP_023 Erkennt die VU einen der vorstehend genannten Fehler,
sendet sie keine Antwort und ignoriert die empfangene
Nachricht.
DDP_024 Die VU kann andere Fehler im Format oder Inhalt der
empfangenen Nachricht (z. B. Nachricht nicht unterstützt)
feststellen, selbst wenn die Nachricht die erforderlichen
Längen und Prüfsummen einhält; in diesem Fall antwortet
die VU dem IDE mit einer Negative Response-Nachricht
unter Angabe der Fehlerart.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 340
Abbildung 2
Fehlerbehandlung durch die VU
▼B
2. Das IDE erkennt einen VU-Übertragungsfehler.
DDP_025 Das IDE prüft jede empfangene Nachricht auf
Timing-Fehler, Byteformatfehler (z. B. Start- und Stopp­
bitverletzungen) sowie Datenpaketfehler (falsche Byte­
anzahl empfangen, falsches Prüfsummenbyte).
DDP_026 Das IDE erkennt Sequenzfehler, z. B. die inkorrekte Er­
höhung des Teilnachrichtenzählers bei nacheinander emp­
fangenen Nachrichten.
DDP_027 Erkennt das IDE einen Fehler oder ist innerhalb des Zeit­
raums P2max keine Antwort von der VU erfolgt, wird die
Anforderungsnachricht für insgesamt maximal drei Über­
tragungen erneut gesendet. Zum Zwecke dieser Fehler­
erkennung wird eine Teilnachrichtquittung als Anforde­
rung an die VU betrachtet.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 341
DDP_028 Vor dem Beginn jeder Sendung wartet das IDE mindes­
tens P3min; die Wartezeit wird vom letzten errechneten
Auftreten eines Stoppbits nach der Fehlererkennung an
gemessen.
Abbildung 3
Fehlerbehandlung durch das IDE
2.2.6 Inhalt der Antwortnachricht
In diesem Abschnitt wird der Inhalt der Datenfelder der verschiedenen
positiven Antwortnachrichten spezifiziert.
Die Datenelemente sind in Anlage 1, Datenglossar, definiert.
Hinweis: Bei Downloads der 2. Generation wird jedes oberste Daten­
element durch ein Datensatz-Array repräsentiert, auch wenn dieser le­
diglich einen Datensatz umfasst. Ein Datensatz-Array beginnt mit dem
Kopf; dieser Kopf enthält Datensatztyp, Datensatzgröße und die Anzahl
an Datensätzen. Die Datensatz-Arrays sind in den folgenden Tabellen
durch „… RecordArray“ (mit Kopf) gekennzeichnet.
▼M3
2.2.6.1 P o s i t i v e R e s p o n s e T r a n s f e r D a t a D o w n l o a d I n t e r ­
f a c e V e r s i o n ( P o s i t i v e A n t w o r t D a t e n ü b e r t r a g u n g ,
V e r s i o n d e r D o w n l o a d - S c h n i t t s t e l l e )
DDP_028a Das Datenfeld der Nachricht „Positive Response Transfer
Data Download Interface Version“ liefert folgende Daten in
folgender Reihenfolge unter SID 76 Hex und TREP 00 Hex:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 342
Datenstruktur der 2. Generation, Version 2 (TREP 00 Hex)
Datenelement Bemerkung
DownloadInterfaceVersion Generation und Version der VU: 02,02 Hex für
2. Generation, Version 2
Nicht unterstützt von VU 1. Generation und 2. Ge­
neration, Version 1, die negativ antworten (Unter­
funktion nicht unterstützt, siehe DDP_018)
2.2.6.2 P o s i t i v e R e s p o n s e T r a n s f e r D a t a O v e r v i e w ( P o s i ­
t i v e A n t w o r t D a t e n ü b e r t r a g u n g , Ü b e r b l i c k )
DDP_029 Das Datenfeld der Nachricht „Positive Response Transfer
Data Overview“ liefert folgende Daten in folgender Rei­
henfolge unter SID 76 Hex und TREP 01, 21 oder 31 Hex.
Es muss eine geeignete Aufteilung und Zählung der Teil­
nachrichten erfolgen:
Datenstruktur der 1. Generation (TREP 01 Hex)
Datenelement Bemerkung
MemberStateCertificate VU-Sicherheitszertifikate
VUCertificate
VehicleIdentificationNumber Fahrzeugkennung
VehicleRegistrationIdentification
CurrentDateTime Aktuelle(s) Datum und Uhrzeit der VU
VuDownloadablePeriod Herunterladbarer Zeitraum
CardSlotsStatus Art der in die VU eingesteckten Karten
VuDownloadActivityData Vorhergehender VU-Download
VuCompanyLocksData Alle gespeicherten Unternehmenssperren. Ist der
Abschnitt leer, wird lediglich noOfLocks = 0 ge­
sendet.
VuControlActivityData Alle in der VU gespeicherten Kontrolldatensätze.
Ist der Abschnitt leer, wird lediglich noOfCon­
trols = 0 gesendet.
Signature RSA-Signatur aller Daten (außer Zertifikate), be­
ginnend mit VehicleIdentificationNumber bis hin
zum letzten Byte des letzten VuControlActivity­
Data.
Datenstruktur der 2. Generation, Version 1 (TREP 21 Hex)
Datenelement Bemerkung
MemberStateCertificateRecordArray Zertifikat des Mitgliedstaates
VUCertificateRecordArray VU-Zertifikat
VehicleIdentificationNumberRecordArray Fahrzeugkennung
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 343
Datenelement Bemerkung
VehicleRegistrationIdentificationRecordArray Amtliches Kennzeichen des Fahrzeugs
CurrentDateTimeRecordArray Aktuelle(s) Datum und Uhrzeit der VU
VuDownloadablePeriodRecordArray Herunterladbarer Zeitraum
CardSlotsStatusRecordArray Art der in die VU eingesteckten Karten
VuDownloadActivityDataRecordArray Vorhergehender VU-Download
VuCompanyLocksRecordArray Alle gespeicherten Unternehmenssperren. Ist der
Abschnitt leer, wird ein Array-Kopf mit noOfRe­
cords = 0 gesendet.
VuControlActivityRecordArray Alle in der VU gespeicherten Kontrolldatensätze.
Ist der Abschnitt leer, wird ein Array-Kopf mit
noOfRecords = 0 gesendet.
SignatureRecordArray ECC-Signatur aller vorhergehenden Daten mit
Ausnahme der Zertifikate.
Datenstruktur der 2. Generation, Version 2 (TREP 31 Hex)
Datenelement Bemerkung
MemberStateCertificateRecordArray Zertifikat des Mitgliedstaates
VUCertificateRecordArray VU-Zertifikat
VehicleIdentificationNumberRecordArray Fahrzeugkennung
VehicleRegistrationNumberRecordArray Amtliches Kennzeichen des Fahrzeugs
CurrentDateTimeRecordArray Aktuelle(s) Datum und Uhrzeit der VU
VuDownloadablePeriodRecordArray Herunterladbarer Zeitraum
CardSlotsStatusRecordArray Art der in die VU eingesteckten Karten
VuDownloadActivityDataRecordArray Vorhergehender VU-Download
VuCompanyLocksRecordArray Alle gespeicherten Unternehmenssperren. Ist der
Abschnitt leer, wird ein Array-Kopf mit noOfRe­
cords = 0 gesendet.
VuControlActivityRecordArray Alle in der VU gespeicherten Kontrolldatensätze.
Ist der Abschnitt leer, wird ein Array-Kopf mit
noOfRecords = 0 gesendet.
SignatureRecordArray ECC-Signatur aller vorhergehenden Daten mit
Ausnahme der Zertifikate.
2.2.6.3 P o s i t i v e R e s p o n s e T r a n s f e r D a t a A c t i v i t i e s ( P o s i ­
t i v e A n t w o r t D a t e n ü b e r t r a g u n g , T ä t i g k e i t e n )
DDP_030 Das Datenfeld der Nachricht „Positive Response Transfer
Data Activities“ liefert folgende Daten in folgender Rei­
henfolge unter SID 76 Hex und TREP 02, 22 oder 32 Hex.
Es muss eine geeignete Aufteilung und Zählung der Teil­
nachrichten erfolgen:
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 344
Datenstruktur der 1. Generation (TREP 02 Hex)
Datenelement Bemerkung
TimeReal Datum des heruntergeladenen Tages
OdometerValueMidnight Kilometerstand am Ende des heruntergeladenen Tages
VuCardIWData Daten zu den Einsteck-/Entnahmevorgängen dieser
Karte.
— Enthält dieser Abschnitt keine verfügbaren Daten,
wird lediglich noOfVuCardIWRecords = 0 gesen­
det.
— Geht ein VuCardIWRecord über 00.00 Uhr (Einste­
cken der Karte am Vortag) oder 24.00 Uhr (Karten­
entnahme am Folgetag) hinaus, erscheint er voll­
ständig für beide Tage.
VuActivityDailyData Steckplatzstatus um 00.00 Uhr und aufgezeichnete Tä­
tigkeitsänderungen für den heruntergeladenen Tag.
VuPlaceDailyWorkPeriodData Aufgezeichnete Ortsdaten für den heruntergeladenen
Tag. Ist der Abschnitt leer, wird lediglich noOfPlaceRe­
cords = 0 gesendet.
VuSpecificConditionData Aufgezeichnete spezifische Bedingungen für den herun­
tergeladenen Tag. Ist der Abschnitt leer, wird lediglich
noOfSpecificConditionRecords = 0 gesendet.
Signature RSA-Signatur aller Daten, beginnend mit TimeReal bis
hin zum letzten Byte des letzten Datensatzes einer spe­
zifischen Bedingung.
Datenstruktur der 2. Generation, Version 1 (TREP 22 Hex)
Datenelement Bemerkung
DateOfDayDownloadedRecordArray Datum des heruntergeladenen Tages
OdometerValueMidnightRecordArray Kilometerstand am Ende des heruntergeladenen Tages
VuCardIWRecordArray Daten zu den Einsteck-/Entnahmevorgängen dieser
Karte.
— Enthält dieser Abschnitt keine verfügbaren Daten,
wird lediglich ein Array-Kopf mit noOfRecords =
0 gesendet.
— Geht ein VuCardIWRecord über 00.00 Uhr (Einste­
cken der Karte am Vortag) oder 24.00 Uhr (Karten­
entnahme am Folgetag) hinaus, erscheint er voll­
ständig für beide Tage.
VuActivityDailyRecordArray Steckplatzstatus um 00.00 Uhr und aufgezeichnete Tä­
tigkeitsänderungen für den heruntergeladenen Tag.
VuPlaceDailyWorkPeriodRecordArray Aufgezeichnete Ortsdaten für den heruntergeladenen
Tag. Ist der Abschnitt leer, wird ein Array-Kopf mit
noOfRecords = 0 gesendet.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 345
Datenelement Bemerkung
VuGNSSADRecordArray 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.
VuSpecificConditionRecordArray Aufgezeichnete spezifische Bedingungen für den herun­
tergeladenen Tag. Ist der Abschnitt leer, wird ein
Array-Kopf mit noOfRecords = 0 gesendet.
SignatureRecordArray ECC-Signatur aller vorhergehenden Daten.
Datenstruktur der 2. Generation, Version 2 (TREP 32 Hex)
Datenelement Bemerkung
DateOfDayDownloadedRecordArray Datum des heruntergeladenen Tages
OdometerValueMidnightRecordArray Kilometerstand am Ende des heruntergeladenen Tages
VuCardIWRecordArray Daten zu den Einsteck-/Entnahmevorgängen dieser
Karte.
— Enthält dieser Abschnitt keine verfügbaren Daten,
wird lediglich ein Array-Kopf mit noOfRecords =
0 gesendet.
— Geht ein VuCardIWRecord über 00.00 Uhr (Einste­
cken der Karte am Vortag) oder 24.00 Uhr (Karten­
entnahme am Folgetag) hinaus, erscheint er voll­
ständig für beide Tage.
VuActivityDailyRecordArray Steckplatzstatus um 00.00 Uhr und aufgezeichnete Tä­
tigkeitsänderungen für den heruntergeladenen Tag.
VuPlaceDailyWorkPeriodRecordArray Aufgezeichnete Ortsdaten für den heruntergeladenen
Tag. Ist der Abschnitt leer, wird ein Array-Kopf mit
noOfRecords = 0 gesendet.
VuGNSSADRecordArray 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.
VuSpecificConditionRecordArray Aufgezeichnete spezifische Bedingungen für den herun­
tergeladenen Tag. Ist der Abschnitt leer, wird ein
Array-Kopf mit noOfRecords = 0 gesendet.
VuBorderCrossingRecordArray Grenzüberschreitungen für den heruntergeladenen Tag.
Ist der Abschnitt leer, wird ein Array-Kopf mit noO­
fRecords = 0 gesendet.
VuLoadUnloadRecordArray Be-/Entladevorgänge für den heruntergeladenen Tag. Ist
der Abschnitt leer, wird ein Array-Kopf mit noOfRe­
cords = 0 gesendet.
SignatureRecordArray ECC-Signatur aller vorhergehenden Daten.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 346
2.2.6.4 P o s i t i v e R e s p o n s e T r a n s f e r D a t a E v e n t s a n d F a u l t s
( P o s i t i v e A n t w o r t D a t e n ü b e r t r a g u n g , E r e i g n i s s e
u n d S t ö r u n g e n )
DDP_031 Das Datenfeld der Nachricht „Positive Response Transfer
Data Events and Faults“ liefert folgende Daten in folgender
Reihenfolge unter SID 76 Hex und TREP 03, 23 oder
33 Hex. Es muss eine geeignete Aufteilung und Zählung
der Teilnachrichten erfolgen:
Datenstruktur der 1. Generation (TREP 03 Hex)
Datenelement Bemerkung
VuFaultData Alle in der VU gespeicherten oder andauernden Störun­
gen.
Ist der Abschnitt leer, wird lediglich noOfVuFaults = 0
gesendet.
VuEventData Alle in der VU gespeicherten oder andauernden Ereig­
nisse (außer Geschwindigkeitsüberschreitung).
Ist der Abschnitt leer, wird lediglich noOfVuEvents = 0
gesendet.
VuOverSpeedingControlData Daten zur letzten Kontrolle Geschwindigkeitsüberschrei­
tung (Standardwert, wenn keine Daten vorhanden).
VuOverSpeedingEventData Alle in der VU gespeicherten Ereignisse Geschwindig­
keitsüberschreitung.
Ist der Abschnitt leer, wird lediglich noOfVuOverSpee­
dingEvents = 0 gesendet.
VuTimeAdjustmentData Alle in der VU gespeicherten Zeiteinstellungsereignisse
(außerhalb des Rahmens einer vollständigen Kalibrie­
rung).
Ist der Abschnitt leer, wird lediglich noOfVuTime­
AdjRecords = 0 gesendet.
Signature RSA-Signatur aller Daten, beginnend mit noOfVuFaults
bis hin zum letzten Byte des letzten Zeiteinstellungs­
datensatzes.
Datenstruktur der 2. Generation, Version 1 (TREP 23 Hex)
Datenelement Bemerkung
VuFaultRecordArray Alle in der VU gespeicherten oder andauernden Störun­
gen.
Ist der Abschnitt leer, wird ein Array-Kopf mit noO­
fRecords = 0 gesendet.
VuEventRecordArray Alle in der VU gespeicherten oder andauernden Ereig­
nisse (außer Geschwindigkeitsüberschreitung).
Ist der Abschnitt leer, wird ein Array-Kopf mit noO­
fRecords = 0 gesendet.
VuOverSpeedingControlDataRecordArray Daten zur letzten Kontrolle Geschwindigkeitsüberschrei­
tung (Standardwert, wenn keine Daten vorhanden).
VuOverSpeedingEventRecordArray Alle in der VU gespeicherten Ereignisse Geschwindig­
keitsüberschreitung.
Ist der Abschnitt leer, wird ein Array-Kopf mit noO­
fRecords = 0 gesendet.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 347
Datenelement Bemerkung
VuTimeAdjustmentRecordArray Alle in der VU gespeicherten Zeiteinstellungsereignisse
(außerhalb des Rahmens einer vollständigen Kalibrie­
rung).
Ist der Abschnitt leer, wird ein Array-Kopf mit noO­
fRecords = 0 gesendet.
SignatureRecordArray ECC-Signatur aller vorhergehenden Daten.
Datenstruktur der 2. Generation, Version 2 (TREP 33 Hex)
Datenelement Bemerkung
VuFaultRecordArray Alle in der VU gespeicherten oder andauernden Störun­
gen.
Ist der Abschnitt leer, wird ein Array-Kopf mit noO­
fRecords = 0 gesendet.
VuEventRecordArray Alle in der VU gespeicherten oder andauernden Ereig­
nisse (außer Geschwindigkeitsüberschreitung).
Ist der Abschnitt leer, wird ein Array-Kopf mit noO­
fRecords = 0 gesendet.
VuOverSpeedingControlDataRecordArray Daten zur letzten Kontrolle Geschwindigkeitsüberschrei­
tung (Standardwert, wenn keine Daten vorhanden).
VuOverSpeedingEventRecordArray Alle in der VU gespeicherten Ereignisse Geschwindig­
keitsüberschreitung.
Ist der Abschnitt leer, wird ein Array-Kopf mit noO­
fRecords = 0 gesendet.
VuTimeAdjustmentRecordArray Alle in der VU gespeicherten Zeiteinstellungsereignisse
(außerhalb des Rahmens einer vollständigen Kalibrie­
rung).
Ist der Abschnitt leer, wird ein Array-Kopf mit noO­
fRecords = 0 gesendet.
SignatureRecordArray ECC-Signatur aller vorhergehenden Daten.
2.2.6.5 P o s i t i v e R e s p o n s e T r a n s f e r D a t a D e t a i l e d S p e e d
( P o s i t i v e A n t w o r t D a t e n ü b e r t r a g u n g , g e n a u e G e ­
s c h w i n d i g k e i t s a n g a b e n )
DDP_032 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 Teil­
nachrichten erfolgen:
Datenstruktur der 1. Generation (TREP 04 Hex)
Datenelement Bemerkung
VuDetailedSpeedData Alle in der VU gespeicherten detaillierten Geschwindig­
keitsdaten (ein Geschwindigkeitsblock pro Minute, in
der sich das Fahrzeug bewegt hat).
60 Geschwindigkeitswerte pro Minute (ein Wert pro
Sekunde).
Signature RSA-Signatur aller Daten, beginnend mit noOfSpeed­
Blocks bis hin zum letzten Byte des letzten Geschwin­
digkeitsblocks.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 348
Datenstruktur der 2. Generation (TREP 24 Hex)
Datenelement Bemerkung
VuDetailedSpeedBlockRecordArray Alle in der VU gespeicherten detaillierten Geschwindig­
keitsdaten (ein Geschwindigkeitsblock pro Minute, in
der sich das Fahrzeug bewegt hat).
60 Geschwindigkeitswerte pro Minute (ein Wert pro
Sekunde).
SignatureRecordArray ECC-Signatur aller vorhergehenden Daten.
2.2.6.6 P o s i t i v e R e s p o n s e T r a n s f e r D a t a T e c h n i c a l D a t a
( P o s i t i v e A n t w o r t D a t e n ü b e r t r a g u n g , T e c h n i s c h e
D a t e n )
DDP_033 Das Datenfeld der Nachricht „Positive Response Transfer
Data Technical Data“ liefert folgende Daten in folgender
Reihenfolge unter SID 76 Hex und TREP 05, 25 oder
35 Hex. Es muss eine geeignete Aufteilung und Zählung
der Teilnachrichten erfolgen:
Datenstruktur der 1. Generation (TREP 05 Hex)
Datenelement Bemerkung
VuIdentification
SensorPaired
VuCalibrationData Alle in der VU gespeicherten Kalibrierungsdatensätze.
Signature RSA-Signatur aller Daten, beginnend mit vuManufactu­
rerName bis hin zum letzten Byte des letzten VuCali­
brationRecord.
Datenstruktur der 2. Generation, Version 1 (TREP 25 Hex)
Datenelement Bemerkung
VuIdentificationRecordArray
VuSensorPairedRecordArray Alle in der VU gespeicherten MS-Kopplungen.
VuSensorExternalGNSSCoupledRecordAr­
ray
Alle in der VU gespeicherten Kopplungen externer
GNSS-Ausrüstung.
VuCalibrationRecordArray Alle in der VU gespeicherten Kalibrierungsdatensätze.
VuCardRecordArray Alle in der VU gespeicherten Karteneinsteckdaten.
VuITSConsentRecordArray
VuPowerSupplyInterruptionRecordArray
SignatureRecordArray ECC-Signatur aller vorhergehenden Daten.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 349
Datenstruktur der 2. Generation, Version 2 (TREP 35 Hex)
Datenelement Bemerkung
VuIdentificationRecordArray
VuSensorPairedRecordArray Alle in der VU gespeicherten MS-Kopplungen.
VuSensorExternalGNSSCoupledRecordAr­
ray
Alle in der VU gespeicherten Kopplungen externer
GNSS-Ausrüstung.
VuCalibrationRecordArray Alle in der VU gespeicherten Kalibrierungsdatensätze.
VuCardRecordArray Alle in der VU gespeicherten Karteneinsteckdaten.
VuITSConsentRecordArray
VuPowerSupplyInterruptionRecordArray
SignatureRecordArray ECC-Signatur aller vorhergehenden Daten.
▼B
2.3. ESM-Datenspeicherung
DDP_034 War eine VU-Datenübertragung Bestandteil eines
Download-Vorgangs, speichert das IDE in einer einzigen
physischen Datei alle Daten, die während des Download-
Vorgangs von der VU in Positive Response Transfer
Data-Nachrichten empfangen wurden. Dabei nicht gespei­
chert werden Nachrichtenköpfe, Teilnachrichtenzähler, leere
Teilnachrichten und Prüfsummen, gespeichert werden je­
doch SID und TREP (nur der ersten Teilnachricht bei meh­
reren Teilnachrichten).
3. PROTOKOLL FÜR DAS HERUNTERLADEN VON DATEN VON
FAHRTENSCHREIBERKARTEN
3.1. Geltungsbereich
Dieser Abschnitt beschreibt das direkte Herunterladen der Kartendaten
einer Kontrollgerätkarte auf ein IDE. Da das IDE nicht Bestandteil der
Sicherheitsumgebung ist, erfolgt keine Authentisierung zwischen der
Karte und dem IDE.
3.2. Begriffsbestimmungen
Download-Vorgang: Die Ausführung eines Download der Chipkar­
tendaten. Der Vorgang umfasst die gesamte
Prozedur vom Zurücksetzen der Chipkarte
durch ein IFD bis zur Deaktivierung der Chip­
karte (Entnahme der Karte oder nächstes Zu­
rücksetzen).
Signierte Datei: Eine Datei von der Chipkarte. Die Datei wird
in Klartext zum IFD übertragen. Auf der Chip­
karte erfolgt eine Hash-Code-Anwendung für
die Datei, sie wird signiert, und die Signatur
wird an das IFD übertragen.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 350
3.3. Herunterladen von der Karte
▼M3
DDP_035 Das Herunterladen einer Fahrtenschreiberkarte beinhaltet die
folgenden Schritte:
— Herunterladen der gemeinsamen Informationen der Karte
in den EF ICC und IC. Diese Informationen sind fakul­
tativ und werden nicht mit einer digitalen Signatur
gesichert.
— Für Fahrtenschreiberkarten der 1. und 2. Generation:
— Herunterladen der EF innerhalb der Tachograph DF
— Herunterladen der EF Card_Certificate und
CA_Certificate. 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 Tachograph DF) außer EF
Card_Download. Diese Informationen werden
mit einer digitalen Signatur gemäß Anlage 11
Gemeinsame Sicherheitsmechanismen Teil A
gesichert.
— Bei jedem Herunterladen ist zumindest das He­
runterladen der EF Application_Identification
und Identification obligatorisch.
— Beim Herunterladen einer Fahrerkarte ist zudem
der Download folgender EF obligatorisch:
Events_Data
Faults_Data
Driver_Activity_Data
Vehicles_Used
Places
Control_Activity_Data
Specific_Conditions.
— Nur für Fahrtenschreiberkarten der 2. Generation:
— Herunterladen der EF innerhalb der DF Tacho­
graph_G2, außer im Fall von Datendownloads einer
in eine VU eingesteckten Fahrerkarte bei Kontrollen
durch eine Nicht-EU-Kontrollbehörde mit einer Kon­
trollkarte der 1. Generation:
— Herunterladen der EF CardSignCertificate,
CA_Certificate und Link_Certificate. Diese In­
formationen werden nicht mit einer digitalen Sig­
natur gesichert.
— Das Herunterladen dieser Dateien ist bei jedem
Download-Vorgang obligatorisch.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 351
— Herunterladen der anderen Anwendungsdaten-EF
(innerhalb der DF Tachograph_G2) außer EF
Card_Download. Diese Informationen werden
mit einer digitalen Signatur gemäß Anlage 11
Gemeinsame Sicherheitsmechanismen Teil B
gesichert.
— Bei jedem Herunterladen ist zumindest das He­
runterladen der EF Application_Identification,
Application_Identification_V2 (wenn vorhanden)
und Identification obligatorisch.
— Beim Herunterladen einer Fahrerkarte ist zudem
der Download folgender EF obligatorisch:
Events_Data
Faults_Data
Driver_Activity_Data
Vehicles_Used
Places
Control_Activity_Data
Specific_Conditions
VehicleUnits_Used
GNSS_Places
Places_Authentication, wenn vorhanden
GNSS_Places_Authentication, wenn vorhanden
Border_Crossings, wenn vorhanden
Load_Unload_Operations, wenn vorhanden
Load_Type_Entries, wenn vorhanden
— Beim Herunterladen einer Fahrerkarte wird das Da­
tum LastCardDownload in der EF Card_Download,
in der DF Tachograph und gegebenenfalls in der
DF Tachograph_G2 aktualisiert.
— Beim Herunterladen einer Werkstattkarte ist der
Kalibrierungszähler in der EF CardDownload in
der DF Tachograph und gegebenenfalls in der
DF Tachograph_G2 zurückzusetzen.
— Beim Herunterladen einer Werkstattkarte ist
EF Sensor_Installation_Data in der DF Tacho­
graph und gegebenenfalls in der DF Tacho­
graph_G2 nicht herunterzuladen.
▼B
3.3.1 Initialisierungssequenz
DDP_036 Das IDE leitet die folgende Sequenz ein:
Karte Richtung IDE/IFD Bedeutung/Bemerkungen
⇦ Hardware zurücksetzen
ATR ⇨
Mit PPS kann auf eine höhere Baudrate gewechselt werden,
sofern die Chipkarte diese Baudrate unterstützt.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 352
3.3.2 Sequenz für unsignierte Dateien
DDP_037 ►M1 Die Sequenz für das Herunterladen der EF ICC, IC,
Card_Certificate (oder CardSignCertificate für DF Tacho­
graph_G2), CA_Certificate und Link_Certificate (nur für
DF Tachograph_G2) lautet folgendermaßen: ◄
Karte Richtung IDE/IFD Bedeutung/Bemerkungen
⇦ Select File Auswahl nach Dateikennung
OK ⇨
⇦ Read Binary Enthält die Datei mehr Daten,
als der Puffer des Lesers oder
der Karte fassen kann, ist der
Befehl so lange zu wieder­
holen, bis die gesamte Datei
ausgelesen ist.
File Data
OK
⇨ Daten auf ESM speichern gemäß 3.4 Data storage for­
mat
Hinweis 1: Vor Auswahl der EF Card_Certificate (Card­
SignCertificate) muss die Fahrtenschreiberanwendung aus­
gewählt werden (Auswahl durch AID).
Hinweis 2: Das Auswählen und Auslesen einer Datei kann
mithilfe des Befehls Read Binary mit Kurz-Elementardatei­
kennung in einem Schritt erfolgen.
3.3.3 Sequenz für signierte Dateien
DDP_038 Die folgende Sequenz wird für die folgenden Dateien ver­
wendet, die jeweils mit ihrer Signatur herunterzuladen sind:
▼M1
Karte Richtung IDE/IFD Bedeutung/Bemerkungen
Select File
OK
Perform Hash of File — Berechnet den Hashwert
über dem Dateninhalt
der ausgewählten Datei
mithilfe des vorgeschrie­
benen Hash-Algorithmus
gemäß Anlage 11 Teil A
oder B. Dieser Befehl ist
kein ISO-Befehl.
Hash of File berechnen
und Hashwert temporär
speichern
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 353
Karte Richtung IDE/IFD Bedeutung/Bemerkungen
OK
Read Binary Enthält die Datei mehr Daten,
als der Puffer des Lesers oder
der Karte fassen kann, ist der
Befehl so lange zu wieder­
holen, bis die gesamte Datei
ausgelesen ist.
File Data
OK
Empfangene Daten auf ESM
speichern
gemäß 3.4 Data storage for­
mat
PSO: Compute Digital
Signature
Perform Security Ope­
ration ‚Compute Digi­
tal Signature‘ mithilfe
des temporär gespei­
cherten Hashwerts
Signature
OK
Daten an die zuvor auf dem
ESM gespeicherten Daten
anfügen
gemäß 3.4 Data storage for­
mat
▼B
Hinweis: Das Auswählen und Auslesen einer Datei kann
mithilfe des Befehls Read Binary mit Kurz-Elementardatei­
kennung in einem Schritt erfolgen. In diesem Fall kann die
EF ausgewählt und ausgelesen werden, bevor der Befehl
Perform Hash of File angewendet wird.
3.3.4 Sequenz für das Zurücksetzen des Kalibrierungszählers
DDP_039 Die Sequenz für das Zurücksetzen des Zählers­
in der EF
auf einer Werkstattkarte lautet folgen­
dermaßen:
Karte Richtung IDE/IFD Bedeutung/Bemerkungen
⇦ Select File EF
Card_Download
Auswahl nach Dateikennung
OK ⇨
⇦ Update Binary
NoOfCalibrationsSince­
Download = „00 00“
setzt Kartendownload
zurück
OK ⇨
Hinweis: Das Auswählen und Aktualisieren einer Datei
kann mithilfe des Befehls Update Binary mit Kurz-Elemen­
tardateikennung in einem Schritt erfolgen.
▼M1
02016R0799 — DE — 21.08.2023 — 003.002 — 354
3.4. Datenspeicherungsformat
3.4.1 Einleitung
DDP_040 Die heruntergeladenen Daten sind nach folgenden Bedin­
gungen zu speichern:
— Die Daten sind transparent zu speichern, d. h. die Rei­
henfolge der von der Karte übertragenen Bytes sowie
die Reihenfolge der in ihnen enthaltenen Bits müssen
während der Speicherung erhalten bleiben.
— Alle im Rahmen eines Download-Vorgangs herunter­
geladenen Dateien der Karte werden in einer einzigen
Datei auf dem ESM gespeichert
3.4.2 Dateiformat
DDP_041 Das Dateiformat ist eine Verkettung mehrerer TLV-Objekte.
DDP_042 Der Tag für eine EF ist die FID sowie der Zusatz „00“.
DDP_043 Der Tag der Signatur einer EF ist die FID der Datei sowie
der Zusatz „01“.
DDP_044 Die Länge ist ein 2-Byte-Wert. Der Wert legt die Anzahl
der Bytes im Wertfeld fest. Der Wert „FF FF“ im Längen­
feld ist für eine künftige Verwendung reserviert.
DDP_045 Wird eine Datei nicht heruntergeladen, ist auch nichts zu
speichern, was mit der Datei im Zusammenhang steht (also
kein Tag und keine Nulllänge).
▼M1
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 ge­
meinsame 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
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 355
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
▼B
4. HERUNTERLADEN VON DER FAHRTENSCHREIBERKARTE
ÜBER EINE FAHRZEUGEINHEIT
DDP_047 Die VU muss das Herunterladen des Inhalts einer einge­
steckten und an ein IDE angeschlossenen Fahrerkarte
zulassen.
DDP_048 Zum Starten dieses Modus sendet das IDE die Nachricht
Transfer Data Request Card Download an die VU (siehe
2.2.2.9).
▼M1
DDP_049 Fahrerkarten der 1. Generation: Für den Datendownload
wird das Datendownload-Protokoll der 1. Generation ver­
wendet, 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 entspre­
chenden TLV-Dateiformat (siehe 3.4.2) sowie eingekapselt
in eine „Positive Response Transfer Data“-Nachricht an das
IDE weiter.
▼B
DDP_050 Das IDE ruft die Kartendaten aus der Nachricht Positive
Response Transfer Data ab (unter Fortlassung aller Köpfe,
SID, TREP, Teilnachrichtenzähler und Prüfsummen) und
speichert sie innerhalb einer in Abschnitt 2.3 beschriebenen
physischen Datei.
DDP_051 Danach aktualisiert die VU gegebenenfalls die Dateien
oder der Fahrer­
karte.
▼M1
02016R0799 — DE — 21.08.2023 — 003.002 — 356
Anlage 8
KALIBRIERUNGSPROTOKOLL
INHALTSVERZEICHNIS
1. EINLEITUNG
2. BEGRIFFE, BEGRIFFSBESTIMMUNGEN UND REFERENZDO­
KUMENTE
3. DIENSTEÜBERSICHT
3.1. Verfügbare Dienste
3.2. Antwortcodes
4. KOMMUNIKATIONSDIENSTE
4.1. Der Dienst StartCommunication
4.2. Der Dienst StopCommunication
4.2.1 Beschreibung der Nachricht
4.2.2 Nachrichtenformat
4.2.3 Parameterdefinition
4.3. Der Dienst TesterPresent
4.3.1 Beschreibung der Nachricht
4.3.2 Nachrichtenformat
5. VERWALTUNGSDIENSTE
5.1. Der Dienst StartDiagnosticSession
5.1.1 Beschreibung der Nachricht
5.1.2 Nachrichtenformat
5.1.3 Parameterdefinition
5.2. Der Dienst SecurityAccess
5.2.1 Beschreibung der Nachricht
5.2.2 Nachrichtenformat — SecurityAccess — requestSeed
5.2.3 Nachrichtenformat — SecurityAccess — sendKey
6. DATENÜBERTRAGUNGSDIENSTE
6.1. Dienst ReadDataByIdentifier
6.1.1 Beschreibung der Nachricht
6.1.2 Nachrichtenformat
6.1.3 Parameterdefinition
6.2. Der Dienst WriteDataByIdentifier
6.2.1 Beschreibung der Nachricht
6.2.2 Nachrichtenformat
6.2.3 Parameterdefinition
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 357
7. PRÜFIMPULSSTEUERUNG — FUNKTIONSEINHEIT EINGABE/
AUSGABE-STEUERUNG
7.1. Der Dienst InputOutputControlByIdentifier
7.1.1 Beschreibung der Nachricht
7.1.2 Nachrichtenformat
7.1.3 Parameterdefinition
▼M3
8. DER DIENST ROUTINECONTROL (ZEITEINSTELLUNG)
8.1. Beschreibung der Nachricht
8.2. Nachrichtenformat
9. DATARECORDS-FORMATE
9.1. Wertebereiche der übertragenen Parameter
9.2. dataRecords-Formate
▼B
1. EINLEITUNG
In dieser Anlage wird der Datenaustausch zwischen einer Fahrzeugein­
heit und einem Prüfgerät über die K-Leitung, die Teil der in Anlage 6
beschriebenen Kalibrierungsschnittstelle ist, beschrieben. Außerdem
enthält sie eine Beschreibung der Steuerung der Eingangs-/Ausgangs­
signalleitung am Kalibrierungsanschluss.
Das Aufbauen der K-Leitungskommunikation wird im Abschnitt 4
„Kommunikationsdienste“ beschrieben.
In dieser Anlage ist vom Konzept der Diagnosevorgänge die Rede, mit
dem der Umfang der K-Leitungssteuerung unter verschiedenen Bedin­
gungen festgelegt wird. Der Standardvorgang ist dabei die „Standard­
DiagnosticSession“, bei der aus einer Fahrzeugeinheit alle Daten aus­
gelesen, jedoch keine Daten in die Fahrzeugeinheit geschrieben werden
können.
Die Auswahl des Diagnosevorgangs wird im Abschnitt 5 „Verwal­
tungsdienste“ beschrieben.
Dieser Anhang gilt als relevant für beide Generationen von VU- und
Werkstattkarten gemäß den in dieser Verordnung beschriebenen Inter­
operabilitätsanforderungen.
CPR_001 Im Programmiervorgang „ECUProgrammingSession“ ist es
möglich, Daten in die Fahrzeugeinheit einzugeben. Bei der
Eingabe von Kalibrierungsdaten muss sich die Fahrzeugein­
heit außerdem in der Betriebsart KALIBRIERUNG befinden.
Die Datenübertragung über die K-Leitung wird im Abschnitt
6 „Datenübertragungsdienste“ beschrieben. Die Formate der
übertragenen Daten werden in Abschnitt 8 „dataRecords-
Formate“ erläutert.
CPR_002 Der Einstellvorgang „ECUAdjustmentSession“ ermöglicht
die Auswahl der E/A-Betriebsart der Kalibrierungs-E/A-Sig­
nalleitung über die Schnittstelle der K-Leitung. Die Steue­
rung der Kalibrierungs-E/A-Signalleitung wird in Abschnitt
7 „Prüfimpulssteuerung — Funktionseinheit Eingabe/Aus­
gabe-Steuerung“ beschrieben.
CPR_003 Im vorliegenden Dokument wird als Adresse für das Prüf­
gerät durchgängig „tt“ verwendet. Ungeachtet dessen, dass
für Prüfgeräte bevorzugte Adressen verwendet werden kön­
nen, muss die VU auf jede Prüfgerätadresse richtig antwor­
ten. Die physische Adresse der VU ist 0xEE.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 358
2. BEGRIFFE, BEGRIFFSBESTIMMUNGEN UND REFERENZDOKU­
MENTE
Die Protokolle, Nachrichten und Fehlercodes beruhen grundsätzlich auf
einem Normentwurf von ISO 14229-1 (Road vehicles — Diagnostic
systems — Part 1: Diagnostic services, Version 6 vom 22. Februar
2001).
Für die Service Identifier (SID), die Bedienanforderungen und -ant­
worten sowie die Standardparameter werden Byte-Codierungen und
hexadezimale Werte verwendet.
Der Begriff „Prüfgerät“ bezeichnet das zur Eingabe der Programmie­
rungs-/Kalibrierungsdaten in die VU verwendete Gerät.
Die Begriffe „Client“ und „Server“ beziehen sich auf das Prüfgerät
bzw. die VU.
Der Begriff „ECU“ bedeutet „elektronische Steuereinheit“ und bezieht
sich auf die VU.
Referenzdokumente:
▼M1
ISO 14230-2: Road Vehicles — Diagnostic Systems — Keyword Pro­
tocol 2000 — Part 2: Data Link Layer.
First edition: 1999.
▼B
3. DIENSTEÜBERSICHT
3.1. Verfügbare Dienste
Die folgende Tabelle gibt einen Überblick über die in dieser Anlage
beschriebenen Dienste, die im Fahrtenschreiber verfügbar sein werden.
CPR_004 In der Tabelle sind die Dienste aufgeführt, die bei aktivier­
tem Diagnosevorgang verfügbar sind.
— Spalte 1 enthält die verfügbaren Dienste.
— Spalte 2 nennt den Abschnitt in der vorliegenden An­
lage, in der der Dienst näher beschrieben wird.
— Spalte 3 ordnet die Service-Identifier-Werte bei Anfor­
derungsnachrichten zu.
— Spalte 4 gibt die Dienste des Standardvorgangs„Standard­
DiagnosticSession“ (SD) an, die in jeder VU implemen­
tiert sein müssen.
— Spalte 5 gibt die Dienste des Einstellvorgangs
„ECUAdjustmentSession“ (ECUAS) an, die imple­
mentiert sein müssen, um die Steuerung der E/A-Signal­
leitung der für die Kalibrierung vorgesehenen Steckver­
bindung an der Frontplatte der VU zu gestatten.
— Spalte 6 gibt die Dienste des Programmiervorgangs
„ECUProgrammingSession“ (ECUPS) an, die imple­
mentiert sein müssen, um die Programmierung von Pa­
rametern in der VU zu ermöglichen.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 359
Tabelle 1
Übersicht über die SId-Werte
Diagnosevorgänge
Name des Diagnosedienstes
Abschnitt
Nr.
Wert SId Req. SD ECUAS ECUPS
StartCommunication 4.1 81 ■ ■ ■
StopCommunication 4.2 82 ■
TesterPresent 4.3 3E ■ ■ ■
StartDiagnosticSession 5.1 10 ■ ■ ■
SecurityAccess 5.2 27 ■ ■ ■
ReadDataByIdentifier 6.1 22 ■ ■ ■
WriteDataByIdentifier 6.2 2E ■
InputOutputControlByIdentifier 7.1 2F ■
▼M3
RoutineControl 8 31 ■ ■
▼B
■ Dieses Symbol zeigt an, dass der betreffende Dienst bei diesem Diagnosevorgang
obligatorisch ist.
Ein Feld ohne Symbol bedeutet, dass der betreffende Dienst bei diesem Diagnose­
vorgang nicht zugelassen ist.
3.2. Antwortcodes
Für jeden Dienst sind Antwortcodes festgelegt.
4. KOMMUNIKATIONSDIENSTE
Um die Kommunikation aufzubauen und aufrecht zu erhalten, sind
einige Dienste erforderlich, die nicht auf der Anwendungsschicht lie­
gen. Die zur Verfügung stehenden Dienste sind in nachstehender Ta­
belle aufgeführt:
Tabelle 2
Kommunikationsdienste
Name des Dienstes Beschreibung
StartCommunication Client fordert Beginn eines Kommuni­
kationsvorgangs mit einem (mehreren)
Server(n) an
StopCommunication Client fordert Beendigung des laufen­
den Kommunikationsvorgangs an
TesterPresent Client teilt dem Server mit, dass die
Verbindung noch aktiv ist
CPR_005 Der Dienst StartCommunication wird genutzt, um eine
Kommunikation einzuleiten. Für die Ausführung eines
Dienstes ist es immer erforderlich, dass die Kommunikation
initialisiert und die für die gewünschte Betriebsart geeig­
neten Kommunikationsparameter verwendet werden.
4.1. Der Dienst StartCommunication
CPR_006 Bei Erhalt eines StartCommunication-Primitivs prüft die VU,
ob die angeforderte Kommunikationsverbindung unter den
gegebenen Bedingungen initialisiert werden kann. Gültige
Bedingungen für die Initialisierung einer Kommunikations­
verbindung sind im Dokument ISO 14230-2 beschrieben.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 360
CPR_007 Die VU führt daraufhin alle erforderlichen Maßnahmen zur
Initialisierung der Kommunikationsverbindung aus und vers­
endet ein StartCommunication-Antwort-Primitiv mit den ge­
wählten Positive Response-Parametern.
CPR_008 Erhält eine bereits initialisierte (und in eine Diagnosesitzung
eingetretene) VU die Anforderung StartCommunication (z.
B. aufgrund Wiederanlauf des Prüfgeräts nach einer Fehler­
bedingung), muss die Anforderung angenommen und die
VU neu initialisiert werden.
CPR_009 Falls sich die Kommunikationsverbindung aus irgendeinem
Grund nicht initialisieren lässt, setzt die VU den Betrieb in
der gleichen Weise wie unmittelbar vor dem Versuch zur
Initialisierung der Kommunikationsverbindung fort.
CPR_010 Die Anforderungsnachricht StartCommunication muss an
eine physische Adresse erfolgen.
CPR_011 Die Initialisierung der VU für Dienste erfolgt mithilfe einer
„Schnellinitialisierung“:
— Jeder Aktivität geht ein Bus-Ruhezustandstakt voraus.
— Das Prüfgerät überträgt anschließend eine Initialisie­
rungssequenz.
— Alle zum Aufbau der Kommunikation benötigten Infor­
mationen sind in der Antwort der VU enthalten.
CPR_012 Nach Beendigung der Initialisierung:
— Alle Kommunikationsparameter werden entsprechend
den Schlüssel-Bytes auf die Werte in Tabelle 4 gesetzt.
— Die VU wartet auf die erste Anforderung vom Prüfgerät.
— Die VU befindet sich in der Standarddiagnosebetriebsart,
d. h. der „StandardDiagnosticSession“.
— Die Kalibrierungs-E/A-Signalleitung befindet sich im
Standardzustand, d. h. im deaktivierten Zustand.
CPR_014 Die Übertragungsgeschwindigkeit (Baudrate) auf der
K-Leitung beträgt 10 400 Baud.
CPR_016 Die Schnellinitialisierung wird ausgelöst, indem das Prüfge­
rät eine Wake-Up-Sequenz (Wup) auf der K-Leitung über­
trägt. Diese beginnt nach dem Ruhezustandstakt auf der
K-Leitung mit einem L-Takt TInil. Das Prüfgerät sendet
das erste Bit des Dienstes StartCommunication im An­
schluss an einen TWup-Takt, der nach der ersten fallenden
Flanke beginnt.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 361
CPR_017 Die Taktwerte für die Schnellinitialisierung sowie für die
Kommunikation generell sind in den nachstehenden Tabel­
len im Einzelnen aufgeführt. Für den Ruhezustandstakt exis­
tieren mehrere Möglichkeiten:
— Erste Übertragung nach Einschalten, Tidle = 300 ms.
— Nach Abschluss eines Dienstes StopCommunication,
Tidle = P3 Minimum
— Nach Beendigung der Kommunikation durch Zeitüber­
schreitung (Time-Out) P3 Maximum, Tidle = 0.
Tabelle 3
Taktwerte zur Schnellinitialisierung
Parameter Min. Max.
TInil 25 ± 1 ms 24 ms 26 ms
TWup 50 ± 1 ms 49 ms 51 ms
Tabelle 4
Taktwerte für die Kommunikation
Takt-Para­
meter
Beschreibung der Parameter
Untere Grenz­
werte [in ms]
Obere Grenz­
werte [in ms]
Min. Max.
P1 Byte-Taktabstand für die
VU-Antwort
0 20
P2 Zeit zwischen Prüfgerätanfor­
derung und VU-Antwort bzw.
zwei VU-Antworten
25 250
P3 Zeit zwischen Ende der
VU-Antworten und Beginn ei­
ner neuen Prüfgerätanforde­
rung
55 5 000
P4 Byte-Taktabstand für die Prüf­
gerätantwort
5 20
CPR_018 Das Nachrichtenformat für die Schnellinitialisierung ist in
den nachstehenden Tabellen spezifiziert.
Tabelle 5
Nachricht StartCommunication Request
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform
#1 Format-Byte — physische
Adressierung
81 FMT
#2 Zieladress-Byte EE TGT
#3 Quelladress-Byte tt SRC
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 362
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform
#4 StartCommunication Request
Service Id
81 SCR
#5 Prüfsumme 00-FF CS
Tabelle 6
Nachricht StartCommunication Positive Response
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform
#1 Format-Byte — physische
Adressierung
80 FMT
#2 Zieladress-Byte tt TGT
#3 Quelladress-Byte EE SRC
#4 Zusatzlängen-Byte 03 LEN
#5 StartCommunication Positive
Response Service
C1 SCRPR
#6 Schlüsselbyte 1 EA KB1
#7 Schlüsselbyte 2 8F KB2
#8 Prüfsumme 00-FF CS
CPR_019 Eine negative Antwort (Negative Response) auf die Anfor­
derungsnachricht StartCommunication gibt es nicht. Kann
keine positive Nachricht (Positive Response) gegeben wer­
den, so erfolgt keine Initialisierung der VU, und diese ver­
bleibt in ihrer normalen Betriebsart.
4.2. Der Dienst StopCommunication
4.2.1 Beschreibung der Nachricht
Dieser Dienst der Kommunikationssteuerungsschicht hat zum Zweck,
einen Kommunikationsvorgang zu beenden.
CPR_020 Bei Erhalt eines StopCommunication-Primitivs prüft die
VU, ob die derzeitigen Bedingungen die Beendigung dieser
Kommunikation gestatten. Ist dies der Fall, so führt die VU
alle erforderlichen Maßnahmen zur Beendigung dieser Kom­
munikation durch.
CPR_021 Ist die Beendigung der Kommunikation möglich, gibt die
VU vor der Beendigung der Kommunikation ein StopCom­
munication-Antwort-Primitiv mit den gewählten Positive
Response-Parametern aus.
CPR_022 Falls sich die Kommunikation aus irgendeinem Grund nicht
beenden lässt, gibt die VU ein StopCommunication-Ant­
wort-Primitiv mit den gewählten Parametern für Negative
Response aus.
CPR_023 Wird von der VU eine Zeitüberschreitung aufgrund P3max
erkannt, muss die Kommunikation ohne Ausgabe eines Ant­
wortelements beendet werden.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 363
4.2.2 Nachrichtenformat
CPR_024 Die Nachrichtenformate für die StopCommunication-Pri­
mitive sind in den folgenden Tabellen aufgeführt.
Tabelle 7
Nachricht StopCommunication Request
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform
#1 Format-Byte — physische
Adressierung
80 FMT
#2 Zieladress-Byte EE TGT
#3 Quelladress-Byte tt SRC
#4 Zusatzlängen-Byte 01 LEN
#5 StopCommunication Request
Service
82 SPR
#6 Prüfsumme 00-FF CS
Tabelle 8
Nachricht StopCommunication Positive Response
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform
#1 Format-Byte — physische
Adressierung
80 FMT
#2 Zieladress-Byte tt TGT
#3 Quelladress-Byte EE SRC
#4 Zusatzlängen-Byte 01 LEN
#5 StopCommunication Positive
Response Service Id
C2 SPRPR
#6 Prüfsumme 00-FF CS
Tabelle 9
Nachricht StopCommunication Negative Response
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform
#1 Format-Byte — physische
Adressierung
80 FMT
#2 Zieladress-Byte tt TGT
#3 Quelladress-Byte EE SRC
#4 Zusatzlängen-Byte 03 LEN
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 364
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform
#5 Negative Response Service Id 7F NR
#6 StopCommunication Request
Service Identification
82 SPR
#7 responseCode = generalReject 10 RC_GR
#8 Prüfsumme 00-FF CS
4.2.3 Parameterdefinition
Dieser Dienst erfordert keine Parameterdefinition.
4.3. Der Dienst TesterPresent
4.3.1 Beschreibung der Nachricht
Mithilfe des Dienstes TesterPresent teilt das Prüfgerät dem Server mit,
dass es sich noch immer in einer aktiven Verbindung mit ihm befindet,
um zu verhindern, dass der Server automatisch in die normale Betriebs­
art zurückkehrt und dadurch möglicherweise die Verbindung beendet.
Dieser Dienst sorgt durch regelmäßiges Aussenden einer Anforderung
dafür, dass die Diagnosesitzung oder Verbindung aktiv bleibt, indem
der P3-Zeitgeber bei jedem Erhalt einer Anforderung für diesen Dienst
zurückgesetzt wird.
4.3.2 Nachrichtenformat
CPR_079 Die Nachrichtenformate für die TesterPresent-Primitive sind
in den folgenden Tabellen aufgeführt.
Tabelle 10
Nachricht TesterPresent Request
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform
#1 Format-Byte — physische
Adressierung
80 FMT
#2 Zieladress-Byte EE TGT
#3 Quelladress-Byte tt SRC
#4 Zusatzlängen-Byte 02 LEN
#5 TesterPresent Request Ser­
vice Id
3E TP
#6 Sub Function = re­
sponseRequired =-
[ yes 01 RESPREQ_Y
no ] 02 RESPREQ_NO
#7 Prüfsumme 00-FF CS
CPR_080 Ist der Parameter responseRequired auf „yes“ gesetzt, so
antwortet der Server mit folgenden positiven Antwortnach­
richten. Ist der Parameter auf „no“ gesetzt, sendet der Server
keine Antwort.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 365
Tabelle 11
Nachricht TesterPresent Positive Response
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform
#1 Format-Byte — physische
Adressierung
80 FMT
#2 Zieladress-Byte tt TGT
#3 Quelladress-Byte EE SRC
#4 Zusatzlängen-Byte 01 LEN
#5 TesterPresent Positive Re­
sponse Service Id
7E TPPR
#6 Prüfsumme 00-FF CS
CPR_081 Der Dienst verwendet die folgenden negativen Antwort-
Codes:
Tabelle 12
Nachricht TesterPresent Negative Response
Byte-Nr. Parameterbezeichnung
Hex-Wert
Symbolform
#1 Format-Byte — physische Adressie­
rung
80 FMT
#2 Zieladress-Byte tt TGT
#3 Quelladress-Byte EE SRC
#4 Zusatzlängen-Byte 03 LEN
#5 Negative Response Service Id 7F NR
#6 TesterPresent Request Service Identi­
fication
3E TP
#7 response­
Code =
[SubFunctionNotSup­
ported-InvalidFormat
12 RC_SFNS_IF
incorrectMessage­
Length]
13 RC_IML
#8 Prüfsumme 00-FF CS
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 366
5. VERWALTUNGSDIENSTE
Die zur Verfügung stehenden Dienste sind in nachstehender Tabelle
aufgeführt:
Tabelle 13
Verwaltungsdienste
Name des Dienstes Beschreibung
StartDiagnosticSession Client fordert Beginn eines Diagnosevor­
gangs mit einer VU an
SecurityAccess Client ruft Funktionen auf, auf die nur be­
rechtigte Benutzer Zugriff haben.
5.1. Der Dienst StartDiagnosticSession
5.1.1 Beschreibung der Nachricht
CPR_025 Der Dienst StartDiagnosticSession dient dazu, verschiedene
Diagnosevorgänge im Server zu aktivieren. Ein Diagnose­
vorgang aktiviert bestimmte Dienste nach Maßgabe von Ta­
belle 17. Mit einem solchen Vorgang kann der Fahrzeug­
hersteller bestimmte Dienste aktivieren, die hier nicht be­
schrieben werden. Die Implementierungsregeln haben fol­
genden Festlegungen zu entsprechen:
— Es ist stets genau ein Diagnosevorgang in der VU aktiv.
— Die VU startet die „StandardDiagnosticSession“ bei je­
dem Einschaltvorgang. Wird kein anderer Diagnosevor­
gang gestartet, so läuft die „StandardDiagnosticSession“
so lange, wie die VU eingeschaltet ist.
— Wird vom Prüfgerät ein bereits laufender Diagnosevor­
gang angefordert, sendet die VU eine positive Antwort­
nachricht (Positive Response).
— Fordert das Prüfgerät einen neuen Diagnosevorgang an,
sendet die VU zuerst eine positive Antwortnachricht auf
„StartDiagnosticSession“, bevor der neue Diagnosevor­
gang in der VU aktiviert wird. Kann die VU den ange­
forderten neuen Diagnosevorgang nicht starten, antwor­
tet sie mit einer negativen Antwortnachricht auf Start­
DiagnosticSession und setzt den laufenden Diagnosevor­
gang fort.
CPR_026 Ein Diagnosevorgang darf erst begonnen werden, wenn die
Nachrichtenverbindung zwischen dem Client und der VU
errichtet wurde.
CPR_027 Nach einer erfolgreichen Anforderung StartDiagnosticSes­
sion sind die in Tabelle 4 aufgeführten Taktparameter aktiv,
wobei der Parameter diagnosticSession in der Anforderungs­
nachricht auf „StandardSession“ gesetzt ist, wenn zuvor ein
anderer Diagnosevorgang aktiv war.
5.1.2 Nachrichtenformat
CPR_028 Die Nachrichtenformate für die StartDiagnosticSession-Pri­
mitive sind in den folgenden Tabellen spezifiziert.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 367
Tabelle 14
Nachricht StartDiagnosticSession Request
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform
#1 Format-Byte — physische
Adressierung
80 FMT
#2 Zieladress-Byte EE TGT
#3 Quelladress-Byte tt SRC
#4 Zusatzlängen-Byte 02 LEN
#5 StartDiagnosticSession Re­
quest Service Id
10 STDS
#6 diagnosticSession = [ein Wert
aus Tabelle 17]
xx DS_…
#7 Prüfsumme 00-FF CS
Tabelle 15
Nachricht StartDiagnosticSession Positive Response
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform
#1 Format-Byte — physische
Adressierung
80 FMT
#2 Zieladress-Byte tt TGT
#3 Quelladress-Byte EE SRC
#4 Zusatzlängen-Byte 02 LEN
#5 StartDiagnosticSession Posi­
tive Response Service Id
50 STDSPR
#6 diagnosticSession = [gleicher
Wert wie Byte Nr. 6 in Tabelle
14]
xx DS_…
#7 Prüfsumme 00-FF CS
Tabelle 16
Nachricht StartDiagnosticSession Negative Response
Byte-Nr. Parameterbezeichnung
Hex-Wert
Symbolform
#1 Format-Byte — physische Adressie­
rung
80 FMT
#2 Zieladress-Byte tt TGT
#3 Quelladress-Byte EE SRC
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 368
Byte-Nr. Parameterbezeichnung
Hex-Wert
Symbolform
#4 Zusatzlängen-Byte 03 LEN
#5 Negative Response Service Id 7F NR
#6 StartDiagnosticSession Request Ser­
vice Id
10 STDS
#7 Response­
Code =
[subFunctionNotSup­
ported ( α ) 12 RC_SFNS
incorrectMessage­
Length ( β )
13 RC_IML
conditionsNotCor­
rect ( γ )
22 RC_CNC
#8 Prüfsumme 00-FF CS
( α ) — Der in Byte Nr. 6 der Anforderungsnachricht eingetragene Wert wird nicht
unterstützt, d. h., er ist nicht in Tabelle 17 definiert.
( β ) — Die Nachricht hat eine falsche Länge.
( γ ) — Die Bedingungen für die angeforderte StartDiagnosticSession sind nicht erfüllt.
5.1.3 Parameterdefinition
CPR_029 Der Parameter diagnosticSession (DS_) dient dem Dienst
StartDiagnosticSession dazu, das spezielle Verhalten des
Servers bzw. der Server zu wählen. Im vorliegenden Doku­
ment sind folgende Diagnosevorgänge spezifiziert:
Tabelle 17
Definition der Werte für diagnosticSession
Hex Beschreibung Symbolform
81 StandardDiagnosticSession
Dieser Diagnosevorgang aktiviert alle Dienste,
die in Spalte 4 „SD“ von Tabelle 1 angegeben
sind. Diese Dienste ermöglichen das Auslesen
der Daten von einem Server (VU). Dieser
Diagnosevorgang ist aktiv, nachdem die Initiali-
sierung zwischen Client (Prüfgerät) und
Server (VU) erfolgreich abgeschlossen wurde.
Dieser Diagnosevorgang kann durch andere in
diesem Abschnitt genannte Diagnosevorgänge
überschrieben werden.
SD
85 ECUProgrammingSession
Dieser Diagnosevorgang aktiviert alle Dienste,
die in Spalte 6 „ECUPS“ von Tabelle 1
angegeben sind. Diese Dienste unterstützen die
Speicherprogrammierung eines Servers (VU).
Dieser Diagnosevorgang kann durch andere in
diesem Abschnitt genannte Diagnosevorgänge
überschrieben werden.
ECUPS
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 369
Hex Beschreibung Symbolform
87 ECUAdjustmentSession
Dieser Diagnosevorgang aktiviert alle Dienste,
die in Spalte 5 „ECUAS“ von Tabelle 1
angegeben sind. Diese Dienste unterstützen die
Eingabe/Ausgabe-Steuerung eines Servers (VU).
Dieser Diagnosevorgang kann durch andere in
diesem Abschnitt genannte Diagnosevorgänge
überschrieben werden.
ECUAS
5.2. Der Dienst SecurityAccess
Das Schreiben von Kalibrierungsdaten ist nur dann möglich, wenn sich
die VU in der Betriebsart KALIBRIERUNG befindet. Der Zugriff auf
die Betriebsart KALIBRIERUNG wird erst gewährt, nachdem eine
gültige Werkstattkarte in die VU eingesteckt und zusätzlich die richtige
persönliche Geheimzahl (PIN) in die VU eingegeben wurde.
Wenn sich die VU in der Betriebsart KALIBRIERUNG oder KON­
TROLLE befindet, ist der Zugriff auf die Eingabe/Ausgabe-Leitung für
die Kalibrierung auch möglich.
Der Dienst SecurityAccess stellt die Möglichkeit zur PIN-Eingabe be­
reit und zeigt dem Prüfgerät an, ob sich die VU in der Betriebsart
KALIBRIERUNG befindet.
Eine PIN-Eingabe durch alternative Methoden ist zulässig.
5.2.1 Beschreibung der Nachricht
Der Dienst SecurityAccess besteht aus der Nachricht SecurityAccess
„requestSeed“, der möglicherweise eine Nachricht SecurityAccess
„sendKey“ folgt. Der Dienst SecurityAccess muss nach dem Dienst
StartDiagnosticSession ausgeführt werden.
CPR_033 Mit der Nachricht SecurityAccess „requestSeed“ stellt das
Prüfgerät fest, ob die Fahrzeugeinheit zur Annahme einer
PIN bereit ist.
CPR_034 Befindet sich die Fahrzeugeinheit bereits in der Betriebsart
KALIBRIERUNG, beantwortet sie die Anforderung durch
Versenden eines Seed 0x0000 mithilfe des Dienstes auf
SecurityAccess Positive Response.
CPR_035 Ist die Fahrzeugeinheit zur Annahme einer PIN zur Verifi­
zierung einer Werkstattkarte bereit, beantwortet sie die An­
forderung durch Versenden eines Seed, der größer als
0x0000 ist, mithilfe des Dienstes SecurityAccess Positive
Response.
CPR_036 Ist die Fahrzeugeinheit zur Annahme einer PIN vom Prüf­
gerät nicht bereit, weil entweder die eingesteckte Werkstatt­
karte ungültig ist, keine Werkstattkarte eingesteckt wurde
oder die Fahrzeugeinheit eine andere Methode der
PIN-Eingabe erwartet, beantwortet sie die Anforderung mit
einer Negative Response, wobei der Antwortcode „conditi­
onsNotCorrectOrRequestSequenceError“ lautet.
CPR_037 Das Prüfgerät sendet dann gegebenenfalls eine Nachricht
SecurityAccess „sendKey“, um eine PIN an die Fahrzeug­
einheit zu übergeben. Um ausreichend Zeit für den Prozess
der Kartenauthentisierung zu gewähren, sendet die VU den
negativen Antwortcode „requestCorrectlyReceived-Respon­
sePending“, mit dem die Antwortzeit verlängert wird. Die
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 370
längst mögliche Wartezeit darf jedoch 5 Minuten nicht über­
schreiten. Sobald der angeforderte Dienst abgeschlossen ist,
sendet die VU eine positive oder negative Antwortnachricht
mit einem anderen Antwortcode als diesem. Der negative
Antwortcode „requestCorrectlyReceived-ResponsePending“
kann so oft von der VU wiederholt werden, bis der ange­
forderte Dienst abgeschlossen ist und die abschließende
Antwortnachricht gesandt wurde.
CPR_038 Die Fahrzeugeinheit darf diese Anforderung nur dann mit
dem Dienst SecurityAccess Positive Response beantworten,
wenn sie sich in der Betriebsart KALIBRIERUNG befindet.
CPR_039 In den nachstehenden Fällen muss die Fahrzeugeinheit diese
Anforderung mit einer Negative Response bei folgenderma­
ßen gesetzten Antwortcodes quittieren:
— subFunctionNotsupported: ungültiges Format für den Pa­
rameter der Unterfunktion (accessType),
— conditionsNotCorrectOrRequestSequenceError: Fahr­
zeugeinheit ist zur Annahme einer PIN-Eingabe nicht
bereit,
— invalidKey: ungültige PIN, Zahl der zulässigen
PIN-Prüfversuche jedoch nicht überschritten,
— exceededNumberOfAttempts: ungültige PIN und Zahl
der zulässigen PIN-Prüfversuche überschritten,
— generalReject: richtige PIN, gegenseitige Authentisie­
rung mit Werkstattkarte ist jedoch fehlgeschlagen.
5.2.2 Nachrichtenformat — SecurityAccess — requestSeed
CPR_040 Die Nachrichtenformate für die SecurityAccess „request­
Seed“-Primitive sind in den folgenden Tabellen spezifiziert.
Tabelle 18
Nachricht SecurityAccess Request — requestSeed
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform
#1 Format-Byte — physische
Adressierung
80 FMT
#2 Zieladress-Byte EE TGT
#3 Quelladress-Byte tt SRC
#4 Zusatzlängen-Byte 02 LEN
#5 SecurityAccess Request Ser­
vice Id
27 SA
#6 accessType — requestSeed 7D AT_RSD
#7 Prüfsumme 00-FF CS
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 371
Tabelle 19
Nachricht SecurityAccess — requestSeed Positive Response
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform
#1 Format-Byte — physische
Adressierung
80 FMT
#2 Zieladress-Byte tt TGT
#3 Quelladress-Byte EE SRC
#4 Zusatzlängen-Byte 04 LEN
#5 SecurityAccess Positive Re­
sponse Service ID
67 SAPR
#6 accessType — requestSeed 7D AT_RSD
#7 Seed High 00-FF SEEDH
#8 Seed Low 00-FF SEEDL
#9 Prüfsumme 00-FF CS
Tabelle 20
Nachricht SecurityAccess Negative Response
Byte-Nr. Parameterbezeichnung
Hex-Wert
Symbolform
#1 Format-Byte — physische Adressie­
rung
80 FMT
#2 Zieladress-Byte tt TGT
#3 Quelladress-Byte EE SRC
#4 Zusatzlängen-Byte 03 LEN
#5 Negative Response Service Id 7F NR
#6 SecurityAccess Request Service Id 27 SA
#7 response­
Code =
[conditionsNotCor­
rectOrRequestSequen­
ceError
22 RC_CNC
incorrectMessage­
Length]
13 RC_IML
#8 Prüfsumme 00-FF CS
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 372
5.2.3 Nachrichtenformat — SecurityAccess — sendKey
CPR_041 Die Nachrichtenformate für die SecurityAccess „sendKey“-
Primitive sind in den folgenden Tabellen spezifiziert.
Tabelle 21
Nachricht SecurityAccess Request — sendKey
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform
#1 Format-Byte — physische
Adressierung
80 FMT
#2 Zieladress-Byte EE TGT
#3 Quelladress-Byte tt SRC
#4 Zusatzlängen-Byte m+2 LEN
#5 SecurityAccess Request Ser­
vice Id
27 SA
#6 accessType — sendKey 7E AT_SK
#7 bis
#m+6
Schlüssel #1 (H) xx KEY
… …
Schlüssel #m (N, m muss min­
destens 4 und darf höchstens 8
betragen)
xx
#m+7 Prüfsumme 00-FF CS
Tabelle 22
Nachricht SecurityAccess — sendKey Positive Response
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform
#1 Format-Byte — physische
Adressierung
80 FMT
#2 Zieladress-Byte tt TGT
#3 Quelladress-Byte EE SRC
#4 Zusatzlängen-Byte 02 LEN
#5 SecurityAccess Positive Re­
sponse Service Id
67 SAPR
#6 accessType — sendKey 7E AT_SK
#7 Prüfsumme 00-FF CS
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 373
Tabelle 23
Nachricht SecurityAccess Negative Response
Byte-Nr. Parameterbezeichnung
Hex-Wert
Symbolform
#1 Format-Byte — physische Adressie­
rung
80 FMT
#2 Zieladress-Byte tt TGT
#3 Quelladress-Byte EE SRC
#4 Zusatzlängen-Byte 03 LEN
#5 Negative Response Service Id 7F NR
#6 SecurityAccess Request Service Id 27 SA
#7 Response­
Code =
[generalReject 10 RC_GR
subFunctionNotSup­
ported
12 RC_SFNS
incorrectMessage­
Length
13 RC_IML
conditionsNotCor­
rectOrRequestSequen­
ceError
22 RC_CNC
invalidKey 35 RC_IK
exceededNumberO­
fAttempts
36 RC_ENA
requestCorrectlyRe­
ceived-ResponsePen­
ding]
78 RC_RCR_RP
#8 Prüfsumme 00-FF CS
6. DATENÜBERTRAGUNGSDIENSTE
Die zur Verfügung stehenden Dienste sind in nachstehender Tabelle
aufgeführt:
Tabelle 24
Datenübertragungsdienste
Name des Dienstes Beschreibung
ReadDataByIdentifier Client fordert an, dass der aktuelle Wert ei­
nes Datensatzes durch Zugriff von recordDa­
taIdentifier übertragen wird.
WriteDataByIdentifier Client fordert an, dass ein Datensatz von
recordDataIdentifier geschrieben wird.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 374
6.1. Dienst ReadDataByIdentifier
6.1.1 Beschreibung der Nachricht
CPR_050 Mit dem Dienst ReadDataByIdentifier fordert der Client
vom Server die Übertragung von Datensatzwerten an, die
durch einen recordDataIdentifier gekennzeichnet sind. Der
Fahrzeughersteller muss dafür sorgen, dass die Serverbedin­
gungen zur Abwicklung dieses Dienstes erfüllt sind.
6.1.2 Nachrichtenformat
CPR_051 Die Nachrichtenformate für die ReadDataByIdentifier-Pri­
mitive sind in den folgenden Tabellen aufgeführt.
Tabelle 25
Nachricht ReadDataByIdentifier Request
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform
#1 Format-Byte — physische
Adressierung
80 FMT
#2 Zieladress-Byte EE TGT
#3 Quelladress-Byte tt SRC
#4 Zusatzlängen-Byte 03 LEN
#5 ReadDataByIdentifier Re­
quest Service Id
22 RDBI
#6 bis #7 recordDataIdentifier = [ein
Wert aus Tabelle 28]
xxxx RDI_…
#8 Prüfsumme 00-FF CS
Tabelle 26
Nachricht ReadDataByIdentifier Positive Response
Byte-Nr. Parameterbezeichnung
Hex-Wert
Symbolform
#1 Format-Byte — physische Adressie­
rung
80 FMT
#2 Zieladress-Byte tt TGT
#3 Quelladress-Byte EE SRC
#4 Zusatzlängen-Byte m+3 LEN
#5 ReadDataByIdentifier Positive Re­
sponse Service Id
62 RDBIPR
#6 und #7 recordDataIdentifier = [gleicher Wert
wie Bytes 6 und 7 in Tabelle 25]
xxxx RDI_...
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 375
Byte-Nr. Parameterbezeichnung
Hex-Wert
Symbolform
#8 bis
#m+7
dataRecord[] = [data#1 xx DREC_DAT­
A1
: : :
data#m] xx DREC_DA­
TAm
#m+8 Prüfsumme 00-FF CS
Tabelle 27
Nachricht ReadDataByIdentifier Negative Response
Byte-Nr. Parameterbezeichnung
Hex-Wert
Symbolform
#1 Format-Byte — physische Adressie­
rung
80 FMT
#2 Zieladress-Byte tt TGT
#3 Quelladress-Byte EE SRC
#4 Zusatzlängen-Byte 03 LEN
#5 Negative Response Service Id 7F NR
#6 ReadDataByIdentifier Request Ser­
vice Id
22 RDBI
#7 Response­
Code=
[requestOutO­
fRange
31 RC_ROOR
incorrectMessage­
Length
13 RC_IML
conditionsNotCor­
rect]
22 RC_CNC
#8 Prüfsumme 00-FF CS
6.1.3 Parameterdefinition
CPR_052 Der Parameter recordDataIdentifier (RDI_) in der Anforde­
rungsnachricht ReadDataByIdentifier kennzeichnet einen
Datensatz.
▼M3
CPR_053 Die hier definierten Werte für recordDataIdentifier sind in
der folgenden Tabelle aufgeführt.
Die Tabelle recordDataIdentifier enthält fünf Spalten mit
mehreren Zeilen.
— Die 1. Spalte (Hex) enthält jeweils den hexadezimalen
Wert für die in der 3. Spalte angeführte Anforderungs­
nachricht recordDataIdentifier.
— Die 2. Spalte (Datenelement) gibt zum jeweiligen re­
cordDataIdentifier das Datenelement gemäß Anlage 1 an
(ggf. Umkodierung erforderlich).
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 376
— Die 3. Spalte (Beschreibung) enthält den dazugehöri­
gen Namen des recordDataIdentifier.
— Die 4. Spalte (Zugriffsrechte) gibt die Zugriffsrechte
des jeweiligen recordDataIdentifier an.
— Die 5. Spalte (Symbolform) gibt die Symbolschreib­
weise des jeweiligen recordDataIdentifier an.
Tabelle 28
Definition der Werte für recordDataIdentifier
Hex Datenelement
recordDataIdentifier-Name
(siehe Format in Abschnitt 8.2)
Zugriffs­
rechte
(Read/
Write)
Symbolform
F90B CurrentDateTime TimeDate R/W RDI_TD
F912 HighResOdometer HighResolutionTotalVehicleDis­
tance
R/W RDI_HRTVD
F918 K-ConstantOfRecordingEquipment Kfactor R/W RDI_KF
F91C L-TyreCircumference LfactorTyreCircumference R/W RDI_LF
F91D W-VehicleCharacteristicConstant WvehicleCharacteristicFactor R/W RDI_WVCF
F921 TyreSize TyreSize R/W RDI_TS
F922 nextCalibrationDate NextCalibrationDate R/W RDI_NCD
F92C SpeedAuthorised SpeedAuthorised R/W RDI_SA
F97D vehicleRegistrationNation RegisteringMemberState R/W RDI_RMS
F97E VehicleRegistrationNumber VehicleRegistrationNumber R/W RDI_ VRN
F190 VehicleIdentificationNumber VIN R/W RDI_ VIN
F9D0 SensorSerialNumber MotionSensorSerialNumber R RDI_SSN
F9D1 RemoteCommunicationModuleSerialN­
umber
RemoteCommunicationFacility­
SerialNumber
R RDI_RCSN
F9D2 SensorGNSSSerialNumber ExternalGNSSFacilitySerialNum­
ber
R RDI_GSSN
F9D3 SealDataVu SmartTachographSealsSerialN­
umber
R/W RDI_SDV
F9D4 VuSerialNumber VuSerialNumber R RDI_VSN
F9D5 ByDefaultLoadType ByDefaultLoadType R/W RDI_BDLT
F9D6 TachographCardsGen1Suppression TachographCardsGen1Suppres­
sion
R/W RDI_TCG1S
F9D7 VehiclePosition VehiclePosition R RDI_VP
F9D8 LastCalibrationCountry CalibrationCountry R RDI_CC
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 377
CPR_054 Der Parameter dataRecord (DREC_) dient der Nachricht
Positive Response auf ReadDataByIdentifier dazu, dem
Client (Prüfgerät) den durch die recordDataIdentifier ge­
kennzeichneten Datensatz bereitzustellen. Die Datensatzfor­
mate werden in Abschnitt 8 definiert. Es können zusätzliche,
vom Benutzer wählbare dataRecord-Werte, z. B. VU-abhän­
gige Eingabedaten, interne Daten und Ausgabedaten inte­
griert werden, diese werden jedoch hier nicht definiert.
6.2. Der Dienst WriteDataByIdentifier
6.2.1 Beschreibung der Nachricht
CPR_056 Der Dienst WriteDataByIdentifier dient dem Client dazu,
Datensatzwerte auf einen Server zu schreiben, die durch
einen recordDataIdentifier gekennzeichnet sind. Der Fahr­
zeughersteller muss dafür sorgen, dass die Serverbedingun­
gen zur Abwicklung dieses Dienstes erfüllt sind. Zur Ak­
tualisierung der in Tabelle 28 aufgeführten Parameter muss
sich die VU in der Betriebsart KALIBRIERUNG befinden.
6.2.2 Nachrichtenformat
CPR_057 Die Nachrichtenformate für die WriteDataByIdentifier-Pri­
mitive sind in den folgenden Tabellen aufgeführt.
Tabelle 29
Nachricht WriteDataByIdentifier Request
Byte-Nr. Parameterbezeichnung
Hex-Wert
Symbolform
#1 Format-Byte — physische Adressie­
rung
80 FMT
#2 Zieladress-Byte EE TGT
#3 Quelladress-Byte tt SRC
#4 Zusatzlängen-Byte m+3 LEN
#5 WriteDataByIdentifier Request
Service Id
2E WDBI
#6 bis #7 recordDataIdentifier = [ein Wert aus
Tabelle 28]
xxxx RDI_…
#8 bis m+7 dataRecord[] = [data#1 xx DREC_DAT­
A1
: : :
data#m] xx DREC_DA­
TAm
#m+8 Prüfsumme 00-FF CS
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 378
Tabelle 30
Nachricht WriteDataByIdentifier Positive Response
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform
#1 Format-Byte — physische
Adressierung
80 FMT
#2 Zieladress-Byte tt TGT
#3 Quelladress-Byte EE SRC
#4 Zusatzlängen-Byte 03 LEN
#5 WriteDataByIdentifier Posi­
tive Response Service Id
6E WDBIPR
#6 bis #7 recordDataIdentifier = [gleicher
Wert wie Bytes 6 und 7 in Ta­
belle 29]
xxxx RDI_…
#8 Prüfsumme 00-FF CS
Tabelle 31
Nachricht WriteDataByIdentifier Negative Response
Byte-Nr. Parameterbezeichnung
Hex-Wert
Symbolform
#1 Format-Byte — physische Adressie­
rung
80 FMT
#2 Zieladress-Byte tt TGT
#3 Quelladress-Byte EE SRC
#4 Zusatzlängen-Byte 03 LEN
#5 Negative Response Service Id 7F NR
#6 WriteDataByIdentifier Request Ser­
vice Id
2E WDBI
#7 Response­
Code=
[requestOutO­
fRange
31 RC_ROOR
incorrectMessage­
Length
13 RC_IML
conditionsNotCor­
rect]
22 RC_CNC
#8 Prüfsumme 00-FF CS
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 379
6.2.3 Parameterdefinition
Der Parameter recordDataIdentifier (RDI_) ist in Tabelle 28 definiert.
Der Parameter dataRecord (DREC_) dient der Anforderungsnachricht
WriteDataByIdentifier dazu, dem Server (VU) den durch die recordDa­
taIdentifier gekennzeichneten Datensatzwerte bereitzustellen. Die Da­
tensatzformate werden in Abschnitt 8 definiert.
7. PRÜFIMPULSSTEUERUNG — FUNKTIONSEINHEIT EINGABE/
AUSGABE-STEUERUNG
Die zur Verfügung stehenden Dienste sind in nachstehender Tabelle
aufgeführt:
Tabelle 32
Funktionseinheit Eingabe/Ausgabe-Steuerung
Name des Dienstes Beschreibung
InputOutputControl­
ByIdentifier
Der Client fordert die Steuerung einer spe­
ziellen Eingabe/Ausgabe für den Server an.
7.1. Der Dienst InputOutputControlByIdentifier
7.1.1 Beschreibung der Nachricht
Über einen der Steckanschlüsse an der Vorderseite ist es möglich,
Prüfimpulse mit einem geeigneten Prüfgerät zu steuern bzw. zu über­
wachen.
CPR_058 Diese Kalibrierungs-E/A-Signalleitung ist mit einem
K-Leitungsbefehl konfigurierbar, wobei mit dem Dienst In­
putOutputControlByIdentifier die für die Leitung ge­
wünschte Eingabe- bzw. Ausgabefunktion gewählt wird.
Es gibt folgende Leitungszustände:
— deaktiviert,
— speedSignalInput: über die Kalibrierungs-E/A-Signallei­
tung wird ein Geschwindigkeitssignal (Testsignal) einge­
geben, das das Geschwindigkeitssignal des Bewegungs­
sensors ersetzt, diese Funktion ist in der Betriebsart
KONTROLLE nicht verfügbar,
— realTimeSpeedSignalOutputSensor: über die Kalibrie­
rungs-E/A-Signalleitung wird das Geschwindigkeitssig­
nal des Bewegungssensors ausgegeben,
— RTCOutput: über die Kalibrierungs-E/A-Signalleitung
wird das UTC-Zeitsignal ausgegeben, diese Funktion
ist in der Betriebsart KONTROLLE nicht verfügbar.
CPR_059 Um den Leitungsstatus zu konfigurieren, muss sich die
Fahrzeugeinheit in einem Einstellvorgang befinden und in
die Betriebsart KALIBRIERUNG oder KONTROLLE ge­
setzt sein. Wenn sich die VU in der Betriebsart KALIBRIE­
RUNG befindet, stehen die vier Leitungsstati zur Verfügung
(deaktiviert, speedSignalInput, realTimeSpeedSignalOutput­
Sensor, RTCOutput). Wenn sich die VU in der Betriebsart
KONTROLLE befindet, stehen nur zwei Leitungsstati zur
Verfügung (deaktiviert, realTimeSpeedOutputSensor). Bei
Verlassen des Einstellvorgangs bzw. der Betriebsart KALI­
BRIERUNG oder KONTROLLE muss die Fahrzeugeinheit
die Rückkehr der E/A-Signalleitung in den Status „deakti­
viert“ (Standardzustand) gewährleisten.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 380
CPR_060 Treffen an der Echtzeit-Eingabeleitung für Geschwindig­
keitssignale der VU Geschwindigkeitsimpulse ein, während
die E/A-Signalleitung auf Eingabe gesetzt ist, muss die E/A-
Signalleitung auf Ausgabe gesetzt werden oder in den de­
aktivierten Zustand zurückkehren.
CPR_061 Der Ablauf muss wie folgt sein:
— Aufbau der Verbindung durch den Dienst StartCommu­
nication
— Einleiten eines Einstellvorgangs durch den Dienst Start­
DiagnosticSession und Eintritt in die Betriebsart KALI­
BRIERUNG oder KONTROLLE (die Reihenfolge die­
ser beiden Vorgänge ist nicht von Bedeutung).
— Änderung des Ausgabestatus durch den Dienst Inpu­
tOutputControlByIdentifier.
7.1.2 Nachrichtenformat
CPR_062 Die Nachrichtenformate für die InputOutputControlByIden­
tifier-Primitive sind in den folgenden Tabellen spezifiziert.
Tabelle 33
Nachricht InputOutputControlByIdentifier Request
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform
#1 Format-Byte — physische
Adressierung
80 FMT
#2 Zieladress-Byte EE TGT
#3 Quelladress-Byte tt SRC
#4 Zusatzlängen-Byte xx LEN
#5 InputOutputControlByIden­
tifier Request SId
2F IOCBI
#6 und #7 InputOutputIdentifier = [Cali­
brationInputOutput]
F960 IOI_CIO
#8 oder
#8 bis #9
ControlOptionRecord = [ COR_…
inputOutputControlParameter
— ein Wert aus Tabelle 36
xx IOCP_…
controlState — ein Wert aus
Tabelle 37 (siehe Hinweis un­
ten)]
xx CS_…
#9 oder
#10
Prüfsumme 00-FF CS
Hinweis: Der Parameter controlState liegt nur in bestimmten
Fällen vor (siehe 7.1.3).
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 381
Tabelle 34
Nachricht InputOutputControlByIdentifier Positive Response
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform
#1 Format-Byte — physische
Adressierung
80 FMT
#2 Zieladress-Byte tt TGT
#3 Quelladress-Byte EE SRC
#4 Zusatzlängen-Byte xx LEN
#5 InputOutputControlByIden­
tifier Positive Response SId
6F IOCBIPR
#6 und #7 inputOutputIdentifier = [Cali­
brationInputOutput]
F960 IOI_CIO
#8 oder
#8 bis #9
controlStatusRecord = [ CSR_
inputOutputControlParameter
(gleicher Wert wie Byte 8 in
Tabelle 33)
xx IOCP_…
controlState (gleicher Wert wie
Byte 9 in Tabelle 33)] (falls
zutreffend)
xx CS_…
#9 oder
#10
Prüfsumme 00-FF CS
Tabelle 35
Nachricht InputOutputControlByIdentifier Negative Response
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform
#1 Format-Byte — physische
Adressierung
80 FMT
#2 Zieladress-Byte tt TGT
#3 Quelladress-Byte EE SRC
#4 Zusatzlängen-Byte 03 LEN
#5 Negative Response Service Id 7F NR
#6 inputOutputControlByIdentifier
Request SId
2F IOCBI
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 382
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform
#7 responseCode=[
incorrectMessageLength 13 RC_IML
conditionsNotCorrect 22 RC_CNC
requestOutOfRange 31 RC_ROOR
deviceControlLimitsExceeded] 7A RC_DCLE
#8 Prüfsumme 00-FF CS
7.1.3 Parameterdefinition
CPR_064 Der Parameter inputOutputControlParameter (IOCP_) ist
in folgender Tabelle beschrieben.
Tabelle 36
Definition der Werte für inputOutputControlParameter
Hex Beschreibung Symbolform
00 ReturnControlToECU
Dieser Wert zeigt dem Server (VU) an, dass das
Prüfgerät die Steuerung der Kalibrierungs-E/A-
Signalleitung beendet hat.
RCTECU
01 ResetToDefault
Dieser Wert zeigt dem Server (VU) die Anfor-
derung an, die Kalibrierungs-E/A-Signalleitung
in den Standardstatus zurückzusetzen.
RTD
03 ShortTermAdjustment
Dieser Wert zeigt dem Server (VU) die Anfor-
derung an, die Kalibrierungs-E/A-Signalleitung
auf den im Parameter controlState enthaltenen
Wert einzustellen.
STA
CPR_065 Der Parameter controlState liegt nur vor, wenn der inpu­
tOutputControlParameter auf ShortTermAdjustment gesetzt
ist; folgende Werte sind möglich:
Tabelle 37
Definition der Werte für controlState
Betriebsart Hex-Wert Beschreibung
Deaktiviert 00 E/A-Leitung deaktiviert (Ausgangszustand)
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 383
Betriebsart Hex-Wert Beschreibung
Aktiviert 01 Kalibrierungs-E/A-Leitung als speedSig­
nalInput aktiviert
Aktiviert 02 Kalibrierungs-E/A-Leitung als realTime­
SpeedSignalOutputSensor aktiviert
Aktiviert 03 Kalibrierungs-E/A-Leitung als RTCOutput
aktiviert
▼M3
8. DER DIENST ROUTINECONTROL (ZEITEINSTELLUNG)
8.1. Beschreibung der Nachricht
CPR_065a Der Dienst RoutineControl (TimeAdjustment) ermöglicht
es, eine Anpassung der Systemuhr der Fahrzeugeinheit an
die vom GNSS-Empfänger bereitgestellte Zeit auszulösen.
Die Fahrzeugeinheit muss sich im Modus KALIBRIE­
RUNG befinden, damit der Dienst RoutineControl (Time­
Adjustment) ausgeführt werden kann.
Voraussetzung: Es ist sichergestellt, dass die Fahrzeugein­
heit authentisierte Positionsnachrichten vom GNSS-Emp­
fänger empfangen kann.
Während die Zeiteinstellung läuft, antwortet die Fahrzeug­
einheit auf die Anforderung RoutineControl, Unterfunktion
requestRoutineResults mit routineInfo = 0x78.
Hinweis: Die Zeiteinstellung kann einige Zeit in Anspruch
nehmen. Das Diagnoseprüfgerät fordert den Zeiteinstel­
lungsstatus unter Verwendung der Unterfunktion reque­
stRoutineResults an.
8.2. Nachrichtenformat
CPR_065b Die Nachrichtenformate für den Dienst RoutineControl (Ti­
meAdjustment) und seine Primitiven sind in den folgenden
Tabellen aufgeführt.
Tabelle 37a
RoutineControl, Nachrichtenanforderung Routine (TimeAdjustment), Unterfunktion startRoutine
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform
#1 Format-Byte – physische Adressierung 80 FMT
#2 Zieladress-Byte EE TGT
#3 Quelladress-Byte tt SRC
#4 Zusatzlängen-Byte xx LEN
#5 RoutineControl Request Sid (Dienstkennung für Anforderung Rou­
tineControl)
31 RC
#6 routineControlType = [startRoutine] 01 RCTP_STR
#7 und #8 routineIdentifier = [TimeAdjustment] 0100 RI_TA
#9 Prüfsumme 00-FF CS
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 384
Tabelle 37b
RoutineControl, Routine (TimeAdjustment), Unterfunktion startRoutine, Positive Antwortnachricht
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform
#1 Format-Byte – physische Adressierung 80 FMT
#2 Zieladress-Byte tt TGT
#3 Quelladress-Byte EE SRC
#4 Zusatzlängen-Byte xx LEN
#5 RoutineControl Positive Response Sid (Dienstkennung für positive
Antwort für RoutineControl)
71 RCPR
#6 routineControlType = [startRoutine] 01 RCTP_STR
#7 und #8 routineIdentifier= [TimeAdjustment] 0100 RI_TA
#9 Prüfsumme 00-FF CS
Tabelle 37c
RoutineControl, Anforderungsnachricht Routine (TimeAdjustment), Unterfunktion requestRoutineResults
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform
#1 Format-Byte – physische Adressierung 80 FMT
#2 Zieladress-Byte EE TGT
#3 Quelladress-Byte tt SRC
#4 Zusatzlängen-Byte xx LEN
#5 RoutineControl Request Sid (Dienstkennung für Anforderung Rou­
tineControl)
31 RC
#6 routineControlType = [requestRoutineResults] 03 RCTP_RRR
#7 und #8 routineIdentifier= [TimeAdjustment] 0100 RI_TA
#9 Prüfsumme 00-FF CS
Tabelle 37d
RoutineControl, Routine (TimeAdjustment), Unterfunktion requestRoutineResults, Positive Antwortnachricht
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform
#1 Format-Byte – physische Adressierung 80 FMT
#2 Zieladress-Byte tt TGT
#3 Quelladress-Byte EE SRC
#4 Zusatzlängen-Byte xx LEN
#5 RoutineControl Positive Response Sid (Dienstkennung für positive
Antwort für RoutineControl)
71 RCPR
#6 routineControlType = [requestRoutineResults] 03 RCTP_RRR
#7 und #8 routineIdentifier= [TimeAdjustment] 0100 RI_TA
#9 routineInfo (siehe Tabelle 37f) XX RINF_TA
#10 routineStatusRecord[] = routineStatus#1 (siehe Tabelle 37g) XX RS_TA
#11 Prüfsumme 00-FF CS
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 385
Tabelle 37e
RoutineControl, Routine (TimeAdjustment), Negative Antwortnachricht
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform
#1 Format-Byte – physische Adressierung 80 FMT
#2 Zieladress-Byte tt TGT
#3 Quelladress-Byte EE SRC
#4 Zusatzlängen-Byte 03 LEN
#5 negativeResponse Service Id (Dienstkennung für negative Antwort) 7F NR
#6 inputOutputControlByIdentifier Request SId 31 RC
#7 responseCode=[
sub-functionNotSupported
incorrectMessageLengthOrInvalidFormat
conditionsNotCorrect
requestOutOfRange
]
12
13
22
31
SFNS
IMLOIF
CNC
ROOR
#8 Prüfsumme 00-FF CS
Tabelle 37f
RoutineControl, Routine (TimeAdjustment), routineInfo
routineInfo Hex-Wert Beschreibung
NormalExitWithResultAvailable 61 Die Routine wurde vollständig ausgeführt; zusätzliche
Ergebnisse der Routine sind verfügbar.
RoutineExecutionOngoing 78 Die Ausführung der Routine läuft noch.
Tabelle 37g
RoutineControl, Routine (TimeAdjustment), routineStatus
Hex-Wert Prüfergebnis Beschreibung
01 positiv Die Zeiteinstellung wurde erfolgreich abgeschlossen.
02..0F RFU
10 negativ Kein GNSS-Signalempfang.
11..7F RFU
80..FF Herstellerspezifisch
9. DATARECORDS-FORMATE
Dieser Abschnitt enthält:
— allgemeine Regeln für die Parameter, die von der Fahrzeugeinheit
zum Prüfgerät übertragen werden,
— die Beschreibung der Formate für die in Abschnitt 6 erläuterten
Datenübertragungsdienste.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 386
CPR_067 Alle hier angegebenen Parameter müssen von der Fahrzeug­
einheit unterstützt werden.
CPR_068 Von der Fahrzeugeinheit an das Prüfgerät aufgrund einer
Anforderungsnachricht übertragene Daten müssen dem je­
weiligen Messtyp entsprechen (d. h. dem aktuellen Wert des
angeforderten Parameters, wie ihn die Fahrzeugeinheit ge­
messen oder vorgegeben hat).
9.1. Wertebereiche der übertragenen Parameter
CPR_069 Tabelle 38 enthält die Wertebereiche, mit deren Hilfe die
Gültigkeit der übermittelten Parameter festgestellt wird.
CPR_070 Mit den Werten im Bereich „Fehlerindikator“ kann die
Fahrzeugeinheit sofort mitteilen, dass aufgrund eines Feh­
lers im Fahrtenschreiber derzeit keine gültigen Werte vor­
handen sind.
CPR_071 Mit den Werten im Bereich „Nicht verfügbar“ kann die
Fahrzeugeinheit eine Nachricht übermitteln, die einen in
diesem Modul nicht verfügbaren oder nicht unterstützten
Parameter enthält. Mit den Werten im Bereich „Nicht ange­
fordert“ kann die Fahrzeugeinheit eine Befehlsnachricht
übermitteln und die Parameter angeben, für die es vom
anderen Gerät keine Antwort erwartet.
CPR_072 Können wegen eines defekten Bauteils keine gültigen Daten
für einen Parameter übermittelt werden, sollte mit dem in
Tabelle 38 angegebenen Fehlerindikator anstelle von Daten
für den angeforderten Parameter geantwortet werden. Wenn
die gemessenen oder errechneten Daten Werte annehmen,
die zwar gültig sind, aber außerhalb des festgelegten Werte­
bereichs für diesen Parameter liegen, ist der Fehlerindikator
jedoch nicht zu verwenden. In diesem Fall sollte der jewei­
lige Mindest- oder Höchstwert für diesen Parameter über­
tragen werden.
Tabelle 38
Wertebereiche der dataRecords
Wertebereichsname
1 Byte
(Hex-Wert)
2 Bytes
(Hex-Wert)
4 Bytes
(Hex-Wert)
ASCII
Gültiges Signal 00 bis FA 0000 bis FAFF 00000000 bis FAFFFFFF 1 bis 254
Parameterspezifischer Indikator FB FB00 bis FBFF FB000000 bis FBFFFFFF keiner
Reserviert für zukünftige
Indikatorbits
FC bis FD FC00 bis FDFF FC000000 bis FDFFFFFF keiner
Fehlerindikator FE FE00 bis FEFF FE000000 bis FEFFFFFF 0
Nicht verfügbar oder
nicht angefordert
FF FF00 bis FFFF FF000000 bis FFFFFFFF FF
CPR_073 Bei den in ASCII dargestellten Parametern ist der Stern „*“
als Trennzeichen reserviert.
9.2. dataRecords-Formate
In Tabelle 39 bis Tabelle 42 sind die Datensatzformate für die Dienste
ReadDataByIdentifier und WriteDataByIdentifier angegeben.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 387
CPR_074 In Tabelle 39 sind Länge, Auflösung und Betriebsbereich
für jeden durch seinen recordDataIdentifier gekennzeichne­
ten Parameter angegeben:
Tabelle 39
dataRecords-Formate
Parameterbezeichnung
Datenlänge
(Bytes)
Auflösung Betriebsbereich
TimeDate 8 siehe Tabelle 40
HighResolutionTotalVehicleDis­
tance
4 Zuwachs 5 m/Bit,
Ausgangswert 0 m
0 bis +21 055 406 km
Kfactor 2 Zuwachs 0,001 Impulse/m/Bit,
Ausgangswert 0
0 bis 64,255 Impulse/m
LfactorTyreCircumference 2 Zuwachs 0,125 10 -3 m/Bit,
Ausgangswert 0
0 bis 8,031 m
WvehicleCharacteristicFactor 2 Zuwachs 0,001 Impulse/m/Bit,
Ausgangswert 0
0 bis 64,255 Impulse/m
TyreSize 15 ASCII ASCII
NextCalibrationDate 3 siehe Tabelle 41
SpeedAuthorised 2 Zuwachs 1/256 km/h/Bit,
Ausgangswert 0
0 bis 250,996 km/h
RegisteringMemberState 3 ASCII ASCII
VehicleRegistrationNumber 14 siehe Tabelle 42
VIN 17 ASCII ASCII
SealDataVu 55 siehe Tabelle 43
ByDefaultLoadType 1 siehe Tabelle 44
VuSerialNumber 8 siehe Tabelle 45
SensorSerialNumber 8 siehe Tabelle 45
SensorGNSSSerialNumber 8 siehe Tabelle 45
RemoteCommunicationModuleSeri­
alNumber
8 siehe Tabelle 45
TachographCardsGen1Suppression 2 siehe Tabelle 46
VehiclePosition 14 siehe Tabelle 47
CalibrationCountry 3 ASCII NationAlpha entsprechend
Anlage 1
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 388
CPR_075 Tabelle 40 enthält die Formate der verschiedenen Bytes für
den Parameter TimeDate:
Tabelle 40
Ausführliches Format des Parameters TimeDate (recordDataIdentifier-Wert F90B)
Byte Parameterdefinition Auflösung Betriebsbereich
1 Sekunden Zuwachs 0,25 s/Bit, Ausgangswert 0 s 0 bis 59,75 s
2 Minuten Zuwachs 1 min/Bit, Ausgangswert 0 min 0 bis 59 min
3 Stunden Zuwachs 1 h/Bit, Ausgangswert 0 h 0 bis 23 h
4 Monat Zuwachs 1 Monat/Bit, Ausgangswert
0 Monate
1 bis 12 Monate
5 Tag Zuwachs 0,25 Tag/Bit, Ausgangswert
0 Tage (siehe HINWEIS unter Tabelle 41)
0,25 bis 31,75 Tage
6 Jahr Zuwachs 1 Jahr/Bit, Ausgangswert
+1985 Jahre
(siehe HINWEIS unter Tabelle 41)
1985 bis 2235 Jahre
7 Lokaler Ausgangswert Mi­
nuten
Zuwachs 1 min/Bit, Ausgangswert -125 min -59 bis +59 min
8 Lokaler Ausgangswert
Stunden
Zuwachs 1 h/Bit, Ausgangswert –125 h –23 bis +23 h
CPR_076 Tabelle 41 enthält die Formate der verschiedenen Bytes für
den Parameter NextCalibrationDate:
Tabelle 41
Ausführliches Format des Parameters NextCalibrationDate (recordDataIdentifier-Wert F922)
Byte Parameterdefinition Auflösung Betriebsbereich
1 Monat Zuwachs 1 Monat/Bit, Ausgangswert
0 Monate
1 bis 12 Monate
2 Tag Zuwachs 0,25 Tage/Bit, Ausgangswert
0 Tage (siehe HINWEIS unten)
0,25 bis 31,75 Tage
3 Jahr Zuwachs 1 Jahr/Bit, Ausgangswert
+1985 Jahre
(siehe Hinweis unten)
1985 bis 2235 Jahre
HINWEIS zur Verwendung des Tag-Parameters:
1) Der Datumswert 0 ist ungültig. Die Werte 1, 2, 3 und 4
kennzeichnen den ersten Tag des Monats; die Werte 5,
6, 7 und 8 kennzeichnen den zweiten Tag des Monats
usw.
2) Dieser Parameter hat keinen Einfluss auf den Stunden­
parameter oben.
HINWEIS zur Verwendung des Jahr-Parameters:
Der Wert 0 für das Jahr kennzeichnet das Jahr 1985; der
Wert 1 das Jahr 1986 usw.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 389
CPR_078 Tabelle 42 enthält die Formate der verschiedenen Bytes für
den Parameter VehicleRegistrationNumber:
Tabelle 42
Ausführliches Format des Parameters VehicleRegistrationNumber (recordDataIdentifier-Wert F97E)
Byte Parameterdefinition Auflösung Betriebsbereich
1 Codeseite (entsprechend Anlage 1) Nicht anwendbar VehicleRegistrationNumber
2 bis 14 Amtliches Kennzeichen (entsprechend An­
lage 1)
Nicht anwendbar VehicleRegistrationNumber
CPR_090 Tabelle 43 enthält die Formate der verschiedenen Bytes für
den Parameter SealDataVu:
Tabelle 43
Ausführliches Format des Parameters SealDataVu (recordDataIdentifier-Wert F9D3)
Byte Parameterdefinition Auflösung Betriebsbereich
1 bis 11 sealRecord1. Format SealRecord entspre­
chend Anlage 1.
Nicht anwendbar SealRecord
12 bis 22 sealRecord2. Format SealRecord entspre­
chend Anlage 1.
Nicht anwendbar SealRecord
23 bis 33 sealRecord3. Format SealRecord entspre­
chend Anlage 1.
Nicht anwendbar SealRecord
34 bis 44 sealRecord4. Format SealRecord entspre­
chend Anlage 1.
Nicht anwendbar SealRecord
45 bis 55 sealRecord5. Format SealRecord entspre­
chend Anlage 1.
Nicht anwendbar SealRecord
HINWEIS: Sind weniger als 5 Plomben verfügbar, wird der
Wert EquipmentType in allen unbenutzten sealRecords auf
15, d. h. unbenutzt, gesetzt.
CPR_091 Tabelle 44 enthält die Formate der verschiedenen Bytes für
den Parameter ByDefaultLoadType:
Tabelle 44
Ausführliches Format des Parameters ByDefaultLoadType (recordDataIdentifier-Wert F9D5)
Byte Parameterdefinition Auflösung Betriebsbereich
1 loadType
'00'H: Art der Ladung nicht definiert
'01'H: Güter
'02'H: Personen
Nicht anwendbar '00'H bis '02'H
CPR_092 Tabelle 45 enthält die Formate der verschiedenen Bytes für
die Parameter VuSerialNumber, SensorSerialNumber, Sen­
sorGNSSSerialNumber und RemoteCommunicationModule­
SerialNumber:
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 390
Tabelle 45
Ausführliches Format der Parameter VuSerialNumber, SensorSerialNumber, SensorGNSSSerialNumber und
RemoteCommunicationModuleSerialNumber (recordDataIdentifier-Werte F9D4, F9D0, F9D2, F9D1)
Byte Parameterdefinition Auflösung Betriebsbereich
1 VuSerialNumber, SensorSerialNumber, Sen­
sorGNSSSerialNumber und RemoteCommu­
nicationModuleSerialNumber:
Format ExtendedSerialNumber entsprechend
Anlage 1
Nicht anwendbar ExtendedSerialNumber
CPR_093 Tabelle 46 enthält die Formate der verschiedenen Bytes für
den Parameter TachographCardsGen1Suppression:
Tabelle 46
Ausführliches Format des Parameters TachographCardsGen1Suppression (recordDataIdentifier-Wert F9D6)
Byte Parameterdefinition Auflösung Betriebsbereich
1 bis 2 TachographCardsGen1Suppression. Format
TachographCardsGen1Suppression entspre­
chend Anlage 1.
Nicht anwendbar '0000'H, 'A5E3'H
CPR_094 Tabelle 47 enthält die Formate der verschiedenen Bytes für
den Parameter VehiclePosition.
Tabelle 47
Ausführliches Format des Parameters VehiclePosition (recordDataIdentifier-Wert F9D7)
Byte Parameterdefinition Auflösung Betriebsbereich
1 bis 4 Zeitstempel der Bestimmung der Position des
Fahrzeugs.
Nicht anwendbar TimeReal
5 GNSS-Genauigkeit Nicht anwendbar GNSSAccuracy
6 bis 11 Fahrzeugposition Nicht anwendbar GeoCoordinates
12 Authentisierungsstatus Nicht anwendbar PositionAuthenticationStatus
13 Derzeitiges Land Nicht anwendbar NationNumeric
14 Derzeitige Region Nicht anwendbar RegionNumeric
Hinweis: Nach einer Aktualisierung der Fahrzeugposition
kann sich die Aktualisierung des derzeitigen Landes und
der derzeitigen Region verzögern.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 391
Anlage 9.
TYPGENEHMIGUNG UND MINDESTANFORDERUNGEN AN DIE
DURCHZUFÜHRENDEN PRÜFUNGEN
INHALTSVERZEICHNIS
1. EINLEITUNG
2. FUNKTIONSPRÜFUNGEN AN DER FAHRZEUGEINHEIT
3. FUNKTIONSTESTS AM BEWEGUNGSSENSOR
4. FUNKTIONSPRÜFUNGEN AN FAHRTENSCHREIBERKARTEN
5. PRÜFUNG EXTERNER GNSS-AUSRÜSTUNG
▼M1
6. PRÜFUNGEN DER EXTERNEN AUSRÜSTUNG ZUR FERNKOM­
MUNIKATION
▼B
7. PAPIERFUNKTIONSPRÜFUNGEN
8. INTEROPERABILITÄTSPRÜFUNGEN
▼M3
9. OSNMA-PRÜFUNGEN
▼B
1. EINLEITUNG
1.1. Typgenehmigung
Die EG-Typgenehmigung von Kontrollgeräten (oder deren Komponenten)
oder einer Fahrtenschreiberkarte beruht auf:
▼M1
— einer Sicherheitszertifizierung auf Grundlage der Spezifizierung All­
gemeiner Kriterien anhand einer Sicherheitsvorgabe in völliger Über­
einstimmung mit Anlage 10 dieses Anhangs,
▼B
— einer Funktionszertifizierung durch die Behörde eines Mitgliedstaa­
tes, mit der bestätigt wird, dass das geprüfte Teil hinsichtlich der
ausgeführten Funktionen, der Messgenauigkeit und der Umwelteigen­
schaften die Anforderungen dieses Anhangs erfüllt,
— einer Interoperabilitätszertifizierung durch die zuständige Stelle, mit
der bestätigt wird, dass das Kontrollgerät (oder die Fahrtenschreiber­
karte) mit dem erforderlichen Muster der Fahrtenschreiberkarte (bzw.
des Kontrollgeräts) (siehe Kapitel 8 in diesem Anhang) uneinge­
schränkt interoperabel ist.
In dieser Anlage ist in Form von Mindestanforderungen festgelegt, welche
Prüfungen eine Behörde der Mitgliedstaaten während der Funktionsprü­
fungen und welche Prüfungen eine zuständige Stelle während der Inter­
operabilitätsprüfungen durchführen muss. Die Verfahren zur Durchführung
der Prüfungen bzw. die Art der Prüfungen werden nicht weiter spezifiziert.
Die Aspekte der Sicherheitszertifizierung sind in dieser Anlage nicht ent­
halten. Werden bestimmte Prüfungen bereits für die Typgenehmigung im
Rahmen des Verfahrens zur Sicherheitsbewertung und -zertifizierung
durchgeführt, so brauchen diese Prüfungen nicht wiederholt zu werden.
In diesem Fall sind lediglich die Ergebnisse dieser Sicherheitsprüfungen
nachzuprüfen. Zu Informationszwecken sind in dieser Anlage Anforderun­
gen, bei denen während der Sicherheitszertifizierung die Durchführung
einer Prüfung erwartet wird (oder die mit durchzuführenden Prüfungen
in einem engen Verhältnis stehen), mit einem „*“ gekennzeichnet.
Die nummerierten Randnummern beziehen sich auf den Hauptteil des
Anhangs, während sich die übrigen Anforderungen auf die übrigen An­
lagen beziehen (Beispiel: PIC_001 bezieht sich auf Anforderung PIC_001
von Anlage 3 Piktogramme).
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 392
In dieser Anlage werden die Typgenehmigungen für den Bewegungssensor, für die
Fahrzeugeinheit und für die externe GNSS-Ausrüstung getrennt betrachtet, da es
sich dabei um Komponenten des Kontrollgeräts handelt. Jede Komponente enthält
eine eigene Typgenehmigung, in der die anderen kompatiblen Komponenten an­
gegeben werden. Die Funktionsprüfung des Bewegungssensors (bzw. der externen
GNSS-Ausrüstung) erfolgt zusammen mit der Fahrzeugeinheit und umgekehrt.
Eine Interoperabilität zwischen sämtlichen Bewegungssensormodellen (bzw. ex­
ternen GNSS-Ausrüstungen) und sämtlichen Fahrzeugeinheitmodellen ist nicht
erforderlich. In einem solchen Fall kann die Typgenehmigung für einen Bewe­
gungssensor (bzw. externe GNSS-Ausrüstung) nur in Kombination mit der Typ­
genehmigung für die relevante Fahrzeugeinheit bzw. umgekehrt erteilt werden.
▼M3
Die Behörde der Mitgliedstaaten, die für die Funktionsprüfungen einer Fahrzeug­
einheit oder einer externen GNSS-Ausrüstung zuständig ist, muss sicherstellen,
dass der integrierte GNSS-Empfänger die in dieser Anlage festgelegten
OSNMA-Prüfungen erfolgreich bestanden hat. Diese Prüfungen gelten als Teil
der Funktionsprüfungen der Fahrzeugeinheit oder der externen GNSS-Ausrüstung.
▼B
1.2. Referenzdokumente
In dieser Anlage werden folgende Referenzdokumente herangezogen:
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)
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) (sinusförmig).
IEC 60068-2-6: Environmental testing — Part 2: Tests — Test Fc: Vi­
bration (sinusoidal) (Umgebungseinflüsse — Teil 2-6: Prüfverfahren —
Prüfung Fc: Schwingen (sinusförmig)
IEC 60068-2-14: Environmental testing; Part 2-14: Tests; Test N: Change
of temperature (Umgebungseinflüsse — Teil 2-14: Prüfverfahren — Prü­
fung N: Temperaturwechsel)
IEC 60068-2-27: Environmental testing. Part 2: Tests. Test Ea and gui­
dance: Shock (Umgebungseinflüsse; Teil 2-27: Prüfverfahren — Prüfung
Ea und Leitfaden: Schocken)
IEC 60068-2-30: Environmental testing — Part 2-30: Tests — Test Db:
Damp heat, cyclic (12 h + 12 h cycle) (Umgebungseinflüsse — Teil 2-30:
Prüfverfahren — Prüfung Db: Feuchte Wärme, zyklisch (12 + 12 Stunden))
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)
IEC 60068-2-78 Environmental testing — Part 2-78: Tests — Test Cab:
Damp heat, steady state (Umgebungseinflüsse — Teil 2-78: Prüfverfahren
— Prüfung Cab: Feuchte Wärme, konstant)
ISO 16750-3 — Mechanical loads (2012-12) (Mechanische Beanspruchungen)
ISO 16750-4 — Climatic loads (2010-04) (Klimatische Beanspruchungen).
ISO 20653: Road vehicles — Degree of protection (IP code) — Protection
of electrical equipment against foreign objects, water and access (Straßen­
fahrzeuge — Schutzarten (IP-Code) — Schutz gegen fremde Objekte,
Wasser und Kontakt — Elektrische Ausrüstungen)
ISO 10605:2008 + Technical Corrigendum:2010 + AMD1:2014 Road ve­
hicles — Test methods for electrical disturbances from electrostatic disch­
arge (Straßenfahrzeuge — Prüfverfahren für elektrische Störungen durch
elektrostatische Entladungen)
ISO 7637-1:2002 + AMD1: 2008 Road vehicles — Electrical disturbances
from conduction and coupling — Part 1: Definitions and general consi­
derations (Straßenfahrzeuge; Elektrische Störungen durch Leitung und
Kopplung — Teil 1: Allgemeines und Definitionen).
ISO 7637-2 Road vehicles — Electrical disturbances from conduction and coup­
ling — Part 2: Electrical transient conduction along supply lines only (Straßenfahr­
zeuge — Elektrische Störungen durch Leitung und Kopplung — Teil 2: Elektri­
sche, leitungsgeführte Störungen auf Versorgungsleitungen).
ISO 7637-3 Road vehicles — Electrical disturbances from conduction and coup­
ling — Part 3: Electrical transient transmission by capacitive and inductive coup­
ling via lines other than supply lines (Straßenfahrzeuge — Elektrische Störungen
durch Leitung und Kopplung — Kapazitiv und induktiv gekoppelte Störungen auf
andere als Versorgungsleitungen).
ISO/IEC 7816-1 Identification cards — Integrated circuit(s) cards with
contacts — Part 1: Physical characteristics (Identifikationskarten — Chip­
karten mit Kontakten — Teil 1: Physikalische Eigenschaften).
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 393
ISO/IEC 7816-2 Information technology — Identification cards — Inte­
grated circuit(s) cards with contacts — Part 2: Dimensions and location of
the contacts (Identifikationskarten — Chipkarten — Karten mit Kontakten
— Teil 2: Maße und Anordnung der Kontakte).
ISO/IEC 7816-3 Information technology — Identification cards — Inte­
grated circuit(s) cards with contacts — Part 3: Electronic signals and
transmission protocol (Chipkarten mit Kontakten — Teil 3: Elektronische
Eigenschaften und Übertragungsprotokolle).
ISO/IEC 10373-1:2006 + AMD1:2012 Identification cards — Test me­
thods — Part 1: General characteristics (Identifikationskarten — Prüfver­
fahren — Teil 1: Generelle Eigenschaften).
ISO/IEC 10373-3:2010 + Technical Corrigendum:2013 Identification
cards — Test methods — Part 3: Integrated circuit cards with contacts
and related interface devices (Identifikationskarten — Prüfverfahren —
Teil 3: Chipkarten mit Kontakten und zugehörige Schnittstellen-Geräte)
ISO 16844-3:2004, Cor 1:2006 Road vehicles — Tachograph systems —
Part 3: Motion sensor interface (with vehicle units) (Straßenfahrzeuge —
Fahrtschreiber (Kontrollgeräte) — Teil 3: Schnittstelle Bewegungssensor).
ISO 16844-4 Road vehicles — Tachograph systems — Part 4: CAN
interface (Straßenfahrzeuge — Fahrtschreiber (Kontrollgeräte) — Teil 4:
CAN-Schnittstelle).
ISO 16844-6 Road vehicles — Tachograph systems — Part 6: Diagnostics
(Straßenfahrzeuge — Fahrtschreiber (Kontrollgeräte) — Teil 6: Diagnose)
ISO 16844-7 Road vehicles — Tachograph systems — Part 7: Parameter
ISO 534 Paper and board – Determination of thickness, density and spe­
cific volume (Papier und Pappe — Bestimmung der Dicke, der Dichte und
des spezifischen Volumens)
▼M3
RGODP Technischer Bericht der JRC – Receiver guidelines for OSNMA
data processing (Leitlinien für Empfänger hinsichtlich der OSNMA-Daten­
verarbeitung)
▼B
UN ECE R10 Uniform provisions concerning the approval of vehicles
with regard to electromagnetic compatibility (United Nation Economic
Commission for Europe) (Regelung der Wirtschaftskommission für Europa
bei den Vereinten Nationen über einheitliche technische Bedingungen für
die Genehmigung von Fahrzeugen hinsichtlich der elektromagnetischen
Verträglichkeit
2. FUNKTIONSPRÜFUNGEN AN DER FAHRZEUGEINHEIT
▼M1
Nr. Prüfung Beschreibung Anforderungsentsprechung
1. 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
2. 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
3. Funktionsprüfungen
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 394
Nr. Prüfung Beschreibung Anforderungsentsprechung
▼M3
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-, Positions- und Wegstreckenmessung 21 bis 37
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 und 134
3.9 Eingaben des Fahrers 56 bis 62c
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 88a, 134
3.13 Kenndaten der Fahrzeugeinheit 93*, 94*, 97, 100
3.14 Einsteck- und Entnahmedaten der Fahrer- oder der Werkstattkarte 102* bis 104*
3.15 Fahrertätigkeitsdaten 105* bis 107*
3.16 Orts- und Positionsdaten 108* bis 112*
3.17 Kilometerstandsdaten 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 Daten der Fahrtenschreiberkarten 132*, 133*
▼M1
02016R0799 — DE — 21.08.2023 — 003.002 — 395
Nr. Prüfung Beschreibung Anforderungsentsprechung
3.28 Grenzüberschreitungen 133a* bis 133d*
3.29 Be-/Entladevorgang 133e* bis 133i*
3.30 Digitale Karte 133j* bis 133t*
3.31 Aufzeichnung und Speicherung von Daten auf Fahrtenschreiberkarten 136, 137, 138*, 139*, 141*,
142, 143
144, 145, 146*, 147*, 147a*,
147b*, 148*, 149, 150, 150a
3.32 Anzeige 90, 134,
151 bis 168,
PIC_001, DIS_001
3.33 Drucken 90, 134,
169 bis 181, PIC_001,
PRT_001 bis PRT_014
3.34 Warnung 134, 182 bis 191,
PIC_001
3.35 Herunterladen von Daten auf externe Datenträger 90, 134, 192 bis 196
3.36 Fernkommunikation für gezielte Straßenkontrollen 197 bis 199
3.37 Datenaustausch mit externen Zusatzgeräten 200, 201
3.38 Kalibrierung 202 bis 206*, 383, 384, 386
bis 391
3.39 Kalibrierungskontrolle unterwegs 207 bis 209
3.40 Zeiteinstellung 210 bis 212*
3.41 Überwachung von Grenzüberschreitungen 226a bis 226c
3.42 Softwareaktualisierung 226d bis 226f
3.43 Störungsfreiheit zusätzlicher Funktionen 06, 425
3.44 Bewegungssensor-Schnittstelle 02, 122
3.45 Externe GNSS-Ausrüstung 03, 123
3.46 Überprüfen, dass die Fahrzeugeinheit die herstellerdefinierten Ereignisse
und/oder Störungen ermittelt, aufzeichnet und speichert, wenn ein ge­
koppelter Bewegungssensor auf Magnetfelder reagiert, die die Ermitt­
lung von Fahrzeugbewegungsdaten stören.
217
3,47 Ziffernfolge und standardisierte Domänenparameter CSM_48, CSM_50
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 396
Nr. Prüfung Beschreibung Anforderungsentsprechung
4. 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 (Umgebungs­
einflü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üfun­
gen zulässig.
213
4.2 Luftfeuchtigkeit IEC 60068-2-30, Prüfung Db, zum Nach­
weis, dass die Fahrzeugeinheit einer zykli­
schen 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 1. Sinusschwingungen
Nachweis, dass die Fahrzeugeinheit Si­
nusschwingungen mit folgenden Merk­
malen 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 befin­
den, keine Prüfung mit Sinusschwingun­
gen vor.
2. Zufallsschwingungen:
Prüfung gemäß ISO 16750-3, Kapi­
tel 4.1.2.8: Prüfung VIII: Nutzfahrzeug,
entkoppelte Fahrerkabine
219
▼M1
02016R0799 — DE — 21.08.2023 — 003.002 — 397
Nr. Prüfung Beschreibung Anforderungsentsprechung
Prüfung mit regellosem Schwingen, 10...2 000
Hz, RMS vertikal 21,3 m/s 2 , RMS longitudi­
nal 11,8 m/s 2 , RMS lateral 13,1 m/s 2 , 3 Ach­
sen, 32 Std. je Achse, einschließlich Tem­
peraturzyklus – 20...70 °C.
Diese Prüfung bezieht sich auf IEC 60068-2-
64: Environmental testing — Part 2-64:
Tests — Test Fh: Vibration, broadband ran­
dom and guidance (Umgebungseinflüsse —
Teil 2-64: Prüfverfahren — Prüfung Fh:
Schwingen, Breitbandrauschen (digital ge­
regelt) und Leitfaden)
3. Stöße:
mechanische Stöße mit 3 g Halbsinus ge­
mäß ISO 16750.
Diese Prüfungen werden an zwei unterschied­
lichen Proben des zu prüfenden Gerätetyps
durchgeführt.
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 ob­
jects, 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 Stromversor­
gung standhält
(ISO 16750-2)
216
4.7 Kurzschlussschutz Nachweis, dass für Eingangs-/Ausgangssig­
nale Schutz vor Kurzschluss der Stromver­
sorgung und vor Erdschluss besteht
(ISO 16750-2)
216
5. EMV-Prüfungen
5.1 Störaussendung und
Störanfälligkeit
Einhaltung von ECE-Regelung R10 218
5.2 Elektrostatische Ent­
ladung
Einhaltung von ISO 10605:2008 +
Technische Korrektur:2010 +
AMD1:2014: +/– 4 kV Kontaktentladung
und +/– 8 kV Luftentladung
218
▼M1
02016R0799 — DE — 21.08.2023 — 003.002 — 398
Nr. Prüfung Beschreibung Anforderungsentsprechung
5.3 Leitungsgeführte Stör­
größen auf Versor­
gungsleitungen
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
▼B
3. FUNKTIONSTESTS AM BEWEGUNGSSENSOR
Nr. Prüfung Beschreibung
Anforderungsentspre­
chung
1. Administrative Prüfung
1.1 Dokumentation Richtigkeit der Dokumentation
2. Sichtprüfung
2.1. Übereinstimmung mit der Dokumentation
2.2. Kennung/Markierungen 225, 226,
2.3 Werkstoffe 219 bis 223
2.4. Plombierung 398, 401 bis 405
3. Funktionsprüfungen
3.1 Kenndaten des Sensors 95 bis 97*
▼M1
02016R0799 — DE — 21.08.2023 — 003.002 — 399
Nr. Prüfung Beschreibung
Anforderungsentspre­
chung
3.2 Koppelung des Bewegungssensors mit der Fahrzeugeinheit 122*, 204
3.3 Bewegungserkennung
Bewegungsmessgenauigkeit
30 bis 35
3.4 VU-Schnittstelle 02
3.5 Überprüfen, dass der Bewegungssensor gegenüber konstanten Magnetfeldern
unempfindlich ist. Andernfalls überprüfen, dass der Bewegungssensor auf kon­
stante Magnetfelder reagiert, die die Ermittlung von Fahrzeugbewegungsdaten
stören, sodass eine verbundene VU Sensorstörungen ermitteln, aufzeichnen und
speichern kann
217
4. Umweltprüfungen
4.1 Betriebstemperatur Prüfung der Funktionstüchtigkeit (entsprechend
Festlegung in Prüfung Nr. 3.3) im Temperatur­
bereich [– 40 °C; + 135 °C] anhand:
IEC 60068-2-1, Prüfung Ad, Prüfdauer 96 Std.
bei Mindesttemperatur To min ,
IEC 60068-2-2 Prüfung Bd, Prüfdauer 96 Std.
bei Höchsttemperatur To max
Prüfung gemäß ISO 16750-4, Kapitel 5.1.1.2:
Betriebsprüfung bei niedrigen Temperaturen (24
h @ – 40 °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üf­
verfahren — Prüfung A: Kälte) IEC 68-2-2 Prü­
fung Bd, Prüfdauer 96 Std. bei Mindesttempera­
tur – 40 °C.
Prüfung gemäß ISO 16750-4, Kapitel 5.1.2.2:
Betriebsprüfung bei hohen Temperaturen (96 h
@ 135 °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)
213
4.2 Temperaturzyklen Prüfung gemäß ISO 16750-4, Kapitel 5.3.2:
Schneller Temperaturwechsel mit angegebener
Übergangsdauer (– 40 °C/135 °C, 20 Zyklen,
Haltezeit 30 min bei jeder Temperatur)
IEC 60068-2-14: Environmental testing; Part 2-
14: Tests; Test N: Change of temperature (Um­
gebungseinflüsse — Teil 2-14: Prüfverfahren —
Prüfung N: Temperaturwechsel)
213
4.3 Luftfeuchtigkeitszyklen Prüfung der Funktionstüchtigkeit (entsprechend
Festlegung in Prüfung Nr. 3.3) anhand IEC
60068-2-30, Prüfung Db, sechs 24-Std.-Zyklen,
jeweils mit einer Temperaturänderung von + 25
°C bis + 55 °C und einer relativen Luftfeuchtig­
keit von 97 % bei + 25 °C bzw. entsprechend
93 % bei + 55 °C
214
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 400
Nr. Prüfung Beschreibung
Anforderungsentspre­
chung
4.4 Schwingungen ISO 16750-3, Kapitel 4.1.2.6: Prüfung VI:
Nutzfahrzeug, Motor, Getriebe
Schwingungsprüfung im gemischten Modus ein­
schließlich
a) Sinusschwingungsprüfung, 20…520 Hz,
11,4 … 120 m/s 2 ,
b) Zufallsschwingungsprüfung, 10…2 000 Hz,
RMS 177 m/s 2
94 Std. je Achse, einschließlich Temperatur­
zyklus – 20…70 °C)
Diese Prüfung bezieht sich auf IEC 60068-2-80:
Environmental testing — Part 2-80: Tests —
Test Fi: Vibration — Mixed mode (Umge­
bungseinflüsse — Teil 2-80: Prüfverfahren —
Prüfung Fi: Schwingungsprüfung im gemischten
Modus)
219
4.5 Mechanischer Stoß ISO 16750-3, Kapitel 4.2.3: Prüfung VI: Prü­
fung für Geräte in oder auf dem Getriebe
Halbsinusstoß, Beschleunigung zu vereinbaren
im Bereich 3 000…15 000 m/s 2 , Impulsdauer
zu vereinbaren, jedoch
ßen: zu vereinbaren
Diese Prüfung bezieht sich auf IEC 60068-2-27:
Environmental testing. Part 2: Tests. Test Ea
and guidance: Shock (Umgebungseinflüsse;
Teil 2-27: Prüfverfahren — Prüfung Ea und
Leitfaden: Schocken)
219
4.6 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 — Schutz­
arten (IP-Code) — Schutz gegen fremde Ob­
jekte, Wasser und Kontakt — Elektrische Aus­
rüstungen)
(Zielwert IP 64)
220, 221
4.7 Falschpolungsschutz Nachweis, dass der Bewegungssensor einer Um­
kehrung der Polarität der Stromversorgung
standhält
216
4.8 Kurzschlussschutz Nachweis, dass für Eingangs-/Ausgangssignale
Schutz vor Kurzschluss der Stromversorgung
und vor Erdschluss besteht
216
5. EMV
5.1 Störaussendung und Stör­
anfälligkeit
Überprüfung der Einhaltung von ECE-Regelung
R10
218
5.2 Elektrostatische Entladung Einhaltung von ISO 10605:2008 + Technische
Korrektur:2010 + AMD1:2014: +/- 4 kV Kon­
taktentladung und +/- 8 kV Luftentladung
218
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 401
Nr. Prüfung Beschreibung
Anforderungsentspre­
chung
5.3 Anfälligkeit gegenüber lei­
tungsgeführten Störgrößen
auf Datenleitungen
24-V-Versionen: Einhaltung von ISO 7637-2 +
ECE-Verordnung 10 Rev. 3:
Impuls 1a: Vs = – 450 V Ri = 50 Ohm
Impuls 2a: Vs = + 37V Ri = 2 Ohm
Impuls 2b: Vs = + 20V Ri = 0,05 Ohm
Impuls 3a: Vs = – 150V Ri = 50 Ohm
Impuls 3b: Vs = + 150V 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 = – 75V Ri = 10 Ohm
Impuls 2a: Vs = + 37V Ri = 2 Ohm
Impuls 2b: Vs = + 10V Ri = 0,05 Ohm
Impuls 3a: Vs = – 112V Ri = 50 Ohm
Impuls 3b: Vs = + 75V 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 vor­
gesehen ist
Blindlastvorschläge siehe ISO 16750-2, 4. Aus­
gabe, Kapitel 4.6.4
218
4. FUNKTIONSPRÜFUNGEN AN FAHRTENSCHREIBERKARTEN
Die Prüfungen gemäß diesem Abschnitt 4,
Abschnitt 5 „Protokollprüfungen“,
Abschnitt 6 „Kartenstruktur“ und
Abschnitt 7 „Funktionsprüfungen“
können vom prüfenden oder bescheinigenden Unternehmen während der
CC-Sicherheitszertifizierung (Common Criteria bzw. Allgemeine Kriterien
für die Bewertung der Sicherheit für Informationstechnologie) für das
Chipmodul durchgeführt werden.
Die Prüfungen 2.3 und 4.2 sind identisch. Hierbei handelt es sich um
mechanische Prüfungen der Kombination Kartenkörper/Chipmodul.
Wenn eine dieser Komponenten (Kartenkörper, Chipmodul) geändert wird,
sind diese Prüfungen erforderlich.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 402
Nr. Prüfung Beschreibung
Anforderungsentspre­
chung
1. Administrative Prüfung
1.1 Dokumentation Richtigkeit der Dokumentation
2 Kartenkörper
2.1 Druckdesign
Gewährleistung, dass sämtliche Schutzanforderungen
und die sichtbar anzubringenden Angaben korrekt
gedruckt sind und den Vorgaben entsprechen.
[Bezeichner]
Anhang 1C, Kapitel 4.1 „Sichtbare Daten“, 227)
Die Vorderseite enthält:
je nach Kartentyp die großgedruckten Wörter „Fah­
rerkarte“ oder „Kontrollkarte“ oder „Werkstattkarte“
oder „Unternehmenskarte“ in der Sprache bzw. den
Sprachen des ausstellenden Mitgliedstaats;
[Name des Mitgliedstaates]
Anhang 1C, Kapitel 4.1 „Sichtbare Daten“, 228)
Die Vorderseite enthält:
den Namen des Mitgliedstaats, der die Karte ausstellt
(fakultativ).
[Zeichen]
Anhang 1C, Kapitel 4.1 „Sichtbare Daten“, 229)
Die Vorderseite enthält:
das Unterscheidungszeichen des ausstellenden Mit-
gliedstaates im Negativdruck in einem blauen Re-
chteck, umgeben von zwölf gelben Sternen:
[Nummerierung]
Anhang 1C, Kapitel 4.1 „Sichtbare Daten“, 232)
Die Rückseite enthält:
eine Erläuterung zu den nummerierten Angaben auf
der Vorderseite der Karte.
[Farbe]
Anhang 1C, Kapitel 4.1 „Sichtbare Daten“, 234)
Die Fahrtenschreiberkarten werden mit folgender
Hintergrundfarbe gedruckt:
— Fahrerkarte: weiß,
— Werkstattkarte: rot,
— Kontrollkarte: blau,
— Unternehmenskarte: gelb.
227 bis 229, 232,
234 bis 236
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 403
Nr. Prüfung Beschreibung
Anforderungsentspre­
chung
[Sicherheit]
Anhang 1C, Kapitel 4.1 „Sichtbare Daten“, 235)
Zum Schutz vor Fälschung und unbefugten Änderun-
gen weisen die Fahrtenschreiberkarten mindestens
folgende Merkmale auf:
— ein Sicherheitshintergrunddesign mit feingemus-
tertem Guillochen und Irisdruck,
— mindestens eine zweifarbige Mikrodruckzeile.
[Markierungen]
Anhang 1C, Kapitel 4.1 „Sichtbare Daten“, 236)
Die Mitgliedstaaten können Farben oder Markierun-
gen wie Staatssymbole oder Sicherheitsmerkmale
hinzufügen.
[Prüfzeichen]
Die Fahrtenschreiberkarten tragen ein Prüfzeichen.
Das Prüfzeichen besteht
— aus einem Rechteck, in dem der Buchstabe „e“
platziert ist, gefolgt von der Kennzahl oder dem
Kennbuchstaben des Landes, das die Typgeneh-
migung erteilt hat,
— aus einer Typgenehmigungsnummer, die der
Nummer des Typgenehmigungsbogens für die
Fahrtenschreiberkarte entspricht und an einer
beliebigen Stelle in der Nähe des Rechtecks
anzubringen ist.
2.2 Mechanische Prüfun­
gen [Kartengröße]
Die Fahrtenschreiberkarten müssen die folgende
Norm erfüllen:
ISO/IEC 7810, Identification cards — Physical
characteristics,
[5] Dimension of card,
[5.1] Card size,
[5.1.1] Card dimensions and tolererances,
card type ID-1 Unused card (Identifikationskarten
— Physikalische Eigenschaften, [5] Abmessungen
der Karte, [5.1] Kartengröße, [5.1.1] Abmessungen
der Karte und Toleranzen, Kartentyp ID-1 Nicht
verwendete Karte)
[Kartenränder]
Die Fahrtenschreiberkarten müssen die folgende
Norm erfüllen:
ISO/IEC 7810, Identification cards — Physical
characteristics,
[5] Dimension of card,
[5.1] Card size,
[5.1.2] Card edges (Identifikationskarten — Physika-
lische Eigenschaften, [5] Abmessungen der Karte,
[5.1] Kartengröße, [5.1.2] Kartenränder)
240, 243
ISO/IEC 7810
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 404
Nr. Prüfung Beschreibung
Anforderungsentspre­
chung
[Aufbau der Karte]
Die Fahrtenschreiberkarten müssen die folgende
Norm erfüllen:
ISO/IEC 7810, Identification cards — Physical
characteristics,
[6] Card construction (Identifikationskarten — Physi-
kalische Eigenschaften, [6] Aufbau der Karte)
[Kartenmaterialien]
Die Fahrtenschreiberkarten müssen die folgende
Norm erfüllen:
ISO/IEC 7810, Identification cards — Physical
characteristics,
[7] Card materials (Identifikationskarten — Physika-
lische Eigenschaften, [7] [Kartenmaterialien])
[Biegesteifigkeit]
Die Fahrtenschreiberkarten müssen die folgende
Norm erfüllen:
ISO/IEC 7810, Identification cards — Physical
characteristics,
[8] Card characteristics,
[8.1] Bending stiffness (Identifikationskarten —
Physikalische Eigenschaften, [8] Eigenschaften der
Karte, [8.1] Biegesteifigkeit)
[Toxizität]
Die Fahrtenschreiberkarten müssen die folgende
Norm erfüllen:
ISO/IEC 7810, Identification cards — Physical
characteristics,
[8] Card characteristics,
[8.3] Toxicity (Identifikationskarten — Physikalische
Eigenschaften, [8] Eigenschaften der Karte, [8.3]
Toxizität)
[Chemikalienbeständigkeit]
Die Fahrtenschreiberkarten müssen die folgende
Norm erfüllen:
ISO/IEC 7810, Identification cards — Physical
characteristics,
[8] Card characteristics,
[8.4] Resistance to chemicals (Identifikationskarten —
Physikalische Eigenschaften, [8] Eigenschaften der
Karte, [8.4] Chemikalienbeständigkeit)
[Stabilität der Karte]
Die Fahrtenschreiberkarten müssen die folgende
Norm erfüllen:
ISO/IEC 7810, Identification cards — Physical
characteristics,
[8] Card characteristics,
[8.5] Card dimensional stability and warpage with
temperature and humidity (Identifikationskarten —
Physikalische Eigenschaften, [8] Eigenschaften der
Karte, [8.5] Stabilität/Verzug der Kartenabmessungen
unter Einfluss von Temperatur und Feuchte)
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 405
Nr. Prüfung Beschreibung
Anforderungsentspre­
chung
[Licht]
Die Fahrtenschreiberkarten müssen die folgende
Norm erfüllen:
ISO/IEC 7810, Identification cards — Physical
characteristics,
[8] Card characteristics,
[8.6] Light (Identifikationskarten — Physikalische
Eigenschaften, [8] Eigenschaften der Karte, [8.6]
Licht)
[Haltbarkeit]
Anhang 1C, Kapitel 4.4 „Spezifikationen für Umge-
bung und Elektrizität“, 241)
Fahrtenschreiberkarten müssen bei Verwendung
gemäß den Spezifikationen für Umgebung und
Elektrizität während einer Dauer von fünf Jahren
ordnungsgemäß funktionieren können.
[Schälfestigkeit]
Die Fahrtenschreiberkarten müssen die folgende
Norm erfüllen:
ISO/IEC 7810, Identification cards — Physical
characteristics,
[8] Card characteristics,
[8.8] Peel strength (Identifikationskarten — Physika-
lische Eigenschaften, [8] Eigenschaften der Karte,
[8.8] Schälfestigkeit)
[Farbhaftung/Blockfestigkeit]
Die Fahrtenschreiberkarten müssen die folgende
Norm erfüllen:
ISO/IEC 7810, Identification cards — Physical
characteristics,
[8] Card characteristics,
[8.9] Adhesion or blocking (Identifikationskarten —
Physikalische Eigenschaften, [8] Eigenschaften der
Karte, [8.9] Farbhaftung/Blockfestigkeit)
[Verzug]
Die Fahrtenschreiberkarten müssen die folgende
Norm erfüllen:
ISO/IEC 7810, Identification cards — Physical
characteristics,
[8] Card characteristics,
[8.11] Overall card warpage (Identifikationskarten —
Physikalische Eigenschaften, [8] Eigenschaften der
Karte, [8.11] Genereller Verzug der Karte)
[Hitzebeständigkeit]
Die Fahrtenschreiberkarten müssen die folgende
Norm erfüllen:
ISO/IEC 7810, Identification cards — Physical
characteristics,
[8] Card characteristics,
[8.12] Resistance to heat (Identifikationskarten —
Physikalische Eigenschaften, [8] Eigenschaften der
Karte, [8.12] Hitzebeständigkeit)
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 406
Nr. Prüfung Beschreibung
Anforderungsentspre­
chung
[Oberflächenverformung]
Die Fahrtenschreiberkarten müssen die folgende
Norm erfüllen:
ISO/IEC 7810, Identification cards — Physical
characteristics,
[8] Card characteristics,
[8.13] Surface distortions (Identifikationskarten —
Physikalische Eigenschaften, [8] Eigenschaften der
Karte, [8.13] Oberflächenverformung)
[Kontaminierung]
Die Fahrtenschreiberkarten müssen die folgende
Norm erfüllen:
ISO/IEC 7810, Identification cards — Physical
characteristics,
[8] Card characteristics,
[8.14] Contamination and interaction of card components
(Identifikationskarten — Physikalische Eigenschaften, [8]
Eigenschaften der Karte, [8.14] Kontaminierung und
Interaktion der Kartenkomponenten)
2.3 Mechanische Prüfun­
gen mit eingebettetem
Chipmodul
[Biegung]
Die Fahrtenschreiberkarten müssen die folgende
Norm erfüllen:
ISO/IEC 7810:2003/Änderung 1:2009, Identification
cards — Physical characteristics, Amendment 1:
Criteria for cards containing integrated circuits
[9.2] Dynamic bending stress (Identifikationskarten
— Physikalische Eigenschaften, Änderung 1: Krite­
rien für Karten mit integrierten Schaltkreisen, [9.2]
Dynamische Biegebelastung)
Gesamtzahl an Biegezyklen: 4 000.
[Torsion]
Die Fahrtenschreiberkarten müssen die folgende Norm
erfüllen:
ISO/IEC 7810:2003/Änderung 1:2009, Identification
cards — Physical characteristics, Amendment 1:
Criteria for cards containing integrated circuits
[9.3] Dynamic torsional stress (Identifikationskarten
— Physikalische Eigenschaften, Änderung 1: Kriter-
ien für Karten mit integrierten Schaltkreisen, [9.3]
Dynamische Torsionsbelastung)
Gesamtzahl an Torsionszyklen: 4 000.
ISO/IEC 7810
3 Modul
3.1 Modul
Das Modul bildet die Kapselung des Chips und die
Kontaktplatte.
[Oberflächenprofil]
Die Fahrtenschreiberkarten müssen die folgende
Norm erfüllen:
ISO/IEC 7816-1:2011, Identification cards — Inte­
grated circuit cards — Part 1: Cards with contacts
— Physical characteristics
[4.2] Surface profile of contacts (Identifikationskarten
— Chipkarten — Teil 1: Chipkarten mit Kontakten —
Physikalische Eigenschaften, [4.2] Oberflächenprofil
der Kontakte)
ISO/IEC 7816
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 407
Nr. Prüfung Beschreibung
Anforderungsentspre­
chung
[Mechanische Stärke]
Die Fahrtenschreiberkarten müssen die folgende Norm
erfüllen:
ISO/IEC 7816-1:2011, Identification cards — Integra­
ted circuit cards — Part 1: Cards with contacts —
Physical characteristics
[4.3] Mechanical strength (of a card and contacts)
(Identifikationskarten — Chipkarten — Teil 1: Chip­
karten mit Kontakten — Physikalische Eigenschaften,
[4.3] Mechanische Stärke (von Karte und Kontakten)
[Elektrischer Widerstand]
Die Fahrtenschreiberkarten müssen die folgende
Norm erfüllen:
ISO/IEC 7816-1:2011, Identification cards — Inte-
grated circuit cards — Part 1: Cards with contacts —
Physical characteristics
[4.4] Electrical resistance (of contacts) (Identifika-
tionskarten — Chipkarten — Teil 1: Chipkarten mit
Kontakten — Physikalische Eigenschaften, [4.4]
Elektrischer Widerstand (der Kontakte)
[Abmessungen]
Die Fahrtenschreiberkarten müssen die folgende
Norm erfüllen:
ISO/IEC 7816-2:2007, Identification cards — Inte-
grated circuit cards — Part 2: Cards with contacts —
Dimension and location of the contacts
[3] Dimension of the contacts (Identifikationskarten
— Chipkarten — Teil 2: Chipkarten mit Kontakten —
Maße und Anordnung der Kontakte, [3] Maße der
Kontakte
[Anordnung]
Die Fahrtenschreiberkarten müssen die folgende
Norm erfüllen:
ISO/IEC 7816-2:2007, Identification cards — Inte-
grated circuit cards — Part 2: Cards with contacts —
Dimension and location of the contacts
[4] Number and location of the contacts (Identifika-
tionskarten — Chipkarten — Teil 2: Chipkarten mit
Kontakten — Maße und Anordnung der Kontakte, [4]
Anzahl und Anordnung der Kontakte
Im Falle von Modulen mit sechs Kontakten zählen die
K o n t a k t e „ C 4 “ u n d „ C 8 “ n i c h t z u d i e s e r
Prüfanforderung.
4 Chip
4.1 Chip
[Betriebstemperatur]
Der Chip der Fahrtenschreiberkarte muss bei Umge­
bungstemperaturen in einem Bereich zwischen – 25
°C und + 85 °C funktionieren.
241 bis 244
ECE R10
ISO/IEC 7810
ISO/IEC 10373
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 408
Nr. Prüfung Beschreibung
Anforderungsentspre­
chung
[Temperatur und Feuchte]
Anhang 1C, Kapitel 4.4 „Spezifikationen für Umge­
bung und Elektrizität“, 241)
Die Fahrtenschreiberkarten müssen unter allen klima­
tischen Bedingungen, die im Gebiet der Gemein­
schaft gewöhnlich anzutreffen sind, ordnungsgemäß
funktionieren können, mindestens im Temperatur­
bereich – 25 °C bis + 70 °C mit gelegentlichen Spit­
zen bis zu + 85 °C, wobei „gelegentlich“ jeweils
nicht mehr als 4 Stunden und nicht mehr als 100
mal während der Lebensdauer der Karte bedeutet.
Die Fahrtenschreiberkarten werden aufeinanderfol­
gend den folgenden Temperaturen und Feuchtigkei­
ten für die angegebene Zeitdauer ausgesetzt. Nach
jedem Schritt werden die Fahrtenschreiberkarten auf
elektrische Funktionsfähigkeit geprüft.
1. Temperatur von – 20 °C für 2 h.
2. Temperatur von +/–0 °C für 2 h.
3. Temperatur von + 20 °C, 50 % RF, für 2 h.
4. Temperatur von 50 °C, 50 % RF, für 2 h.
5. Temperatur von 70 °C, 50 % RF, für 2 h.
Die Temperatur wird periodisch auf + 85 °C,
50 % RF, für 60 min erhöht.
6. Temperatur von 70 °C, 85 % RF, für 2 h.
Die Temperatur wird periodisch auf + 85 °C,
85 % RF, für 30 min erhöht.
[Luftfeuchtigkeit]
Anhang 1C, Kapitel 4.4 „Spezifikationen für Umge-
bung und Elektrizität“, 242)
Die Fahrtenschreiberkarten müssen bei einer Luft-
feuchtigkeit von 10 bis 90 % ordnungsgemäß funk-
tionieren können.
[Elektromagnetische Verträglichkeit — EMV]
Anhang 1C, Kapitel 4.4 „Spezifikationen für Umge-
bung und Elektrizität“, 244)
Während des Betriebs müssen die Fahrtenschreiber-
karten ECE R10 bezüglich der elektromagnetischen
Verträglichkeit erfüllen.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 409
Nr. Prüfung Beschreibung
Anforderungsentspre­
chung
[Statische Elektrizität]
Anhang 1C, Kapitel 4.4 „Spezifikationen für Umge-
bung und Elektrizität“, 244)
Während des Betriebs müssen die Fahrtenschreiber-
karten gegen elektrostatische Entladungen geschützt
sein.
Die Fahrtenschreiberkarten müssen die folgende
Norm erfüllen:
ISO/IEC 7810:2003/Änderung 1:2009, Identification
cards — Physical characteristics, Amendment 1:
Criteria for cards containing integrated circuits
[9.4] Static electricity
[9.4.1] Contact IC cards (Identifikationskarten —
Physikalische Eigenschaften, Änderung 1: Kriterien
für Karten mit integrierten Schaltkreisen, [9.4]
Statische Elektrizität, [9.4.1] Kontakt IS-Karten)
Prüfspannung: 4 000 V.
[Röntgenstrahlen]
Die Fahrtenschreiberkarten müssen die folgende
Norm erfüllen:
ISO/IEC 7810:2003/Änderung 1:2009, Identification
cards — Physical characteristics, Amendment 1:
Criteria for cards containing integrated circuits
[9.1] Röntgenstrahlen
[Ultraviolettlicht]
ISO/IEC 10373-1:2006, Identification cards — Test
methods — Part 1: General characteristics
[5.11] Ultraviolet light (Identifikationskarten —
Physikalische Eigenschaften — Teil 1: Allgemeine
Merkmale, [5.11] Ultraviolettlicht)
[3-Rad]
Die Fahrtenschreiberkarten müssen die folgende
Norm erfüllen:
I S O / I E C 1 0 3 7 3 - 1 : 2 0 0 6 / Ä n d e r u n g I S O / I E C
103731:2012, Identification cards — Test methods
— Part 1: General characteristics, Amendment 1
[5.22] ICC — Mechanical strength: 3 wheel test for
ICCs with contacts (Identifikationskarten — Physika-
lische Eigenschaften — Teil 1: Allgemeine Merkmale,
Änderung 1, [5.22] ICC — Mechanische Belastbar-
keit: 3-Rad-Prüfung für ICC mit Kontakten)
[Umhüllung]
Die Fahrtenschreiberkarten müssen die folgende
Norm erfüllen:
MasterCard CQM V2.03:2013
[11.1.3] R-L3-14-8: Wrapping Test Robustness (Bes-
tändigkeit bei der Umhüllungsprüfung)
[13.2.1.32] TM-422: Mechanical Reliability: Wrap-
p i n g Te s t ( M e c h a n i s c h e Z u v e r l ä s s i g k e i t :
Umhüllungsprüfung)
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 410
Nr. Prüfung Beschreibung
Anforderungsentspre­
chung
4.2 Mechanische Prüfun­
gen, Chipmodule in
Kartenkörper eingebet­
tet -> wie 2.3
[Biegung]
Die Fahrtenschreiberkarten müssen die folgende
Norm erfüllen:
ISO/IEC 7810:2003/Änderung 1:2009, Identifica­
tion cards — Physical characteristics, Amendment
1: Criteria for cards containing integrated circuits
[9.2] Dynamic bending stress (Identifikationskarten
— Physikalische Eigenschaften, Änderung 1: Krite­
rien für Karten mit integrierten Schaltkreisen, [9.2]
Dynamische Biegebelastung)
Gesamtzahl an Biegezyklen: 4 000.
[Torsion]
Die Fahrtenschreiberkarten müssen die folgende
Norm erfüllen:
ISO/IEC 7810:2003/Änderung 1:2009, Identification
cards — Physical characteristics, Amendment 1:
Criteria for cards containing integrated circuits
[9.3] Dynamic torsional stress (Identifikationskarten
— Physikalische Eigenschaften, Änderung 1: Kriter-
ien für Karten mit integrierten Schaltkreisen, [9.3]
Dynamische Torsionsbelastung)
Gesamtzahl an Torsionszyklen: 4 000.
ISO/IEC 7810
5 Protokollprüfungen
5.1 ATR Prüfen, dass ATR den Anforderungen entspricht ISO/IEC 7816-3
TCS_14, TCS_17,
TCS_18
5.2 T=0 Prüfen, dass Protokoll T=0 den Anforderungen ent­
spricht
ISO/IEC 7816-3
TCS_11, TCS_12,
TCS_13, TCS_15
5.3 PTS Prüfen, dass der Befehl PTS durch Einstellen von T=1
ausgehend von T=0 den Anforderungen entspricht
ISO/IEC 7816-3
TCS_12, TCS_19,
TCS_20, TCS_21
5.4 T=1 Prüfen, dass Protokoll T=1 den Anforderungen ent­
spricht
ISO/IEC 7816-3
TCS_11, TCS_13,
TCS_16
6 Kartenstruktur
6.1 Prüfen, dass die Dateistruktur der Karte den Anforde­
rungen entspricht. Hierzu sind das Vorhandensein der
obligatorischen Dateien auf der Karte und die Zu­
griffsbedingungen darauf zu überprüfen
TCS_22 bis TCS_28
TCS_140 bis
TCS_179
7 Funktionsprüfungen
7.1 Normale Verarbeitung Für jeden Befehl ist jede zulässige Ausführung zumin­
dest einmal zu prüfen (z. B.: Prüfung des Befehls
UPDATE BINARY mit CLA = „00“, CLA = „0C“
und mit unterschiedlichen Parametern P1, P2 und Lc).
Prüfen, dass die Operationen auf der Karte tatsächlich
ausgeführt wurden (z. B.: durch das Lesen der Datei,
für die der Befehl ausgeführt wurde)
TCS_29 bis TCS_139
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 411
Nr. Prüfung Beschreibung
Anforderungsentspre­
chung
7.2 Fehlermeldungen Für jeden Befehl ist jede Fehlermeldung (entsprechend
Anlage 2) zumindest einmal zu prüfen.
Jeder generische Fehler ist zumindest einmal zu prüfen
(mit Ausnahme von „6400“-Integritätsfehlern, die
während der Sicherheitszertifizierung geprüft werden)
7.3 Ziffernfolge und standardisierte Domänenparameter CSM_48, CSM_50
8 Personalisierung
8.1 Optische Personalisie­
rung Anhang 1C, Kapitel 4.1 „Sichtbare Daten“, 230)
Die Vorderseite enthält:
Angaben zu der ausgestellten Karte.
Anhang 1C, Kapitel 4.1 „Sichtbare Daten“, 231)
Die Vorderseite enthält:
Datumsangaben im Format „TT/MM/JJJJ“ oder
„TT.MM.JJJJ“ (Tag, Monat, Jahr).
Anhang 1C, Kapitel 4.1 „Sichtbare Daten“, 235)
Zum Schutz vor Fälschung und unbefugten Änderun-
gen weisen die Fahrtenschreiberkarten mindestens
folgende Merkmale auf:
— im Bereich des Lichtbilds eine Überlappung des
Sicherheitshintergrunddesigns-
mit dem Lichtbild.
230, 231, 235
5. PRÜFUNG EXTERNER GNSS-AUSRÜSTUNG
Nein Prüfung Beschreibung
Anforderungsentspre­
chung
1. Administrative Prüfung
1.1 Dokumentation Richtigkeit der Dokumentation
2. Sichtprüfung der externen GNSS-Ausrüstung
2.1 Übereinstimmung mit der Dokumentation
2.2 Kennung/Markierungen 224 bis 226
2.3 Werkstoffe 219 bis 223
3. Funktionsprüfungen
3.1 Kenndaten des Sensors 98,99
3.2 Externes GNSS-Modul — Kopplung mit der Fahrzeugeinheit 123, 205
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 412
Nein Prüfung Beschreibung
Anforderungsentspre­
chung
3.3 GNSS-Position 36, 37
3.4 VU-Schnittstelle, wenn es sich beim GNSS-Empfänger der VU um ein externes
Gerät handelt.
03
3.5 Ziffernfolge und standardisierte Domänenparameter CSM_48, CSM_50
4. 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: Environmen­
tal testing — Part 2-1: Tests — Test A: Cold (Umgebungs­
einflü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 envi­
ronmental 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 Tem­
peraturwechsel 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 Ta­
belle 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 Fahr­
zeugeinheit einer zyklischen Feuchtigkeitsprüfung (Wär­
meprüfung) von sechs 24-Std.-Zyklen jeweils mit einer Tem­
peraturänderung von + 25 °C bis + 55 °C und einer relativen
Luftfeuchtigkeit von 97 % bei +25 o C bzw. entsprechend
93 % bei + 55 °C standhält
214
4.3 Mechanisch 1. 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 Mindest­
prüfdauer von 3 × 12 Std. (12 Std. je Achse)
ISO 16750-3 schreibt für Geräte, die sich in einer entkop­
pelten Fahrerkabine befinden, keine Prüfung mit Sinus­
schwingungen vor.
219
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 413
Nein Prüfung Beschreibung
Anforderungsentspre­
chung
2. 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/s 2 , RMS longitudinal 11,8 m/s 2 , RMS
lateral 13,1 m/s 2 , 3 Achsen, 32 Std. je Achse, einschließlich
Temperaturzyklus – 20…70 °C.
Diese Prüfung bezieht sich auf IEC 60068-2-64: Environ-
mental 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.
4.4 Schutz vor
Wasser und
vor Fremdkör­
pern
Prüfung gemäß ISO 20653: Road vehicles — Degree of pro­
tection (IP code) — Protection of electrical equipment against
foreign objects, water and access (Straßenfahrzeuge —
Schutzarten (IP-Code) — Schutz gegen fremde Objekte,
Wasser und Kontakt (Keine Parameteränderung)
220, 221
4.5 Überspan­
nungsschutz
Nachweis, dass die Fahrzeugeinheit folgende Versorgungs­
spannungen aushält:
216
24-V-Versionen: 34V bei + 40 °C 1
Stunde
12-V-Versionen: 17 V bei + 40 °C 1
Stunde
(ISO 16750-2, Kapitel 4.3)
4.6 Falschpolungs­
schutz
Nachweis, dass die Fahrzeugeinheit einer Umkehrung der
Polarität der Stromversorgung standhält
(ISO 16750-2, Kapitel 4.7)
216
4.7 Kurzschluss­
schutz
Nachweis, dass für Eingangs-/Ausgangssignale Schutz vor
Kurzschluss der Stromversorgung und vor Erdschluss besteht
(ISO 16750-2, Kapitel 4.10)
216
5 EMV-Prüfungen
5.1 Störaussendung
und Störanfäl­
ligkeit
Einhaltung von ECE-Regelung R10 218
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 414
Nein Prüfung Beschreibung
Anforderungsentspre­
chung
5.2 Elektrostatische
Entladung
Einhaltung von ISO 10605:2008 + Technische Korrek­
tur:2010 + AMD1:2014: +/– 4 kV Kontaktentladung und
+/– 8 kV Luftentladung
218
5.3 Leitungsge­
führte Störgrö­
ßen auf Versor­
gungsleitungen
24-V-Versionen: Einhaltung von ISO 7637-2 + ECE-Verord­
nung 10 Rev. 3:
Impuls 1a: Vs = – 450 V Ri = 50 Ohm
Impuls 2a: Vs = + 37V Ri = 2 Ohm
Impuls 2b: Vs = + 20V Ri = 0,05 Ohm
Impuls 3a: Vs = – 150V Ri = 50 Ohm
Impuls 3b: Vs = + 150V 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-Verord­
nung 10 Rev. 3:
Impuls 1: Vs = – 75V Ri = 10 Ohm
Impuls 2a: Vs = + 37V Ri = 2 Ohm
Impuls 2b: Vs = + 10V Ri = 0,05 Ohm
Impuls 3a: Vs = – 112V Ri = 50 Ohm
Impuls 3b: Vs = + 75V 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 Fahr­
zeugen 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
▼M1
6. PRÜFUNGEN DER EXTERNEN AUSRÜSTUNG ZUR FERNKOM­
MUNIKATION
Nr. Prüfung Beschreibung
Anforderungsentspre­
chung
1. Administrative Prüfung
1.1 Dokumentation Richtigkeit der Doku­
mentation
2. 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
3. Funktionsprüfungen
3.1 Fernkommunikation für gezielte Straßenkontrollen 4, 197 bis 199
3.2 Aufzeichnung und Speicherung von Daten im Massenspeicher 91
3.3 Kommunikation mit der Fahrzeugeinheit Anlage 14 DSC_66
bis DSC_70, DSC_71
bis DSC_76
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 415
Nr. Prüfung Beschreibung
Anforderungsentspre­
chung
4. Umweltprüfungen
4.1 Temperatur Funktionsprüfung durch:
Prüfung gemäß ISO 16750-4, Kapitel 5.1.1.2: Betriebs­
prüfung bei niedrigen Temperaturen (72 h @ – 20 °C)
Diese Prüfung bezieht sich auf IEC 60068-2-1: Environ­
mental testing — Part 2-1: Tests — Test A: Cold (Um­
gebungseinflüsse — Teil 2-1: Prüfverfahren — Prü­
fung A: Kälte)
Prüfung gemäß ISO 16750-4, Kapitel 5.1.2.2: Betriebs­
prü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üfverfah­
ren — 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 1 h bei jeder Tem­
peratur)
In Bezug auf Mindest- und Höchsttemperatur sowie wäh­
rend 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ör­
pern
Prüfung gemäß ISO 20653: Road vehicles — Degree of
protection (IP code) — Protection of electrical equip­
ment against foreign objects, water and access (Straßen­
fahrzeuge — Schutzarten (IP-Code) — Schutz gegen
fremde Objekte, Wasser und Kontakt — Elektrische
Ausrüstungen) (Zielwert IP40)
220, 221
5 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 Korrek­
tur:2010 + AMD1:2014: +/– 4 kV Kontaktentladung
und +/– 8 kV Luftentladung
218
5.3 Leitungsgeführte
Störgrößen auf Ver­
sorgungsleitungen
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
218
▼M1
02016R0799 — DE — 21.08.2023 — 003.002 — 416
Nr. Prüfung Beschreibung
Anforderungsentspre­
chung
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 ge­
meinsame externe Blindlast vorgesehen ist.
Blindlastvorschläge siehe ISO 16750-2, 4. Ausgabe, Ka­
pitel 4.6.4.
▼B
7. PAPIERFUNKTIONSPRÜFUNGEN
Nr. Prüfung Beschreibung
Anforderungsentspre­
chung
1. Administrative Prüfung
1,1 Dokumentation Richtigkeit der Dokumentation
2 Allgemeine Prüfungen
2.1 Zeichenzahl pro
Zeile
Sichtprüfung der Ausdrucke. 172
2.2 Mindestzeichengröße Sichtprüfung von Ausdrucken und Zeichen. 173
2.3 Unterstützte Zeichen­
sätze
Der Drucker muss die in Anlage 1 Kapitel 4 „Zeichen­
sätze“ spezifizierten Zeichen unterstützen.
174
2.4 Definition der Aus­
drucke
Überprüfung der Typgenehmigung des Fahrtenschrei­
bers und Prüfung der Ausdrucke
174
2.5 Lesbarkeit und Iden­
tifizierung der Aus­
drucke
Prüfung der Ausdrucke
Nachgewiesen durch Prüfberichte und -protokolle des
Herstellers.
Sämtliche Genehmigungsnummern der Fahrtenschreiber,
mit denen das Druckerpapier verwendet werden kann,
sind auf dem Papier abgedruckt.
175, 177, 178
2.6 Hinzunahme hand­
schriftlicher Notizen
Sichtprüfung: Unterschriftsfeld für den Fahrer ist ver­
fügbar.
Felder für weitere handschriftliche Eintragungen sind
verfügbar.
180
2.7 Weitere Details auf
den Seiten.
Die Vorder- und Rückseiten des Papiers können weitere
Einzelheiten und Informationen enthalten.
Diese zusätzlichen Einzelheiten und Informationen dür­
fen die Lesbarkeit der Ausdrucke nicht beeinträchtigen.
Sichtprüfung.
177, 178
▼M1
02016R0799 — DE — 21.08.2023 — 003.002 — 417
Nr. Prüfung Beschreibung
Anforderungsentspre­
chung
3 Lagerprüfung
3.1 Trockene Wärme Vorbehandlung: 16 Stunden bei + 23 °C ± 2 °C/55 %
± 3 % relative Feuchte
Prüfumgebung: 72 Stunden bei + 70 °C ± 2 °C
Wiederherstellung: 16 Stunden bei + 23 °C ± 2 °C/
55 % ±3 % relative Feuchte
176, 178
IEC 60068-2-2-Bb
3.2 Feuchte Wärme Vorbehandlung: 16 Stunden bei + 23 °C ± 2 °C/55 %
±3 % relative Feuchte
Prüfumgebung: 144 Stunden bei +55 °C ± 2 °C und
93 % ± 3 % RF
Wiederherstellung: 16 Stunden bei + 23 °C ± 2 °C/
55 % ± 3 % relative Feuchte
176, 178
IEC 60068-2-78-Cab
4 Betriebsprüfungen Papier
4.1 Feuchtigkeitsbestän­
digkeit Hintergrund
(unbedrucktes Pa­
pier)
Vorbehandlung: 16 Stunden bei + 23 °C ± 2 °C/55 %
± 3 % relative Feuchte
Prüfumgebung: 144 Stunden bei + 55 °C ± 2 °C und
93 % ± 3 % RF
Wiederherstellung: 16 Stunden bei + 23 °C ± 2 °C/
55 % ± 3 % relative Feuchte
176, 178
IEC 60068-2-78-Cab
4.2 Bedruckbarkeit Vorbehandlung: 24 Stunden bei +40 °C ± 2 °C/93 %
± 3 % relative Feuchte
Prüfumgebung: Ausdruck erfolgt bei + 23 °C ± 2 °C
Wiederherstellung: 16 Stunden bei + 23 °C ± 2 °C/
55 % ±3 % relative Feuchte
176, 178
4.3 Wärmebeständigkeit Vorbehandlung: 16 Stunden bei + 23 °C ± 2 °C/55 %
±3 % relative Feuchte
Prüfumgebung: 2 Stunden bei + 70 °C ± 2 °C, trockene
Wärme
Wiederherstellung: 16 Stunden bei + 23 °C ± 2 °C/
55 % ±3 % relative Feuchte
176, 178
IEC 60068-2-2-Bb
4.4 Beständigkeit bei
niedrigen Temperatu­
ren
Vorbehandlung: 16 Stunden bei +23 °C ± 2 °C/55 %
± 3 % relative Feuchte
Prüfumgebung: 24 Stunden bei – 20 °C ± 3 °C, tro­
ckene Kälte
Wiederherstellung: 16 Stunden bei + 23 °C ± 2 °C/
55 % ± 3 % relative Feuchte
176, 178
ISO 60068-2-1-Ab
4.5 Lichtbeständigkeit Vorbehandlung: 16 Stunden bei + 23 °C ± 2 °C/55 %
± 3 % relative Feuchte
Prüfumgebung: 100 Stunden unter 5000 Lux Beleuch­
tung bei + 23 °C ± 2 °C/55 % ± 3 % Relative Feuchte
Wiederherstellung: 16 Stunden bei + 23 °C ± 2 °C/
55 % ± 3 % relative Feuchte
176, 178
Lesbarkeitskriterien für die Prüfungen 3.x und 4.x:
Lesbarkeit des Ausdrucks ist gewährleistet, wenn die optische Dichte die
folgenden Grenzwerte einhält:
Gedruckte Zeichen: min. 1,0
Hintergrund (unbedrucktes Papier): max. 0,2
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 418
Optische Dichten der Ausdrucke zu messen gemäß DIN EN ISO 534.
Bei den Ausdrucken dürfen keine Änderungen der Maße auftreten; sie
müssen perfekt lesbar bleiben.
8. INTEROPERABILITÄTSPRÜFUNGEN
▼M1
Nr. Prüfung Beschreibung
8.1 Interoperabilitätsprüfungen zwischen Fahrzeugeinheiten und Fahrtenschreiberkarten
1 Gegenseitige Authentisierung Prüfen, dass die gegenseitige Authentisierung zwischen der Fahr­
zeugeinheit und der Fahrtenschreiberkarte normal abläuft
2 Lese-/Schreib-Prüfungen Ausführung eines typischen Tätigkeitsszenarios an der Fahrzeug­
einheit. Dabei sind in Abhängigkeit von der zu prüfenden Karte
Schreibvorgänge in so vielen EF wie bei der Karte möglich durch­
zufü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 entsprechen­
den 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 Bewegungssen­
sor. 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 ent­
sprechenden Aufzeichnungen korrekt zu lesen sind.
8.3 Interoperabilitätsprüfungen zwischen Fahrzeugeinheiten und externen GNSS-Ausrüstungen (soweit vorhan­
den)
1 Gegenseitige Authentisierung Prüfen, dass die gegenseitige Authentisierung zwischen der Fahr­
zeugeinheit 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 ent­
sprechenden Aufzeichnungen korrekt zu lesen sind.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 419
9. OSNMA-PRÜFUNGEN
9.1. Einleitung
In diesem Kapitel werden die Prüfungen beschrieben, mit denen die kor­
rekte Implementierung von OSNMA im GNSS-Empfänger nachzuweisen
ist. Da die Authentisierung der Satellitensignale ausschließlich vom
GNSS-Empfänger und unabhängig von anderen Komponenten des Fahr­
tenschreibers durchgeführt wird, können die in diesem Kapitel beschrie­
benen Prüfungen am GNSS-Empfänger als eigenständiges Element durch­
geführt werden. In diesem Fall legt der Hersteller des Fahrtenschreibers
den Typgenehmigungsbehörden einen Bericht mit Einzelheiten zur Ent­
wicklung und zu den Ergebnissen der Prüfungen vor, die unter der Ver­
antwortung des Herstellers des GNSS-Empfängers durchgeführt wurden.
9.2 Anwendbare Bedingungen
— Die in den OSNMA-Prüfungen festgelegten Kriterien für „bestanden“/
„nicht bestanden“ werden nur für die festgestellten Prüfbedingungen
als gültig betrachtet.
— Die Kriterien könnten zum Zeitpunkt der Erklärung des Galileo
OSNMA-Dienstes und unter Berücksichtigung der damit verbundenen
Leistungsverpflichtungen des Dienstes geändert werden.
9.3. Begriffsbestimmungen und Akronyme
9.3.1 Begriffsbestimmungen
GNSS-Kalt-/Warm-/
Heißstart:
Bezieht sich auf die Startbedingung eines
GNSS-Empfängers auf der Grundlage der
Verfügbarkeit von Zeit (T), aktuellen
Almanach- (A) und Ephemeriden-Daten (E),
Position (P):
— GNSS-Kaltstart: keine
— GNSS-Warmstart: T, A, P
— GNSS-Heißstart: T, A, E, P
OSNMA-Kalt-/Warm-/
Heißstart:
Bezieht sich auf die Startbedingung der
OSNMA-Funktion auf der Grundlage der
Verfügbarkeit des öffentlichen Schlüssels (P)
und der DSM-KROOT (K)-Informationen
(gemäß der Begriffsbestimmung in den Leit­
linien für OSNMA-Empfänger, auf die in An­
lage 12 verwiesen wird):
— OSNMA-Kaltstart: keine
— OSNMA-Warmstart: P
— OSNMA-Heißstart: P, K
9.3.2 Akronyme
ADKD Authentication Data & Key Delay (Authentisierungsdaten
und Schlüsselverzögerung)
DSM-KROOT Digital Signature Message KROOT (Digitalsignaturnach­
richt KROOT)
GSM Global Navigation Satellite System (Globales Satelliten­
navigationssystem)
KROOT Root Key of the TESLA key chain (Wurzel-Schlüssel der
TESLA-Schlüsselkette)
MAC Message Authentication Code (Nachrichtenauthentisie­
rungscode)
NMACK Number of MAC & key blocks (Anzahl der MAC- und
Schlüsselblöcke) (je 30 Sekunden)
OSNMA Galileo Open Service Navigation Message Authentication
(Authentisierung von Navigationsnachrichten im Offenen
Dienst von Galileo)
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 420
SLMAC Slow MAC (langsamer MAC)
TESLA Timed Efficient Stream Loss-tolerant Authentication
(zeitgesteuerte effiziente stromverlusttolerante Authenti­
sierung) (in OSNMA verwendetes Protokoll)
9.4. Ausrüstung für die Erzeugung der GNSS-Signale
Die GNSS-Signale können unter Verwendung eines GNSS-Simulators mit
mehreren Konstellationen, der die Übertragung von OSNMA-Nachrichten
unterstützt, erzeugt werden. Alternativ kann eine Hochfrequenzsignal-Wie­
dergabevorrichtung verwendet werden, die in der Lage ist, GNSS-Signal­
proben aus Dateien wiederzugeben. Die typische Bit-Tiefe und Abtast­
frequenz sind 4 Bits I/Q und 10 MHz.
Es wird davon ausgegangen, dass der GNSS-Empfänger über Schnittstel­
len verfügt, über die Befehle zum Löschen des Empfängerspeichers gege­
ben werden können (unabhängiges Löschen des öffentlichen Schlüssels,
von KROOT, Uhrzeitinformationen, Positionsinformationen, Ephemeri­
den- und Almanach-Daten), um die Realisierung der lokalen Zeit des
Empfängers für die OSNMA-Zeitverifizierungsanforderung festzulegen
und die kryptografischen Informationen zu laden. Diese Befehle können
auf Prüfzwecke beschränkt sein und daher für den Nennbetrieb des Emp­
fängers möglicherweise nicht verfügbar sein.
9.5 Prüfbedingungen
9.5.1 GNSS-Bedingungen
Die simulierten oder wiedergegebenen GNSS-Signale weisen folgende
Merkmale auf:
— Szenario eines statischen Nutzerempfängers
— Mindestens GPS- und Galileo-Konstellationen
— E1/L1-Frequenz
— Mindestens 4 Galileo-Satelliten mit einem Höhenwinkel von mehr als 5°
— Dauer wie für jede Prüfung erforderlich
— Konstante Navigationsephemeriden von den Satelliten während der
Prüfung
9.5.2 OSNMA-Bedingungen
Die im HF-Signal übermittelte OSNMA-9.4Merkmale auf:
— Eine HKROOT-Nachricht, deren OSNMA-Status auf Betrieb oder Prü­
fung eingestellt ist, und eine feste DSM-KROOT von 8 Blöcken für
die geltende Kette
— Mindestens 4 Galileo-Satelliten, die OSNMA übertragen
— Eine MACK-Nachricht mit einem MACK-Block (d. h. NMACK = 1)
und mindestens einem ADKD = 0 und einem ADKD = 12 pro Satellit
und MACK-Block
— Eine Tag-Größe von 40 Bit
— Die Tag-Mindestlänge, wie sie in den Leitlinien für OSNMA-Emp­
fänger vorgeschrieben ist (derzeit 80 Bit).
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 421
Sofern nichts anderes angegeben, muss die interne Empfängerzeitrealisie­
rung mit ausreichender Genauigkeit bekannt sein und ordnungsgemäß an
die simulierte Zeit angeglichen sein. Dadurch wird gewährleistet, dass die
Anforderung der Synchronisierung der OSNMA-Anfangszeit für jede Prüf­
bedingung erfüllt ist, d. h. eine nominale Synchronisierung für alle Prü­
fungen außer der SLMAC-Prüfung. Weitere Einzelheiten zur Zeitinitiali­
sierung sind in den Leitlinien für OSNMA-Empfänger zu finden.
Hinweis: Die genannten Kriterien für „bestanden“/„nicht bestanden“ sind
konservativ und repräsentieren nicht die erwartete Leistung von Galileo
OSNMA.
9.6. Prüfspezifikation
Nr. Prüfung Beschreibung
Anforderungsentspre­
chung
1. Administrative Prüfung
1.1 Dokumentation Richtigkeit der Dokumentation
2 Allgemeine Prüfungen
2.1 OSNMA-Heißstart Ziel: Nachweis, dass der GNSS-Empfänger nach einem
Heißstart eine Position mit OSNMA berechnet.
Prüfungsdurchführung:
Der GNSS-Empfänger startet unter GNSS- und
OSNMA-Heißstartbedingungen und empfängt die Sig­
nale sichtbarer Galileo-Satelliten.
Der Empfänger authentisiert die Galileo-Navigations­
daten mit OSNMA (ADKD = 0) und stellt eine Posi­
tion mit authentisierten Daten bereit.
Kriterien für „bestanden“/„nicht bestanden“: Der Emp­
fänger berechnet innerhalb von 160 Sekunden eine au­
thentisierte Positionsbestimmung.
Anlage 12,
GNS_3b
2.2 OSNMA-Warmstart Ziel: Nachweis, dass der GNSS-Empfänger nach einem
Warmstart eine Position mit OSNMA berechnet.
Prüfungsdurchführung:
Vor Beginn der Prüfung werden die Ephemeriden- und
KROOT-Informationen aus dem Speicher des
GNSS-Empfängers gelöscht, um einen GNSS- und
OSNMA-Warmstart zu erzwingen.
Der GNSS-Empfänger startet und empfängt die Signale
der sichtbaren Galileo-Satelliten.
Die DSM-KROOT wird empfangen und verifiziert.
Der Empfänger authentisiert die Galileo-Navigations­
daten mit OSNMA (ADKD = 0) und stellt eine Posi­
tion mit authentisierten Daten bereit.
Kriterien für „bestanden“/„nicht bestanden“: Der Emp­
fänger berechnet innerhalb von 430 Sekunden eine au­
thentisierte gültige Positionsbestimmung.
Anlage 12,
GNS_3b
2.3 OSNMA-Warmstart
mit SLMAC
Ziel: Nachweis, dass der GNSS-Empfänger nach einem
Warmstart eine Position mit OSNMA mit einer Zeitini­
tialisierung berechnet, die den SLMAC-Modus erfordert
(gemäß den Leitlinien für OSNMA-Empfänger).
Prüfungsdurchführung:
Die interne Empfängerzeitrealisierung wird so konfigu­
riert, dass eine Anfangszeitunsicherheit zwischen 2
und 2,5 Sekunden besteht, sodass gemäß den Leitlinien
für OSNMA-Empfänger der Modus „Slow MAC“ ak­
tiviert wird.
Anlage 12,
GNS_3b
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 422
Nr. Prüfung Beschreibung
Anforderungsentspre­
chung
Vor Beginn der Prüfungen werden die Ephemeriden-
und KROOT-Informationen aus dem Speicher des
GNSS-Empfängers gelöscht, um einen GNSS- und
OSNMA-Warmstart zu erzwingen.
Der GNSS-Empfänger startet und empfängt die Signale
der sichtbaren Galileo-Satelliten.
Die DSM-KROOT wird empfangen und verifiziert.
Der Empfänger authentisiert die Galileo-Navigations­
daten nur mit OSNMA Slow MAC (ADKD = 12)
und stellt eine Position mit authentisierten Daten bereit.
Kriterien für „bestanden“/„nicht bestanden“: Der Emp­
fänger berechnet innerhalb von 730 Sekunden eine au­
thentisierte gültige Positionsbestimmung.
2.4 OSNMA-Heißstart mit
wiedergegebenem Sig­
nal
Ziel: Nachweis, dass der GNSS-Empfänger ein wieder­
gegebenes Signal erkennt
Prüfungsdurchführung:
Der GNSS-Empfänger startet unter GNSS- und
OSNMA-Heißstartbedingungen und empfängt die Sig­
nale sichtbarer Galileo-Satelliten.
Der Empfänger authentisiert die Galileo-Navigations­
daten mit OSNMA (ADKD = 0) und stellt eine Posi­
tion mit authentisierten Daten bereit.
Sobald der Empfänger eine PVT-Lösung mit authenti­
sierten Daten bereitstellt, wird er ausgeschaltet.
Ein wiedergegebenes Signal mit einer Verzögerung von
40 Sekunden bezogen auf das vorherige Signal wird
simuliert, und der Empfänger wird eingeschaltet.
Der Empfänger erkennt, dass die Galileo-Systemzeit aus
der Signal-im Raum-Zeit (SIS-Zeit) und die lokale Zeit­
realisierung die Synchronisierungsanforderung nicht er­
füllen und stoppt die Verarbeitung von OSNMA-Daten
gemäß den Leitlinien für OSNMA-Empfänger.
Kriterien für „bestanden“/„nicht bestanden“: Der Emp­
fänger erkennt die Wiedergabe und berechnet ab dem
Start der Wiedergabe bis zum Ende der Prüfung keine
authentisierte gültige Position.
Anlage 12,
GNS_3b
2.5 OSNMA-Heißstart mit
falschen Daten
Ziel: Nachweis, dass OSNMA falsche Daten erkennt.
Prüfungsdurchführung:
Der GNSS-Empfänger startet unter GNSS- und
OSNMA-Heißstartbedingungen.
Der GNSS-Empfänger muss in der Lage sein, das Sig­
nal aller sichtbaren Galileo-Satelliten zu empfangen und
die Echtheit ihrer Navigationsnachrichten mittels
OSNMA zu verifizieren.
Mindestens ein Bit der von jedem Galileo-Satelliten
bereitgestellten Ephemeriden-Daten stimmt nicht mit
den authentisierten Originaldaten überein, aber die
Galileo-I/NAV-Nachricht muss konsistent sein, ein­
schließlich CRC.
Kriterien für „bestanden“/„nicht bestanden“: Der Emp­
fänger erkennt die falschen Daten innerhalb von 160 Se­
kunden und berechnet bis zum Ende der Prüfung keine
authentisierte gültige Position.
Anlage 12,
GNS_3b
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 423
Anlage 10
SICHERHEITSANFORDERUNGEN
In dieser Anlage werden die Anforderungen an die IT-Sicherheit für die Kom­
ponenten von intelligenten Fahrtenschreibersystemen (Fahrtenschreiber der zwei­
ten Generation) festgelegt.
SEC_001 Für folgende Komponenten des intelligenten Fahrtenschreibersystems
erfolgt eine Sicherheitszertifizierung gemäß dem Common-Criteria-
Zertifizierungsverfahren:
— Fahrzeugeinheit,
— Fahrtenschreiberkarte,
— Bewegungssensor,
— externe GNSS-Ausrüstung.
SEC_002 Die von jeder Komponente, für die eine Sicherheitszertifizierung zu
erfolgen hat, zu erfüllenden Mindestanforderungen an die IT-Sicher­
heit werden in einem Schutzprofil gemäß dem Common-Criteria-Zer­
tifizierungsverfahren festgelegt.
SEC_003 Die Europäische Kommission stellt sicher, dass vier mit diesem An­
hang konforme Schutzprofile gefördert, entwickelt, von den für die
IT-Sicherheitszertifizierung zuständigen staatlichen Stellen, die in der
Joint Interpretation Working Group zusammenarbeiten (die die gegen­
seitige Anerkennung von Zertifikaten im Rahmen des europäischen
Abkommens zur gegenseitigen Anerkennung von IT-Sicherheitszerti­
fikaten (Agreement on Mutual Recognition of Information Technology
Security Evaluation Certificates, SOGIS-MRA) unterstützt), genehmigt
und registriert werden:
— Schutzprofil für die Fahrzeugeinheit,
— Schutzprofil für die Fahrtenschreiberkarte,
— Schutzprofil für den Bewegungssensor,
— Schutzprofil für die externe GNSS-Ausrüstung.
Das Schutzprofil für die Fahrzeugeinheit gilt für die Fälle, in denen die VU zur
Verwendung mit oder ohne eine externe GNSS-Ausrüstung bestimmt ist. Im
ersten Fall sind die Sicherheitsanforderungen der externen GNSS-Ausrüstung
im spezifischen Schutzprofil festgelegt.
SEC_004 Zur Formulierung der Sicherheitsanforderungen, die bei Beantragung
der Sicherheitszertifizierung für die Komponente erfüllt werden müs­
sen, konkretisieren und vervollständigen die Komponentenhersteller
erforderlichenfalls das geeignete Schutzprofil, ohne die bestehenden
Sicherheitsgefährdungen, Ziele, Verfahrensmöglichkeiten und SEF-
Spezifikationen zu ändern bzw. zu streichen.
SEC_005 Während des Bewertungsverfahrens muss die strikte Konformität die­
ser spezifischen Sicherheitsanforderungen mit dem entsprechenden
Schutzprofil festgestellt werden.
SEC_006 Die für jedes Schutzprofil vorgegebene Vertrauenswürdigkeitsstufe ist
EAL4, erweitert um die Vertrauenswürdigkeitskomponenten
ATE_DPT.2 und AVA_VAN.5.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 424
Anlage 11
GEMEINSAME SICHERHEITSMECHANISMEN
INHALTSVERZEICHNIS
VORWORT
TEIL A FAHRTENSCHREIBERSYSTEM DER 1. GENERATION
1. EINLEITUNG
1.1. Referenzdokumente
1.2. Notationen und Abkürzungen
2. KRYPTOGRAFISCHE SYSTEME UND ALGORITHMEN
2.1. Kryptografische Systeme
2.2. Kryptografische Algorithmen
2.2.1 RSA-Algorithmus
2.2.2 Hash-Algorithmus
2.2.3 Datenverschlüsselungsalgorithmus
3. SCHLÜSSEL UND ZERTIFIKATE
3.1. Erzeugung und Verteilung der Schlüssel
3.1.1 Erzeugung und Verteilung der RSA-Schlüssel
3.1.2 RSA-Prüfschlüssel
3.1.3 Bewegungssensorschlüssel
3.1.4 Erzeugung und Verteilung von T-DES-Sitzungsschlüsseln
3.2. Schlüssel
3.3. Zertifikate
3.3.1 Inhalt der Zertifikate
3.3.2 Ausgestellte Zertifikate
3.3.3 Verifizieren und Entpacken der Zertifikate
4. GEGENSEITIGE AUTHENTISIERUNG
5. VERTRAULICHKEITS-, INTEGRITÄTS- UND AUTHENTISIE­
RUNGSMECHANISMEN FÜR DIE DATENÜBERTRAGUNG
VU-KARTE
5.1. Secure Messaging
5.2. Behandlung von Secure-Messaging-Fehlern
5.3. Algorithmus zur Berechnung der kryptografischen Prüfsummen
5.4. Algorithmus zur Berechnung von Kryptogrammen für Vertraulich­
keits-DOs
6. DIGITALE SIGNATURMECHANISMEN BEIM HERUNTER­
LADEN VON DATEN
6.1. Erzeugung der Signatur
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 425
6.2. Verifizierung der Signatur
TEIL B FAHRTENSCHREIBERSYSTEM DER 2. GENERATION
7. EINLEITUNG
7.1. Referenzdokumente
7.2. Notationen und Abkürzungen
7.3. Begriffsbestimmungen
8. KRYPTOGRAFISCHE SYSTEME UND ALGORITHMEN
8.1. Kryptografische Systeme
8.2. Kryptografische Algorithmen
8.2.1 Symmetrische Algorithmen
8.2.2 Asymmetrische Algorithmen und standardisierte Domänenpara­
meter
8.2.3 Hash-Algorithmen
8.2.4 Cipher Suites
9. SCHLÜSSEL UND ZERTIFIKATE
9.1. Asymmetrische Schlüsselpaare und Public-Key-Zertifikate
9.1.1 Allgemein
9.1.2 Europäische Ebene
9.1.3 Mitgliedstaatebene
9.1.4 Geräteebene: Fahrzeugeinheiten
9.1.5 Geräteebene: Fahrtenschreiberkarten
9.1.6 Geräteebene: Externe GNSS-Ausrüstung
9.1.7 Überblick Ersatz von Zertifikaten
9.2. Symmetrische Schlüssel
9.2.1 Schlüssel für die Sicherung der Kommunikation VU-Bewegungs­
sensor
9.2.2 Schlüssel zur Sicherung der DSRC-Kommunikation
9.3. Zertifikate
9.3.1 Allgemein
9.3.2 Zertifikatsinhalt
9.3.3 Beantragen von Zertifikaten
10. GEGENSEITIGE AUTHENTISIERUNG VU-KARTE UND SE­
CURE MESSAGING
10.1. Allgemein
10.2. Gegenseitige Verifizierung der Zertifikatkette
10.2.1 Verifizierung der Kartenzertifikatkette durch die VU
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 426
10.2.2 Verifizierung der VU-Zertifikatkette durch die Karte
10.3. VU-Authentisierung
10.4. Chip-Authentisierung und Vereinbarung des Sitzungsschlüssels
10.5. Secure Messaging
10.5.1 Allgemein
10.5.2 Secure-Message-Struktur
10.5.3 Abbruch einer Secure-Messaging-Sitzung
11. VU UND EXTERNE GNSS-AUSRÜSTUNG: KOPPELUNG, GE­
GENSEITIGE AUTHENTISIERUNG UND SECURE MESSA­
GING
11.1. Allgemein
11.2. Koppelung von VU und externer GNSS-Ausrüstung
11.3. Gegenseitige Verifizierung der Zertifikatkette
11.3.1 Allgemein
11.3.2 Während der Koppelung VU-EGF
11.3.3 Im Normalbetrieb
11.4. VU-Authentisierung, Chip-Authentisierung und Vereinbarung des
Sitzungsschlüssels
11.5. Secure Messaging
12. KOPPELUNG UND KOMMUNIKATION VU-BEWEGUNGS­
SENSOR
12.1. Allgemein
12.2. Koppelung VU-Bewegungssensor unter Verwendung verschiedener
Schlüsselgenerationen
12.3. Koppelung und Kommunikation VU-Bewegungssensor mit AES
12.4. Koppelung VU-Bewegungssensor bei verschiedenen Gerätegenera­
tionen
13. SICHERHEIT FÜR FERNKOMMUNIKATION PER DSRC
13.1. Allgemein
13.2. Verschlüsselung der Fahrtenschreibernutzdaten und MAC-Generie­
rung
13.3. Verifizierung und Entschlüsselung der Fahrtenschreibernutzdaten
14. SIGNIEREN VON DATENDOWNLOADS UND VERIFIZIEREN
DER SIGNATUREN
14.1. Allgemein
14.2. Erzeugung der Signatur
14.3. Verifizierung der Signatur
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 427
VORWORT
Diese Anlage enthält die Spezifizierung der Sicherheitsmechanismen zur Gewähr­
leistung
— der gegenseitigen Authentisierung zwischen unterschiedlichen Komponenten
im Fahrtenschreibersystem.
— Vertraulichkeit, Integrität, Authentizität und/oder Nichtabstreitbarkeit der zwi­
schen den unterschiedlichen Komponenten des Fahrtenschreibersystems über­
tragenen oder auf externe Speichermedien heruntergeladenen Daten.
Diese Anlage besteht aus zwei Teilen. In Teil A werden die Sicherheitsmecha­
nismen für das Fahrtenschreibersystem der 1. Generation (digitaler Fahrtenschrei­
ber) definiert. In Teil B werden die Sicherheitsmechanismen für das Fahrten­
schreibersystem der 2. Generation (intelligenter Fahrtenschreiber) definiert.
Die in Teil A dieser Anlage angegebenen Mechanismen kommen zur Anwen­
dung, wenn mindestens eine der am Prozess der gegenseitigen Authentisierung
und/oder Datenübertragung beteiligten Komponenten des Fahrtenschreibersys­
tems der 1. Generation angehört.
Die in Teil B dieser Anlage angegebenen Mechanismen kommen zur Anwen­
dung, wenn beide am Prozess der gegenseitigen Authentisierung und/oder Daten­
übertragung beteiligten Komponenten des Fahrtenschreibersystems der 2. Gene­
ration angehören.
In Anlage 15 sind weitere Informationen über die Verwendung von Komponen­
ten der 1. Generation zusammen mit Komponenten der 2. Generation aufgeführt.
TEIL A
FAHRTENSCHREIBERSYSTEM DER 1. GENERATION
1. EINLEITUNG
1.1. Referenzdokumente
In dieser Anlage werden folgende Referenzdokumente herangezogen:
SHA-1 National Institute of Standards and Technology
(NIST). FIPS Publication 180-1: Secure Hash Stan­
dard. April 1995.
PKCS1 RSA Laboratories. PKCS # 1: RSA Encryption Stan­
dard. Version 2.0. Oktober 1998.
TDES National Institute of Standards and Technology
(NIST). FIPS Publication 46-3: Data Encryption
Standard. Draft 1999.
TDES-OP ANSI X9.52, Triple Data Encryption Algorithm Mo­
des of Operation. 1998.
ISO/IEC 7816-4 Information Technology — Identification cards — In­
tegrated circuit(s) cards with contacts — Part 4: Inte­
rindustry commands for interexchange (Informations­
technik — Identifikationskarten, mit integrierten
Schaltkreisen und Kontakten — Teil 4: Interindu­
strielle Kommandos). Erste Ausgabe: 1995 + Ände­
rung 1: 1997.
ISO/IEC 7816-6 Information Technology — Identification cards — In­
tegrated circuit(s) cards with contacts — Part 6: Inte­
rindustry data elements (Identifikationskarten — Chip­
karten — Teil 6: Datenelemente für den interindu­
striellen Informationsaustausch.) Erste Ausgabe: 1996
+ Berichtigung 1: 1998.
ISO/IEC 7816-8 Information Technology — Identification cards — In­
tegrated circuit(s) cards with contacts — Part 8: Secu­
rity related interindustry commands (Informationstech­
nik — Identifikationskarten, mit integrierten Schalt­
kreisen und Kontakten — Teil 8: Interindustrielle si­
cherheitsbezogene Kommandos). Erste Ausgabe 1999.
ISO/IEC 9796-2 Information Technology — Security techniques —
Digital signature schemes giving message recovery
— Part 2: Mechanisms using a hash function (Infor­
mationstechnik — IT-Sicherheitsverfahren — Digitale
Signaturschemata welche die Nachricht wieder herstel­
len — Teil 2: Mechanismen die eine dedizierte Hash
Funktion verwenden). Erste Ausgabe: 1997.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 428
ISO/IEC 9798-3 Information Technology — Security techniques —
Entity authentication mechanisms — Part 3: Entity
authentication using a public key algorithm (Informa­
tionstechnik — Sicherheitsverfahren — Mechanismen
zur Authentifikation von Instanzen — Teil 3: Authen­
tifikation von Instanzen unter Nutzung eines Algorith­
mus mit öffentlichem Schlüssel). Zweite Ausgabe
1998.
ISO 16844-3 Road vehicles — Tachograph systems — Part 3: Mo­
tion sensor interface (Straßenfahrzeuge — Fahrten­
schreibersysteme — Teil 3: Bewegungssensor-Schnitt­
stelle).
1.2. Notationen und Abkürzungen
In dieser Anlage werden folgende Notationen und Abkürzungen
verwendet:
(K a , K b , K c ) ein Schlüsselbund zur Verwendung durch den Triple
Data Encryption Algorithm
CA Certification Authority (Zertifizierungsstelle)
CAR Certification Authority Reference (Referenz der Zerti­
fizierungsstelle)
CC Cryptographic Checksum (kryptografische Prüfsumme)
CG Cryptogram (Kryptogramm)
CH Command Header (Befehlskopf)
CHA Certificate Holder Authorisation (Autorisierung des
Zertifikatsinhabers)
CHR Certificate Holder Reference (Referenz des Zertifikats­
inhabers)
D() Entschlüsselung mit DES
DE Datenelement
DO Datenobjekt
d privater RSA-Schlüssel, privater Exponent
e öffentlicher RSA-Schlüssel, öffentlicher Exponent
E() Verschlüsselung mit DES
EQT Equipment (Gerät)
Hash() Hash-Wert, ein Ergebnis von Hash
Hash Hash-Funktion
KID Key Identifier (Schlüsselbezeichner)
Km T-DES-Schlüssel Hauptschlüssel gemäß ISO 16844-3
Km VU in Fahrzeugeinheiten integrierter T-DES-Schlüssel
Km WC in Werkstattkarten integrierter T-DES-Schlüssel
m Nachrichtenrepräsentant, eine ganze Zahl zwischen 0
und n-1
n RSA-Schlüssel, Modulus
PB Padding Bytes (Füllbytes)
PI Padding Indicator-Byte (Verwendung im Krypto­
gramm für Vertraulichkeits-DO)
PV Plain Value (Klarwert)
s Signaturrepräsentant, eine ganze Zahl zwischen 0 und n-1
SSC Send Sequence Counter (Sendesequenzzähler)
SM Secure Messaging
TCBC TDEA-Modus Cipher Block Chaining
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 429
TDEA Triple Data Encryption Algorithm (Triple-Datenver­
schlüsselungsalgorithmus)
TLV Tag Length Value (Taglängenwert)
VU Fahrzeugeinheit (Vehicle Unit)
X.C Zertifikat von Benutzer X, ausgestellt durch eine Zer­
tifizierungsstelle
X.CA Zertifizierungsstelle von Benutzer X
X.CA.PK o X.C Vorgang des Entpackens eines Zertifikats zur Heraus­
lösung eines öffentlichen Schlüssels; es handelt sich
um einen Infix-Operator, dessen linker Operand der
öffentliche Schlüssel einer Zertifizierungsstelle und
dessen rechter Operand das von der Zertifizierungs­
stelle ausgestellte Zertifikat ist; das Ergebnis ist der
öffentliche Schlüssel von Benutzer X, dessen Zertifi­
kat der rechte Operand ist
X.PK öffentlicher RSA-Schlüssel eines Benutzers X
X.PK[I] RSA-Chiffrierung einer Information I unter Verwen­
dung des öffentlichen Schlüssels von Benutzer X
X.SK privater RSA-Schlüssel eines Benutzers X
X.SK[I] RSA-Chiffrierung einer Information I unter Verwen­
dung des privaten Schlüssels von Benutzer X
„xx“ ein Hexadezimalwert
|| Verkettungsoperator
2. KRYPTOGRAFISCHE SYSTEME UND ALGORITHMEN
2.1. Kryptografische Systeme
CSM_001 Fahrzeugeinheiten und Fahrtenschreiberkarten verwenden ein
klassisches RSA-Public-Key-Verschlüsselungssystem, sodass
folgende Sicherheitsmechanismen vorliegen:
— Authentisierung zwischen Fahrzeugeinheiten und Karten,
— Übertragung von Triple-DES-Sitzungsschlüsseln zwischen
Fahrzeugeinheiten und Fahrtenschreiberkarten,
— digitale Signatur von Daten, die von Fahrzeugeinheiten
oder Fahrtenschreiberkarten an externe Medien herunter­
geladen werden.
CSM_002 Fahrzeugeinheiten und Fahrtenschreiberkarten verwenden ein
symmetrisches Triple-DES-Verschlüsselungssystem, sodass
ein Mechanismus für die Datenintegrität während des Benut­
zerdatenaustauschs zwischen Fahrzeugeinheiten und Fahrten­
schreiberkarten und gegebenenfalls die Vertraulichkeit beim
Datenaustausch zwischen Fahrzeugeinheiten und Fahrten­
schreiberkarten gewährleistet sind.
2.2. Kryptografische Algorithmen
2.2.1 RSA-Algorithmus
CSM_003 Der RSA-Algorithmus wird durch folgende Beziehungen voll­
ständig definiert:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 430
X.SK[m] = s = m d mod n
X.PK[s] = m = s e mod n
Eine ausführlichere Beschreibung der RSA-Funktion findet
sich im Referenzdokument PKCS1. Der im RSA-Algorithmus
verwendete öffentliche Exponent e ist eine Ganzzahl zwi­
schen 3 und n-1, wobei gilt: gcd(e, lcm(p-1, q-1))=1.
2.2.2 Hash-Algorithmus
CSM_004 Die Mechanismen für die digitale Signatur verwenden den
Hash-Algorithmus SHA-1 gemäß Definition im Referenzdo­
kument SHA-1.
2.2.3 Datenverschlüsselungsalgorithmus
CSM_005 DES-gestützte Algorithmen werden im Modus Cipher Block
Chaining verwendet.
3. SCHLÜSSEL UND ZERTIFIKATE
3.1. Erzeugung und Verteilung der Schlüssel
3.1.1 Erzeugung und Verteilung der RSA-Schlüssel
CSM_006 Die Erzeugung der RSA-Schlüssel erfolgt auf drei hierar­
chischen Funktionsebenen:
— auf europäischer Ebene,
— auf Mitgliedstaatebene,
— auf Geräteebene.
CSM_007 Auf europäischer Ebene wird ein einziges Schlüsselpaar
(EUR.SK und EUR.PK) erzeugt. Der europäische private
Schlüssel wird zur Zertifizierung der öffentlichen Schlüssel
der Mitgliedstaaten verwendet. Über alle zertifizierten Schlüs­
sel sind Belege aufzubewahren. Diese Aufgaben werden von
einer Europäischen Zertifizierungsstelle wahrgenommen, die
der Europäischen Kommission untersteht.
CSM_008 Auf Mitgliedstaatebene wird ein Mitgliedstaatschlüsselpaar
(MS.SK und MS.PK) erzeugt. Öffentliche Mitgliedstaat­
schlüssel werden von der Europäischen Zertifizierungsstelle
zertifiziert. Der private Mitgliedstaatschlüssel wird für die
Zertifizierung von öffentlichen Schlüsseln verwendet, die in
Geräten (Fahrzeugeinheit oder Fahrtenschreiberkarte) einge­
fügt sind. Über alle zertifizierten öffentlichen Schlüssel sind
Belege zusammen mit der Kennung des Geräts, für das sie
bestimmt sind, aufzubewahren. Diese Aufgaben werden von
der Zertifizierungsstelle des jeweiligen Mitgliedstaates wahr­
genommen. Ein Mitgliedstaat darf sein Schlüsselpaar in regel­
mäßigen Abständen ändern.
CSM_009 Auf Geräteebene wird ein einziges Schlüsselpaar (EQT.SK
und EQT.PK) erzeugt und in jedes Gerät eingefügt. Die öf­
fentlichen Geräteschlüssel werden von der Zertifizierungs­
stelle des jeweiligen Mitgliedstaates zertifiziert. Diese Auf­
gaben können von Geräteherstellern, Geräteintegratoren und
Behörden der Mitgliedstaaten wahrgenommen werden. Dieses
Schlüsselpaar wird zur Authentisierung, für die digitale Sig­
natur sowie zur Chiffrierung verwendet.
CSM_010 Bei der Erzeugung, ggf. bei der Übertragung sowie bei der
Speicherung ist die Vertraulichkeit der privaten Schlüssel zu
wahren.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 431
Im folgenden Schaubild ist der Datenfluss dieses Prozesses
zusammengefasst:
3.1.2 RSA-Prüfschlüssel
CSM_011 Zum Zwecke der Geräteprüfung (einschließlich Interoperabi­
litätsprüfungen) erzeugt die Europäische Zertifizierungsstelle
ein anderes einziges europäisches Prüfschlüsselpaar und min­
destens zwei Mitgliedstaat-Prüfschlüsselpaare, deren öffent­
liche Schlüssel mit dem europäischen privaten Prüfschlüssel
zertifiziert werden. Von den Herstellern werden in Geräte, die
der Typgenehmigungsprüfung unterzogen werden, Prüfschlüs­
sel eingefügt, die durch einen dieser Mitgliedstaatprüfschlüs­
sel zertifiziert sind.
3.1.3 Bewegungssensorschlüssel
Die Geheimhaltung der drei genannten T-DES-Schlüssel ist während der
Erzeugung, der Übermittlung und ggf. der Aufbewahrung in geeigneter
Weise zu gewährleisten.
Um die Unterstützung von Fahrtenschreiberkomponenten, die der ISO
16844 entsprechen, zu gewährleisten, stellen die Europäische Zertifizie­
rungsstelle und die Zertifizierungsstellen der Mitgliedstaaten darüber hi­
naus Folgendes sicher:
CSM_036 Die Europäische Zertifizierungsstelle erzeugt KmVU und
KmWC als zwei voneinander unabhängige und einmalige
Triple-DES-Schlüssel sowie Km, wobei gilt: Km = Km VU
XOR Km WC . Die Europäische Zertifizierungsstelle übermittelt
diese Schlüssel unter geeigneten Sicherheitsvorkehrungen auf
deren Anforderung an die Zertifizierungsstellen der Mitglied­
staaten.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 432
CSM_037 Die Zertifizierungsstellen der Mitgliedstaaten:
— verschlüsseln mit Km die von den Herstellern der Bewe­
gungssensoren angeforderten Bewegungssensordaten (die
mit Km zu verschlüsselnden Daten sind in ISO 16844-3
festgelegt),
— übermitteln Km VU zum Einbau in die Fahrzeugeinheiten
unter geeigneten Sicherheitsvorkehrungen an deren Her­
steller,
— stellen sicher, dass Km WC bei der Personalisierung
der Karten in alle Werkstattkarten eingefügt
wird ( in
der Elementardatei).
3.1.4 Erzeugung und Verteilung von T-DES-Sitzungsschlüsseln
CSM_012 Im Rahmen des Prozesses der gegenseitigen Authentisierung
erzeugen Fahrzeugeinheiten und Fahrtenschreiberkarten die
erforderlichen Daten zur Erstellung eines gemeinsamen
Triple-DES-Sitzungsschlüssels und tauschen diese Daten
aus. Die Vertraulichkeit dieses Datenaustauschs wird durch
einen RSA-Verschlüsselungsmechanismus geschützt.
CSM_013 Dieser Schlüssel wird für alle nachfolgenden kryptografischen
Operationen unter Anwendung des Secure Messaging benutzt.
Seine Gültigkeit erlischt am Ende der Sitzung (Entnahme oder
Zurücksetzen der Karte) und/oder nach 240 Benutzungen
(eine Benutzung des Schlüssels = ein mittels Secure Messa­
ging an die Karte gesandter Befehl und die dazugehörige
Antwort).
3.2. Schlüssel
CSM_014 RSA-Schlüssel haben (ungeachtet der Ebene) folgende Länge:
Modulus n 1 024 Bit, öffentlicher Exponent e max. 64 Bit,
privater Exponent d 1 024 Bit.
CSM_015 Triple-DES-Schlüssel haben die Form (K a , K b , K a ), wobei K a
und K b unabhängige Schlüssel mit einer Länge von 64 Bit
sind. Es wird kein Paritätsfehler-Erkennungsbit gesetzt.
3.3. Zertifikate
CSM_016 Bei den RSA-Public-Key-Zertifikaten muss es sich um Zerti­
fikate entsprechend der Definition „non self descriptive“ und
„card verifiable“ des Referenzdokuments ISO/IEC 7816-8
handeln.
3.3.1 Inhalt der Zertifikate
CSM_017 RSA-Public-Key-Zertifikate sind aus den folgenden Daten in
folgender Reihenfolge aufgebaut:
Daten Format Bytes Bemerkung
CPI INTEGER 1 Certificate Profile Identifier
(Zertifikatsprofil „01“ in
dieser Version)
CAR OCTET
STRING
8 Certification Authority Re­
ference (Referenz der Zer­
tifizierungsstelle)
CHA OCTET
STRING
7 Certificate Holder Authori­
sation (Autorisierung des
Zertifikatsinhabers)
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 433
Daten Format Bytes Bemerkung
EOV TimeReal 4 Ablauf der Gültigkeit des
Zertifikats, bei Nichtver­
wendung mit „FF“ gefüllt
CHR OCTET
STRING
8 Certificate Holder Refe­
rence (Referenz des Zertifi­
katsinhabers)
n OCTET
STRING
128 Öffentlicher Schlüssel
(Modulus)
e OCTET
STRING
8 Öffentlicher Schlüssel (öf­
fentlicher Exponent)
164
Hinweise:
1. Mit dem Certificate Profile Identifier (Zertifikatsprofilbezeichner, CPI)
wird die genaue Struktur eines Authentisierungszertifikats abgegrenzt.
Er kann als interner Gerätebezeichner einer relevanten Kopfliste ver­
wendet werden, die die Verkettung der Datenelemente innerhalb des
Zertifikats beschreibt.
Die Kopfliste für diesen Zertifikatinhalt lautet wie folgt:
„4D“ „16“ „5F
29“
„01“ „42“ „08“ „5F
4B“
„07“ „5F
24“
„04“ „5F
20“
„08“ „7F
49“
„05“ „81“ „81
80“
„82“ „08“
Ta
g
fü
r
er
w
ei
te
rt
e
K
op
fl
is
te

L
än
ge
d
er
K
op
fl
is
te

C
P
I-
T
ag

C
P
I-
L
än
ge

C
A
R
-T
ag

C
A
R
-L
än
ge

C
H
A
-T
ag

C
H
A
-L
än
ge

E
O
V
-T
ag

E
O
V
-L
än
ge

C
H
R
-T
ag

C
H
R
-L
än
ge

Ta
g
fü
r
öf
fe
nt
li
ch
en
S
ch
lü
ss
el
(
ko
ns
tr
ui
er
t)

L
än
ge
d
er
f
ol
ge
nd
en
D
O

M
od
ul
us
-T
ag

M
od
ul
us
-L
än
ge

Ta
g
fü
r
öf
fe
nt
li
ch
en
E
xp
on
en
te
n
L
än
ge
d
es
ö
ff
en
tl
ic
he
n
E
xp
on
en
te
n
2. „Certification Authority Reference“ (Referenz der Zertifizierungs­
stelle, CAR) identifiziert die das Zertifikat ausstellende Zertifizie­
rungsstelle, sodass das Datenelement gleichzeitig als Authority Key
Identifier (Schlüsselbezeichner der Stelle) zur Angabe des öffentlichen
Schlüssels der Zertifizierungsstelle verwendet werden kann (Kodie­
rung siehe „Key Identifier“).
3. Mit „Certificate Holder Authorisation“ (Autorisierung des Zertifikats­
inhabers, CHA) wird die Berechtigung des Zertifikatsinhabers aus­
gewiesen. Sie besteht aus der Kontrollgerätanwendungs-ID sowie
aus der Art des Geräts, für das das Zertifikat bestimmt ist (entspre­
chend dem Datenelement , „00“ für einen Mit­
gliedstaat).
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 434
4. „Certificate Holder Reference“ (Referenz des Zertifikatsinhabers,
CHR) dient der eindeutigen Identifizierung des Zertifikatsinhabers,
sodass das Datenelement gleichzeitig als „Subject Key Identifier“
(Schlüsselbezeichner des Subjekts) zur Angabe des öffentlichen
Schlüssels des Zertifikatsinhabers verwendet werden kann.
5. „KEY IDENTIFIERS“ (SCHLÜSSELBEZEICHNER, KID) DIENEN
DER EINDEUTIGEN IDENTIFIZIERUNG DES ZERTIFIKATS­
INHABERS ODER DER ZERTIFIZIERUNGSSTELLEN. SIE
SIND WIE FOLGT KODIERT:
5.1 Gerät (VU oder Karte):
Daten Serien­
nummer
Gerät
Datum Art Hersteller
Länge 4 Bytes 2 Bytes 1 Byte 1 Byte
Wert Ganze
Zahl
MM JJ BCD-Kod. Herstellerspezi­
fisch
Herstellercode
Dem Hersteller einer VU ist die Kennung des Geräts, in das die
Schlüssel eingefügt werden, bei der Beantragung von Zertifikaten
unter Umständen nicht bekannt.
Ist dem Hersteller die Gerätekennung bekannt, sendet er sie mit
dem öffentlichen Schlüssel zwecks Zertifizierung an die Zertifi­
zierungsstelle seines Mitgliedstaats. Das Zertifikat enthält dann
die Gerätekennung, und der Hersteller muss sicherstellen, dass
Schlüssel und Zertifikat in das vorgesehene Gerät eingefügt wer­
den. Der Key Identifier weist die oben genannte Form auf.
Ist dem Hersteller die Gerätekennung nicht bekannt, muss er
jeden Antrag auf ein Zertifikat eindeutig kennzeichnen und diese
Kennung zusammen mit dem öffentlichen Schlüssel zwecks Zer­
tifizierung an die Zertifizierungsstelle seines Mitgliedstaates sen­
den. Das Zertifikat enthält dann die Antragskennung. Nach dem
Einfügen der Schlüssel in das Gerät muss der Hersteller der Zer­
tifizierungsstelle die Zuordnung des Schlüssels zum Gerät mit­
teilen (d. h. Kennung des Zertifikatsantrags, Gerätekennung).
Der Key Identifier (KID) hat folgende Form:
Daten Serien­
nummer
Zertifi­
katsantrag
Datum Art Hersteller
Länge 4 Bytes 2 Bytes 1 Byte 1 Byte
Wert Ganze
Zahl
MM JJ BCD-Kod. „FF“ Herstellercode
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 435
5.2 Zertifizierungsstelle:
Daten Kennung Seriennr.
Schlüssel
Zusatzinfo Kennung
Länge 4 Bytes 1 Byte 2 Bytes 1 Byte
Wert 1 Byte numeri­
scher Landescode
3 Bytes alpha­
numerischer Lan­
descode
Ganze Zahl Zusatzkodie­
rung
(CA-spezi­
fisch)
„FF FF“ bei
Nichtverwen­
dung
„01“
Mit der Seriennummer Schlüssel werden die verschiedenen
Schlüssel eines Mitgliedstaates unterschieden, sofern der Schlüs­
sel verändert wird.
6. Den Zertifikatsprüfern ist implizit bekannt, dass es sich bei dem zer­
tifizierten Schlüssel um einen für die Authentisierung, für die Verifi­
zierung der digitalen Signatur und für die vertrauliche Chiffrierung
relevanten RSA-Schlüssel handelt (das Zertifikat enthält keine Objekt­
kennung zur entsprechenden Spezifizierung).
3.3.2 Ausgestellte Zertifikate
CSM_018 Das ausgestellte Zertifikat ist eine digitale Signatur mit teil­
weiser Wiederherstellung des Zertifikatsinhalts gemäß ISO/
IEC 9796-2 (ausgenommen Anhang A4) mit angefügter „Cer­
tification Authority Reference“.
X.C = X.CA.SK[„6A“ || C r || Hash (Cc) || „BC“] || C n || X.CAR
wobei Zertifikats­
inhalt = Cc =
C r || C n
106 Bytes 58 Bytes
Hinweise:
1. Dieses Zertifikat ist 194 Bytes lang.
2. Die von der Signatur verdeckte CAR wird ebenfalls an die Signatur
angefügt, sodass der öffentliche Schlüssel der Zertifizierungsstelle zur
Verifizierung des Zertifikats gewählt werden kann.
3. Dem Zertifikatsprüfer ist der von der Zertifizierungsstelle für die Un­
terzeichnung des Zertifikats verwendete Algorithmus implizit bekannt.
4. Die zu dem ausgestellten Zertifikat gehörende Kopfliste lautet wie
folgt:
„7F 21“ „09“ „5F 37“ „81 80“ „5F 38“ „3A“ „42“ „08“
Ta
g
fü
r
C
V
-Z
er
ti
fi
ka
t
(k
on
st
ru
ie
rt
)
L
än
ge
d
er
f
ol
ge
nd
en
D
O

S
ig
na
tu
r-
T
ag

S
ig
na
tu
r-
L
än
ge

R
es
t-
T
ag

R
es
tl
än
ge

C
A
R
-T
ag

C
A
R
-L
än
ge

▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 436
3.3.3 Verifizieren und Entpacken der Zertifikate
Das Verifizieren und Entpacken der Zertifikate besteht in der Verifizie­
rung der Signatur entsprechend ISO/IEC 9796-2, wodurch der Zertifikats­
inhalt und der enthaltene öffentliche Schlüssel aufgerufen werden: X.PK
= X.CA.PK o X.C, sowie in der Verifizierung der Gültigkeit des Zerti­
fikats.
CSM_019 Dazu gehören folgende Schritte:
Verifizierung der Signatur und Abrufen des Inhalts:
— von X.C Abruf von Sign, C n ' und
CAR':
X.C = Sign || C n ' || CAR'
128 Bytes 58 Bytes 8 Bytes
— von CAR' Auswahl des entsprechenden öffentlichen
Schlüssels der Zertifizierungsstelle (wenn nicht bereits zu­
vor durch andere Mittel erfolgt),
— Öffnen von Sign mit öffentlichem CA-Schlüssel: Sr'=
X.CA.PK [Sign],
— Prüfung Sr' startet mit „6A“ und endet mit „BC“
— Berechnung von C r ' und H' aus: Sr' = „6A“ || C r ' || H' || „BC“
106 Bytes 20 Bytes
— Wiederherstellung des Zertifikatsinhalts C' = C r ' || C n ',
— Prüfung Hash (C') = H'
Sind die Prüfungen positiv, ist das Zertifikat echt und sein
Inhalt ist C'.
Verifizierung der Gültigkeit. Von C':
— Prüfung des Ablaufdatums der Gültigkeit, wenn
zutreffend,
Abruf und Speicherung des öffentlichen Schlüssels, des Key
Identifier, der Certificate Holder Authorisation und des Ab­
laufs der Gültigkeit des Zertifikats von C':
— X.PK = n || e
— X.KID = CHR
— X.CHA = CHA
— X.EOV = EOV
4. GEGENSEITIGE AUTHENTISIERUNG
Die gegenseitige Authentisierung zwischen Karten und VU beruht auf
dem folgenden Prinzip:
Jede Seite weist der Gegenseite nach, dass sie sich im Besitz eines
gültigen Schlüsselpaares befindet, dessen öffentlicher Schlüssel von der
Zertifizierungsstelle des jeweiligen Mitgliedstaates zertifiziert worden ist,
die wiederum von der europäischen Zertifizierungsstelle zertifiziert
wurde.
Der Nachweis wird geführt, indem mit dem privaten Schlüssel eine von
der Gegenseite gesandte Zufallszahl signiert wird; die Gegenseite muss
bei der Verifizierung dieser Signatur die Zufallszahl wiederherstellen
können.
Der Mechanismus wird von der VU beim Einstecken der Karte ausgelöst.
Er beginnt mit dem Austausch der Zertifikate und dem Entpacken der
öffentlichen Schlüssel und endet mit der Erzeugung eines Sitzungsschlüs­
sels.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 437
CSM_020 Folgendes Protokoll findet Verwendung (Pfeile weisen auf
Befehle und ausgetauschte Daten hin, siehe Anlage 2):
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 438
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 439
5. VERTRAULICHKEITS-, INTEGRITÄTS- UND AUTHENTISIE­
RUNGSMECHANISMEN FÜR DIE DATENÜBERTRAGUNG
VU-KARTE
5.1. Secure Messaging
CSM_021 Die Integrität der Datenübertragung zwischen VU und Karte
wird durch Secure Messaging entsprechend den Referenzdo­
kumenten ISO/IEC 7816-4 und ISO/IEC 7816-8 geschützt.
CSM_022 Müssen Daten während der Übertragung geschützt werden,
wird den innerhalb des Befehls oder der Antwort gesandten
Datenobjekten ein Datenobjekt „Cryptographic Checksum“
angefügt. Diese kryptografische Prüfsumme wird vom Emp­
fänger verifiziert.
CSM_023 Die kryptografische Prüfsumme der innerhalb eines Befehls
gesandten Daten integriert den Befehlskopf sowie alle gesand­
ten Datenobjekte (=>CLA = „0C“, und alle Datenobjekte sind
mit Tags zu kapseln, bei denen b1=1).
CSM_024 Die Statusinformationsbytes der Antwort sind durch eine
kryptografische Prüfsumme zu schützen, wenn die Antwort
kein Datenfeld enthält.
CSM_025 Kryptografische Prüfsummen sind 4 Bytes lang.
Somit weisen Befehle und Antworten bei Anwendung von
Secure Messaging folgende Struktur auf:
Die DO werden als Teilmenge der in ISO/IEC 7816-4 be­
schriebenen Secure-Messaging-DO verwendet:
Tag Symbolform Bedeutung
„81“ T PV Klarwert, nicht in BER-TLV kodiert (durch CC zu
schützen)
„97“ T LE Wert von Le im ungesicherten Befehl (durch CC zu
schützen)
„99“ T SW Status-Info (durch CC zu schützen)
„8E“ T CC Kryptografische Prüfsumme (CC)
„87“ T PI CG Padding Indicator Byte || Cryptogram (Klarwert,
nicht in BER-TLV kodiert)
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 440
Ausgehend von einem ungesicherten Befehl-Antwort-Paar:
Befehlskopf Befehlskörper
CLA INS P1 P2 [L c -Feld] [Datenfeld] [L e -Feld]
vier Bytes L Bytes, bezeichnet als B 1 bis B L
Antwortkörper Antwortendmarke
[Datenfeld] SW1 SW2
L r Datenbytes zwei Bytes
lautet das entsprechende gesicherte Befehl-Antwort-Paar:
Gesicherter Befehl:
Befehlskopf (CH) Befehlskörper
CLA INS P1 P2 [Neues L c -Feld] [Neues Datenfeld] [Neues
L e -Feld]
„OC“ Länge des neuen
Datenfelds
T PV L PV PV T LE L LE L e T CC L CC CC „00“
„81“ L c Datenfeld „97“ „01“ L e „8E“ „04“ CC
In die Prüfsumme zu integrierende Daten = CH || PB || T PV ||
L PV || PV || T LE || L LE || L e || PB
PB = Padding Bytes (80 .. 00) gemäß ISO-IEC 7816-4 und
ISO 9797, Methode 2.
Die PV und LE der DO sind nur vorhanden, wenn entspre­
chende Daten im ungesicherten Befehl vorliegen.
Gesicherte Antwort:
1. Wenn das Antwortdatenfeld nicht leer ist und nicht ver­
traulichkeitsgeschützt werden muss:
Antwortkörper Antwortendmarke
[Neues Datenfeld] SW1 SW2 neu
T PV L PV PV T CC L CC CC
„81“ L r Datenfeld „8E“ „04“ CC
In die Prüfsumme zu integrierende Daten = T PV || L PV ||
PV || PB
2. Wenn das Antwortdatenfeld nicht leer ist und vertraulich­
keitsgeschützt werden muss:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 441
Antwortkörper Antwortendmarke
[Neues Datenfeld] SW1 SW2 neu
T PI CG L PI
CG
PI CG T CC L CC CC
„87“ PI || CG „8E“ „04“ CC
Daten in CG: nicht-BER-TLV-kodierte Daten und Füll­
bytes.
In die Prüfsumme zu integrierende Daten = T PI CG || L PI
CG || PI CG || PB
3. Wenn das Antwortdatenfeld leer ist:
Antwortkörper Antwortendmarke
[Neues Datenfeld] SW1 SW2 neu
T SW L SW SW T CC L CC CC
„99“ „02“ SW1 SW2 neu „8E“ „04“ CC
In die Prüfsumme zu integrierende Daten = T SW || L SW ||
SW || PB
5.2. Behandlung von Secure-Messaging-Fehlern
CSM_026 Erkennt die Fahrtenschreiberkarte beim Interpretieren eines
Befehls einen SM-Fehler, müssen die Statusbytes ohne SM
zurückgesandt werden. Laut ISO/IEC 7816-4 sind folgende
Statusbytes zur Anzeige von SM-Fehlern definiert:
„66 88“: Verifizierung der kryptografischen Prüfsumme
fehlgeschlagen,
„69 87“: erwartete SM-Datenobjekte fehlen,
„69 88“: SM-Datenobjekte inkorrekt.
CSM_027 Sendet die Fahrtenschreiberkarte Statusbytes ohne SM-DO
oder mit einem fehlerhaften SM-DO zurück, muss die VU
den Vorgang abbrechen.
5.3. Algorithmus zur Berechnung der kryptografischen Prüfsummen
CSM_028 Kryptografische Prüfsummen werden unter Verwendung eines
üblichen MAC gemäß ANSI X9.19 mit DES aufgebaut:
— Ausgangsstufe: Der Ausgangsprüfblock y0 ist E(Ka,
SSC).
— Folgestufe: Unter Verwendung von Ka werden die Prüf­
blöcke y1, …, yn berechnet.
— Endstufe: Die kryptografische Prüfsumme wird aus dem
letzten Prüfblock yn wie folgt berechnet: E(Ka, D(Kb,
yn)).
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 442
E() bedeutet Verschlüsselung mit DES, und D() bedeutet Ent­
schlüsselung mit DES.
Die vier höchstwertigen Bytes der kryptografischen Prüf­
summe werden übertragen.
CSM_029 Während der Schlüsselvereinbarung wird der „Send Sequence
Counter“ (Sendesequenzzähler, SSC) wie folgt initialisiert:
Anfangs-SSC: Rnd3 (4 niedrigstwertige Bytes) || Rnd1 (4
niedrigstwertige Bytes).
CSM_030 Vor jeder Berechnung eines MAC wird der SSC um 1 erhöht
(d. h. der SSC für den ersten Befehl ist Anfangs-SSC + 1, der
SSC für die erste Antwort Anfangs-SSC + 2).
Die folgende Abbildung zeigt die Berechnung des MAC:
5.4. Algorithmus zur Berechnung von Kryptogrammen für Vertraulich­
keits-DOs
CSM_031 Kryptogramme werden mit TDEA im Modus TCBC entspre­
chend den Referenzdokumenten TDES und TDES-OP sowie
mit dem Nullvektor als Initial Value-Block berechnet.
Die folgende Abbildung zeigt die Anwendung von Schlüsseln
in T-DES:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 443
6. DIGITALE SIGNATURMECHANISMEN BEIM HERUNTERLADEN
VON DATEN
CSM_032 Das Intelligent Dedicated Equipment (IDE) speichert die von
einem Gerät (VU oder Karte) während eines Übertragungs­
vorgangs empfangenen Daten in einer Datei ab. Diese Datei
muss die Zertifikate MS i .C und EQT.C enthalten. Die Datei
enthält digitale Signaturen von Datenblöcken gemäß Anlage
7, Protokolle zum Herunterladen der Daten.
CSM_033 Für die digitalen Signaturen heruntergeladener Daten wird ein
digitales Signatursystem mit Anhang verwendet, sodass die
heruntergeladenen Daten auf Wunsch ohne Dechiffrierung
lesbar sind.
6.1. Erzeugung der Signatur
CSM_034 Die Erzeugung der Datensignatur durch das Gerät folgt dem
in Referenzdokument PKCS1 definierten digitalen Signatur­
system mit Anhang und der Hash-Funktion SHA-1:
Signatur = EQT.SK[„00“ || „01“ || PS || „00“ || DER(SHA-
1(Data))]
PS = Füllstring von Oktetten mit Wert „FF“, sodass die
Länge 128 beträgt.
DER(SHA-1(M)) ist die Kodierung der Algorithmus-ID für
die Hash-Funktion und den Hash-Wert in einen ASN.1-
Wert des Typs DigestInfo (Kodierungsregeln):
„30“||„21“||„30“||„09“||„06“||„05“||„2B“||„0E“||„03“||„02“||„1A“||
„05“||„00“||„04“||„14“||Hash-Wert.
6.2. Verifizierung der Signatur
CSM_035 Die Verifizierung der Datensignatur bei heruntergeladenen
Daten folgt dem in Referenzdokument PKCS1 definierten
digitalen Signatursystem mit Anhang und der Hash-Funktion
SHA-1.
Der europäische öffentliche Schlüssel EUR.PK muss dem
Prüfer von unabhängiger Seite her (für ihn verlässlich) be­
kannt sein.
Die folgende Tabelle veranschaulicht das Protokoll, das von
einem IDE mit Kontrollkarte zur Verifizierung der Integrität
von heruntergeladenen und in ESM (externen Speicherme­
dien) gespeicherten Daten herangezogen werden kann. Die
Kontrollkarte wird zur Dechiffrierung digitaler Signaturen
verwendet. Diese Funktion kann in diesem Fall nicht im
IDE implementiert sein.
Das Gerät, das die zu analysierenden Daten heruntergeladen
und signiert hat, ist mit EQT bezeichnet.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 444
TEIL B
FAHRTENSCHREIBERSYSTEM DER 2. GENERATION
7. EINLEITUNG
7.1. Referenzdokumente
Referenzdokumente zu dieser Anlage:
AES National Institute of Standards and Technology (NIST),
FIPS PUB 197: Advanced Encryption Standard (AES),
26. November 2001
DSS National Institute of Standards and Technology (NIST),
FIPS PUB 186-4: Digital Signature Standard (DSS), Juli
2013
ISO 7816-4 ISO/IEC 7816-4, Identification cards — Integrated circuit
cards — Part 4: Organization, security and commands for
interchange (Identifikationskarten — Chipkarten — Teil 4
— Regeln, Sicherheitsfunktionen und Befehle für den
Datenaustausch). Dritte Ausgabe 2013-04-15
ISO 7816-8 ISO/IEC 7816-8, Identification cards — Integrated circuit
cards — Part 8: Commands for security operations (Iden­
tifikationskarten — Chipkarten — Teil 8 — Kommandos
für Sicherheitsoperationen). Zweite Ausgabe, 2004-06-01.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 445
ISO 8825-1 ISO/IEC 8825-1, Information technology — ASN.1 en­
coding rules: Specification of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguis­
hed Encoding Rules (DER) (Informationstechnik — Co­
dierungsregeln für ASN.1: Spezifikation der Basis-Codie­
rungsregeln (BER), der Kanonischen Codierungsregeln
(CER) und der Besonderen Codierungsregeln (DER)).
Vierte Ausgabe, 2008-12-15.
ISO 9797-1 ISO/IEC 9797-1, Information technology — Security tech­
niques — Message Authentication Codes (MACs) — Part
1: Mechanismen using a block cipher (Informationstechnik
— Sicherheitsverfahren — Message Authentication Codes
(MACs) — Teil 1 — Mechanismen, die eine Blockchiffre
verwenden). Zweite Ausgabe, 2011-03-01.
ISO 10116 ISO/IEC 10116, Information technology — Security tech­
niques — Modes of operation of an n-bit block cipher
(Informationstechnik — Sicherheitsverfahren — Betriebs­
arten für n-bit Blockchiffre). Dritte Ausgabe, 2006-02-01.
ISO 16844-3 ISO/IEC 16844-3, Road vehicles — Tachograph systems
— Part 3: Motion sensor interface (Straßenfahrzeuge —
Fahrtenschreibersysteme — Teil 3:
Bewegungssensor-Schnittstelle). Erste Ausgabe 2004, ein­
schließlich Technical Corrigendum 1 2006.
RFC 5480 Elliptic Curve Cryptography Subject Public Key Informa­
tion, März 2009
RFC 5639 Elliptic Curve Cryptography (ECC) — Brainpool Stan­
dard Curves and Curve Generation, 2010
RFC 5869 HMAC-based Extract-and-Expand Key Derivation
Function (HKDF), Mai 2010
SHS National Institute of Standards and Technology (NIST),
FIPS PUB 180-4: Secure Hash Standard, März 2012
SP 800-38B National Institute of Standards and Technology (NIST),
Special Publication 800-38B: Recommendation for Block
Cipher Modes of Operation: The CMAC Mode for Au­
thentication, 2005
TR-03111 BSI Technical Guideline TR-03111, Elliptic Curve Cryp­
tography, Version 2.00, 28.6.2012
7.2. Notationen und Abkürzungen
In dieser Anlage werden folgende Notationen und Abkürzungen
verwendet:
AES Advanced Encryption Standard
CA Certification Authority (Zertifizierungsstelle)
CAR Certification Authority Reference (Referenz der Zertifizie­
rungsstelle)
CBC Cipher Block Chaining (Betriebsmodus)
CH Command Header (Befehlskopf)
CHA Certificate Holder Authorisation (Autorisierung des Zerti­
fikatsinhabers)
CHR Certificate Holder Reference (Referenz des Zertifikatsinha­
bers)
CV Constant Vector (Konstanter Vektor)
DER Distinguished Encoding Rules (Besondere Codierungs­
regeln)
DO Datenobjekt
DSRC Dedicated Short Range Communication (Dedizierte Nah­
bereichskommunikation)
ECC Elliptic Curve Cryptography (Elliptische-Kurven-Krypto­
grafie)
ECDSA Elliptic Curve Digital Signature Algorithm (auf elliptischen
Kurven basierender Algorithmus für digitale Signaturen)
ECDH Elliptic Curve Diffie-Hellman (Diffie-Hellman-Schlüssel­
austausch)
EGF External GNSS Facility (Externe GNSS-Ausrüstung)
EQT Equipment (Gerät)
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 446
IDE Intelligent Dedicated Equipment
K M Bewegungssensor-Hauptschlüssel, ermöglicht die Koppe­
lung einer Fahrzeugeinheit mit einem Bewegungssensor
K M-VU In Fahrzeugeinheiten eingesetzter Schlüssel, der es einer
VU gestattet, den Bewegungssensor-Hauptschlüssel ab­
zuleiten, wenn eine Werkstattkarte in die VU eingesetzt ist
K M-VC In Werkstattkarten eingesetzter Schlüssel, der es einer VU
gestattet, den Bewegungssensor-Hauptschlüssel abzuleiten,
wenn eine Werkstattkarte in die VU eingesetzt ist
MAC Message Authentication Code
MoS Bewegungssensor
MSB Most Significant Bit (höchstwertige Bitposition)
PKI Public Key Infrastructure (Public-Key-Infrastruktur)
RCF Remote Communication Facility (Ausrüstung zur Fern­
kommunikation)
SSC Send Sequence Counter (Sendesequenzzähler)
SM Secure Messaging
TDES Triple Data Encryption Standard (Triple-Datenverschlüs­
selungsstandard)
TLV Tag Length Value (Taglängenwert)
VU Fahrzeugeinheit (Vehicle Unit, VU)
X.C Zertifikat des öffentlichen Schlüssels von Benutzer X
X.CA Zertifizierungsstelle, die das Zertifikat von Benutzer X
ausgestellt hat
X.CA die im Zertifikat von Benutzer X erwähnte Referenz der
Zertifizierungsstelle
X.CA die im Zertifikat von Benutzer X erwähnte Referenz des
Zertifikatsinhabers
X.PK öffentlicher Schlüssel von Benutzer X
X.SK privater Schlüssel von Benutzer X
X.PK eph flüchtiger öffentlicher Schlüssel von Benutzer X
X.SK eph flüchtiger privater Schlüssel von Benutzer X
„xx“ ein Hexadezimalwert
|| Verkettungsoperator
7.3. Begriffsbestimmungen
Die in dieser Anlage verwendeten Begriffsbestimmungen sind in Anhang
1C Abschnitt I aufgeführt.
8. KRYPTOGRAFISCHE SYSTEME UND ALGORITHMEN
8.1. Kryptografische Systeme
CSM_38 Fahrzeugeinheiten und Fahrtenschreiberkarten verwenden
ein auf elliptischen Kurven basierendes Public-Key-Ver­
schlüsselungssystem, sodass folgende Sicherheitsmechanis­
men vorliegen:
— gegenseitige Authentisierung zwischen Fahrzeugeinheit
und Karte,
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 447
— Vereinbarung von AES-Sitzungsschlüsseln zwischen
Fahrzeugeinheit und Karte,
— Gewährleistung der Authentizität, Integrität und Nicht­
abstreitbarkeit der von Fahrzeugeinheiten oder Fahrten­
schreiberkarten an externe Medien heruntergeladenen
Daten.
CSM_39 Fahrzeugeinheiten und externe GNSS-Ausrüstung verwen­
den ein auf elliptischen Kurven basierendes Public-Key-
Verschlüsselungssystem, sodass folgende Sicherheits­
mechanismen vorliegen:
— Koppelung von Fahrzeugeinheit und externer GNSS-
Ausrüstung,
— gegenseitige Authentisierung zwischen Fahrzeugeinheit
und externer GNSS-Ausrüstung,
— Vereinbarung eines AES-Sitzungsschlüssels zwischen
Fahrzeugeinheit und externer GNSS-Ausrüstung.
CSM_40 Fahrzeugeinheiten und Fahrtenschreiberkarten verwenden
ein AES-basiertes symmetrisches Verschlüsselungssystem,
sodass folgende Sicherheitsmechanismen vorliegen:
— Gewährleistung von Authentizität und Integrität der
zwischen Fahrzeugeinheit und Fahrtenschreiberkarte
ausgetauschten Daten,
— gegebenenfalls Gewährleistung der Vertraulichkeit der
zwischen Fahrzeugeinheit und Fahrtenschreiberkarte
ausgetauschten Daten.
CSM_41 Fahrzeugeinheiten und externe GNSS-Ausrüstung verwen­
den ein AES-basiertes symmetrisches Verschlüsselungssys­
tem, sodass folgende Sicherheitsmechanismen vorliegen:
— Gewährleistung von Authentizität und Integrität der
zwischen Fahrzeugeinheit und externer GNSS-Ausrüs­
tung ausgetauschten Daten,
CSM_42 Fahrzeugeinheiten und Bewegungssensoren verwenden ein
AES-basiertes symmetrisches Verschlüsselungssystem, so­
dass folgende Sicherheitsmechanismen vorliegen:
— Koppelung von Fahrzeugeinheit und Bewegungssensor,
— gegenseitige Authentisierung zwischen Fahrzeugeinheit
und Bewegungssensor,
— Gewährleistung der Vertraulichkeit der zwischen Fahr­
zeugeinheit und Bewegungssensor ausgetauschten Da­
ten.
CSM_43 Fahrzeugeinheiten und Kontrollkarten verwenden ein
AES-basiertes symmetrisches Verschlüsselungssystem, so­
dass an der Schnittstelle für die Fernkommunikation fol­
gende Sicherheitsmechanismen vorliegen:
— Gewährleistung von Vertraulichkeit, Authentizität und
Integrität der von der Fahrzeugeinheit an die Kontroll­
karte übermittelten Daten.
Hinweise:
— Genau genommen werden die Daten von einer Fahrzeug­
einheit unter Aufsicht eines Kontrolleurs mithilfe einer
VU-internen oder -externen Ausrüstung zur Fernkom­
munikation an die Fernabfrageeinrichtung übermittelt
(siehe Anlage 14). Allerdings sendet die Fernabfrageein­
richtung die erhaltenen Daten zwecks Entschlüsselung
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 448
und Validierung der Authentizität an eine Kontrollkarte.
Im Hinblick auf die Sicherheit sind die Ausrüstung zur
Fernkommunikation und die Fernabfrageeinrichtung
vollständig transparent.
— Eine Werkstattkarte bietet die gleichen Sicherheits­
mechanismen für die DSRC-Schnittstelle wie eine
Kontrollkarte. Dadurch kann eine Werkstatt überprü­
fen, ob die Schnittstelle für die Fernkommunikation
einer VU ordnungsgemäß funktioniert und sicher ist.
Weitere Informationen siehe Abschnitt 9.2.2.
8.2. Kryptografische Algorithmen
8.2.1 Symmetrische Algorithmen
CSM_44 Fahrzeugeinheiten, Fahrtenschreiberkarten, Bewegungssen­
soren und externe GNSS-Ausrüstung unterstützen den in
Referenzdokument AES definierten AES-Algorithmus, mit
Schlüssellängen von 128, 192 und 256 Bits.
8.2.2 Asymmetrische Algorithmen und standardisierte Domänenparameter
CSM_45 Fahrzeugeinheiten, Fahrtenschreiberkarten und externe
GNSS-Ausrüstung unterstützen Elliptische-Kurven-Krypto­
grafie mit einer Schlüsselgröße von 256, 384 und 512/521
Bits.
CSM_46 Fahrzeugeinheiten, Fahrtenschreiberkarten und externe
GNSS-Ausrüstung unterstützen den ECDSA Signaturalgo­
rithmus gemäß Referenzdokument DSS.
CSM_47 Fahrzeugeinheiten, Fahrtenschreiberkarten und externe
GNSS-Ausrüstung unterstützen den ECKA-EG-Algorith­
mus zur Schlüsselvereinbarung gemäß Referenzdokument
TR 03111.
CSM_48 Fahrzeugeinheiten, Fahrtenschreiberkarten und externe
GNSS-Ausrüstung unterstützen sämtliche standardisierte
Domänenparameter gemäß Tabelle 1 unten für Elliptische-
Kurven-Kryptografie.
Tabelle 1
Standardisierte Domänenparameter
Name Größe (Bits) Referenzdokument Objektkennung
NIST P-256 256 [DSS], [RFC 5480]
BrainpoolP256r1 256 [RFC 5639]
NIST P-384 384 [DSS], [RFC 5480]
BrainpoolP384r1 384 [RFC 5639]
BrainpoolP512r1 512 [RFC 5639]
NIST P-521 521 [DSS], [RFC 5480]
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 449
Hinweis: Die in der letzten Spalte von Tabelle 1 genannten
Objektkennungen sind in Referenzdokument RFC 5639 für
Brainpool-Kurven und in Referenzdokument RFC 5480 für
NIST-Kurven angegeben.
8.2.3 Hash-Algorithmen
▼M1
CSM_49 Fahrzeugeinheiten, Fahrtenschreiberkarten und externe
GNSS-Ausrüstung unterstützen die Algorithmen SHA-256,
SHA-384 und SHA-512 gemäß Referenzdokument SHS.
▼B
8.2.4 Cipher Suites
CSM_50 Wenn ein symmetrischer Algorithmus, ein asymmetrischer
Algorithmus und/oder ein Hash-Algorithmus zusammen
ein Sicherheitsprotokoll bilden, haben ihre jeweiligen
Schlüssellängen und Hashgrößen (grob) die gleiche Stärke
aufzuweisen. Tabelle 2 zeigt die zulässigen Cipher Suites:
Tabelle 2
Zulässige Cipher Suites
Kennung der Cipher
Suite
ECC-Schlüsselgröße
(Bits)
AES-Schlüssellänge
(Bits)
Hash-Algorithmus MAC-Länge
(Bytes)
CS#1 256 128 SHA-256 8
CS#2 384 192 SHA-384 12
CS#3 512/521 256 SHA-512 16
Hinweis: ECC-Schlüsselgrößen von 512 Bits und 521 Bits
gelten im Sinne dieser Anlage als gleich stark.
9. SCHLÜSSEL UND ZERTIFIKATE
9.1. Asymmetrische Schlüsselpaare und Public-Key-Zertifikate
9.1.1 Allgemein
Hinweis: Die in diesem Abschnitt beschriebenen Schlüssel werden zur
gegenseitigen Authentisierung und zum Secure Messaging zwischen den
Fahrzeugeinheiten und den Fahrtenschreiberkarten sowie zwischen den
Fahrzeugeinheiten und externer GNSS-Ausrüstung verwendet. Diese
Vorgänge werden detailliert in den Kapiteln 10 und 11 dieser Anlage
beschrieben.
CSM_51 Beim europäischen intelligenten Fahrtenschreibersystem
werden die ECC-Schlüsselpaare und die entsprechenden
Zertifikate auf drei hierarchischen Funktionsebenen erzeugt
und verwaltet:
— auf europäischer Ebene,
— auf Mitgliedstaatebene,
— auf Geräteebene.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 450
CSM_52 Im gesamten europäischen intelligenten Fahrtenschreiber­
system werden öffentliche und private Schlüssel sowie
Zertifikate mithilfe genormter und sicherer Methoden er­
zeugt, verwaltet und kommuniziert.
9.1.2 Europäische Ebene
CSM_53 Auf europäischer Ebene wird ein einziges ECC-Schlüssel­
paar (EUR) erzeugt. Es besteht aus einem privaten
(EUR.SK) und einem öffentlichen Schlüssel (EUR.PK).
Dieses Schlüsselpaar bildet das Wurzel-Schlüsselpaar der
gesamten europäischen intelligenten Fahrtenschreiber-PKI.
Diese Aufgabe wird von einer Europäischen Wurzel-
Zertifizierungsstelle (ERCA) wahrgenommen, die der Eu­
ropäischen Kommission untersteht.
CSM_54 Die ERCA verwendet den europäischen privaten Schlüssel,
um ein (selbstsigniertes) Wurzelzertifikat des europäischen
öffentlichen Schlüssels zu signieren, und übermittelt dieses
europäische Wurzelzertifikat an alle Mitgliedstaaten.
CSM_55 Die ERCA verwendet den europäischen privaten Schlüssel,
um auf Anfrage die Zertifikate der öffentlichen Schlüssel
der Mitgliedstaaten zu signieren. Die ERCA führt ein Ver­
zeichnis aller signierten Public-Key-Zertifikate der Mit­
gliedstaaten.
CSM_56 Wie in Abbildung 1 (Abschnitt 9.1.7) dargestellt, erzeugt
die ERCA alle 17 Jahre ein neues europäisches Wurzel-
Schlüsselpaar. Immer, wenn die ERCA ein neues europäi­
sches Wurzel-Schlüsselpaar erzeugt, erstellt es ein neues
selbstsigniertes Wurzelzertifikat für den neuen europäi­
schen öffentlichen Schlüssel. Die Gültigkeitsdauer eines
europäischen Wurzelzertifikats beträgt 34 Jahre und 3 Mo­
nate.
Hinweis: Die Einführung eines neuen Wurzel-Schlüssel­
paares bedeutet auch, dass die ERCA einen neuen
Bewegungssensor-Hauptschlüssel und einen neuen
DSRC-Hauptschlüssel erzeugt, siehe Abschnitte 9.2.1.2
und 9.2.2.2.
CSM_57 Bevor ein neues europäisches Wurzel-Schlüsselpaar er­
zeugt wird, analysiert die ERCA die für das neue Schlüs­
selpaar erforderliche kryptografische Stärke, da dieses die
kommenden 34 Jahre Sicherheit bieten soll. Wenn nötig,
wechselt die ERCA zu einer Cipher Suite, die stärker als
die aktuelle ist, wie in CSM_50 festgelegt.
▼M1
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 signie­
ren. Die Gültigkeitsdauer des Linkzertifikats beträgt 17
Jahre und 3 Monate. Dies wird auch in Abbildung 1 (Ab­
schnitt 9.1.7) gezeigt.
▼B
Hinweis: Da ein Linkzertifikat den öffentlichen Schlüssel
der Generation X von ERCA enthält und mit dem privaten
Schlüssel der Generation X-1 von ERCA signiert ist, bietet
ein Linkzertifikat Ausrüstung, die im Laufe der Generation
X-1 herausgegeben wurde, eine Möglichkeit, im Laufe der
Generation X herausgegebener Ausrüstung zu vertrauen.
CSM_59 Die ERCA darf in keinem Fall den privaten Schlüssel
eines Wurzel-Schlüsselpaares verwenden, sobald die neuen
Wurzelzertifikate Gültigkeit erlangen.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 451
CSM_60 Die ERCA muss jederzeit über folgende kryptografische
Schlüssel und Zertifikate verfügen:
— das aktuelle EUR-Schlüsselpaar samt zugehörigem Zer­
tifikat
— sämtliche vorherigen EUR-Vorgängerzertifikate, die
zur Verifizierung noch gültiger MSCA-Zertifikate ver­
wendet werden sollen
— Linkzertifikate aller Generationen von EUR-Linkzerti­
fikaten mit Ausnahme des ersten
9.1.3 Mitgliedstaatebene
CSM_61 Auf Mitgliedstaatebene müssen alle Mitgliedstaaten, die
zur Signierung von Fahrtenschreiberkartenzertifikaten ver­
pflichtet sind, eines oder mehrere einzigartige ECC-Schlüs­
selpaare erzeugen, das mit MSCA_Card bezeichnet wird.
Alle Mitgliedstaaten, die zur Signierung von Zertifikaten
für Fahrzeugeinheiten oder externe GNSS-Ausrüstung ver­
pflichtet sind, müssen zusätzlich eines oder mehrere ein­
zigartige ECC-Schlüsselpaare erzeugen, das mit
MSCA_VU-EGF bezeichnet wird.
CSM_62 Die Aufgabe, Mitgliedstaat-Schlüsselpaare zu erzeugen,
wird durch eine Zertifizierungsstelle des jeweiligen Mit­
gliedstaates (Member State Certificate Authority, MSCA)
übernommen. Immer, wenn eine MSCA ein Mitgliedstaat-
Schlüsselpaar erzeugt, übermittelt sie den öffentlichen
Schlüssel an die ERCA, um ein entsprechendes durch
die ERCA signiertes Mitgliedstaatzertifikat zu erhalten.
CSM_63 Die MSCA wählt die Stärke eines Mitgliedstaat-Schlüssel­
paars so, dass sie derjenigen des europäischen
Wurzel-Schlüsselpaars entspricht, das zur Signierung des
zugehörigen Mitgliedstaatzertifikats verwendet wird.
CSM_64 Ein gegebenenfalls vorhandenes MSCA_VU-EGF-Schlüs­
selpaar besteht aus dem privaten Schlüssel MSCA_VU-
EGF.SK und dem öffentlichen Schlüssel MSCA_VU-
EGF.PK. Eine MSCA darf den privaten Schlüssel
MSCA_VU-EGF.SK ausschließlich dazu nutzen, die
Public-Key-Zertifikate von Fahrzeugeinheiten und externer
GNSS-Ausrüstung zu signieren.
CSM_65 Ein MSCA_Card-Schlüsselpaar besteht aus einem privaten
(MSCA_Card.SK) und einem öffentlichen Schlüssel
(MSCA_Card.PK). Eine MSCA darf den privaten Schlüs­
sel MSCA_Card.SK ausschließlich dazu nutzen, die
Public-Key-Zertifikate von Fahrtenschreiberkarten zu
signieren.
CSM_66 Eine MSCA muss Aufzeichnungen über alle signierten
VU-Zertifikate, externen GNSS-Ausrüstungs-Zertifikate
und Kartenzertifikate sowie die Kennung der Geräte, für
die jedes dieser Zertifikate bestimmt ist, aufbewahren.
CSM_67 Die Gültigkeitsdauer eines MSCA_VU-EGF-Zertifikats be­
trägt 17 Jahre und 3 Monate. Die Gültigkeitsdauer eines
MSCA_Card-Zertifikats beträgt 7 Jahre und 1 Monat.
CSM_68 Wie in Abbildung 1 (Abschnitt 9.1.7) dargestellt, beträgt
die Nutzungsdauer eines privaten Schlüssels eines
MSCA_VU-EGF-Schlüsselpaares und eines privaten
Schlüssels eines MSCA_Card-Schlüsselpaares zwei Jahre.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 452
CSM_69 Das MSCA darf in keinem Fall den privaten Schlüssel
eines MSCA_VU-EGF-Schlüsselpaares verwenden, sobald
die Nutzungsdauer abgelaufen ist. Ebenso wenig darf das
MSCA den privaten Schlüssel eines MSCA_Card-Schlüs­
selpaares verwenden, sobald die Nutzungsdauer abgelaufen
ist.
CSM_70 Das MSCA muss jederzeit über folgende kryptografische
Schlüssel und Zertifikate verfügen:
— das aktuelle MSCA_Card-Schlüsselpaar samt zugehöri­
gem Zertifikat
— sämtliche vorherigen MSCA_Card-Vorgängerzertifi­
kate, die zur Verifizierung noch gültiger Zertifikate
für Fahrtenschreiberkarten verwendet werden sollen
— das für die Verifizierung des aktuellen MSCA-Zertifi­
kats erforderliche aktuelle EUR-Zertifikat
— sämtliche vorherigen EUR-Vorgängerzertifikate, die
zur Verifizierung noch gültiger MSCA-Zertifikate er­
forderlich sind
CSM_71 Wenn eine MSCA Zertifikate für Fahrzeugeinheiten oder
externe GNSS-Ausrüstung signiert, muss sie zusätzlich
über folgende Schlüssel und Zertifikate verfügen:
— das aktuelle MSCA_VU-EGF-Schlüsselpaar samt zu­
gehörigem Zertifikat
— sämtliche vorherigen öffentlichen MSCA_VU-EGF-
Schlüssel, die zur Verifizierung noch gültiger Zertifi­
kate von VU oder externer GNSS-Ausrüstung verwen­
det werden sollen
9.1.4 Geräteebene: Fahrzeugeinheiten
▼M1
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 Fahr­
zeugeinheit genutzt werden.
▼B
CSM_73 Die Zertifikate VU_MA und VU_Sign jeder gegebenen
Fahrzeugeinheit müssen das gleiche Certificate Effective
Date aufweisen.
CSM_74 Der VU-Hersteller wählt die Stärke eines VU-Schlüssel­
paars so, dass sie derjenigen des MSCA-Schlüsselpaars
entspricht, das zur Signierung des zugehörigen VU-Zerti­
fikats verwendet wird.
CSM_75 Fahrzeugeinheiten dürfen ihr aus dem privaten Schlüssel
VU_MA.SK und dem öffentlichen Schlüssel VU_MA.PK
bestehendes VU_MA-Schlüsselpaar ausschließlich dazu
verwenden, die VU-Authentisierung gegenüber Fahrten­
schreiberkarten und externer GNSS-Ausrüstung durch­
zuführen, wie in den Abschnitten 10.3 und 11.4 dieser
Anlage beschrieben.
CSM_76 Fahrzeugeinheiten müssen in der Lage sein, flüchtige
ECC-Schlüsselpaare, zu erzeugen und dürfen ein flüchtiges
Schlüsselpaar ausschließlich dazu nutzen, eine Sitzungs­
schlüsselvereinbarung mit einer Fahrtenschreiberkarte
oder externer GNSS-Ausrüstung durchzuführen, wie in
den Abschnitten 10.4 und 11.4 dieser Anlage beschrieben.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 453
CSM_77 Fahrzeugeinheiten nutzen den privaten Schlüssel
VU_Sign.SK des VU_Sign-Schlüsselpaars ausschließlich
dazu, heruntergeladene Datendateien zu signieren, wie in
Kapitel 14 dieser Anlage beschrieben. Der zugehörige öf­
fentliche Schlüssel VU_Sign.PK darf nur dazu genutzt
werden, Signaturen, die durch die Fahrzeugeinheit erzeugt
wurden, zu verifizieren.
CSM_78 Wie in Abbildung 1 (Abschnitt 9.1.7) dargestellt, beträgt
die Gültigkeitsdauer eines VU_MA-Zertifikats 15 Jahre
und 3 Monate. Die Gültigkeitsdauer eines VU_Sign-Zerti­
fikats beträgt ebenfalls 15 Jahre und 3 Monate.
Hinweise:
— Die erweiterte Gültigkeitsdauer eines VU_Sign-Zertifi­
kats ermöglicht es einer Fahrzeugeinheit, während der
ersten drei Monate nach Ablauf gültige Signaturen für
heruntergeladene Daten zu erzeugen, wie in der
Verordnung (EU) Nr. 581/2010 vorgeschrieben.
— Die erweiterte Gültigkeitsdauer eines VU_MA-Zertifi­
kats ist erforderlich, um der VU die Authentisierung
gegenüber einer Kontroll- oder Unternehmenskarte
während der ersten drei Monate nach Ablauf zu ermög­
lichen, sodass es möglich ist, Daten herunterzuladen.
CSM_79 Nach Ablauf der Gültigkeitsdauer des entsprechenden Zer­
tifikats darf die Fahrzeugeinheit den privaten Schlüssel
eines VU-Schlüsselpaars keinesfalls verwenden.
CSM_80 Die VU-Schlüsselpaare (mit Ausnahme flüchtiger Schlüs­
selpaare) und zugehörigen Zertifikate einer gegebenen
Fahrzeugeinheit dürfen nicht bei der Praxisanwendung aus­
getauscht oder erneuert werden, sobald das Fahrzeug in
Betrieb genommen wurde.
Hinweise:
— Flüchtige Schlüsselpaare sind nicht Teil dieser Anfor­
derung, da eine VU jedes Mal, wenn eine Chip-Au­
thentisierung und eine Sitzungsschlüsselvereinbarung
durchgeführt werden, ein neues flüchtiges Schlüssel­
paar erzeugt (siehe Abschnitt 10.4). Die flüchtigen
Schlüsselpaare verfügen nicht über zugehörige Zertifi­
kate.
— Diese Anforderung verbietet nicht die Möglichkeit, im
Rahmen einer Modernisierung oder Reparatur in einer
sicheren, vom VU-Hersteller kontrollierten Umgebung
statische VU-Schlüsselpaare zu ersetzen.
CSM_81 Im Betrieb müssen die Fahrzeugeinheiten die folgenden
kryptografischen Schlüssel und Zertifikate enthalten:
— den privaten VU_MA-Schlüssel samt zugehörigem
Zertifikat
— den privaten VU_Sign-Schlüssel samt zugehörigem
Zertifikat
— das MSCA_VU-EGF-Zertifikat mit dem öffentlichen
MSCA_VU-EGF.PK-Schlüssel zur Verifizierung des
VU_MA-Zertifikats und des VU_Sign-Zertifikats
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 454
— das EUR-Zertifikat mit dem öffentlichen EUR.PK-
Schlüssel zur Verifizierung des MSCA_VU-EGF-Zer­
tifikats
— das EUR-Zertifikat, dessen Gültigkeitsdauer direkt der
Gültigkeitsdauer des zur Verifizierung des MSCA_VU-
EGF-Zertifikats zu verwendenden EUR-Zertifikats vo­
rausgeht, falls vorhanden
— das Linkzertifikat, das diese beiden EUR-Zertifikate
verbindet, sofern vorhanden
CSM_82 Über die in CSM_81 aufgeführten kryptografischen
Schlüssel und Zertifikate hinaus müssen die Fahrzeugein­
heiten zudem die in Teil A dieser Anlage aufgeführten
Schlüssel und Zertifikate enthalten, damit eine Fahrzeug­
einheit mit Fahrtenschreiberkarten der 1. Generation inte­
ragieren kann.
9.1.5 Geräteebene: Fahrtenschreiberkarten
▼M1
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 Werkstatt­
karte 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, über­
mittelt die erzeugende Partei den öffentlichen Schlüssel an
ihre MSCA, um das entsprechende durch die MSCA sig­
nierte Kartenzertifikat zu erhalten. Der private Schlüssel
darf nur durch die Fahrtenschreiberkarte genutzt werden.
▼B
CSM_84 Die Zertifikate Card_MA und Card_Sign jeder gegebenen
Fahrer- oder Werkstattkarte müssen das gleiche Certificate
Effective Date aufweisen.
CSM_85 Der Kartenhersteller oder -integrator wählt die Stärke eines
Kartenschlüsselpaars so, dass sie derjenigen des MSCA-
Schlüsselpaars entspricht, das zur Signierung des zugehö­
rigen Kartenzertifikats verwendet wird.
CSM_86 Fahrtenschreiberkarten dürfen ihr aus dem privaten Schlüs­
sel Card_MA.SK und dem öffentlichen Schlüssel
Card_MA.PK bestehendes Card_MA-Schlüsselpaar aus­
schließlich dazu verwenden, die gegenseitige Authentisie­
rung und Sitzungsschlüsselvereinbarung gegenüber Fahr­
zeugeinheiten durchzuführen, wie in den Abschnitten
10.3 und 10.4 dieser Anlage beschrieben.
CSM_87 Fahrer- oder Werkstattkarten nutzen den privaten Schlüssel
Card_Sign.SK des Card_Sign-Schlüsselpaars ausschließ­
lich dazu, heruntergeladene Datendateien zu signieren,
wie in Kapitel 14 dieser Anlage beschrieben. Der zugehö­
rige öffentliche Schlüssel Card_Sign.PK darf nur dazu ge­
nutzt werden, Signaturen, die durch die Karte erzeugt wur­
den, zu verifizieren.
▼M1
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
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 455
CSM_89 Die Gültigkeitsdauer des Card-Sign-Zertifikats lautet wie
folgt:
— Fahrerkarten: 5 Jahre und 1 Monat
— Werkstattkarten: 1 Jahr und 1 Monat
Hinweis: Die erweiterte Gültigkeitsdauer eines Card_Sign-
Zertifikats ermöglicht es einer Fahrerkarte, während des
ersten Monats nach Ablauf gültige Signaturen für herunter­
geladene Daten zu erzeugen. Dies ist aufgrund der
Verordnung (EU) Nr. 581/2010 erforderlich, nach der
das Herunterladen von Daten einer Fahrerkarte bis 28
Tage nach Aufzeichnung der letzten Tage möglich sein
muss.
CSM_90 Die Schlüsselpaare und entsprechenden Zertifikate einer
Fahrtenschreiberkarte dürfen nicht mehr ersetzt oder erneu­
ert werden, sobald die Karte ausgegeben ist.
CSM_91 Nach der Ausgabe müssen die Fahrtenschreiberkarten die
folgenden kryptografischen Schlüssel und Zertifikate
enthalten:
— den privaten Card_MA-Schlüssel samt zugehörigem
Zertifikat
— Zusätzlich für Fahrerkarten und Werkstattkarten: der
private Card_Sign-Schlüssel und das entsprechende
Zertifikat
— das MSCA_Card-Zertifikat mit dem öffentlichen
MSCA_Card.PK-Schlüssel zur Verifizierung des
Card_MA-Zertifikats und des Card_Sign-Zertifikats
— das EUR-Zertifikat mit dem öffentlichen EUR.PK-
Schlüssel zur Verifizierung des MSCA_Card-Zertifi­
kats
— das EUR-Zertifikat, dessen Gültigkeitsdauer direkt der
Gültigkeitsdauer des zur Verifizierung des MSCA_Card-
Zertifikats zu verwendenden EUR-Zertifikats vorausgeht,
falls vorhanden
— das Linkzertifikat, das diese beiden EUR-Zertifikate
verbindet, sofern vorhanden
▼M1
— 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-Zertifi­
kat, das zwei Generationen älter ist, falls vorhanden.
Hinweis zum letzten Gedankenstrich: Beispielsweise
müssen die genannten Karten in den ersten drei Mo­
naten der Gültigkeit des ERCA(3)-Zertifikats (siehe
Abbildung 1) das ERCA(1)-Zertifikat enthalten. Dies
ist erforderlich, damit diese Karten für den Daten­
download von ERCA(1)-Fahrzeugeinheiten verwendet
werden können, deren normale Gültigkeitsdauer von
15 Jahren zuzüglich der drei Monate für das Herunter­
laden von Daten in diesen Monaten abläuft (siehe An­
hang IC Randnummer 13 letzter Gedankenstrich).
▼B
CSM_92 Über die in CSM_91 aufgeführten kryptografischen
Schlüssel und Zertifikate hinaus müssen die Fahrtenschrei­
berkarten zudem die in Teil A dieser Anlage aufgeführten
Schlüssel und Zertifikate enthalten, damit diese Karten mit
Fahrzeugeinheiten der 1. Generation interagieren können.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 456
9.1.6 Geräteebene: Externe GNSS-Ausrüstung
▼M1
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 er­
zeugende 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.
▼B
CSM_94 Der EGF-Hersteller wählt die Stärke eines EGF_MA-
Schlüsselpaars so, dass sie derjenigen des MSCA-Schlüs­
selpaars entspricht, das zur Signierung des zugehörigen
EGF-MA-Zertifikats verwendet wird.
▼M1
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 aus­
schließlich dazu verwenden, die gegenseitige Authentisie­
rung und Sitzungsschlüsselvereinbarung gegenüber Fahr­
zeugeinheiten durchzuführen, wie in Abschnitt 11.4 dieser
Anlage beschrieben.
▼B
CSM_96 Die Gültigkeitsdauer des EGF_MA-Zertifikats beträgt 15
Jahre.
CSM_97 Eine externe GNSS-Ausrüstung darf den privaten Schlüs­
sel ihres EGF_MA Schlüsselpaars nicht zur Koppelung mit
einer Fahrzeugeinheit verwenden, wenn das entsprechende
Zertifikat abgelaufen ist.
Hinweis: Wie in Abschnitt 11.3.3 erläutert, kann eine ex­
terne GNSS-Ausrüstung ihren privaten Schlüssel mögli­
cherweise auch nach Ablauf des entsprechenden Zertifikats
gegenüber der VU verwenden, mit der sie bereits gekop­
pelt ist.
CSM_98 EGF_MA-Schlüsselpaar und zugehöriges Zertifikat einer
gegebenen externen GNSS-Ausrüstung dürfen nicht bei
der Praxisanwendung ausgetauscht oder erneuert werden,
sobald die EGF in Betrieb genommen wurde.
Hinweis: Diese Anforderung verbietet nicht die Möglich­
keit, im Rahmen einer Modernisierung oder Reparatur in
einer sicheren, vom EGF-Hersteller kontrollierten Umge­
bung EGF-Schlüsselpaare zu ersetzen.
CSM_99 Im Betrieb muss eine externe GNSS-Ausrüstung die fol­
genden kryptografischen Schlüssel und Zertifikate
enthalten:
— den privaten EGF_MA-Schlüssel samt zugehörigem
Zertifikat
— das MSCA_VU-EGF-Zertifikat mit dem öffentlichen
MSCA_VU-EGF.PK-Schlüssel zur Verifizierung des
EGF_MA-Zertifikats
— das EUR-Zertifikat mit dem öffentlichen EUR.PK-
Schlüssel zur Verifizierung des MSCA_VU-EGF-Zer­
tifikats
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 457
— das EUR-Zertifikat, dessen Gültigkeitsdauer direkt der
Gültigkeitsdauer des zur Verifizierung des MSCA_VU-
EGF-Zertifikats zu verwendenden EUR-Zertifikats vo­
rausgeht, falls vorhanden
— das Linkzertifikat, das diese beiden EUR-Zertifikate
verbindet, sofern vorhanden
9.1.7 Überblick Ersatz von Zertifikaten
In der untenstehenden Abbildung 1 ist dargestellt, wie die verschiedenen
Generationen von ERCA-Wurzelzertifikaten, ERCA-Linkzertifikaten,
MSCA-Zertifikaten und Ausrüstungszertifikaten (VU und Karte) im
Laufe der Zeit ausgegeben und genutzt werden:
▼M1
Abbildung 1
Ausgabe und Nutzung der verschiedenen Generationen von ERCA-Wurzelzertifikaten, ERCA-Linkzertifikaten,
MSCA-Zertifikaten und Ausrüstungszertifikaten
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 458
Hinweise zu Abbildung 1:
1. Unterschiedliche Generationen des Wurzelzertifikats werden durch
eine Zahl in Klammern dargestellt. Beispiel: ERCA (1) gibt die erste
Generation des ERCA-Wurzelzertifikats an; ERCA (2) die zweite
Generation usw.
2. Sonstige Zertifikate sind durch zwei Zahlen in Klammern dargestellt,
wobei die erste Zahl die Generation des Wurzelzertifikats angibt,
unter dem sie ausgestellt wurden, und die zweite Zahl die Generation
des jeweiligen Zertifikats selbst. MSCA_Card (1-1) ist beispielsweise
das erste unter ERCA (1) ausgestellte MSCA_Card-Zertifikat;
MSCA_Card (2-1) ist das erste unter ERCA ausgestellte
MSCA_Card-Zertifikat (2); MSCA_Card (2-last) ist das letzte unter
ERCA (2) ausgestellte MSCA_Card-Zertifikat; Card_MA(2-1) ist das
erste unter ERCA (2) ausgestellte Kartenzertifikat für die gegenseitige
Authentisierung usw.
3. Die Zertifikate MSCA_Card (2-1) und MSCA_Card (1-last) werden
fast, aber nicht exakt am selben Tag ausgestellt. MSCA_Card (2-1) ist
das erste unter ERCA (2) ausgestellte MSCA_Card-Zertifikat und
wird ein wenig später ausgestellt als MSCA_Card (1-last), dem letzten
MSCA_Card-Zertifikat unter ERCA (1).
4. Wie in der Abbildung dargestellt, werden die ersten unter ERCA (2)
ausgestellten VU- und Kartenzertifikate fast zwei Jahre, bevor die
letzten VU- und Kartenzertifikate unter ERCA (1) ausgegeben wer­
den, verfügbar sein. Grund dafür ist, dass VU- und Kartenzertifikate
nicht direkt unter dem ERCA-Zertifikat, sondern unter einem
MSCA-Zertifikat ausgestellt werden. Das MSCA (2-1) Zertifikat
wird direkt nach Gültigkeitsbeginn von ERCA (2) ausgegeben; das
Zertifikat MSCA (1-last) wird hingegen unmittelbar davor ausgestellt,
im letzten Moment, zu dem das Zertifikat ERCA (1) noch gültig ist.
Aus diesem Grund haben diese beiden MSCA-Zertifikate fast die
gleiche Gültigkeitsdauer, gehören aber zu verschiedenen Generatio­
nen.
5. Die für Karten angegebene Gültigkeitsdauer entspricht derjenigen von
Fahrerkarten (5 Jahre).
▼M1
6. Aus Platzgründen ist die unterschiedliche Gültigkeitsdauer der Zerti­
fikate Card_MA und Card_Sign nur für die 1. Generation angegeben.
▼B
9.2. Symmetrische Schlüssel
9.2.1 Schlüssel für die Sicherung der Kommunikation VU-Bewegungssensor
9.2.1.1 Allgemein
Hinweis: In diesem Abschnitt wird die Kenntnis des Inhalts von Refe­
renzdokument ISO 16844-3 vorausgesetzt, in dem die Schnittstelle zwi­
schen Fahrzeugeinheit und Bewegungssensor erläutert wird. Die Koppe­
lung zwischen einer VU und einem Bewegungssensor wird in Kapitel 12
dieser Anlage detailliert beschrieben.
CSM_100 Eine Reihe symmetrischer Schlüssel wird zur Koppelung
von Fahrzeugeinheiten und Bewegungssensoren, zur gegen­
seitigen Authentisierung zwischen Fahrzeugeinheiten und
Bewegungssensoren sowie zur Verschlüsselung der Kom­
munikation zwischen Fahrzeugeinheiten und Bewegungssen­
soren benötigt (siehe Tabelle 3). Bei diesen Schlüsseln muss
es sich stets um AES-Schlüssel handeln, deren Schlüssel­
länge derjenigen des Bewegungssensor-Hauptschlüssels ent­
spricht, die wiederum an die Länge des (vorgesehenen) eu­
ropäischen Wurzelschlüsselpaars angepasst ist (siehe
CSM_50).
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 459
Tabelle 3
Schlüssel für die Sicherung der Kommunikation VU-Bewegungssensor
Schlüssel Symbol Generiert durch Generierungsmethode Gespeichert durch
Bewegungssensor-Haupt­
schlüssel — VU-Teil
K M-VU ERCA Zufall ERCA, an der Ausgabe von
VU-Zertifikaten beteiligte
MSCA, VU-Hersteller, Fahr­
zeugeinheiten
Bewegungssensor-Haupt­
schlüssel — Werkstattteil
K M-WC ERCA Zufall ERCA, MSCA, Kartenherstel­
ler, Werkstattkarten
Bewegungssensor-Haupt­
schlüssel
K M Nicht unabhängig
generiert
Berechnet als K M = K M-
VU XOR K M-WC
ERCA, an der Ausgabe von
Bewegungssensor-Schlüsseln be­
teiligte MSCA (fakultativ) (*)
Identifikationsschlüssel K ID Nicht unabhängig
generiert
Berechnet als K ID = K M
XOR CV (CV angege­
ben in CSM_106)
ERCA, an der Ausgabe von
Bewegungssensor-Schlüsseln be­
teiligte MSCA (fakultativ) (*)
Koppelungsschlüssel K P Hersteller von Be­
wegungssensoren
Zufall Ein Bewegungssensor
Sitzungsschlüssel K S VU (während der
Koppelung von
VU und Bewe­
gungssensor)
Zufall Eine VU und ein Bewegungs­
sensor
(*) Die Speicherung von K M und K ID ist fakultativ, da diese Schlüssel von K M-VU , K M-WC und CV abgeleitet werden können.
CSM_101 Die Europäische Wurzel-Zertifizierungsstelle (ERCA) gene­
riert K M-VU und K M-WC , zwei zufällig erzeugte und eindeu­
tige AES-Schlüssel, aus denen sich der Bewegungssensor-
Hauptschlüssel K M als K M-VU XOR K M-WC berechnen lässt.
Die ERCA teilt den Zertifizierungsstellen der Mitgliedstaa­
ten die Schlüssel K M, K M-VU und K M-WC auf Anfrage mit.
CSM_102 Die ERCA weist jedem Bewegungssensor-Hauptschlüssel
K M eine eindeutige Versionsnummer zu, die auch für die
zugrunde liegenden Schlüssel K M-VU und K M-WC und für
den zugehörigen Identifikationsschlüssel K ID gilt. Wenn
die ERCA den MSCA die Schlüssel K M-VU und K M-WC
übermittelt, informiert sie diese über die Versionsnummer.
Hinweis: Mithilfe der Versionsnummer können die verschie­
denen Generationen dieser Schlüssel unterschieden werden;
dies ist in Abschnitt 9.2.1.2 detailliert erläutert.
CSM_103 Die Zertifizierungsstelle des jeweiligen Mitgliedstaates leitet
den Schlüssel K M-VU samt Versionsnummer an die
VU-Hersteller auf deren Anfrage weiter. Die VU-Hersteller
setzen den Schlüssel K M-VU samt Versionsnummer in allen
hergestellten VU ein.
CSM_104 Die Zertifizierungsstelle des Mitgliedstaates stellt sicher,
dass der Schlüssel K M-WC samt Versionsnummer in jede
Werkstattkarte eingefügt wird, die unter ihrer Verantwortung
ausgegeben wird.
Hinweise:
— Siehe die Beschreibung des Datentyps
in Anlage 2.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 460
— Wie in Abschnitt 9.2.1.2 erläutert, müssen in eine ein­
zelne Werkstattkarte mehrere Generationen von K M-WC
eingesetzt werden.
CSM_105 Über den in CSM_104 angegebenen AES-Schlüssel hinaus
muss die MSCA sicherstellen, dass der unter Randnummer
CSM_037 in Teil A dieser Anlage angegebene T-DES-
Schlüssel Km WC in jede Werkstattkarte eingesetzt wird,
die unter ihrer Verantwortung ausgegeben wird.
Hinweise:
— Dadurch kann eine Werkstattkarte der 2. Generation zur
Koppelung einer VU der 1. Generation verwendet
werden.
— Eine Werkstattkarte der 2. Generation umfasst zwei ver­
schiedene Anwendungen: Eine entspricht Teil B dieser
Anlage, die andere Teil A. Die Letztgenannte enthält
den T-DES-Schlüssel Km WC .
CSM_106 Eine an der Ausgabe von Bewegungssensoren beteiligte
MSCA leitet den Identifikationsschlüssel per XOR-Berech­
nung mit einem konstanten Vektor CV vom Bewegungssen­
sor-Hauptschlüssel ab. Der Wert von CV lautet wie folgt:
▼M1
— Für 128-Bit-Bewegungssensor-Hauptschlüssel: CV =
„B6 44 2C 45 0E F8 D3 62 0B 7A 8A 97 91 E4 5D 83“
▼B
— Für 192-Bit-Bewegungssensor-Hauptschlüssel: CV = „72
AD EA FA 00 BB F4 EE F4 99 15 70 5B 7E EE BB
1C 54 ED 46 8B 0E F8 25“
— Für 256-Bit-Bewegungssensor-Hauptschlüssel: CV =
„1D 74 DB F0 34 C7 37 2F 65 55 DE D5 DC D1
9A C3 23 D6 A6 25 64 CD BE 2D 42 0D 85 D2 32
63 AD 60“
Hinweis: Die konstanten Vektoren sind wie folgt zu
berechnen:
Pi_10 = die ersten 10 Bytes des Dezimalteils der mathema­
tischen Konstante π = „24 3F 6A 88 85 A3 08 D3 13 19“
CV_128-bits = erste 16 Bytes von SHA-256(Pi_10)
CV_192-bits = erste 24 Bytes von SHA-384(Pi_10)
CV_256-bits = erste 32 Bytes von SHA-512(Pi_10)
CSM_107 ►M1 Die Hersteller von Bewegungssensoren generieren
für jeden Bewegungssensor einen zufälligen, eindeutigen
Koppelungsschlüssel K P und senden jeden einzelnen Kop­
pelungsschlüssel an die Zertifizierungsstelle des Mitglied­
staates. Die MSCA verschlüsselt jeden Koppelungsschlüssel
einzeln mit dem Bewegungssensor-Hauptschlüssel K M und
übermittelt den kodierten Schlüssel zurück an den Hersteller
des Bewegungssensors. Für jeden kodierten Schlüssel infor­
miert die MSCA den Hersteller von Bewegungssensoren
über die Versionsnummer des zugehörigen K M . ◄
Hinweis: Wie in Abschnitt 9.2.1.2 erläutert, muss ein Her­
steller von Bewegungssensoren für einen einzelnen Bewe­
gungssensor unter Umständen mehrere eindeutige Koppe­
lungsschlüssel generieren.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 461
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 K ID und übermittelt
die kodierte Seriennummer zurück an den Hersteller des
Bewegungssensors. Für jede kodierte Seriennummer infor­
miert die MSCA den Hersteller von Bewegungssensoren
über die Versionsnummer des zugehörigen K ID .
▼B
CSM_109 Bezüglich der Randnummern CSM_107 und CSM_108
muss die MSCA den AES-Algorithmus im Modus Cipher
Block Chaining gemäß Referenzdokument ISO 10116, mit
einem Verschachtelungsparameter m = 1 und einem Initiali­
sierungsvektor SV = „00“{16}, d. h. sechzehn Bytes mit
dem Binärwert 0, verwenden. Falls erforderlich, muss die
MSCA die Auffüllmethode 2 gemäß Referenzdokument
ISO 9797-1 verwenden.
CSM_110 Der Hersteller von Bewegungssensoren speichert den ko­
dierten Koppelungsschlüssel und die kodierte Seriennummer
im vorgesehenen Bewegungssensor, zusammen mit den ent­
sprechenden Klartextwerten und der Versionsnummer der
zur Verschlüsselung verwendeten K M und K ID .
Hinweis: Wie in Abschnitt 9.2.1.2 erläutert, muss ein Her­
steller von Bewegungssensoren für einen einzelnen Bewe­
gungssensor unter Umständen mehrere kodierte Koppelungs­
schlüssel und mehrere kodierte Seriennummern einfügen.
CSM_111 Über die in CSM_110 erläuterten AES-basierten kryptogra­
fischen Elemente hinaus kann der Hersteller von Bewe­
gungssensoren in jedem Bewegungssensor auch die in Teil
A dieser Anlage, Randnummer CSM_037, genannten
T-DES-basierten kryptografischen Elemente speichern.
Hinweis: Dadurch kann ein Bewegungssensor der 2. Gene­
ration mit einer VU der 1. Generation gekoppelt werden.
CSM_112 Die Länge des während der Koppelung mit einem Bewe­
gungssensor von einer VU generierten Sitzungsschlüssels K S
muss derjenigen seines K M-VU entsprechen (siehe CSM_50).
9.2.1.2 Austausch des Bewegungssensor-Hauptschlüssels bei Geräten der zwei­
ten Generation
CSM_113 Sämtliche Bewegungssensor-Hauptschlüssel und alle zu­
gehörigen Schlüssel (siehe Tabelle 3) sind einer bestimmten
Generation des ERCA-Wurzelschlüsselpaars zugeordnet.
Diese Schlüssel müssen deshalb alle 17 Jahre ersetzt wer­
den. Die Gültigkeitsdauer jeder Generation von Bewegungs­
sensor-Hauptschlüsseln beginnt ein Jahr, bevor das zugehö­
rige ERCA-Wurzel-Schlüsselpaar gültig wird, und endet,
wenn das zugehörige ERCA-Wurzel-Schlüsselpaar ausläuft.
Dies ist in Abbildung 2 dargestellt.
▼M1
02016R0799 — DE — 21.08.2023 — 003.002 — 462
Abbildung 2
Ausstellung und Verwendung verschiedener Generationen von Bewegungssensor-Hauptschlüsseln in
Fahrzeugeinheiten, Bewegungssensoren und Werkstattkarten
CSM_114 Mindestens ein Jahr, bevor ein neues European Wurzel-
Schlüsselpaar erstellt wird (siehe CSM_56), erstellt die
ERCA K M durch Generierung neuer K M-VU und K M-WC
einen neuen Bewegungssensor-Hauptschlüssel. Die Länge
des Bewegungssensor-Hauptschlüssels muss der vorgesehe­
nen Stärke des neuen europäischen Wurzel-Schlüsselpaars
gemäß CSM_50 entsprechen. Die ERCA teilt den MSCA
auf Anfrage die neuen K M , K M-VU und K M-WC samt Ver­
sionsnummer mit.
CSM_115 Die MSCA stellt sicher, dass alle gültigen Generationen von
K M-WC in jeder unter ihrer Verantwortung ausgegebenen
Werkstattkarte samt ihren Versionsnummern gespeichert
werden (siehe Abbildung 2).
Hinweis: Dies hat zur Folge, dass im letzten Jahr der Gültig­
keitsdauer eines ERCA-Zertifikats Werkstattkarten mit drei
verschiedenen Generationen von K M-WC ausgegeben werden
(siehe Abbildung 2).
CSM_116 Bezüglich des unter CSM_107 und CSM_108 oben genann­
ten Verfahrens: Die MSCA kodiert jeden Koppelungsschlüs­
sel K P , den sie von einem Hersteller von Bewegungssenso­
ren erhält, separat mit jeder gültigen Generation des
Bewegungssensor-Hauptschlüssels K M . Weiterhin kodiert
die MSCA jede Seriennummer, die sie von einem Hersteller
von Bewegungssensoren erhält, separat mit jeder gültigen
Generation des Identifizierungsschlüssels K ID . Der Hersteller
von Bewegungssensoren speichert sämtliche Kodierungen
des Koppelungsschlüssels sowie sämtliche Kodierungen
der Seriennummern im vorgesehenen Bewegungssensor, zu­
sammen mit den entsprechenden Klartextwerten und der
Versionsnummer der zur Verschlüsselung verwendeten K M
und K ID .
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 463
Hinweis: Dies hat zur Folge, dass im letzten Jahr der Gültig­
keitsdauer eines ERCA-Zertifikats Bewegungssensoren mit
kodierten Daten ausgegeben werden, die auf drei verschie­
denen K M -Generationen basieren (siehe Abbildung 2).
CSM_117 Bezüglich des unter CSM_107 oben genannten Verfahrens:
Da die Länge des Koppelungsschlüssels K P an der Länge
von K M auszurichten ist (siehe CSM_100), muss ein Her­
steller von Bewegungssensoren für einen Bewegungssensor
unter Umständen bis zu drei verschiedene Koppelungs­
schlüssel (unterschiedlicher Länge) für den Fall generieren,
dass nachfolgende K M -Generationen unterschiedliche Län­
gen aufweisen. In einem solchen Fall sendet der Hersteller
sämtliche Koppelungsschlüssel an die MSCA. Die MSCA
stellt sicher, dass jeder Koppelungsschlüssel mit der richti­
gen Generation des Bewegungssensor-Hauptschlüssels ko­
diert ist, also derjenigen gleicher Länge.
Hinweis: Wenn der Hersteller von Bewegungssensoren ent­
scheidet, einen T-DES-basierten Koppelungsschlüssel für ei­
nen Bewegungssensor der 2. Generation zu generieren (siehe
CSM_111), muss der Hersteller die MSCA darauf hinwei­
sen, dass der T-DES-basierte Bewegungssensor-Haupt­
schlüssel zur Dekodierung dieses Koppelungsschlüssels ver­
wendet werden muss. Grund dafür ist, dass die Länge eines
T-DES-Schlüssels mit derjenigen eines AES-Schlüssels
identisch sein kann; die MSCA kann die Unterscheidung
deshalb nicht alleine anhand der Schlüssellänge treffen.
CSM_118 Die VU-Hersteller dürfen in jede Fahrzeugeinheit nur eine
K M-VU -Generation samt Versionsnummer einsetzen. Diese
K M-VU -Generation ist an das ERCA-Zertifikat zu binden,
auf dem die Zertifikate der VU basieren.
Anmerkungen:
— Eine Fahrzeugeinheit, die auf dem ERCA-Zertifikat der
Generation X basiert, darf nur den K M-VU der Generation
X enthalten, selbst wenn dieser erst nach Beginn der
Gültigkeitsdauer des ERCA-Zertifikats der Generation
X+1 ausgestellt wurde. Dies ist in Abbildung 2
dargestellt.
— Eine VU der Generation X kann nicht mit einem Bewe­
gungssensor der Generation X-1 gekoppelt werden.
— Da Werkstattkarten eine Gültigkeitsdauer von einem Jahr
aufweisen, bewirken CSM_113 — CSM_118, dass alle
Werkstattkarten dann, wenn der neue K M-VU ausgegeben
werden wird, den neuen K M-WC enthalten werden. Somit
wird eine solche VU immer in der Lage sein, den neuen
K M zu berechnen. Zudem werden dann die meisten
neuen Bewegungssensoren ebenfalls kodierte Daten ent­
halten, die auf dem neuen K M beruhen.
9.2.2 Schlüssel zur Sicherung der DSRC-Kommunikation
9.2.2.1 Allgemein
CSM_119 Die Authentizität und Vertraulichkeit der von einer Fahr­
zeugeinheit per DSRC-Fernkommunikationskanal an eine
Kontrollbehörde übermittelten Daten kann mithilfe einer
Reihe VU-spezifischer AES-Schlüssel sichergestellt werden,
die von einem einzigen DSRC-Hauptschlüssel, KM DSRC ,
abgeleitet sind.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 464
CSM_120 Beim DSRC-Hauptschlüssel KM DSRC muss es sich um einen
AES-Schlüssel handeln, der von der ERCA sicher generiert,
gespeichert und verteilt wird. Die Schlüssellänge kann 128,
192 oder 256 Bits betragen und orientiert sich an der Länge
des europäischen Wurzel-Schlüsselpaars (siehe CSM_50).
CSM_121 Die ERCA übermittelt auf Anfrage den Zertifizierungsstellen
der Mitgliedstaaten den DSRC-Hauptschlüssel in sicherer
Form, damit diese Stellen VU-spezifische DSRC-Schlüssel
ableiten und somit sicherstellen können, dass der
DSRC-Hauptschlüssel in alle unter ihrer Verantwortung aus­
gegebenen Kontrollkarten und Werkstattkarten eingesetzt ist.
CSM_122 Die ERCA weist jedem DSRC-Hauptschlüssel eine eindeu­
tige Versionsnummer zu. Wenn die ERCA den MSCA den
DSRC-Hauptschlüssel übermittelt, informiert sie diese über
die Versionsnummer.
Hinweis: Mithilfe der Versionsnummer können die verschie­
denen Generationen des DSRC-Hauptschlüssels unterschie­
den werden; dies ist in Abschnitt 9.2.2.2 detailliert erläutert.
▼M1
CSM_123 Für jede Fahrzeugeinheit erstellt der Hersteller der Fahrzeug­
einheit eine eindeutige VU-Seriennummer und sendet diese
an die Zertifizierungsstelle des Mitgliedstaates, um eine
Gruppe von zwei VU-spezifischen DSRC-Schlüsseln zu be­
antragen. Die VU-Seriennummer verfügt über den Datentyp
.
Hinweis:
— Die VU-Seriennummer muss mit dem Element ‚vuSeri­
alNumber‘ 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 be­
kannt. In diesem Fall sendet der Hersteller der VU statt­
dessen die bei der Beantragung der VU-Zertifikate ver­
wendete 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.
▼B
CSM_124 Nach Erhalt des Antrags auf VU-spezifische DSRC-Schlüssel
leitet die MSCA für die Fahrzeugeinheit zwei AES-Schlüssel
namens K_VU DSRC _ENC und K_VU DSRC _MAC ab. Diese
VU-spezifischen Schlüssel sind genauso lang wie der
DSRC-Hauptschlüssel. Die MSCA verwendet die in Referenz­
dokument RFC 5869 definierte Schlüsselableitungsfunktion.
Die zum Instanzieren der HMAC-Hashfunktion erforderliche
Hashfunktion ist an der Länge des DSRC-Hauptschlüssels aus­
zurichten (siehe CSM_50). Die in RFC 5869 dargelegte
Schlüsselableitungsfunktion ist wie folgt zu verwenden:
Schritt 1 (Extrahieren):
— PRK = HMAC-Hash (salt, IKM) wobei salt einen leeren
String „“ darstellt und IKM KM DSRC entspricht
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 465
Schritt 2 (Expandieren):
— OKM = T(1), wobei
T(1) = HMAC-Hash (PRK, T(0) || info || „01“) mit
— T(0) = leerer String („“)
— ►M1 info = VU-Seriennummer oder Kennung des
Zertifikatsantrags gemäß CSM_123 ◄
— K_VU DSRC _ENC = erste L-Oktette von OKM und
K_VU DSRC _MAC = letzte L-Oktette von OKM;
dabei ist L die erforderliche Länge von K_VU DSRC _ENC
und K_VU DSRC _MAC in Oktetten.
CSM_125 Die MSCA verteilt K_VU DSRC _ENC und K_VU DSRC _MAC
in sicherer Form an die VU-Hersteller, damit diese sie in die
vorgesehene Fahrzeugeinheit einsetzen.
CSM_126 Bei der Ausgabe müssen im geschützten Speicher einer
Fahrzeugeinheit K_VU DSRC _ENC und K_VU DSRC _MAC
abgelegt sein, um die Integrität, Authentizität und Vertrau­
lichkeit der über den Fernkommunikationskanal gesendeten
Daten gewährleisten zu können. Außerdem muss in einer
Fahrzeugeinheit die Versionsnummer des zum Ableitung
dieser VU-spezifischen Schlüssel verwendeten DSRC-
Hauptschlüssels gespeichert sein.
CSM_127 Bei der Ausgabe muss im geschützten Speicher von Kon­
trollkarten und Werkstattkarten KM DSRC abgelegt sein, um
die Integrität und Authentizität der von einer VU über den
Fernkommunikationskanal gesendeten Daten zu überprüfen
und diese Daten zu entschlüsseln. Auch in den Kontrollkar­
ten und Werkstattkarten muss die Versionsnummer des
DSRC-Hauptschlüssels abgelegt sein.
Hinweis: Wie in Abschnitt 9.2.2.2 erläutert, müssen unter
Umständen in eine einzelne Werkstatt- oder Kontrollkarte
mehrere Generationen von K MDSRC eingesetzt werden.
▼M1
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.
9.2.2.2 Austausch des DSRC-Hauptschlüssels
CSM_129 Sämtliche DSRC-Hauptschlüssel sind einer bestimmten Ge­
neration des ERCA-Wurzelschlüsselpaars zugeordnet. Die
ERCA tauscht den DSRC-Hauptschlüssel deshalb alle 17
Jahre aus. Die Gültigkeitsdauer jeder Generation von
DSRC-Hauptschlüsseln beginnt zwei Jahre, bevor das zu­
gehörige ERCA-Wurzel-Schlüsselpaar gültig wird, und en­
det, wenn das zugehörige ERCA-Wurzel-Schlüsselpaar aus­
läuft. Dies ist in Abbildung 3 dargestellt.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 466
Abbildung 3
Ausstellung und Verwendung verschiedener Generationen von DSRC-Hauptschlüsseln in Fahrzeugeinheiten,
Werkstatt- und Kontrollkarten
CSM_130 Spätestens zwei Jahre vor dem Erstellen eines neuen euro­
päischen Wurzel-Schlüsselpaars (siehe CSM_56) erstellt die
ERCA einen neuen DSRC-Hauptschlüssel. Die Länge des
DSRC-Hauptschlüssels muss der vorgesehenen Stärke des
neuen europäischen Wurzel-Schlüsselpaars gemäß CSM_50
entsprechen. Die ERCA teilt den MSCA auf Anfrage den
neuen DSRC-Hauptschlüssel samt Versionsnummer mit.
CSM_131 Die MSCA stellt sicher, dass alle gültigen Generationen von
K MDSRC in jeder unter ihrer Verantwortung ausgegebenen
Kontrollkarte samt Versionsnummern gespeichert werden
(siehe Abbildung 3).
Hinweis: Dies hat zur Folge, dass in den letzten beiden
Jahren der Gültigkeitsdauer eines ERCA-Zertifikats Kon­
trollkarten mit drei verschiedenen Generationen von K MDSRC
ausgegeben werden (siehe Abbildung 3).
CSM_132 Die MSCA stellt sicher, dass alle Generationen von
K MDSRC , die seit mindestens einem Jahr und auch noch
weiter gültig sind, in jeder unter ihrer Verantwortung aus­
gegebenen Werkstattkarte samt ihren Versionsnummern ge­
speichert werden (siehe Abbildung 3).
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 467
Hinweis: Dies hat zur Folge, dass im letzten Jahr der Gültig­
keitsdauer eines ERCA-Zertifikats Werkstattkarten mit drei
verschiedenen Generationen von K MDSRC ausgegeben wer­
den (siehe Abbildung 3).
CSM_133 Die VU-Hersteller dürfen in jede Fahrzeugeinheit nur eine
Gruppe VU-spezifischer DSRC-Schlüssel samt Versions­
nummer einsetzen. Diese Schlüsselgruppe ist von der
KM DSRC -Generation abzuleiten, die an das ERCA-Zertifikat
gebunden ist, auf dem die Zertifikate der VU basieren.
Hinweise:
— Dies bedeutet, dass eine Fahrzeugeinheit, die auf dem
ERCA-Zertifikat der Generation X basiert, nur die
K_VU_ENC und K_VU DSRC _MAC der Generation ent­
halten darf, selbst wenn die VU erst nach Beginn der
Gültigkeitsdauer des ERCA-Zertifikats der Generation
X+1 ausgestellt wurde. Dies ist in Abbildung 3
dargestellt.
— Da Werkstattkarten eine Gültigkeitsdauer von einem Jahr
und Kontrollkarten eine Gültigkeitsdauer von zwei Jah­
ren aufweisen, bewirken CSM_131 — CSM_133, dass
alle Werkstatt- und Kontrollkarten dann, wenn die erste
VU mit VU-spezifischen Schlüsseln auf Grundlage die­
ses Hauptschlüssels ausgegeben werden wird, den neuen
DSRC-Hauptschlüssel enthalten werden.
9.3. Zertifikate
9.3.1 Allgemein
CSM_134 Bei allen Zertifikaten im europäischen intelligenten Fahrten­
schreibersystem muss es sich um selbstbeschreibende,
kartenverifizierbare (CV) Zertifikate gemäß ISO 7816-4
und ISO 7816-8 handeln.
CSM_135 ►M1 Zur Kodierung der Datenobjekte innerhalb der Zerti­
fikate 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. ◄
Hinweis: Diese Kodierung bewirkt folgende TLV-Struktur
(Tag-Length-Value, Tag-Längen-Wert):
Tag: Der Tag ist in ein oder zwei Oktette verschlüsselt
und gibt den Inhalt an.
Länge: Die Länge ist als unsignierte Ganzzahl in ein, zwei
oder drei Oktette verschlüsselt, was zu einer Länge
von maximal 65 535 Oktetten führt. Es ist die
Mindestzahl an Oktetten zu verwenden.
Wert: Der Wert ist in null oder mehr Oktette verschlüs­
selt.
9.3.2 Zertifikatsinhalt
CSM_136 Alle Zertifikate weisen die Struktur des Zertifikatprofils in
Tabelle 4 auf.
Tabelle 4
Zertifikatprofil Version 1
Feld Feldkennung Tag Länge (Bytes)
ASN.1-Datentyp
(siehe Anlage 1)
ECC-Zertifikat C „7F 21“ var
ECC Certificate Body B „7F 4E“ var
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 468
Feld Feldkennung Tag Länge (Bytes)
ASN.1-Datentyp
(siehe Anlage 1)
Certificate Profile
Identifier
CPI „5F 29“ „01“
Certificate Authority
Reference
CAR „42“ „08“
Certificate Holder
Authorisation
CHA „5F 4C“ „07“
Public Key PK „7F 49“ var
Domain Parameters DP „06“ var
Public Point PP „86“ var
Certificate Holder
Reference
CHR „5F 20“ „08“
Certificate Effective
Date
CEfD „5F 25“ „04“
Certificate Expiration
Date
CExD „5F 24“ „04“
ECC Certificate Sig­
nature
S „5F 37“ var
Hinweis: Mit der Feldkennung werden in späteren Abschnit­
ten dieser Anlage einzelne Felder eines Zertifikats angege­
ben — X.CAR ist beispielsweise die im Zertifikat von Be­
nutzer X angegebene Certificate Authority Reference.
9.3.2.1 Certificate Profile Identifier
CSM_137 Die Zertifikate müssen mit einem Certificate Profile Identi­
fier das verwendete Zertifikatprofil angeben. Version 1
(siehe Tabelle 4) ist durch einen Wert von „00“ anzugeben.
9.3.2.2 Certificate Authority Reference
CSM_138 Mit der Certificate Authority Reference wird der öffentliche
Schlüssel angegeben, mit dem die Zertifikatsignatur verifi­
ziert wird. Die Certificate Authority Reference muss deshalb
mit der Certificate Holder Reference im Zertifikat der ent­
sprechenden Zertifizierungsstelle übereinstimmen.
CSM_139 Ein ERCA-Wurzelzertifikat muss selbstsigniert sein, d. h.
Certificate Authority Reference und Certificate Holder Re­
ference im Zertifikat müssen übereinstimmen.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 469
CSM_140 Bei einem ERCA-Linkzertifikat muss die Certificate Holder
Reference der CHR des neuen ERCA-Wurzelzertifikats ent­
sprechen. Die Certificate Holder Reference eines Linkzerti­
fikats muss der CHR des vorherigen ERCA-Wurzelzertifi­
kats entsprechen.
9.3.2.3 Certificate Holder Authorisation
▼M1
CSM_141 Mit ‚Certificate Holder Authorisation‘ wird die Zertifikatart
angegeben. Sie besteht aus den sechs höchstwertigen Bytes
der Fahrtenschreiberanwendungs-ID, verkettet mit dem Ge­
rä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 verwen­
det, um zwischen einem Zertifikat für die gegenseitige Au­
thentisierung und einem Zertifikat für die Erzeugung digi­
taler Signaturen zu unterscheiden (siehe Abschnitt 9.1 und
Anlage 1, Datentyp EquipmentType).
▼B
9.3.2.4 Public Key
Public Key verschachtelt zwei Datenelemente: den mit dem öffentlichen
Schlüssel im Zertifikat zu verwendenden standardisierten Domänenpara­
meter und den Wert des öffentlichen Punktes.
CSM_142 Das Datenelement Domain Parameters muss eine der in Ta­
belle 1 angegebenen Objektkennungen enthalten, um auf
eine Gruppe standardisierter Domänenparameter zu
verweisen.
CSM_143 Das Datenelement Public Point enthält den öffentlichen
Punkt. Öffentliche Punkte auf elliptischen Kurven sind ge­
mäß TR-03111 in Oktettstrings umzuwandeln. Dabei ist das
unkomprimierte Verschlüsselungsformat zu verwenden.
Beim Wiederherstellen eines Punktes auf einer elliptischen
Kurve aus seinem verschlüsselten Format sind stets die in
TR-03111 genannten Validierungen durchzuführen.
9.3.2.5 Certificate Holder Reference (Referenz des Zertifikatinhabers)
CSM_144 Certificate Holder Reference ist eine Kennung für den im
Zertifikat angegebenen öffentlichen Schlüssel. Mit dieser
Kennung wird in anderen Zertifikaten auf diesen öffent­
lichen Schlüssel verwiesen.
CSM_145 Bei Kartenzertifikaten und Zertifikaten externer GNSS-Aus­
rüstung muss Certificate Holder Reference den in Anlage 1
angegebenen Datentyp
aufweisen.
CSM_146 Bei Fahrzeugeinheiten ist dem Hersteller bei der Beantragung
eines Zertifikats die herstellerspezifische Seriennummer der
VU, für die das Zertifikat und der zugehörige private Schlüs­
sel vorgesehen sind, unter Umständen
nicht bekannt. Wenn sie ihm bekannt ist, muss Certificate
Holder Reference den in Anlage 1 angegebenen Datentyp
aufweisen. Wenn sie ihm nicht
bekannt ist, muss Certificate Holder Reference den in Anlage
1 angegebenen Datentyp
aufweisen.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 470
Hinweis: Bei Kartenzertifikaten muss der Wert der CHR
dem Wert von „cardExtendedSerialNumber“ in EF_ICC ent­
sprechen (siehe Anlage 2). Bei EGF-Zertifikaten muss der
Wert der CHR dem Wert von „sensorGNSSSerialNumber“
in EF_ICC entsprechen (siehe Anlage 14). Bei VU-Zertifi­
katen muss der Wert der CHR dem Element „vuSerialN­
umber“ von „VuIdentification“ entsprechen (siehe Anlage 1),
es sei denn, dem Hersteller ist die herstellerspezifische Se­
riennummer zum Zeitpunkt der Beantragung des Zertifikats
nicht bekannt.
▼B
CSM_147 Bei ERCA- und MSCA-Zertifikaten muss Certificate Holder
Reference den in Anlage 1 angegebenen Datentyp Certifica­
tionAuthorityKID
aufweisen.
9.3.2.6 Certificate Effective Date
▼M1
CSM_148 Certificate Effective Date gibt Anfangsdatum und -uhrzeit
der Gültigkeitsdauer des Zertifikats an.
▼B
9.3.2.7 Certificate Expiration Date
CSM_149 Certificate Expiration Date gibt Enddatum und -uhrzeit der
Gültigkeitsdauer des Zertifikats an.
9.3.2.8 Certificate Signature
CSM_150 Die Signatur des Zertifikats wird anhand des kodierten Zer­
tifikatkörpers erstellt, einschließlich Tag und Länge des Zer­
tifikatkörpers. Als Signaturalgorithmus wird ECDSA gemäß
DSS verwendet; dabei ist der an die Schlüsselgröße der
signierenden Stelle gebundene Hash-Algorithmus zu ver­
wenden (siehe CSM_50). Das Signaturformat ist Klartext,
wie in TR-03111 angegeben.
9.3.3 Beantragen von Zertifikaten
CSM_151 ►M1 Beim Beantragen eines Zertifikats muss die MSCA
der ERCA die folgenden Daten übermitteln: ◄
— den Certificate Profile Identifier des beantragten Zertifi­
kats
— die Certificate Authority Reference, die zum Signieren
des Zertifikats voraussichtlich verwendet werden soll
— den zu signierenden Public Key
CSM_152 Über die in CSM_151 genannten Angaben hinaus muss die
MSCA der ERCA in einem Zertifikatsantrag die folgenden
Daten übermitteln, damit Letztgenannte die Certificate Hol­
der Reference des neuen MSCA-Zertifikats erstellen kann:
— den numerischen Landescode der Zertifizierungsstelle
(der in Anlage 1 definierte Datentyp )
— den alphanumerischen Landescode der Zertifizierungs­
stelle (der in Anlage 1 definierte Datentyp
)
— die 1-Byte-Seriennummer zur Unterscheidung der ver­
schiedenen Schlüssel der Zertifizierungsstelle für den
Fall des Wechsels von Schlüsseln
— das 2-Byte-Feld mit weiteren Informationen zur Zertifi­
zierungsstelle
▼M1
02016R0799 — DE — 21.08.2023 — 003.002 — 471
CSM_153 Der Gerätehersteller muss der MSCA in einem Zertifikats­
antrag 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 ein­
deutige Kennung für den Zertifikatsantrag.
— Monat und Jahr der Geräteherstellung oder des Zertifi­
katsantrags.
Der Hersteller muss sicherstellen, dass diese Angaben richtig sind und
dass das von der MSCA übermittelte Zertifikat in die vorgesehene Aus­
rüstung eingesetzt wird.
▼B
CSM_154 Bei Fahrzeugeinheiten ist dem Hersteller bei der Beantra­
gung eines Zertifikats die herstellerspezifische Seriennum­
mer der VU, für die das Zertifikat und der zugehörige pri­
vate Schlüssel vorgesehen sind, unter Umständen nicht be­
kannt. Wenn bekannt, übermittelt der VU-Hersteller die Se­
riennummer der MSCA. Wenn nicht bekannt, kennzeichnet
der Hersteller jeden Zertifikatsantrag eindeutig und übermit­
telt diese Seriennummer der MSCA. Das ausgestellte Zerti­
fikat enthält dann die Seriennummer des Zertifikatsantrags.
Sobald das Zertifikat in eine bestimmte VU eingesetzt ist,
übermittelt der Hersteller der MSCA den Zusammenhang
zwischen der Seriennummer des Zertifikatsantrags und der
VU-Kennung.
10. GEGENSEITIGE AUTHENTISIERUNG VU-KARTE UND SECURE
MESSAGING
10.1. Allgemein
CSM_155 Generell wird die sichere Kommunikation zwischen Fahr­
zeugeinheit und Fahrtenschreiberkarte durch die folgenden
Schritte gewährleistet:
— Im ersten Schritt zeigt jede Partei der jeweils anderen,
dass sie über ein gültiges Public-Key-Zertifikat verfügt,
signiert durch die Zertifizierungsstelle des Mitgliedstaats.
Das Public-Key-Zertifikat der MSCA wiederum muss
durch die Europäische Wurzel-Zertifizierungsstelle sig­
niert sein. Dieser Schritt, die Verifizierung der Zertifi­
katkette, wird in Abschnitt 10.2 detailliert erläutert.
— Im zweiten Schritt weist die Fahrzeugeinheit der Karte
nach, dass sie über den privaten Schlüssel verfügt, der
dem öffentlichen Schlüssel im vorgelegten Zertifikat ent­
spricht. Dazu signiert sie eine von der Karte übermittelte
Zufallszahl. Die Karte verifiziert die Signatur anhand der
Zufallszahl. Wenn diese Verifizierung erfolgreich ver­
läuft, ist die VU authentisiert. Dieser Schritt, die VU-
Authentisierung, wird in Abschnitt 10.3 detailliert erläu­
tert.
▼M1
02016R0799 — DE — 21.08.2023 — 003.002 — 472
— Im dritten Schritt berechnen beide Parteien unabhängig
voneinander mithilfe eines asymmetrischen Algorithmus
zur Schlüsselvereinbarung zwei AES-Sitzungsschlüssel.
Mit einem dieser Sitzungsschlüssel erstellt die Karte an­
hand einiger von der Karte gesendeter Daten einen Code
für die Nachrichtenauthentisierung (MAC). Die VU ve­
rifiziert den MAC. Wenn diese Verifizierung erfolgreich
verläuft, ist die Karte authentisiert. Dieser Schritt, die
Kartenauthentisierung, wird in Abschnitt 10.4 detailliert
erläutert.
— Im vierten Schritt gewährleisten VU und Karte mithilfe
der vereinbarten Sitzungsschlüssel die Vertraulichkeit,
Integrität und Authentizität aller ausgetauschten Nach­
richten. Dieser Schritt namens Secure Messaging wird
in Abschnitt 10.5 detailliert erläutert.
CSM_156 Der in CSM_155 beschriebene Mechanismus wird von der
Fahrzeugeinheit ausgelöst, sobald in einen ihrer Steckplätze
eine Karte eingesetzt wird.
10.2. Gegenseitige Verifizierung der Zertifikatkette
10.2.1 Verifizierung der Kartenzertifikatkette durch die VU
CSM_157 ►M1 Die Fahrzeugeinheiten verifizieren mithilfe des in
Abbildung 4 dargestellten Protokolls die Zertifikatkette einer
Fahrtenschreiberkarte. Bei jedem aus der Karte ausgelese­
nem Zertifikat überprüft die VU die Richtigkeit des Feldes
Certificate Holder Authorisation (CHA):
— Im Feld CHA des Kartenzertifikats muss ein Kartenzer­
tifikat 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. ◄
Hinweise zu Abbildung 4:
— Bei den in der Abbildung erwähnten Kartenzertifikaten
und öffentlichen Schlüsseln handelt es sich um diejeni­
gen zur gegenseitigen Authentisierung. In Abschnitt
9.1.5 werden sie als Card_MA bezeichnet.
— Bei den in der Abbildung erwähnten Card.CA-Zertifika­
ten und öffentlichen Schlüsseln handelt es sich um die­
jenigen zur Signierung der Kartenzertifikate, die in der
CAR des Card-Zertifikats angegeben sind. In Abschnitt
9.1.3 werden sie als MSCA_Card bezeichnet.
— Bei dem in der Abbildung erwähnten Card.CA.EUR-
Zertifikat handelt es sich um das europäische Wurzelzer­
tifikat, das in der CAR des Card.CA-Zertifikats angege­
ben ist.
— Das in der Abbildung erwähnte Card.Link-Zertifikat ist
das Linkzertifikat der Karte, sofern vorhanden. Wie in
Abschnitt 9.1.2 angegeben, handelt es sich hierbei um
ein Linkzertifikat für ein neues europäisches
Wurzel-Schlüsselpaar, das durch die ERCA erstellt und
mithilfe des zuvor erwähnten europäischen privaten
Schlüssels signiert wird.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 473
— Bei dem Card.Link.EUR-Zertifikat handelt es sich um
das europäische Wurzelzertifikat, das in der CAR des
Card.Link-Zertifikats angegeben ist.
CSM_158 Wie in Abbildung 4 dargestellt, beginnt beim Einsetzen der
Karte die Verifizierung ihrer Zertifikatkette. Die Fahrzeug­
einheit liest aus der EF-ECC die Kennung des Karteninha­
bers ( ) aus. Die VU
muss überprüfen, ob sie die Karte kennt — ob sie also in
der Vergangenheit die Zertifikatkette der Karte erfolgreich
überprüft und zur späteren Referenz abgelegt hat. Wenn dies
der Fall und das Zertifikat der Karte weiterhin gültig ist,
wird nun die Zertifikatkette der VU verifiziert. Andernfalls
muss die VU das MSCA_Card-Zertifikat zur Verifizierung
des Kartenzertifikats, das Card.CA.EUR-Zertifikat zur Veri­
fizierung des MSCA_Card-Zertifikats und eventuell das
Linkzertifikat nacheinander aus der Karte auslesen, bis sie
auf ein bekanntes Zertifikat stößt. Wenn sie ein solches
Zertifikat findet, verifiziert die VU mit diesem die zugrunde
liegenden Kartenzertifikate, die sie der Karte entnommen
hat. Wenn diese Überprüfung erfolgreich verläuft, wird
nun die Zertifikatkette der VU verifiziert. Andernfalls igno­
riert die VU die Karte.
Hinweis: Der VU kann das Card.CA.EUR-Zertifikat auf drei
Arten bekannt sein:
— es handelt sich um das gleiche Zertifikat wie das
EUR-Zertifikat der VU selbst;
— das Card.EUR-Zertifikat ist ein Vorgänger des
EUR-Zertifikats der VU und die VU enthielt dieses Zer­
tifikat bereits ab Ausgabe (siehe CSM_81);
— das Card.CA.EUR-Zertifikat ist ein Nachfolger des
EUR-Zertifikat der VU und die VU hat in der Vergan­
genheit von einer anderen Fahrtenschreiberkarte ein
Linkzertifikat erhalten, verifiziert und zur zukünftigen
Referenz abgespeichert.
CSM_159 Wie in Abbildung 4 angegeben, kann die VU, sobald sie die
Authentizität und Gültigkeit eines zuvor unbekannten Zerti­
fikats überprüft hat, dieses Zertifikat zur zukünftigen Refe­
renz abspeichern. Sie braucht dann die Authentizität dieses
Zertifikats nicht ein weiteres Mal zu prüfen, wenn es ihr
erneut vorgelegt wird. Die VU braucht nicht das gesamte
Zertifikat zu speichern, sondern lediglich den Inhalt des
Zertifikatkörpers (siehe Abschnitt 9.3.2). ►M1 Während
die Speicherung aller anderen Arten von Zertifikaten optio­
nal ist, muss ein von einer Karte vorgelegtes neues Linkzer­
tifikat von der VU gespeichert werden. ◄
CSM_160 Die VU überprüft die temporäre Gültigkeit aller Zertifikate,
die sie aus der Karte ausliest oder gespeichert hat, und lehnt
abgelaufene Zertifikate ab. Die VU überprüft die temporäre
Gültigkeit eines von einer Karte vorgelegten Zertifikats mit­
hilfe ihrer Systemuhr.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 474
Abbildung 4
Protokoll zur Verifizierung der Kartenzertifikatkette durch die VU
10.2.2 Verifizierung der VU-Zertifikatkette durch die Karte
CSM_161 ►M1 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.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 475
— 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). ◄
Abbildung 5
Protokoll zur Verifizierung der VU-Zertifikatkette durch Card
Hinweise zu Abbildung 5:
— Bei den in der Abbildung erwähnten VU-Zertifikaten und öffent­
lichen Schlüsseln handelt es sich um diejenigen zur gegenseitigen
Authentisierung. In Abschnitt 9.1.4 werden sie als VU_MA
bezeichnet.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 476
— Bei den in der Abbildung erwähnten VU.CA-Zertifikaten und öffent­
lichen Schlüsseln handelt es sich um diejenigen zur Signierung der
Zertifikate von VU und externer GNSS-Ausrüstung. In Abschnitt
9.1.3 werden sie als MSCA_VU-EGF bezeichnet.
— Bei dem in der Abbildung erwähnten VU.CA.EUR-Zertifikat handelt
es sich um das europäische Wurzelzertifikat, das in der CAR des
VU.CA-Zertifikats angegeben ist.
— Das in der Abbildung erwähnte VU.Link-Zertifikat ist das Linkzerti­
fikat der VU, sofern vorhanden. Wie in Abschnitt 9.1.2 angegeben,
handelt es sich hierbei um ein Linkzertifikat für ein neues europäi­
sches Wurzel-Schlüsselpaar, das durch die ERCA erstellt und mithilfe
des zuvor erwähnten europäischen privaten Schlüssels signiert wird.
— Bei dem VU.Link.EUR-Zertifikat handelt es sich um das europäische
Wurzelzertifikat, das in der CAR des VU.Link-Zertifikats angegeben ist.
CSM_162 Wie in Abbildung 5 dargestellt, versucht die Fahrzeugein­
heit bei der Verifizierung der Zertifikatkette der Fahrzeug­
einheit zunächst, ihren eigenen öffentlichen Schlüssel zur
Verwendung in der Fahrtenschreiberkarte anzugeben.
Wenn dies erfolgreich verläuft, bedeutet dies, dass die Karte
zu einem früheren Zeitpunkt die Zertifikatkette der VU er­
folgreich verifiziert und das VU-Zertifikat zur späteren Re­
ferenz abgelegt hat. In einem solchen Fall wird das
VU-Zertifikat verwendet, und es schließt sich die
VU-Authentisierung an. Wenn der Karte das VU-Zertifikat
nicht bekannt ist, präsentiert die VU nacheinander das
VU.CA-Zertifikat zur Verifizierung ihres VU-Zertifikats,
das VU.CA.EUR-Zertifikat zur Verifizierung ihres
VU.CA-Zertifikats und eventuell das Linkzertifikat, um fest­
zustellen, ob die Karte eines dieser Zertifikate kennt oder
verifizieren kann. Wenn sie ein solches Zertifikat findet,
verifiziert die Karte mit diesem die ihr präsentierten zu­
grunde liegenden VU-Zertifikate. Im Erfolgsfall legt die
VU schließlich ihren öffentlichen Schlüssel zur Verwen­
dung in der Fahrtenschreiberkarte fest. Andernfalls ignoriert
die VU die Karte.
Hinweis: Der VU kann das VU.CA.EUR-Zertifikat auf drei
Arten bekannt sein:
— es handelt sich um das gleiche Zertifikat wie das
EUR-Zertifikat der Karte selbst;
— das VU.CA.EUR-Zertifikat ist ein Vorgänger des
EUR-Zertifikats der Karte und die Karte enthielt dieses
Zertifikat bereits ab Ausgabe (siehe CSM_91);
— das VU.CA.EUR-Zertifikat ist ein Nachfolger des
EUR-Zertifikat der Karte und die Karte hat in der Ver­
gangenheit von einer anderen Fahrzeugeinheit ein Link­
zertifikat erhalten, verifiziert und zur zukünftigen Refe­
renz abgespeichert.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 477
CSM_163 Die VU legt mithilfe des Befehls MSE: Set AT ihren öffent­
lichen Schlüssel zur Verwendung in der Fahrtenschreiber­
karte fest. Wie in Anlage 2 erläutert, gibt dieser Befehl das
kryptografische Verfahren an, das zusammen mit dem fest­
gelegten Schlüssel verwendet wird. Hierbei handelt es sich
um eine VU-Authentisierung unter Verwendung des
ECDSA-Algorithmus in Kombination mit dem Hash-Algo­
rithmus, der an die Schlüsselgröße des VU_MA-Schlüssel­
paars der VU gebunden ist (siehe CSM_50).
CSM_164 Der Befehl MSE: Set AT beinhaltet zudem die Angabe des
flüchtigen Schlüsselpaars, das die VU während der Verein­
barung des Sitzungsschlüssels verwendet (siehe Abschnitt
10.4). Vor dem Senden des Befehls MSE: Set AT generiert
die VU deshalb ein flüchtiges ECC-Schlüsselpaar. Zur Ge­
nerierung des flüchtigen Schlüsselpaars verwendet die VU
die im Kartenzertifikat angegebenen standardisierten Domä­
nenparameter. Das flüchtige Schlüsselpaar wird dargestellt
als (VU.SK eph , VU.PK eph , Card.DP). Die VU wählt die
x-Koordinate des flüchtigen öffentlichen Punkts des
ECDH-Verfahrens als Schlüsselkennung; dies ist eine kom­
primierte Darstellung des öffentlichen Schlüssels und wird
in der Form Comp(VU.PK eph ) dargestellt.
▼M1
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 Ver­
einbarung des Sitzungsschlüssels zwei oder mehr erfolgrei­
che Befehle „MSE: Set AT“ gesendet werden, speichert die
Karte lediglich den letzten erhaltenen Comp(VU.PKeph).
Nach einem erfolgreichen Befehl GENERAL AUTHENTI­
CATE setzt die Karte Comp(VU.PKeph) zurück.
▼B
CSM_166 Die Karte überprüft die temporäre Gültigkeit aller von der
VU präsentierten oder von der VU als Referenz verwende­
ten Zertifikate, die im Speicher der Karte abgelegt sind, und
lehnt abgelaufene Zertifikate ab.
CSM_167 Um die temporäre Gültigkeit eines von der VU präsentierten
Zertifikats zu überprüfen, speichert jede Fahrtenschreiber­
karte intern gewisse Daten, die den aktuellen Zeitpunkt dar­
stellen. Diese Daten dürfen von einer VU nicht direkt ak­
tualisiert werden können. Im Moment der Ausgabe wird die
aktuelle Uhrzeit einer Karte auf das Effective Date des
Card_MA-Zertifikats der Karte gesetzt. Eine Karte darf
dann ihre aktuelle Uhrzeit aktualisieren, wenn das Effective
Date eines authentischen, von einer VU präsentierten Zerti­
fikats einer „gültigen Zeitquelle“ jünger ist als die aktuelle
Uhrzeit der Karte. In diesem Fall setzt die Karte ihre ak­
tuelle Uhrzeit auf das Effective Date dieses Zertifikats. Die
Karte darf nur die folgenden Zertifikate als gültige Zeit­
quelle akzeptieren:
— ERCA-Linkzertifikate der 2. Generation
— MSCA-Zertifikate der 2. Generation
— VU-Zertifikate der 2. Generation, die vom selben Land
ausgestellt sind wie das bzw. die Kartenzertifikat(e) der
Karte selbst.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 478
Hinweis: Die letzte Anforderung impliziert, dass eine Karte
die CAR des VU-Zertifikats, d. h. das MSCA_VU-EGF-
Zertifikat, erkennen muss. Diese ist mit der CAR ihres ei­
genen Zertifikats, dem MSCA_Card-Zertifikat, nicht
identisch.
CSM_168 Wie in Abbildung 5 angegeben, kann die Karte, sobald sie
die Authentizität und Gültigkeit eines zuvor unbekannten
Zertifikats überprüft hat, dieses Zertifikat zur zukünftigen
Referenz abspeichern. Sie braucht dann die Authentizität
dieses Zertifikats nicht ein weiteres Mal zu prüfen, wenn
es ihr erneut vorgelegt wird. Die Karte braucht nicht das
gesamte Zertifikat zu speichern, sondern lediglich den Inhalt
des Zertifikatkörpers (siehe Abschnitt 9.3.2).
10.3. VU-Authentisierung
CSM_169 Fahrzeugeinheiten und Karten verwenden zur Authentisie­
rung der VU gegenüber der Karte das VU-Authentisierungs­
protokoll Abbildung 6. Durch die VU-Authentisierung kann
die Fahrtenschreiberkarte explizit verifizieren, dass die VU
authentisch ist. Dazu verwendet die VU ihren privaten
Schlüssel, um eine von der Karte erzeugte Zufallszahl zu
signieren.
CSM_170 ►M1 Neben der Zufallszahl enthält die Signatur der VU
die dem Kartenzertifikat entnommene Kennung des
Zertifikatinhabers. ◄
Hinweis: Dadurch lässt sich sicherstellen, dass es sich bei
der Karte, gegenüber der die VU sich authentisiert, um
dieselbe Karte handelt, deren Zertifikatkette die VU zuvor
verifiziert hat.
CSM_171 Außerdem nimmt die VU in die Signatur die Kennung des
flüchtigen öffentlichen Schlüssels Comp(VU.PK eph ) auf, mit
dem die VU während der Chip-Authentisierung das Secure
Messaging konfiguriert (siehe Abschnitt 10.4).
Hinweis: Dadurch wird sichergestellt, dass es sich bei der
VU, mit der die Karte während einer Secure-Messaging-Sit­
zung kommuniziert, um die von der Karte authentisierte VU
handelt.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 479
Abbildung 6
VU-Authentisierungsprotokoll
▼B
CSM_172 Wenn die VU während der VU-Authentisierung mehrere
Befehle GET CHALLENGE sendet, gibt die Karte jedes
Mal einen neue 8-Byte-Zufallszahl zurück, speichert aber
nur die letzte Zufallszahl.
CSM_173 Die VU verwendet zur VU-Authentisierung den Signatural­
gorithmus ECDSA gemäß DSS; dabei wird der an die
Schlüsselgröße des VU_MA-Schlüsselpaars der VU gebun­
dene Hash-Algorithmus verwendet (siehe CSM_50). Das
Signaturformat ist Klartext, wie in TR-03111 angegeben.
Die VU sendet die resultierende Signatur an die Karte.
▼M1
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 r card der Kartenzufallszahl und die Ken­
nung des flüchtigen öffentlichen Schlüssels der VU,
Comp(VU.PK eph ), 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 Authentisierungs­
token.
▼M1
02016R0799 — DE — 21.08.2023 — 003.002 — 480
10.4. Chip-Authentisierung und Vereinbarung des Sitzungsschlüssels
CSM_175 Fahrzeugeinheiten und Karten verwenden zur Authentisie­
rung der Karte gegenüber der VU das Chip-Authentisie­
rungsprotokoll Abbildung 7. Durch die Chip-Authentisie­
rung kann die Fahrzeugeinheit explizit verifizieren, dass die
Karte authentisch ist.
Abbildung 7
Chip-Authentisierung und Vereinbarung des Sitzungsschlüssels
CSM_176 VU und Karte gehen wie folgt vor:
1. Die Fahrzeugeinheit leitet die Chip-Authentisierung
durch Senden des Befehls MSE: Set AT ein. Dieser zeigt
eine Chip-Authentisierung unter Verwendung des
ECDH-Algorithmus an; die Länge des AES-Sitzungs­
schlüssels ist an die Schlüsselgröße des Card_MA-
Schlüsselpaars der Karte gebunden (siehe CSM_50).
Die VU ermittelt aus dem Kartenzertifikat die Schlüssel­
größe des Schlüsselpaars der Karte.
▼M1
2. Die VU sendet den öffentlichen Punkt VU.PK eph ihres
flüchtigen Schlüsselpaars an die Karte. Der öffentliche
Punkt ist gemäß TR-03111 in einen Oktettstring um­
zuwandeln. Dabei ist das unkomprimierte Verschlüsse­
lungsformat 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.PK eph ) an die Karte, die diese Ken­
nung speicherte.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 481
3. Die Karte berechnet nun Comp(VU.PK eph ) anhand von
VU.PK eph und vergleicht diesen mit dem gespeicherten
Wert von Comp(VU.PK eph ).
4. Mithilfe des ECDH-Algorithmus in Kombination mit
dem statischen privaten Schlüssel der Karte und dem
flüchtigen öffentlichen Schlüssel der VU berechnet die
Karte einen geheimen Wert K.
5. Die Karte wählt eine zufällige 8-Byte-Nonce N PICC und
leitet mit dieser zwei AES-Sitzungsschlüssel K MAC und
K ENC von K ab. Siehe CSM_179.
▼M1
6. Mithilfe von K MAC berechnet die Karte anhand der Ken­
nung des flüchtigen öffentlichen Punkts der VU einen
Authentisierungstoken: T PICC = CMAC(K MAC ,
VU.PK eph ). Der öffentliche Punkt muss das von der
VU verwendete Format haben (siehe Nummer 2 oben).
Die Karte übermittelt N PICC und T PICC an die Fahrzeug­
einheit.
▼B
7. Mithilfe des ECDH-Algorithmus in Kombination mit
dem statischen privaten Schlüssel der Karte und dem
flüchtigen privaten Schlüssel der VU berechnet die VU
den geheimen Wert K auf die gleiche Weise, wie die
Karte dies in Schritt 4 durchführte.
8. Die VU leitet die Sitzungsschlüssel K MAC und K ENC
von K und N PICC ab, siehe CSM_179.
9. Die VU verifiziert den Authentisierungstoken T PICC .
CSM_177 In Schritt 3 oben berechnet die Karte Comp(VU.PKeph) als
x-Koordinate des öffentlichen Punkts in VU.PKeph.
CSM_178 In den Schritten 4 und 7 oben verwenden Karte und Fahr­
zeugeinheit den ECKA-EG Algorithmus gemäß TR-03111.
CSM_179 In den Schritten 5 und 8 oben verwenden Karte und Fahr­
zeugeinheit die Schlüsselableitungsfunktion für AES-Sit­
zungsschlüssel gemäß TR-03111, mit den folgenden Präzi­
sierungen und Änderungen:
— Der Zählerwert beträgt „00 00 00 01“ für K ENC und „00
00 00 02“ für K MAC.
— Es wird die optionale Nonce r verwendet, die mit N PICC
identisch ist.
— Zum Ableiten von 128-Bits-AES-Schlüsseln ist der
Hash-Algorithmus SHA-256 zu verwenden.
— Zum Ableiten von 192-Bits-AES-Schlüsseln ist der
Hash-Algorithmus SHA-384 zu verwenden.
— Zum Ableiten von 256-Bits-AES-Schlüsseln ist der
Hash-Algorithmus SHA-512 zu verwenden.
Die Länge des Sitzungsschlüssels (d. h. die Länge, nach der
der Hash abgeschnitten wird) ist an die Größe des
Card_MA-Schlüsselpaars zu binden, siehe CSM_50.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 482
CSM_180 In den Schritten 6 und 9 oben verwenden Karte und Fahr­
zeugeinheit den AES-Algorithmus im CMAC-Modus, wie
in SP 800-38B festgelegt. Die Länge von T PICC ist an die
Länge des AES-Sitzungsschlüssels gemäß CSM_50 zu
binden.
10.5. Secure Messaging
10.5.1 Allgemein
CSM_181 Alle zwischen Fahrzeugeinheit und Fahrtenschreiberkarte im
Anschluss an eine erfolgreiche Chip-Authentisierung bis
zum Sitzungsende ausgetauschten Befehle und Antworten
sind durch den Secure-Messaging-Modus zu schützen.
CSM_182 Außer beim Lesen aus einer Datei mit Zugriffsbedingung
SM-R-ENC-MAC-G2 (siehe Anlage 2 Abschnitt 4) muss
das Secure Messaging im reinen Authentisierungsmodus
stattfinden. In diesem Modus werden sämtliche Befehle
und Antworten um eine kryptografische Prüfsumme (MAC)
ergänzt, um die Authentizität und Integrität der Nachricht zu
gewährleisten.
CSM_183 Beim Lesen von Daten aus einer Datei mit Zugriffsbedin­
gung SM-R-ENC-MAC-G2 ist Secure Messaging im Modus
Verschlüsseln-dann-Authentisieren zu verwenden. Das be­
deutet, dass die Antwort zunächst verschlüsselt wird, um
die Vertraulichkeit der Nachricht zu gewährleisten. An­
schließend wird anhand der formatierten verschlüsselten Da­
ten ein MAC berechnet, um Authentizität und Integrität
sicherzustellen.
CSM_184 Beim Secure Messaging muss AES gemäß Definition im
Referenzdokument AES mit den während der Chip-Authen­
tisierung vereinbarten Sitzungsschlüsseln K MAC und K ENC
verwendet werden.
CSM_185 Als Sendesequenzzähler (Send Sequence Counter, SSC) ist
eine unsignierte Ganzzahl zu verwenden, um Replay-An­
griffe zu verhindern. Die Größe des SSC muss mit derjeni­
gen des AES-Blocks übereinstimmen, d. h. 128 Bits. Der
SSC muss im Format MSB-first vorliegen. Beim Start von
Secure Messaging ist der SSC auf null zu setzen (d. h. „00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00“). Der SSC
ist jedes Mal hochzusetzen, bevor eine Befehls- oder
Antwort-APDU generiert wird: Da der SSC-Anfangswert
in einer SM-Sitzung 0 beträgt, wird er im ersten Befehl
auf 1 gesetzt. Der SSC-Wert der ersten Antwort lautet 2.
CSM_186 Zur Nachrichtenverschlüsselung ist K ENC mit AES im
CBC-Modus (Cipher Block Chaining) gemäß ISO 10116
zu verwenden, mit einem Verschachtelungsparameter m =
1 und einem Initialisierungsvektor SV = E(K ENC , SSC), d.
h. dem aktuellen SSC verschlüsselt mit K ENC .
CSM_187 Zur Nachrichtenauthentisierung ist K MAC mit AES in
CMAC-Modus gemäß SP 800-38B zu verwenden. Die
Länge des MAC ist an die Länge des AES-Sitzungsschlüs­
sels gemäß CSM_50 zu binden. Der SSC ist im MAC vor
dem zu authentisierenden Datenpaket einzufügen.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 483
10.5.2 Secure-Message-Struktur
CSM_188 Beim Secure Messaging dürfen nur die in Tabelle 5 auf­
geführten Secure-Messaging-Datenobjekte (siehe ISO 7816-
4) verwendet werden. In allen Nachrichten sind diese Da­
tenobjekte in der in dieser Tabelle angegebenen Reihenfolge
zu verwenden.
Tabelle 5
Secure-Messaging-Datenobjekte
Datenobjektname Tag
Vorgeschrieben (V), an
Bedingungen geknüpft (B)
oder untersagt (U) in
Befehlen Antworten
Klarwert, nicht in BER-TLV kodiert „81“ B B
Klarwert, in BER-TLV kodiert, jedoch
ohne SM DO
„B3“ B B
Padding Indicator, gefolgt von Krypto­
gramm, Klarwert nicht in BER-TLV
kodiert
„87“ B B
Geschütztes Le „97“ B U
Verarbeitungsstatus „99“ U V
Kryptografische Prüfsumme (CC) „8E“ V V
Hinweis: Wie in Anlage 2 angegeben, können Fahrten­
schreiberkarten die Befehle READ BINARY und UPDATE
BINARY mit ungeradem INS-Byte („B1“ bzw. „D7“) un­
terstützen. Die Befehlsvarianten sind erforderlich, um Da­
teien mit 32 768 Bytes oder mehr zu lesen und zu aktuali­
sieren. Falls eine Variante verwendet wird, ist anstelle eines
Objekts mit Tag „81“ ein Datenobjekt mit Tag „B3“ zu
verwenden. Weitere Informationen siehe Anlage 2.
CSM_189 Alle SM-Datenobjekte sind gemäß ISO 8825-1 in DER
TLV zu kodieren. Diese Kodierung bewirkt folgende
TLV-Struktur (Tag-Length-Value, Tag-Längen-Wert):
Tag: Der Tag ist in ein oder zwei Oktette verschlüsselt
und gibt den Inhalt an.
Länge: Die Länge ist als unsignierte Ganzzahl in ein,
zwei oder drei Oktette verschlüsselt, was zu einer
Länge von maximal 65 535 Oktetten führt. Es ist
die Mindestzahl an Oktetten zu verwenden.
Wert: Der Wert ist in null oder mehr Oktette verschlüs­
selt.
CSM_190 Durch Secure Messaging geschützte APDU sind wie folgt
zu erstellen:
— Der Befehlskopf ist in der MAC-Berechnung zu berück­
sichtigen, deshalb ist für das Klassenbyte CLA der Wert
„0C“ zu verwenden.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 484
— Wie in Anlage 2 angegeben, müssen sämtliche
INS-Bytes gerade sein, mit der möglichen Ausnahme
ungerader INS-Bytes für die Befehle READ BINARY
und UPDATE BINARY.
— Der tatsächliche Wert von Lc wird nach Anwendung
von Secure Messaging in Lc' geändert.
— Das Datenfeld muss aus SM-Datenobjekten bestehen.
— Im geschützten APDU-Befehl ist das neue Le-Byte auf
„00“ zu setzen. Gegebenenfalls ist ein Datenobjekt „97“
in das Datenfeld aufzunehmen, um den Originalwert von
Le zu übertragen.
▼M1
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 fol­
gende 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.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 485
Im Folgenden sind drei APDU-Transformationen für Befehle mit gera­
dem INS-Code beispielhaft aufgeführt. Abbildung 8 zeigt einen authen­
tisierten 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üs­
selte 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
▼M1
02016R0799 — DE — 21.08.2023 — 003.002 — 486
Abbildung 10
Transformation einer verschlüsselten und authentisierten
▼B
10.5.3 Abbruch einer Secure-Messaging-Sitzung
CSM_192 Eine Fahrzeugeinheit muss eine laufende Secure-Messaging-
Sitzung abbrechen, wenn (und nur wenn) eine der folgenden
Bedingungen eintritt:
— Sie erhält eine APDU-Antwort in Klartext.
— Sie entdeckt in einer APDU-Antwort einen Secure-Mes­
saging-Fehler:
— Ein erwartetes Secure-Messaging-Datenobjekt fehlt,
die Reihenfolge der Datenobjekte ist falsch, oder ein
unbekanntes Datenobjekt ist vorhanden.
— Ein Secure-Messaging-Datenobjekt ist falsch, z. B. der
MAC-Wert ist falsch, die TLV-Struktur ist fehlerhaft,
oder der Padding Indicator in Tag „87“ ist nicht gleich
„01“.
— Die Karte sendet ein Statusbyte, laut dem sie einen
SM-Fehler entdeckt hat (siehe CSM_194).
— 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 VU von ihrem
Hersteller festgelegt, der dabei die Sicherheitsanforderun­
gen der verwendeten Hardware berücksichtigt; der
Höchstwert beträgt 240 SM-Befehle und zugehörige Ant­
worten pro Sitzung.
▼M1
02016R0799 — DE — 21.08.2023 — 003.002 — 487
CSM_193 Eine Fahrtenschreiberkarte muss eine laufende Secure-Messa­
ging-Sitzung abbrechen, wenn (und nur wenn) eine der fol­
genden Bedingungen eintritt:
— Sie erhält einen APDU-Befehl in Klartext.
— Sie entdeckt in einem APDU-Befehl einen Secure-Messa­
ging-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, bei­
spielsweise 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 Sicherheitsanfor­
derungen der verwendeten Hardware berücksichtigt; der
Höchstwert beträgt 240 SM-Befehle und zugehörige Ant­
worten pro Sitzung.
▼B
CSM_194 SM-Fehlerbehandlung durch eine Fahrtenschreiberkarte:
— Wenn in einem APDU-Befehl erwartete Secure-Messa­
ging-Datenobjekte fehlen, die Reihenfolge der Daten­
objekte falsch ist oder unbekannte Datenobjekte vorhan­
den sind, antwortet die Fahrtenschreiberkarte mit den Sta­
tusbytes „69 87“.
— Wenn ein Secure-Messaging-Datenobjekt in einem
APDU-Befehl falsch ist, antwortet die Fahrtenschreiber­
karte mit Statusbytes „69 88“.
In einem solchen Fall werden die Statusbytes ohne SM zu­
rückgesendet.
CSM_195 Wenn eine Secure-Messaging-Sitzung zwischen VU und
Fahrtenschreiberkarte abgebrochen wird, führen VU und
Fahrtenschreiberkarte Folgendes durch:
— Sie zerstören die gespeicherten Sitzungsschlüssel auf si­
chere Weise.
— Sie leiten sofort eine neue Secure-Messaging-Sitzung ein,
wie in den Abschnitten 10.2 — 10.5 beschrieben.
CSM_196 Wenn die VU aus beliebigem Grund entscheidet, die gegen­
seitige Authentisierung mit einer eingesetzten Karte neu zu
starten, beginnt der Prozess mit der Verifizierung der Zertifi­
katkette der Karte (siehe Abschnitt 10.2) und geht dann ge­
mäß den Abschnitten 10.2 — 10.5 weiter.
▼M1
02016R0799 — DE — 21.08.2023 — 003.002 — 488
11. VU UND EXTERNE GNSS-AUSRÜSTUNG: KOPPELUNG, GEGEN­
SEITIGE AUTHENTISIERUNG UND SECURE MESSAGING
11.1. Allgemein
CSM_197 Bei der von einer VU zur Ermittlung ihrer Position genutzten
GNSS-Ausrüstung kann es sich um ein internes (d. h. in das
VU-Gehäuse fest integriertes) oder externes Modul handeln.
Im ersten Fall ist es nicht nötig, die interne Kommunikation
zwischen GNSS-Ausrüstung und VU zu standardisieren; die
Anforderungen dieses Kapitels gelten deshalb nicht. Im zwei­
ten Fall muss die Kommunikation zwischen VU und externer
GNSS-Ausrüstung nach den Beschreibungen in diesem Kapi­
tel standardisiert und geschützt werden.
CSM_198 Die sichere Kommunikation zwischen Fahrzeugeinheit und
externer GNSS-Ausrüstung erfolgt genauso wie die sichere
Kommunikation zwischen Fahrzeugeinheit und Fahrtenschrei­
berkarte, wobei die externe GNSS-Ausrüstung (EGF) die
Rolle der Karte einnimmt. Die externe GNSS-Ausrüstung
muss alle in Kapitel 10 für Fahrtenschreiberkarten erwähnten
Anforderungen erfüllen, wobei die in diesem Kapitel genann­
ten Abweichungen, Klärungen und Ergänzungen zu berück­
sichtigen sind. Insbesondere müssen gegenseitige Verifizie­
rung der Zertifikatkette, VU-Authentisierung und Chip-Au­
thentisierung gemäß den Abschnitten 11.3 und 11.4 erfolgen.
CSM_199 Die Kommunikation zwischen Fahrzeugeinheit und EGF un­
terscheidet sich von der Kommunikation zwischen Fahrzeug­
einheit und Karte insofern, als Fahrzeugeinheit und EGF ein­
mal in einer Werkstatt gekoppelt werden müssen, damit VU
und EGF im Normalbetrieb GNSS-basierte Daten austauschen
können. Die Koppelung wird in Abschnitt 11.2 beschrieben.
CSM_200 Zur Kommunikation zwischen Fahrzeugeinheit und EGF sind
APDU-Befehle und -Antworten gemäß ISO 7816-4 und ISO
7816-8 zu verwenden. Die genaue Struktur dieser APDU ist
in Anlage 2 dieses Anhangs festgelegt.
11.2. Koppelung von VU und externer GNSS-Ausrüstung
CSM_201 Fahrzeugeinheit und EGF in einem Fahrzeug müssen durch
eine Werkstatt gekoppelt werden. Nur gekoppelte Fahrzeug­
einheiten und EGF dürfen im Normalbetrieb kommunizieren.
CSM_202 Die Koppelung von Fahrzeugeinheit und EGF darf nur mög­
lich sein, wenn sich die Fahrzeugeinheit im Kalibrierungs­
modus befindet. Die Koppelung ist durch die Fahrzeugeinheit
einzuleiten.
CSM_203 Eine Werkstatt kann eine Fahrzeugeinheit jederzeit mit einer
anderen oder derselben EGF neu koppeln. Während der Neu­
koppelung muss die VU das in ihrem Speicher vorhandene
EGF_MA-Zertifikat auf sichere Weise zerstören und das
EGF_MA-Zertifikat der EGF, mit der sie gekoppelt wird,
im Speicher ablegen.
CSM_204 Eine Werkstatt kann eine externe GNSS-Ausrüstung jederzeit
mit einer anderen oder derselben VU neu koppeln. Während
der Neukoppelung muss die EGF das in ihrem Speicher vor­
handene VU_MA-Zertifikat auf sichere Weise zerstören und
das VU_MA-Zertifikat der VU, mit der sie gekoppelt wird,
im Speicher ablegen.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 489
11.3. Gegenseitige Verifizierung der Zertifikatkette
11.3.1 Allgemein
CSM_205 Die gegenseitige Verifizierung der Zertifikatkette zwischen
VU und EGF kann nur während der Koppelung von VU
und EGF durch eine Werkstatt erfolgen. Im Normalbetrieb
gekoppelter VU und EGF werden keine Zertifikate verifiziert.
Stattdessen vertrauen VU und EGF den während der Koppe­
lung gespeicherten Zertifikaten, überprüfen allerdings deren
temporäre Gültigkeit. Um im Normalbetrieb die Kommunika­
tion zwischen VU und EGF zu schützen, vertrauen VU und
EGF lediglich diesen Zertifikaten.
11.3.2 Während der Koppelung VU-EGF
CSM_206 Während der Koppelung an eine EGF verwendet die Fahr­
zeugeinheit das in Abbildung 4 (Abschnitt 10.2.1) dargestellte
Protokoll, um die Zertifikatkette der externen GNSS-Ausrüs­
tung zu verifizieren.
Hinweise zu Abbildung 4 in diesem Kontext:
— Die Kommunikationskontrolle ist nicht Gegenstand dieser
Anlage. Allerdings handelt es sich bei einer EGF nicht um
eine Chipkarte, weshalb die VU vermutlich kein Reset
zum Einleiten der Kommunikation senden und kein
ATR erhalten wird.
— Die in der Abbildung genannten Zertifikate und öffent­
lichen Schlüssel der Karte sind als Zertifikate und öffent­
lichen Schlüssel der EGF zur gegenseitigen Authentisie­
rung zu verstehen. In Abschnitt 9.1.6 werden sie als
EGF_MA bezeichnet.
— Die in der Abbildung genannten Card.CA-Zertifikate und
öffentlichen Schlüssel sind als Zertifikate und öffentlichen
Schlüssel der MSCA zum Signieren der EGF-Zertifikate
zu verstehen. In Abschnitt 9.1.3 werden sie als
MSCA_VU-EGF bezeichnet.
— Das in der Abbildung erwähnte Card.CA.EUR-Zertifikat
ist als das europäische Wurzelzertifikat zu verstehen, das
in der CAR des MSCA-VU-EGF-Zertifikats angegeben
ist.
— Das in der Abbildung erwähnte Card.Link-Zertifikat ist
als das Linkzertifikat der EGF zu verstehen, sofern vor­
handen. Wie in Abschnitt 9.1.2 angegeben, handelt es sich
hierbei um ein Linkzertifikat für ein neues europäisches
Wurzel-Schlüsselpaar, das durch die ERCA erstellt und
mithilfe des zuvor erwähnten europäischen privaten
Schlüssels signiert wird.
— Bei dem Card.Link.EUR-Zertifikat handelt es sich um das
europäische Wurzelzertifikat, das in der CAR des
Card.Link-Zertifikats angegeben ist.
— Anstelle der liest die
VU die aus der EF-ICC.
— Die VU wählt nicht die Fahrtenschreiber-AID, sondern
die EGF-AID.
— „Karte ignorieren“ ist als „EGF ignorieren“ zu verstehen.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 490
CSM_207 Wenn die Fahrzeugeinheit das EGF_MA-Zertifikat verifiziert
hat, speichert sie es zur Verwendung im Normalbetrieb; siehe
Abschnitt 11.3.3.
CSM_208 ►M1 Während der Koppelung an eine VU verwendet die
externe GNSS-Ausrüstung das in Abbildung 5 (Ab­
schnitt 10.2.2) dargestellte Protokoll, um die Zertifikatkette
der VU zu verifizieren. ◄
Hinweise zu Abbildung 5 in diesem Kontext:
— Die VU generiert mithilfe der Domänenparameter im
EGF-Zertifikat ein neues flüchtiges Schlüsselpaar.
— Bei den in der Abbildung erwähnten VU-Zertifikaten und
öffentlichen Schlüsseln handelt es sich um diejenigen zur
gegenseitigen Authentisierung. In Abschnitt 9.1.4 werden
sie als VU_MA bezeichnet.
— Bei den in der Abbildung erwähnten VU.CA-Zertifikaten
und öffentlichen Schlüsseln handelt es sich um diejenigen
zur Signierung der Zertifikate von VU und externer
GNSS-Ausrüstung. In Abschnitt 9.1.3 werden sie als
MSCA_VU-EGF bezeichnet.
— Bei dem in der Abbildung erwähnten VU.CA.EUR-Zerti­
fikat handelt es sich um das europäische Wurzelzertifikat,
das in der CAR des VU.CA-Zertifikats angegeben ist.
— Das in der Abbildung erwähnte VU.Link-Zertifikat ist das
Linkzertifikat der VU, sofern vorhanden. Wie in Ab­
schnitt 9.1.2 angegeben, handelt es sich hierbei um ein
Linkzertifikat für ein neues europäisches Wurzel-Schlüs­
selpaar, das durch die ERCA erstellt und mithilfe des
zuvor erwähnten europäischen privaten Schlüssels signiert
wird.
— Bei dem VU.Link.EUR-Zertifikat handelt es sich um das
europäische Wurzelzertifikat, das in der CAR des
VU.Link-Zertifikats angegeben ist.
CSM_209 In Abweichung von Anforderung CSM_167 verwendet eine
EGF die GNSS-Zeit, um die temporäre Gültigkeit präsentier­
ter Zertifikate zu überprüfen.
▼M1
CSM_210 Wenn die externe GNSS-Ausrüstung das VU_MA-Zertifikat
verifiziert hat, speichert sie es zur Verwendung im Normal­
betrieb; siehe Abschnitt 11.3.3.
▼B
11.3.3 Im Normalbetrieb
CSM_211 ►M1 Im Normalbetrieb verwenden Fahrzeugeinheit und
EGF das in Abbildung 11 dargestellte Protokoll, um die tem­
porä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 Normal­
betrieb findet keine weitere gegenseitige Verifizierung der
Zertifikatketten statt. ◄
Hinweis: Abbildung 11 besteht im Wesentlichen aus den ers­
ten in Abbildung 4 und Abbildung 5 dargestellten Schritten.
Wie bereits erwähnt, handelt es sich bei einer EGF nicht um
eine Chipkarte, weshalb die VU vermutlich kein Reset zum
Einleiten der Kommunikation senden und kein ATR erhalten
wird. Dies ist nicht Gegenstand dieser Anlage.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 491
Abbildung 11
Gegenseitige Verifizierung der temporären Gültigkeit von Zertifikaten im normalen VU-EGF-Betrieb
CSM_212 Wie in Abbildung 11 dargestellt, meldet die Fahrzeugeinheit
einen Fehler, wenn das EGF_MA-Zertifikat nicht mehr gültig
ist. Allerdings erfolgen gegenseitige Authentisierung, Schlüs­
selvereinbarung und anschließende Kommunikation per Se­
cure Messaging normal.
11.4. VU-Authentisierung, Chip-Authentisierung und Vereinbarung des
Sitzungsschlüssels
CSM_213 VU-Authentisierung, Chip-Authentisierung und Sitzungs­
schlüsselvereinbarung zwischen VU und EGF erfolgen im
Rahmen der Koppelung und jedes Mal, wenn im Normal­
betrieb eine Secure-Messaging-Sitzung wiederhergestellt wird.
VU und EGF gehen wie in den Abschnitten 10.3 und 10.4
erläutert vor. Es gelten sämtliche Anforderungen dieser Ab­
schnitte.
11.5. Secure Messaging
CSM_214 Alle zwischen Fahrzeugeinheit und externer GNSS-Ausrüs­
tung im Anschluss an eine erfolgreiche Chip-Authentisierung
bis zum Sitzungsende ausgetauschten Befehle und Antworten
sind durch Secure Messaging im reinen Authentisierungs­
modus zu schützen. Es gelten sämtliche Anforderungen von
Abschnitt 10.5.
CSM_215 Wenn eine Secure-Messaging-Sitzung zwischen VU und EGF
abgebrochen wird, leitet die VU sofort eine neue Secure-Mes­
saging-Sitzung ein (siehe Abschnitte 11.3.3 und 11.4).
12. KOPPELUNG UND KOMMUNIKATION VU-BEWEGUNGSSENSOR
12.1. Allgemein
CSM_216 Die Kommunikation zwischen Fahrzeugeinheit und Bewe­
gungssensor während der Koppelung und im Normalbetrieb
hat mithilfe des in ISO 16844-3 spezifizierten Schnittstellen­
protokolls zu erfolgen, unter Vornahme der in diesem Kapitel
und in Abschnitt 9.2.1 beschriebenen Änderungen.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 492
Hinweis: Es wird vorausgesetzt, dass die Leserinnen und Le­
ser dieses Kapitels mit den Inhalten von ISO 16844-3 vertraut
sind.
12.2. Koppelung VU-Bewegungssensor unter Verwendung verschiedener
Schlüsselgenerationen
Wie in Abschnitt 9.2.1 erläutert, werden der Hauptschüssel des Bewe­
gungssensors und alle damit verbundenen Schlüssel regelmäßig ersetzt.
Dies führt dazu, dass in Werkstattkarten bis zu drei AES-Schlüssel K M-
WC (fortlaufender Schlüsselgenerationen) für den Bewegungssensor vor­
handen sind. Ebenso können in Bewegungssensoren bis zu drei verschie­
dene AES-basierte Datenverschlüsselungen (basierend auf fortlaufenden
Generationen des K M -Bewegungssensor-Hauptschlüssels) vorhanden
sein. Eine Fahrzeugeinheit enthält nur einen K M-VU -Schlüssel für den
Bewegungssensor.
CSM_217 Eine VU der 2. Generation und ein Bewegungssensor der 2.
Generation sind wie folgt zu koppeln (vergleiche Tabelle 6 in
ISO 16844-3):
1. Eine Werkstattkarte der zweiten Generation wird in die
VU eingesteckt und diese mit dem Bewegungssensor
verbunden.
2. Die VU liest alle auf der Werkstattkarte verfügbaren K M-
WC -Schlüssel, geht deren Versionsnummern durch und
wählt denjenigen aus, der mit der Versionsnummer des
K M-VU -Schlüssels der VU übereinstimmt. Befindet sich
der passende K M-WC -Schlüssel nicht auf der Werkstatt­
karte, bricht die VU den Koppelungsprozess ab und zeigt
dem Inhaber der Werkstattkarte eine entsprechende Fehler­
meldung an.
3. Die VU berechnet den Bewegungssensor-Hauptschlüssel
K M aus dem K M-VU und dem K M-WC sowie den Identifi­
kationsschlüssel K ID aus dem K M , wie in Abschnitt 9.2.1
spezifiziert.
4. Die VU sendet den Befehl zum Einleiten des Koppelungs­
prozesses an den Bewegungssensor, wie in ISO 16844-3
beschrieben, und verschlüsselt die Seriennummer, die sie
vom Bewegungssensor erhält, mit dem Identifikations­
schlüssel K ID. Die VU sendet die verschlüsselte Serien­
nummer zurück an den Bewegungssensor.
5. Der Bewegungssensor gleicht die verschlüsselte Serien­
nummer nacheinander mit jeder intern vorhandenen Ver­
schlüsselung der Seriennummer ab. Wenn er das passende
Gegenstück findet, wird die VU authentisiert. Der Bewe­
gungssensor erkennt die von der VU verwendete K ID -Ge­
neration und sendet die kodierte Version des Koppelungs­
schlüssels, d. h. die Verschlüsselung, die mithilfe dersel­
ben K M -Generation erstellt wurde, zurück.
6. Die VU entschlüsselt den Koppelungsschlüssel mithilfe
des K M , generiert einen Sitzungsschlüssel K S, verschlüsselt
ihn mit dem Koppelungsschlüssel und sendet das Ergebnis
an den Bewegungssensor. Der Bewegungssensor ent­
schlüsselt den K S .
7. Die VU setzt die Koppelungsinformation gemäß ISO
16844-3 zusammen, verschlüsselt die Information mit
dem Koppelungsschlüssel und sendet das Ergebnis an
den Bewegungssensor. Der Bewegungssensor entschlüsselt
die Koppelungsinformation.
8. Der Bewegungssensor verschlüsselt die empfangene Kop­
pelungsinformation mit dem empfangenen K S und sendet
sie an die VU zurück. Die VU prüft, ob die Koppelungs­
information mit derjenigen übereinstimmt, die die VU im
vorherigen Schritt an den Bewegungssensor gesendet hat.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 493
Falls ja, ist damit belegt, dass der Bewegungssensor den­
selben K S verwendet hat wie die VU und somit in Schritt
5 seinen mit der korrekten K M -Generation verschlüsselten
Koppelungsschlüssel gesendet hat. Der Bewegungssensor
ist somit authentisiert.
Es ist zu beachten, dass die Schritte 2 und 5 vom Standard­
prozess gemäß ISO 16844-3 abweichen; die übrigen Schritte
entsprechen dem Standardprozess.
Beispiel: Angenommen, im ersten Jahr der Gültigkeit des
ERCA (3)-Zertifikats findet eine Koppelung statt; siehe Ab­
bildung 2 in Abschnitt 9.2.1.2, und
— angenommen, der Bewegungssensor wurde im letzten Jahr
der Gültigkeit des ERCA (1)-Zertifikats ausgestellt. Unter
diesen Umständen enthält er die folgenden Schlüssel und
Daten:
— N s [1]: seine Seriennummer, verschlüsselt mit K ID -Ge­
neration 1
— N s [2]: seine Seriennummer, verschlüsselt mit K ID -Ge­
neration 2
— N s [3]: seine Seriennummer, verschlüsselt mit K ID -Ge­
neration 3
— K P [1]: seinen Koppelungsschlüssel der 1. Genera­
tion ( 1 ), verschlüsselt mit K M -Generation 1
— K P [2]: seinen Koppelungsschlüssel der 2. Generation,
verschlüsselt mit K M -Generation 2
— K P [3]: seinen Koppelungsschlüssel der 3. Generation,
verschlüsselt mit K M -Generation 3
— Angenommen, die Werkstattkarte wurde im ersten Jahr
der Gültigkeit des ERCA (3)-Zertifikats ausgestellt. Unter
diesen Umständen enthält sie den Schlüssel K M-WC der 2.
und 3. Generation.
— Angenommen, bei der VU handelt es sich um eine VU
der 2. Generation, die die 2. Generation des K M-VU ent­
hält.
Unter diesen Umständen geschieht in den Schritten 2–5 Fol­
gendes:
— Schritt 2: Die VU liest den K M-WC der 2. und 3. Gene­
ration von der Werkstattkarte und prüft deren Versions­
nummern.
— Schritt 3: Die VU kombiniert den K M-WC der 2. Genera­
tion mit K M-VU , um K M und K ID zu berechnen.
— Schritt 4: Die VU verschlüsselt die Seriennummer, die sie
vom Bewegungssensor erhält, mit dem K ID.
— Schritt 5: Der Bewegungssensor vergleicht die empfange­
nen Daten mit N s [1] und findet kein Gegenstück. Dann
vergleicht er die Daten mit N s [2] und findet ein Gegen­
stück. Er folgert, dass es sich bei der VU um eine VU der
2. Generation handelt, und sendet daher K P [2] zurück.
▼B
( 1 ) Es ist zu beachten, dass es sich bei den Koppelungsschlüsseln der 1., 2. und 3. Gene­
ration um denselben Schlüssel oder aber um drei verschiedene, unterschiedlich lange
Schlüssel handeln kann, wie in CSM_117 erläutert.
02016R0799 — DE — 21.08.2023 — 003.002 — 494
12.3. Koppelung und Kommunikation VU-Bewegungssensor mit AES
CSM_218 Wie in Tabelle 3 in Abschnitt 9.2.1 spezifiziert, handelt es
sich bei allen Schlüsseln, die an der Koppelung einer Fahr­
zeugeinheit (der 2. Generation) und eines Bewegungssensors
sowie an der nachfolgenden Kommunikation beteiligt sind,
nicht um T-DES-Schlüssel doppelter Länge, sondern um
AES-Schlüssel (siehe ISO 16844-3). Diese AES-Schlüssel
können eine Länge von 128, 192 oder 256 Bits aufweisen.
Da die AES-Blockgröße bei 16 Bytes liegt, muss die Länge
einer verschlüsselten Nachricht ein Mehrfaches von 16 Bytes
betragen (T-DES: 8 Bytes). Darüber hinaus werden einige
dieser Nachrichten für die Übertragung von AES-Schlüsseln
verwendet, deren Länge bei 128, 192 oder 256 Bits liegen
kann. Daher ist die Anzahl an Datenbyte pro Anweisung in
Tabelle 5 von ISO 16844-3 gemäß folgender Tabelle 6 zu
verändern:
▼M1
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 Da­
tenbytes bei Verwendung von
AES-Schlüsseln mit Bitlänge
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 Koppelungsinforma­
tion
24 24 32 32 32
50 Antwort Koppelungsinforma­
tion
24 24 32 32 32
70 Anforderung Authentisierungsdaten 8 8 16 16 16
80 Antwort Zählerwert Bewe­
gungssensor + Au­
thentisierungsdaten
8 8 16 16 16
▼B
CSM_219 Die Koppelungsinformation, die in den Anweisungen 43
(VU-Anforderung) und 50 (Antwort des Bewegungssensors)
gesendet wird, ist gemäß der Beschreibung in Abschnitt
7.6.10 von ISO 16844-3 zusammenzusetzen, allerdings wird
anstelle des T-DES-Algorithmus im Verschlüsselungssystem
für die Koppelungsdaten der AES-Algorithmus verwendet,
sodass zwei AES-Verschlüsselungen erfolgen und die in
CSM_220 beschriebene Auffüllmethode passend zur
AES-Blockgröße angewandt wird. Der für diese Verschlüsse­
lung verwendete Schlüssel K' p wird wie folgt generiert:
— Wenn der Koppelungsschlüssel K P 16 Bytes lang ist: K' p
= K P XOR (N s ||N s )
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 495
— Wenn der Koppelungsschlüssel K P 24 Bytes lang ist: K' p
= K P XOR (N s ||N s ||N s )
— Wenn der Koppelungsschlüssel K P 32 Bytes lang ist: K' p
= K P XOR (N s ||N s ||N s ||N s )
wobei N s die 8-Byte-Seriennummer des Bewegungssensors
ist.
CSM_220 Falls die Länge der Klartextdaten (bei Verwendung von
AES-Schlüsseln) kein Vielfaches von 16 Bytes ist, hat die
in ISO 9797-1 beschriebene Auffüllmethode 2 zur Anwen­
dung zu kommen.
Hinweis: In ISO 16844-3 ist die Anzahl der Klartext-Daten­
bytes stets ein Vielfaches von 8, sodass bei Verwendung von
T-DES kein Auffüllen erforderlich ist. Die Definition der
Daten und Nachrichten in ISO 16844-3 wird durch diesen
Teil der Anlage nicht verändert, was die Anwendung der
Auffüllmethode erforderlich macht.
CSM_221 Für Anweisung 11 und falls mehr als ein Datenblock ver­
schlüsselt werden muss, ist der Betriebsmodus Cipher Block
Chaining gemäß ISO 10116 zu verwenden, mit einem Ver­
schachtelungsparameter von m = 1. Der zu verwendende IV
ist:
— für Anweisung 11: der in Abschnitt 7.6.3.3 von ISO
16844-3 spezifizierte 8-Byte-Authentisierungsblock, auf­
gefüllt mithilfe der in ISO 9797-1 beschriebenen Auffüll­
methode 2; siehe auch Abschnitte 7.6.5 und 7.6.6 von
ISO 16844-3.
— für alle anderen Befehle, in denen mehr als 16 Bytes
übertragen werden, wie in Tabelle 6 spezifiziert: „00“
{16}, d. h. sechzehn Bytes mit Binärwert 0.
Hinweis: Wie in den Abschnitten 7.6.5 und 7.6.6 von ISO
16844-3 beschrieben, wird — wenn der Bewegungssensor
Dateien für die Einbeziehung in Anweisung 11 verschlüsselt
— der Authentisierungsblock sowohl
— als Initialisierungsvektor für die Verschlüsselung der Da­
teien mithilfe des CBC-Modus verwendet als auch
— verschlüsselt und als erster Block in die Daten einbezo­
gen, die an die VU gesendet werden.
12.4. Koppelung VU-Bewegungssensor bei verschiedenen Gerätegeneratio­
nen
CSM_222 Wie in Abschnitt 9.2.1 erläutert, kann ein Bewegungssensor
der zweiten Generation die T-DES-basierte Verschlüsselung
der Koppelungsdaten (wie in Teil A dieser Anlage definiert)
enthalten, wodurch sich der Bewegungssensor mit einer VU
der 1. Generation koppeln lässt. In diesem Fall sind eine VU
der 1. Generation und ein Bewegungssensor der 2. Generation
so zu koppeln, wie in Teil A dieser Anlage und in ISO
16844-3 beschrieben. Für den Koppelungsprozess kann eine
Werkstattkarte der 1. oder 2. Generation verwendet werden.
Hinweise:
— Eine VU der 2. Generation kann nicht mit einem Bewe­
gungssensor der 1. Generation gekoppelt werden.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 496
— Eine Werkstattkarte der 1. Generation kann nicht zur Kop­
pelung einer VU der 2. Generation an einen Bewegungs­
sensor verwendet werden.
13. SICHERHEIT FÜR FERNKOMMUNIKATION PER DSRC
13.1. Allgemein
Wie in Anlage 14 spezifiziert, generiert eine VU regelmäßig Daten zur
Fernüberwachung des Fahrtenschreibers (Remote Tachograph Monito­
ring, RTM) und sendet diese an die (interne oder externe) Fernkommuni­
kationsvorrichtung (Remote Communication Facility, RCF). Die RCF
sendet diese Daten über die in Anlage 14 beschriebene DSRC-Schnitt­
stelle an die Fernabfrageeinrichtung (Remote Interrogator, RI). Gemäß
Anlage 1 sind die RTM-Daten eine Verkettung von:
Fahrtenschreibernutzdaten die Verschlüsselung der Klartextnutzdaten
des Fahrtenschreibers
DSRC-Sicherheitsdaten weiter unten beschrieben
Das Format der Klartextnutzdaten des Fahrtenschreibers ist in Anlage 1
spezifiziert und in Anlage 14 genauer erläutert. Dieser Abschnitt be­
schreibt die Struktur der DSRC-Sicherheitsdaten; die formale Spezifika­
tion findet sich in Anlage 1.
CSM_223 Die -Klartextdaten, die von einer
VU an eine RCF (wenn die RCF sich außerhalb der VU
befindet) oder von der VU per DSRC-Schnittstelle an den
RI (wenn die RCF sich innerhalb der VU befindet) gesendet
werden, sind im Modus Verschlüsseln-dann-Authentisieren zu
schützen, d. h., die Fahrtenschreibernutzdaten werden zu­
nächst verschlüsselt, um die Vertraulichkeit der Nachricht
sicherzustellen, und anschließend wird ein MAC berechnet,
um die Authentizität und Integrität der Daten zu gewährleis­
ten.
CSM_224 Die DSRC-Sicherheitsdaten müssen aus einer Verkettung fol­
gender Datenelemente in folgender Reihenfolge bestehen;
siehe auch Abbildung 12:
Current date time aktuelles Datum und aktuelle Uhrzeit der Fahrzeugeinheit
(Datentyp )
Counter ein 3-Byte-Zähler, siehe CSM_225
▼M1
VU serial number die Seriennummer der VU oder die Kennung für den Zer­
tifikatsantrag (Datentyp VuSerialNumber oder Certificate­
RequestID) — siehe CSM_123
▼B
DSRC master key version number die 1-Byte-Versionsnummer des DSRC-Hauptschlüssels,
von dem die VU-spezifischen DSRC-Schlüssel abgeleitet
wurden, siehe Abschnitt 9.2.2.
MAC der mithilfe aller vorausgehenden Bytes in den RTM-Daten
berechnete MAC
CSM_225 Der 3-Byte-Zähler in den DSRC-Sicherheitsdaten muss im
Format MSB-first vorliegen. Bei der ersten Berechnung eines
RTM-Datensatzes nach ihrer Inproduktionsnahme setzt die
VU den Wert des Zählers auf 0. Die VU erhöht den Wert
der Zählerdaten vor jeder Berechnung eines weiteren
RTM-Datensatzes um 1.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 497
13.2. Verschlüsselung der Fahrtenschreibernutzdaten und MAC-Generie­
rung
CSM_226 Bei Vorliegen eines Klartext-Datenelements vom Datentyp
im Sinne von Anlage 14 verschlüs­
selt eine VU diese Daten gemäß Abbildung 12: Der DSRC-
Schlüssel der VU für die Verschlüsselung K_VU DSRC _ENC
(siehe Abschnitt 9.2.2) ist mit AES im Betriebsmodus Cipher
Block Chaining (CBC) gemäß ISO 10116 zu verwenden, mit
einem Verschachtelungsparameter von m = 1. Der Initialisie­
rungsvektor muss IV = current date time ||„00 00 00 00 00 00
00 00 00“ || counter entsprechen, wobei current date time
und counter in CSM_224 spezifiziert sind. Die zu verschlüs­
selnden Daten sind mit der in ISO 9797-1 definierten Auffüll­
methode 2 aufzufüllen.
CSM_227 Die VU berechnet MAC in den DSRC-Sicherheitsdaten ge­
mäß Abbildung 12: Der MAC ist mithilfe aller vorausgehen­
den Bytes in den RTM-Daten zu berechnen, bis einschließlich
der DSRC-Hauptschlüsselversionsnummer und einschließlich
der Tags und Längen der Datenobjekte. Die VU muss ihren
DSRC-Schlüssel zur Authentizität K_VU DSRC _MAC verwen­
den (siehe Abschnitt 9.2.2), mit dem AES-Algorithmus im
CMAC-Modus (siehe SP 800-38B). Die Länge des MAC
ist an die Länge des VU-spezifischen DSRC-Schlüssels ge­
bunden (siehe CSM_50).
Abbildung 12
Verschlüsselung der Fahrtenschreibernutzdaten und MAC-Generierung
13.3. Verifizierung und Entschlüsselung der Fahrtenschreibernutzdaten
CSM_228 Wenn ein RI von einer VU RTM-Daten erhält, muss er die
gesamten RTM-Daten an eine Kontrollkarte im Datenfeld ei­
nes Befehls PROCESS DSRC MESSAGE senden (siehe An­
lage 2). Anschließend gilt:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 498
1. Die Kontrollkarte überprüft die DSRC-Hauptschlüsselver­
sionsnummer in den DSRC-Sicherheitsdaten. Wenn die
Kontrollkarte den angegebenen DSRC-Hauptschlüssel
nicht kennt, muss sie eine Fehlermeldung gemäß Anlage
2 zurücksenden und den Prozess abbrechen.
▼M1
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_VU DSRC _ENC und K_VU DSRC _MAC
abzuleiten (siehe CSM_124).
▼B
3. Die Kontrollkarte verwendet K_VU DSRC _MAC, um den
MAC in den DSRC-Sicherheitsdaten zu überprüfen (siehe
CSM_227). Wenn der MAC inkorrekt ist, muss die Kon­
trollkarte eine Fehlermeldung gemäß Anlage 2 zurücksen­
den und den Prozess abbrechen.
4. Die Kontrollkarte verwendet K_VU DSRC _ENC, um die
verschlüsselten Fahrtenschreibernutzdaten zu entschlüsseln,
wie in CSM_226 spezifiziert. Die Kontrollkarte entfernt
die Auffüllung und sendet die verschlüsselten Fahrten­
schreibernutzdaten an den RI zurück.
CSM_229 Um Replay-Angriffe zu verhindert, muss der RI die Frische
der RTM-Daten überprüfen, indem er sicherstellt, dass cur­
rent date time in den DSRC-Sicherheitsdaten nicht zu sehr
von der aktuellen Zeit des RI abweicht.
Hinweise:
— Hierfür muss der RI über eine präzise und verlässliche
Zeitquelle verfügen.
— Da eine VU gemäß Anlage 14 alle 60 Sekunden einen
neuen RTM-Datensatz berechnen muss und die Uhr der
VU 1 Minute von der Echtzeit abweichen darf, beträgt
die untere Grenze für die Frische der RTM-Daten 2 Mi­
nuten. Die jeweiligen Frischeanforderungen hängen auch
von der Genauigkeit der RI-Uhr ab.
CSM_230 Wenn eine Werkstatt das einwandfreie Funktionieren der
DSRC-Funktion der VU überprüft, sendet sie alle von der
VU erhaltenen RTM-Daten an eine Werkstattkarte im Daten­
feld eines Befehls PROCESS DSRC MESSAGE (siehe An­
lage 2). Die Werkstattkarte muss alle in CSM_228 angegebe­
nen Prüfungen und Aktionen durchführen.
14. SIGNIEREN VON DATENDOWNLOADS UND VERIFIZIEREN DER
SIGNATUREN
14.1. Allgemein
CSM_231 Das Intelligent Dedicated Equipment (IDE) speichert die von
einer VU oder Karte während eines Übertragungsvorgangs
empfangenen Daten in einer Datei ab. Daten können auf ei­
nem externen Speichermedium (ESM) gespeichert werden.
Die Datei enthält digitale Signaturen von Datenblöcken ge­
mäß Anlage 7. Die betreffende Datei muss außerdem fol­
gende Zertifikate enthalten (siehe Abschnitt 9.1):
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 499
— im Falle eines VU-Downloads:
— das VU_Sign-Zertifikat
— das MSCA_VU-EGF-Zertifikat mit dem öffentlichen
Schlüssel zur Verifizierung des VU_Sign-Zertifikats
— im Falle eines Kartendownloads:
— das Card_Sign-Zertifikat
— das MSCA_Card-Zertifikat mit dem öffentlichen
Schlüssel zur Verifizierung des Card_Sign-Zertifikats
CSM_232 Das IDE muss außerdem über Folgendes verfügen:
— falls es eine Kontrollkarte zur Verifizierung der Signatur
verwendet, wie in Abbildung 13 gezeigt: das Linkzertifi­
kat, das das neueste EUR-Zertifikat gegebenenfalls mit
dem direkt davor gültigen EUR-Zertifikat verknüpft.
— falls es die Signatur selbst verifiziert: alle gültigen euro­
päischen Wurzelzertifikate.
Hinweis: Die Methode, mit der das IDE diese Zertifikate
abruft, ist in dieser Anlage nicht spezifiziert.
14.2. Erzeugung der Signatur
CSM_233 Als Signaturalgorithmus zur Erzeugung digitaler Signaturen
anhand heruntergeladener Daten wird ECDSA gemäß DSS
verwendet; dabei ist der an die Schlüsselgröße der VU oder
Karte gebundene Hash-Algorithmus zu verwenden (siehe
CSM_50). Das Signaturformat ist Klartext, wie in
TR-03111 angegeben.
14.3. Verifizierung der Signatur
CSM_234 ►M1 Ein IDE kann die Verifizierung einer Signatur anhand
heruntergeladener Daten selbst durchführen oder zu diesem
Zweck eine Kontrollkarte verwenden. Falls es eine Kontroll­
karte verwendet, ist die Verifizierung der Signatur gemäß
Abbildung 13 durchzuführen. Die Kontrollkarte überprüft
die temporäre Gültigkeit eines vom IDE vorgelegten Zertifi­
kats 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 aktu­
elle Uhrzeit der Karte. Die Karte darf nur die folgenden Zer­
tifikate 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 über­
prüfen. In beiden Fällen ist es erforderlich, bei jedem aus der
Datei ausgelesenem Zertifikat die Richtigkeit des Feldes Cer­
tificate 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).
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 500
— In der CHA des EQT.CA-Zertifikats muss eine MSCA
angegeben sein.
— In der CHA des EQT.Link-Zertifikats muss die ERCA
angegeben sein. ◄
Hinweise zu Abbildung 13:
— Das Gerät, das die zu analysierenden Daten signiert hat,
ist mit EQT bezeichnet.
— Bei den in der Abbildung erwähnten EQT-Zertifikaten
und öffentlichen Schlüsseln handelt es sich um diejenigen
zur Signierung von Kartenzertifikaten, d. h. VU_Sign
oder Card_Sign.
— Bei den in der Abbildung erwähnten EQT.CA-Zertifikaten
und öffentlichen Schlüsseln handelt es sich um diejenigen
zur Signierung der Zertifikate von VU bzw. Karte.
— Bei dem in der Abbildung erwähnten EQT.CA.EUR-Zer­
tifikat handelt es sich um das europäische Wurzelzertifi­
kat, das in der CAR des EQT.CA-Zertifikats angegeben
ist.
— Das in der Abbildung erwähnte EQT.Link-Zertifikat ist
das Linkzertifikat des Geräts, sofern vorhanden. Wie in
Abschnitt 9.1.2 angegeben, handelt es sich hierbei um ein
Linkzertifikat für ein neues europäisches Wurzel-Schlüs­
selpaar, das durch die ERCA erstellt und mithilfe des
zuvor erwähnten europäischen privaten Schlüssels signiert
wird.
— Bei dem EQT.Link.EUR-Zertifikat handelt es sich um das
europäische Wurzelzertifikat, das in der CAR des
EQT.Link-Zertifikats angegeben ist.
CSM_235 Zur Berechnung des Hashwerts M, der im Befehl PSO:Hash
an die Kontrollkarte gesendet wird, verwendet das IDE den
Hash-Algorithmus, der mit der Schlüsselgröße der VU oder
der Karte, von der die Daten heruntergeladen werden, verlinkt
ist (siehe CSM_50).
CSM_236 Bei der Verifizierung der Signatur des Geräts folgt die Kon­
trollkarte dem in DSS definierten Signatursystem.
Das vorliegende Dokument spezifiziert keinerlei Maßnahmen
für den Fall, dass die Signatur über eine heruntergeladene
Datei nicht verifiziert werden kann oder die Verifizierung
erfolglos ist.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 501
Abbildung 13
Protokoll für die Verifizierung der Signatur mithilfe einer heruntergeladenen Datei
▼M1
02016R0799 — DE — 21.08.2023 — 003.002 — 502
Anlage 12
POSITIONSBESTIMMUNG MITHILFE EINES GLOBALEN
SATELLITENNAVIGATIONSSYSTEMS (GNSS)
INHALTSVERZEICHNIS
1. EINLEITUNG
1.1. Anwendungsbereich
▼M3
1.1.1. Referenzdokumente
▼B
1.2. Akronyme und Notationen
▼M3
2. GRUNDLEGENDE MERKMALE DES GNSS-EMPFÄNGERS
3. VOM GNSS-EMPFÄNGER GELIEFERTE DATENSÄTZE
▼B
4. FAHRZEUGEINHEIT MIT EXTERNER GNSS-AUSRÜSTUNG
4.1. Konfiguration
4.1.1 Hauptkomponenten und Schnittstellen
4.1.2 Zustand der externen GNSS-Ausrüstung am Ende der Produktion
4.2. Kommunikation zwischen der externen GNSS-Ausrüstung und der Fahr­
zeugeinheit
4.2.1 Kommunikationsprotokoll
4.2.2 Sichere Übertragung von GNSS-Daten
4.2.3 Struktur des Befehls Read Record
▼M3
4.2.4. Struktur des Befehls WriteRecord
4.2.5 Sonstige Befehle
▼B
4.3. Kopplung, gegenseitige Authentisierung und Sitzungsschlüsselverein­
barung der externen GNSS-Ausrüstung mit der Fahrzeugeinheit
4.4. Fehlerbehandlung
4.4.1 Kommunikationsfehler mit der externen GNSS-Ausrüstung
4.4.2 Verletzung der physischen Integrität der externen GNSS-Ausrüstung.
4.4.3 Fehlende Positionsdaten des GNSS-Empfängers
4.4.4 Abgelaufenes Zertifikat der externen GNSS-Ausrüstung
5. FAHRZEUGEINHEIT OHNE EXTERNE GNSS-AUSRÜSTUNG
5.1. Konfiguration
▼M3
5.2. Übermittlung von Daten vom GNSS-Empfänger an die Fahrzeugeinheit
__________
5.3. Übermittlung von Daten von der Fahrzeugeinheit an den GNSS-Empfän­
ger
5.4. Fehlerbehandlung
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 503
5.4.1 Fehlende Positionsdaten des GNSS-Empfängers
6. POSITIONSDATENVERARBEITUNG UND -AUFZEICHNUNG
DURCH DIE FAHRZEUGEINHEIT
7. GNSS-ZEITKONFLIKT
8. DATENKONFLIKT FAHRZEUGBEWEGUNG
1. EINLEITUNG
Diese Anlage enthält die technischen Anforderungen für den
GNSS-Empfänger und die GNSS-Daten, die von der Fahrzeugeinheit
verwendet werden, einschließlich der Protokolle, die implementiert wer­
den müssen, um die sichere und korrekte Übertragung der Positions­
bestimmungsinformationen zu gewährleisten.
1.1. Anwendungsbereich
GNS_1 Die Fahrzeugeinheit muss Standortdaten von mindestens einem
globalen GNSS-Satellitennetz erfassen.
Die Fahrzeugeinheit kann gegebenenfalls über eine externe
GNSS-Ausrüstung verfügen (siehe Abbildung 1):
1.1.1. Referenzdokumente
Referenzdokumente zu dieser Anlage:
NMEA NMEA (National Marine Electronics Association – Nationale
Vereinigung für Marineelektronik) 0183 Interface Standard,
V4.11
▼B
Abbildung 1
Verschiedene Konfigurationen für den GNSS-Empfänger.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 504
1.2. Akronyme und Notationen
In dieser Anlage werden folgende Akronyme verwendet:
DOP Dilution of Precision (Verschlechterung der Genauigkeit)
EGF Elementary file GNSS Facility (Elementardatei GNSS-Aus­
rüstung)
EGNOS European Geostationary Navigation Overlay Service (Euro­
päische Erweiterung des geostationären Navigationssystems)
GNSS Global Navigation Satellite System (Globales Satellitennavi­
gationssystem)
GSA GPS DOP und aktive Satelliten
HDOP Horizontal Dilution of Precision (Horizontalgenauigkeit)
ICD Interface Control Document (Schnittstellendokument)
NMEA National Marine Electronics Association (US-amerikanische
Vereinigung für Marineelektronik)
▼M3
OSNMA Galileo Open Service Navigation Message Authentication
(Authentisierung von Navigationsnachrichten im Offenen
Dienst von Galileo)
▼B
PDOP Position Dilution of Precision (Positionsgenauigkeit)
RMC Recommended Minimum Specific (Empfohlener minimaler
spezifischer Datensatz)
▼M3
RTC Real Time Clock (Echtzeituhr)
▼B
SIS Signal in Space (Signal im Raum)
VDOP Vertical Dilution of Precision (Vertikalgenauigkeit)
VU Fahrzeugeinheit
▼M3
2. GRUNDLEGENDE MERKMALE DES GNSS-EMPFÄNGERS
▼B
Unabhängig von der Konfiguration des intelligenten Fahrtenschreibers —
mit oder ohne externer GNSS-Ausrüstung — ist die Bereitstellung prä­
ziser und verlässlicher Positionsbestimmungsinformationen eine wesent­
liche Voraussetzung für den effektiven Betrieb des intelligenten Fahrten­
schreibers. Daher sollte seine Kompatibilität mit den Diensten, die gemäß
der Verordnung (EU) Nr. 1285/2013 des Europäischen Parlaments und
des Rates durch das Galileo-Programm und das Programm zur Europäi­
schen Erweiterung des geostationären Navigationssystems (EGNOS) be­
reitgestellt werden, verlangt werden ( 1 ). Bei dem im Rahmen des
Galileo-Programms eingerichteten System handelt es sich um ein un­
abhängiges globales Satellitennavigationssystem, bei dem im Rahmen
von EGNOS eingerichteten System hingegen um ein regionales Satelli­
tennavigationssystem zur Verbesserung der Qualität des GPS-Signals.
GNS_2 Die Hersteller müssen gewährleisten, dass die GNSS-Empfän­
ger in den intelligenten Fahrtenschreibern mit den durch die
Galileo- und EGNOS-Systeme bereitgestellten Positionsbestim­
mungsdiensten kompatibel sind. Die Hersteller können außer­
dem die Kompatibilität mit anderen Satellitennavigationssyste­
men gewährleisten.
▼B
( 1 ) Verordnung (EU) Nr. 1285/2013 des Europäischen Parlaments und des Rates vom
11. Dezember 2013 betreffend den Aufbau und den Betrieb der europäischen Satelliten­
navigationssysteme und zur Aufhebung der Verordnung (EG) Nr. 876/2002 und
Verordnung (EG) Nr. 683/2008 des Rates und des Europäischen Parlaments und des
Rates (ABl. L 347 vom 20.12.2013, S. 1).
02016R0799 — DE — 21.08.2023 — 003.002 — 505
GNS_3 Der GNSS-Empfänger muss fähig sein, die Authentisierung
von Navigationsnachrichten im Offenen Dienst von Galileo
(OSNMA) zu unterstützen.
GNS_3a Der GNSS-Empfänger führt eine Reihe von Konsistenzprüfun­
gen durch, um zu verifizieren, ob die vom GNSS-Empfänger
auf der Grundlage der OSNMA-Daten berechneten Messungen
zu den korrekten Informationen zu Position, Geschwindigkeit
und Daten des Fahrzeugs geführt haben und somit nicht durch
externe Angriffe wie dem Wiederabstrahlen von empfangenen
Signalen mit einem Repeater (Meaconing) beeinflusst wurden.
Diese Konsistenzprüfungen umfassen beispielsweise Folgendes:
— Feststellung anormaler Leistungsemissionen durch kom­
binierte Überwachung von automatischer Verstärkungsrege­
lung (Automatic Gain Control, AGC) und Träger-Rausch­
dichte-Verhältnis (C/N0)
— Konsistenz der Pseudostreckenmessung und der Doppler-
Messung im Zeitverlauf, einschließlich Erkennung abrupter
Messsprünge
— Techniken der autonomen empfängerseitigen Integritätsprü­
fung (Receiver Autonomous Integrity Monitoring, RAIM),
einschließlich Erkennung von Inkonsistenzen zwischen
Messung und geschätzter Position
— Positions- und Geschwindigkeitsprüfungen, einschließlich
anormaler Positions- und Geschwindigkeitslösungen, plötz­
licher Sprünge und eines Verhaltens, das nicht mit der
Fahrzeugdynamik vereinbar ist
— Konsistenz von Zeit und Frequenz, einschließlich Uhrzeit­
sprünge und -abweichungen, die nicht im Einklang mit den
Eigenschaften der Empfängeruhr stehen
GNS_3b Die Europäische Kommission erarbeitet und genehmigt die fol­
genden Dokumente:
— Ein Schnittstellenkontrolldokument für das Signal im Raum
(Signal In Space Interface Control Document, SIS-ICD), in
dem Einzelheiten zu den im Galileo-Signal übermittelten
OSNMA-Informationen festgelegt werden.
— Leitlinien für OSNMA-Empfänger, in denen die Anforde­
rungen und Verfahren in den Empfängern aufgeführt sind,
um eine sichere Implementierung von OSNMA zu gewähr­
leisten, und die Empfehlungen zur Verbesserung der
OSNMA-Leistung enthalten.
Die in Fahrtenschreiber integrierten GNSS-Empfänger, ob in­
tern oder extern, müssen gemäß dem SIS-ICD und den Leit­
linien für OSNMA-Empfänger gebaut sein.
GNS_3c Der GNSS-Empfänger liefert Positionsnachrichten (in diesem
Anhang und seinen Anlagen als authentisierte Positionsnach­
richten bezeichnet), die ausschließlich unter Verwendung von
Satelliten erstellt werden, für die die Authentizität der Naviga­
tionsnachrichten erfolgreich verifiziert wurde.
GNS_3d Der GNSS-Empfänger liefert auch Standardpositionsnachrich­
ten, die unter Verwendung der sichtbaren Satelliten erstellt
werden, unabhängig davon, ob diese authentisiert sind.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 506
GNS_3e Der GNSS-Empfänger verwendet die Echtzeituhr (RTC) der
Fahrzeugeinheit als Zeitreferenz für die für OSNMA erforder­
liche Synchronisierung der Zeit.
GNS_3f Die RTC-Zeit der Fahrzeugeinheit wird dem GNSS-Empfänger
von der Fahrzeugeinheit übermittelt.
GNS_3g Die maximale Zeitabweichung gemäß Anhang IC Randnum­
mer 41 wird dem GNSS-Empfänger zusammen mit der
RTC-Zeit der Fahrzeugeinheit übermittelt.
3. VOM GNSS-EMPFÄNGER GELIEFERTE DATENSÄTZE
In diesem Abschnitt werden die Datensätze beschrieben, die für das
Funktionieren des intelligenten Fahrtenschreibers bei der Übermittlung
von Standard- und authentifizierten Positionsnachrichten verwendet wer­
den. Dieser Abschnitt gilt für die Konfiguration des intelligenten Fahrten­
schreibers sowohl mit als auch ohne externe GNSS-Ausrüstung.
GNS_4 Die Standardpositionsdaten basieren auf dem von der NMEA
empfohlenen minimalen spezifischen Datensatz (Recommen­
ded Minimum Specific, RMC) für das GNSS, der die Positi­
onsinformation (Breite, Länge), die Zeit im UTC-Format
(hhmmss.ss), die Geschwindigkeit in Knoten über Grund so­
wie zusätzliche Werte umfasst.
Der RMC-Datensatz weist folgendes Format auf (gemäß
Norm NMEA V4.11):
Abbildung 2
Struktur des RMC-Datensatzes
$–RMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x .x,xxxx,x.x,a,a,a*hh
1) Zeit (UTC)
2) Status, A= Gültige Position, V= Warnmeldung
3) Breite
4) N oder S
5) Länge
6) O oder W
7) Geschwindigkeit in Knoten über Grund
8) Wahrer Kurs, Grad
9) Datum, TTMMJJ
10) Magnetische Deklination, Grad
11) O oder W
12) FAA Betriebsartanzeiger
13) Navigationsstatus
14) Prüfsumme
Der Navigationsstatus ist optional und möglicherweise nicht
im RMC-Datensatz enthalten.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 507
Der Status zeigt an, ob das GNSS-Signal verfügbar ist. So­
lange der Statuswert nicht auf „A“ gesetzt ist, können die
empfangenen Daten (z. B. Uhrzeit oder Breite/Länge) nicht
verwendet werden, um die Position des Fahrzeugs in der Fahr­
zeugeinheit aufzuzeichnen.
Die Auflösung der Position basiert auf dem oben beschriebe­
nen 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).
GNS_4a Die authentisierten Positionsdaten basieren auf einem
NMEA-artigen Datensatz, dem authentisierten minimalen spe­
zifischen Datensatz (Authenticated Minimum Specific, AMC),
der die Positionsinformation (Breite, Länge), die Zeit im
UTC-Format (hhmmss.ss), die Geschwindigkeit in Knoten
über Grund sowie zusätzliche Werte umfasst.
Der AMC-Datensatz weist folgendes Format auf (gemäß
Norm NMEA V4.11, außer für Wert 2):
Abbildung 3
Struktur des AMC-Datensatzes
$–AMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,xxxx,x.x,a,a,a*hh
1) Zeit (UTC)
2) Status, A = authentisierte Position (ermittelt anhand von mindestens 4 Satel­
liten, von denen die Authentizität der Navigationsnachrichten erfolgreich
verifiziert wurde), J = Jamming oder O = anderer GNSS-Angriff bei fehl­
geschlagener Authentisierung von Navigationsnachrichten (anhand von im­
plementierten Konsistenzprüfungen gemäß GNS_3a), F = fehlgeschlagene
Authentisierung von Navigationsnachrichten (gemäß Feststellung mittels
OSNMA-Überprüfungen, die in den in GNS_3b angeführten Referenzdoku­
menten festgelegt sind), V = ungültig (authentisierte Position aus anderem
Grund nicht verfügbar)
3) Breite
4) N oder S
5) Länge
6) O oder W
7) Geschwindigkeit in Knoten über Grund
8) Wahrer Kurs, Grad
9) Datum, TTMMJJ
10) Magnetische Deklination, Grad
11) O oder W
12) FAA Betriebsartanzeiger
13) Navigationsstatus
14) Prüfsumme
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 508
Der Navigationsstatus ist optional und möglicherweise nicht
im AMC-Datensatz enthalten.
Der Status zeigt an, ob eine authentisierte GNSS-Position ver­
fügbar ist, ob ein Angriff auf die GNSS-Signale erkannt
wurde, ob die Authentisierung der Navigationsnachrichten
fehlgeschlagen ist oder ob die GNSS-Position ungültig ist.
Wenn der Statuswert nicht auf „A“ gesetzt ist, werden die
empfangenen Daten (z. B. Uhrzeit oder Breite/Länge) als nicht
gültig betrachtet und können daher nicht verwendet werden,
um die Position des Fahrzeugs in der Fahrzeugeinheit auf­
zuzeichnen. Wenn der Statuswert auf „J“ (Jamming), „O“
(anderer GNSS-Angriff) oder „F“ (fehlgeschlagene Authenti­
sierung von Navigationsnachrichten) gesetzt ist, wird in der
Fahrzeugeinheit eine GNSS-Anomalie gemäß Anhang IC und
Anlage 1 (EventFaultCode) aufgezeichnet.
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) (gemäß
Norm NMEA V4.11) kann von der Fahrzeugeinheit verwen­
det werden, um die Signalverfügbarkeit und -genauigkeit von
Standardpositionen zu bestimmen und aufzuzeichnen. Die
HDOP dient insbesondere dazu, die Genauigkeit der auf­
gezeichneten Standortdaten anzugeben (siehe 4.2.2). Die Fahr­
zeugeinheit 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 sa­
tellitengestützte Ergänzungssysteme (Satellite-Based Augmen­
tation System, SBAS) die entsprechende NMEA-ID an.
Abbildung 4
Struktur des GSA-Datensatzes (Standardpositionen)
$–GSA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*h h
1) Auswahlmodus
2) Modus
3) ID des 1. für die Ortung verwendeten Satelliten
4) ID des 2. für die Ortung verwendeten Satelliten
…
14) ID des 12. für die Ortung verwendeten Satelliten
15) PDOP
16) HDOP
17) VDOP
18) System-ID
19) Prüfsumme
Die System-ID ist optional und möglicherweise nicht im
GSA-Datensatz enthalten.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 509
In entsprechender Weise kann der NMEA-ähnliche Datensatz
für authentisierte aktive Satelliten (Authenticated Active Satel­
lites, ASA) von der Fahrzeugeinheit verwendet werden, um
die Signalverfügbarkeit und Genauigkeit von authentisierten
Positionen zu bestimmen und aufzuzeichnen. Die Werte 1
bis 18 sind in der Norm NMEA-V4.11 definiert.
Abbildung 5
Struktur des ASA-Datensatzes (authentisierte Positionen)
$–ASA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*h h
1) Auswahlmodus
2) Modus
3) ID des 1. für die Ortung verwendeten Satelliten
4) ID des 2. für die Ortung verwendeten Satelliten
…
14) ID des 12. für die Ortung verwendeten Satelliten
15) PDOP
16) HDOP
17) VDOP
18) System-ID
19) Prüfsumme
Die System-ID ist optional und möglicherweise nicht im
ASA-Datensatz enthalten.
GNS_6 Bei Verwendung einer externen GNSS-Ausrüstung wird der
GSA-Datensatz im GNSS Secure Transceiver mit der Daten­
satznummer „02“ bis „06“ gespeichert, und der ASA-Daten­
satznummer wird unter der Datensatznummer „12“ bis „16“
gespeichert.
GNS_7 Die maximale Größe der NMEA-Datensätze (z. B. RMC,
AMC, GSA, ASA oder sonstige) für den Befehl Read Record
beträgt 85 Bytes (siehe Tabelle 1).
▼B
4. FAHRZEUGEINHEIT MIT EXTERNER GNSS-AUSRÜSTUNG
4.1. Konfiguration
4.1.1 Hauptkomponenten und Schnittstellen
In dieser Konfiguration ist der GNSS-Empfänger Teil der externen
GNSS-Ausrüstung.
GNS_8 Die externe GNSS-Ausrüstung muss über eine spezielle
Fahrzeugschnittstelle eingeschaltet werden.
▼M3
GNS_9 Die externe GNSS-Ausrüstung muss folgende Komponen­
ten umfassen (siehe Abbildung 6):
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 510
a) Einen handelsüblichen GNSS-Empfänger, um die Posi­
tionsdaten über die GNSS-Datenschnittstelle bereit­
zustellen. Die GNSS-Datenschnittstelle kann beispiels­
weise der Norm NMEA V4.11 entsprechen; der
GNSS-Empfänger dient dann als Sender und überträgt
NMEA-Datensätze an den GNSS Secure Transceiver mit
einer Frequenz von 1 Hz für die zuvor festgelegten
NMEA- und NMEA-ähnlichen Datensätze, die mindes­
tens die RMC, AMC, RMC- und ASA-Datensätze um­
fassen müssen. Die Implementierung der GNSS-Daten­
schnittstelle wählt der Hersteller der externen GNSS-
Ausrüstung.
▼B
b) Eine Sende- und Empfangseinheit (GNSS Secure Trans­
ceiver) mit der Fähigkeit zur Unterstützung der Norm
ISO/IEC 7816-4:2013 (siehe 4.2.1) zur Kommunikation
mit der Fahrzeugeinheit und zur Unterstützung der
GNSS-Datenschnittstelle zum GNSS-Empfänger. Die
Einheit muss über einen Speicher für die Kenndaten
des GNSS-Empfängers und der externen GNSS-Ausrüs­
tung verfügen.
▼M3
c) Ein Gehäusesystem mit Funktion zur Manipulations­
erkennung, in dem der GNSS-Empfänger und der
GNSS Secure Transceiver untergebracht sind. Die Funk­
tion zur Manipulationserkennung muss den Sicherheits­
maßnahmen gemäß dem Schutzprofil des intelligenten
Fahrtenschreibers entsprechen.
▼B
d) Eine auf dem Fahrzeug angebrachte und durch das Ge­
häusesystem mit dem GNSS-Empfänger verbundene
GNSS-Antenne.
GNS_10 Die externe GNSS-Ausrüstung besitzt mindestens die fol­
genden externen Schnittstellen:
a) die Schnittstelle zu der auf dem Fahrzeug angebrachten
GNSS-Antenne, falls eine externe Antenne verwendet
wird.
b) die Schnittstelle zur Fahrzeugeinheit.
GNS_11 In der VU bildet der VU Secure Transceiver das andere
Ende der sicheren Kommunikation mit dem GNSS Secure
Transceiver und muss ISO/IEC 7816-4:2013 für die Ver­
bindung zur externen GNSS-Ausrüstung unterstützen.
GNS_12 Hinsichtlich der physischen Aspekte der Kommunikation
mit der externen GNSS-Ausrüstung muss die Fahrzeugein­
heit ISO/IEC 7816-12:2005 oder einen anderen Standard
unterstützen, der ISO/IEC 7816-4:2013 unterstützt (siehe
4.2.1).
4.1.2 Zustand der externen GNSS-Ausrüstung am Ende der Produktion
GNS_13 Die externe GNSS-Ausrüstung muss ab Werk folgende
Werte im nichtflüchtigen Speicher des GNSS Secure Trans­
ceivers gespeichert haben:
— das EGF_MA-Schlüsselpaar mit zugehörigem Zertifikat,
— das MSCA_VU-EGF-Zertifikat mit dem öffentlichen
MSCA_VU-EGF.PK-Schlüssel zur Verifizierung des
EGF_MA-Zertifikats,
— das EUR-Zertifikat mit dem öffentlichen EUR.PK-
Schlüssel zur Verifizierung des MSCA_VU-EGF-Zerti­
fikats,
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 511
— das EUR-Zertifikat, dessen Gültigkeitsdauer direkt der
Gültigkeitsdauer des zur Verifizierung des MSCA_VU-
EGF-Zertifikats zu verwendenden EUR-Zertifikats vo­
rausgeht, falls vorhanden,
— das Linkzertifikat, das diese beiden EUR-Zertifikate
verbindet, sofern vorhanden,
— die erweiterte Seriennummer der externen GNSS-Aus­
rüstung,
— die Kennung des Betriebssystems der GNSS-Ausrüs­
tung,
— die Typgenehmigungsnummer der externen GNSS-Aus­
rüstung,
— den Bezeichner der Sicherheitskomponente des externen
GNSS-Moduls.
4.2. Kommunikation zwischen der externen GNSS-Ausrüstung und der
Fahrzeugeinheit
4.2.1 Kommunikationsprotokoll
▼M3
GNS_14 Das Protokoll der Kommunikation zwischen der externen
GNSS-Ausrüstung und der Fahrzeugeinheit muss die fol­
genden Funktionen unterstützen:
1. das Erfassen und Verteilen von GNSS-Daten (z. B.
Standort, Zeit, Geschwindigkeit),
2. das Erfassen der Konfigurationsdaten der externen
GNSS-Ausrüstung,
3. das Verwaltungsprotokoll zur Unterstützung der Kopp­
lung, gegenseitigen Authentisierung und Sitzungsschlüs­
selvereinbarung zwischen der externen GNSS-Ausrüs­
tung und der Fahrzeugeinheit,
4. die Übermittlung der RTC-Zeit der Fahrzeugeinheit und
der maximalen Differenz zwischen der tatsächlichen Zeit
und der RTC-Zeit der Fahrzeugeinheit an die externe
GNSS-Ausrüstung.
▼B
GNS_15 Das Kommunikationsprotokoll muss auf der Norm ISO/IEC
7816-4:2013 beruhen, wobei der VU Secure Transceiver
den Master und der GNSS Secure Transceiver den Slave
bildet. Die physische Verbindung zwischen der externen
GNSS-Ausrüstung und der Fahrzeugeinheit basiert auf ISO/
IEC 7816-12:2005 oder einem anderen Standard, der ISO/
IEC 7816-4:2013 unterstützt.
▼M1
GNS_16 Im Kommunikationsprotokoll müssen erweiterte Längenfel­
der nicht unterstützt werden.
▼B
GNS_17 Das Kommunikationsprotokoll nach ISO 7816 (sowohl
*-4:2013 als auch *-12:2005) zwischen der externen
GNSS-Ausrüstung und der VU muss auf T=1 eingestellt
sein.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 512
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 ei­
ner Dateisystemarchitektur simulieren, die sich aus einem
Wurzelverzeichnis (Master File, MF), einer Verzeichnis­
datei (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.
▼M3
GNS_18a Im Hinblick auf die Funktion 4) Übermittlung der RTC-Zeit
der Fahrzeugeinheit und der maximalen Differenz zwischen
der tatsächlichen Zeit und der RTC-Zeit der Fahrzeugeinheit
an die externe GNSS-Ausrüstung muss der GNSS-Secure
Transceiver eine EF (EF VU) in derselben DF mit Datei­
kennung „2F30“ gemäß Beschreibung in Tabelle 1
verwenden.
▼B
GNS_19 Der GNSS Secure Transceiver muss die vom GNSS-Emp­
fänger kommenden Daten und die Konfiguration in der
Elementardatei EF.EGF speichern. Es handelt sich hierbei
um einen linearen Datensatz von variabler Länge mit der
Kennung „2F2F“ im Hexadezimalformat.
▼M3
GNS_19a Der GNSS Secure Transceiver muss die von der Fahrzeug­
einheit kommenden Daten in der Elementardatei EF VU
speichern. Es handelt sich hierbei um einen linearen Daten­
satz von fester Länge mit der Kennung „2F30“ im Hexa­
dezimalformat.
GNS_20 Der GNSS Secure Transceiver muss für die Speicherung
der Daten einen Speicher verwenden und mindestens die
Anzahl von Schreib/Lese-Zyklen durchführen können, die
während einer Lebensdauer von mindestens 15 Jahren not­
wendig sind. Von diesem Aspekt abgesehen bleiben das
Innendesign und die Implementierung des GNSS Secure
Transceivers dem Hersteller überlassen.
▼M1
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 satelliten­
gestützte Ergänzungssysteme (Satellite-Based Augmentation
System, SBAS) gibt.
▼B
GNS_21 Die Dateistruktur geht aus Tabelle 1 hervor. Für die Zu­
griffsbedingungen (ALW, NEV, SM-MAC) siehe Anlage 2
Kapitel 3.5.
▼M3
Tabelle 1
Dateistruktur
Zugriffsbedingungen
Datei Dateikennung Lesen Aktualisieren Verschlüsselt
MF 3F00
EF.ICC 0002 ALW NEV
(durch VU)
Nein
▼M1
02016R0799 — DE — 21.08.2023 — 003.002 — 513
Zugriffsbedingungen
Datei Dateikennung Lesen Aktualisieren Verschlüsselt
DF GNSS Facility 0501 ALW NEV Nein
EF EGF_MACertificate C100 ALW NEV Nein
EF CA_Certificate C108 ALW NEV Nein
EF Link_Certificate C109 ALW NEV Nein
EF EGF 2F2F SM-MAC NEV
(durch VU)
Nein
EF VU 2F30 SM-MAC SM-MAC Nein
Datei/Datenelement Datensatz Nr. Größe (Bytes) Standardwerte
Min. Max.
MF 552 1031
EF.ICC
sensorGNSSSerialNumber 8 8
DF GNSS Facility 612 1023
EF EGF_MACertificate 204 341
EGFCertificate 204 341 {00..00}
EF CA_Certificate 204 341
MemberStateCertificate 204 341 {00..00}
EF Link_Certificate 204 341
LinkCertificate 204 341 {00..00}
EF EGF
RMC NMEA-Datensatz '01' 85 85
1. GSA NMEA-Datensatz '02' 85 85
2. GSA NMEA-Datensatz '03' 85 85
3. GSA NMEA-Datensatz '04' 85 85
4. GSA NMEA-Datensatz '05' 85 85
5. GSA NMEA-Datensatz '06' 85 85
Erweiterte Seriennummer der externen
GNSS-Ausrüstung gemäß Anlage 1
als SensorGNSSSerialNumber.
'07' 8 8
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 514
Datei/Datenelement Datensatz Nr. Größe (Bytes) Standardwerte
Kennung des Betriebssystems des
GNSS Secure Transceiver gemäß An­
lage 1 als SensorOSIdentifier.
'08' 2 2
Typgenehmigungsnummer der exter­
nen GNSS-Ausrüstung gemäß An­
lage 1 als SensorExternalGNSSAppro­
valNumber.
'09' 16 16
Kennung der Sicherheitskomponente
der externen GNSS-Ausrüstung gemäß
Anlage 1 als SensorExternalGNSSS­
CIdentifier.
'10' 8 8
AMC-Datensatz '11' 85 85
1. ASA-Datensatz '12' 85 85
2. ASA-Datensatz '13' 85 85
3. ASA-Datensatz '14' 85 85
4. ASA-Datensatz '15' 85 85
5. ASA-Datensatz '16' 85 85
RFU Für künftige Anwendungen reser­
viert
von „17“
bis „FD“
EF VU
VuRtcTime (siehe Anlage 1) '01' 4 4 {00..00}
VuGnssMaximalTimeDifference (siehe
Anlage 1)
'02' 2 2 {00..00}
▼B
4.2.2 Sichere Übertragung von GNSS-Daten
▼M3
GNS_22 Die sichere Übertragung von GNSS-Positionsdaten, RTC-
Zeit der Fahrzeugeinheit und maximaler Differenz zwischen
der tatsächlichen Zeit und der RTC-Zeit der Fahrzeugeinheit
ist nur unter den folgenden Bedingungen zulässig:
▼B
1. Der Koppelungsprozess ist gemäß der Beschreibung in
Anlage 11, Gemeinsame Sicherheitsmechanismen, abge­
schlossen.
2. Die regelmäßige gegenseitige Authentisierung und Sit­
zungsschlüsselvereinbarung zwischen VU und externer
GNSS-Ausrüstung gemäß Anlage 11 ist erfolgt. Die ge­
meinsamen Sicherheitsmechanismen wurden mit der an­
gegebenen Häufigkeit angewandt.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 515
GNS_23 Alle T Sekunden (wobei T kleiner/gleich 20 ist), sofern
nicht eine Koppelung oder gegenseitige Authentisierung
und Sitzungsschlüsselvereinbarung erfolgen, fordert die
VU von der externen GNSS-Ausrüstung die Positionsdaten
auf Grundlage des folgenden Datenflusses an:
1. Die Fahrzeugeinheit fordert von der externen
GNSS-Ausrüstung die Positionsdaten samt DOP-Daten
an (aus dem GSA- und dem ASA-Datensatz). Der Se­
cure Transceiver der Fahrzeugeinheit verwendet die Be­
fehle SELECT (Auswählen) und READ RECORD(S)
(Datensatz/Datensätze lesen) gemäß ISO/IEC 7816-
4:2013 im Secure Messaging (reiner Authentisierungs­
modus), wie in Anlage 11 Abschnitt 11.5 beschrieben,
mit der Dateikennung „2F2F“ und der Datensatznummer
„01“ für den RMC NMEA-Datensatz, den Datensatz­
nummern „02“, „03“, „04“, „05“ und „06“ für den
GSA NMEA-Datensatz, der Datensatznummer „11“ für
den AMC-Datensatz und den Datensatznummern „12“,
„13“, „14“, „15“, „16“ für den ASA-Datensatz.
2. Die zuletzt empfangenen Positionsdaten werden in der
EF mit der Kennung „2F2F“ gespeichert und die in
Tabelle 1 beschriebenen Datensätze im GNSS Secure
Transceiver, wenn der GNSS Secure Transceiver vom
GNSS-Empfänger NMEA-Daten mit einer Frequenz
von mindestens 1 Hz über die GNSS-Datenschnittstelle
erhält.
3. Der GNSS Secure Transceiver sendet die Antwort an
den Secure Transceiver der Fahrzeugeinheit, indem er
die APDU-Antwortnachricht im Secure Messaging (rei­
ner Authentisierungsmodus) verwendet, wie in Anlage 11
Abschnitt 11.5 beschrieben.
4. Der Secure Transceiver der Fahrzeugeinheit prüft die
Authentizität und Integrität der erhaltenen Antwort. Im
Falle eines positiven Ergebnisses werden die Positions­
daten über die GNSS-Datenschnittstelle an den Prozessor
der Fahrzeugeinheit übermittelt.
5. Der Prozessor der Fahrzeugeinheit prüft die empfange­
nen 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 nicht authentisierte Position gültig ist. Wenn die
nicht authentisierte Position gültig ist, extrahiert der Pro­
zessor der Fahrzeugeinheit auch die HDOP-Werte aus
den GSA NMEA-Datensätzen und berechnet den Min­
destwert für das verfügbare Satellitensystem (z. B. wenn
die Ortung verfügbar ist).
6. Der Prozessor der Fahrzeugeinheit extrahiert auch die
Informationen (z. B. Breite, Länge, Zeit) aus dem
AMC-Datensatz. Der AMC-Datensatz gibt Auskunft da­
rüber, ob die authentisierte Position nicht gültig ist oder
ob das GNSS-Signal angegriffen wurde. Wenn die Po­
sition gültig ist, extrahiert der Prozessor der Fahrzeug­
einheit auch die HDOP-Werte aus den ASA-Datensätzen
und berechnet den Mindestwert für das verfügbare Sa­
tellitensystem (d. h. wenn die Ortung verfügbar ist).
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 516
GNS_23a Die Fahrzeugeinheit schreibt auch die RTC-Zeit der Fahr­
zeugeinheit und die maximale Differenz zwischen der tat­
sächlichen Zeit und der RTC-Zeit der Fahrzeugeinheit nach
Bedarf unter Verwendung der Befehle SELECT (Auswäh­
len) und WRITE RECORD(S) (Datensatz/Datensätze
schreiben) gemäß ISO/IEC 7816-4:2013 im Secure Messa­
ging (reiner Authentisierungsmodus), wie in Anlage 11 Ab­
schnitt 11.5 beschrieben, mit der Dateikennung „2F30“ und
den Datensatznummern „01“ für VuRtcTime und „02“ für
MaximalTimeDifference.
▼B
4.2.3 Struktur des Befehls Read Record
Dieser Abschnitt beschreibt die Struktur des Befehls Read Record im
Einzelnen. Secure Messaging (reiner Authentisierungsmodus) wird ge­
mäß der Beschreibung in Anlage 11 (Gemeinsame Sicherheitsmecha­
nismen) hinzugefügt.
GNS_24 Der Befehl muss das Secure Messaging (reiner Authentisie­
rungsmodus) unterstützen, siehe Anlage 11.
GNS_25 Befehlsnachricht
Byte Länge Wert Beschreibung
CLA 1 „0Ch“ Secure Messaging angefordert.
INS 1 „B2h“ Read Record
P1 1 „XXh“ Datensatznummer („00“ verweist auf den
aktuellen Datensatz)
P2 1 „04h“ Lesen des Datensatzes mit der in P1 an­
gegebenen Datensatznummer
Le 1 „XXh“ Erwartete Datenlänge. Anzahl der zu le­
senden Bytes.
GNS_26 Der in P1 angegebene Datensatz wird zum aktuellen Daten­
satz.
Byte Länge Wert Beschreibung
#1-#X X „XX..XXh“ Gelesene Daten
SW 2 „XXXXh“ Statusbytes (SW1, SW2)
— Ist der Befehl erfolgreich, sendet der GNSS Secure
Transceiver „9000“ zurück.
— Wenn die aktuelle Datei nicht datensatzorientiert ist,
sendet der GNSS Secure Transceiver „6981“ zurück.
— Wenn der Befehl mit P1 = „00“ verwendet wird, aber
keine aktuelle EF vorliegt, sendet der GNSS Secure
Transceiver „6986“ (Befehl nicht zulässig) zurück.
▼M3
— Wird der Datensatz nicht gefunden, sendet der GNSS
Secure Transceiver „6A83“ zurück.
— Wenn die externe GNSS-Ausrüstung eine Manipulation
erkannt hat, muss sie die Statusbytes „6690“ zurücksen­
den.
__________
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 517
4.2.4. Struktur des Befehls WriteRecord
Dieser Abschnitt beschreibt die Struktur des Befehls Write Record
(Datensatz schreiben) im Einzelnen. Secure Messaging (reiner Authen­
tisierungsmodus) wird gemäß der Beschreibung in Anlage 11 (Ge­
meinsame Sicherheitsmechanismen) hinzugefügt.
GNS_26a Der Befehl muss das Secure Messaging (reiner Authenti­
sierungsmodus) unterstützen, siehe Anlage 11.
GNS_26b Befehlsnachricht
Byte Länge Wert Beschreibung
CLA 1 „0Ch“ Secure Messaging angefordert.
INS 1 „D2h“ Datensatz schreiben
P1 1 „XXh“ Datensatznummer ('00' verweist auf den
aktuellen Datensatz)
P2 1 „04h“ Schreiben des Datensatzes mit der in P1
angegebenen Datensatznummer
Daten X „XXh“ Daten
GNS_26c Der in P1 angegebene Datensatz wird zum aktuellen Da­
tensatz.
Byte Länge Wert Beschreibung
SW 2 „XXXXh“ Statusbytes (SW1, SW2)
— Ist der Befehl erfolgreich, sendet der GNSS Secure
Transceiver „9000“ zurück.
— Wenn die aktuelle Datei nicht datensatzorientiert ist,
sendet der GNSS Secure Transceiver „6981“ zurück.
— Wenn der Befehl mit P1 = '00' verwendet wird, aber
keine aktuelle EF vorliegt, sendet der GNSS Secure
Transceiver „6986“ (Befehl nicht zulässig) zurück.
— Wird der Datensatz nicht gefunden, sendet der GNSS
Secure Transceiver „6A83“ zurück.
— Wenn die externe GNSS-Ausrüstung eine Manipulation
erkannt hat, muss sie die Statusbytes „6690“ zurück­
senden.
4.2.5 Sonstige Befehle
GNS_27 Der GNSS Secure Transceiver muss die folgenden, in An­
lage 2 spezifizierten Befehle für Fahrtenschreiber der 2. Gene­
ration unterstützen:
Befehl Referenz
Select (Auswählen) Anlage 2 Kapitel 3.5.1
Read Binary (Binär lesen) Anlage 2 Kapitel 3.5.2
Get Challenge (Zufallszahl abrufen) Anlage 2 Kapitel 3.5.4
PSO: Verify Certificate (Zertifikat
verifizieren)
Anlage 2 Kapitel 3.5.7
External Authenticate (Externe Au­
thentisierung)
Anlage 2 Kapitel 3.5.9
General Authenticate (Allgemeine
Authentisierung)
Anlage 2 Kapitel 3.5.10
MSE:SET Anlage 2 Kapitel 3.5.11
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 518
4.3. Kopplung, gegenseitige Authentisierung und Sitzungsschlüsselver­
einbarung der externen GNSS-Ausrüstung mit der Fahrzeugein­
heit
Kopplung, gegenseitige Authentisierung und Sitzungsschlüsselverein­
barung zwischen externer GNSS-Ausrüstung und Fahrzeugeinheit wer­
den in Anlage 11, Gemeinsame Sicherheitsmechanismen, Kapitel 11,
beschrieben.
4.4. Fehlerbehandlung
In diesem Abschnitt wird erläutert, wie mögliche Fehlerzustände der
externen GNSS-Ausrüstung behandelt und in der VU aufgezeichnet
werden.
4.4.1 Kommunikationsfehler mit der externen GNSS-Ausrüstung
▼M3
GNS_28 Ein Ereignis „Kommunikationsfehler mit der externen
GNSS-Ausrüstung“ muss in der Fahrzeugeinheit auf­
gezeichnet werden, wie in Anhang IC Randnummer 82
und Anlage 1 (EventFaultType) definiert. In diesem Kon­
text wird ein Kommunikationsfehler ausgelöst, wenn der
Secure Transceiver der Fahrzeugeinheit im Anschluss an
eine Anforderungsnachricht gemäß 4.2 keine Antwortnach­
richt erhält.
▼B
4.4.2 Verletzung der physischen Integrität der externen GNSS-Ausrüstung.
▼M3
GNS_29 Wenn bei der externen GNSS-Ausrüstung eine Sicherheits­
verletzung stattgefunden hat, muss der GNSS Secure
Transceiver sicherstellen, dass das kryptografische Material
nicht verfügbar ist. 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 „Versuch Sicherheitsverletzung“ wie in Anhang IC
Randnummer 85 und Anlage 1 (EventFaultType für Mani­
pulationserkennung beim GNSS) definiert. Alternativ kann
die externe GNSS-Ausrüstung auf Anforderungen der VU
ohne Secure Messaging und mit dem Status „6A88“
antworten.
▼B
4.4.3 Fehlende Positionsdaten des GNSS-Empfängers
▼M3
GNS_30 Wenn der GNSS Secure Transceiver keine Daten vom
GNSS-Empfänger erhält, generiert der GNSS Secure
Transceiver auf den Befehl READ RECORD (Datensatz
lesen) eine Antwortnachricht mit der Datensatznummer
„01“ und einem Datenfeld von 12 Bytes, die alle auf
0xFF gesetzt sind. Bei Erhalt der Antwortnachricht mit
diesem Wert im Datenfeld muss die Fahrzeugeinheit ein
Ereignis des Typs „Fehlende Positionsdaten des GNSS-
Empfängers“ generieren und aufzeichnen, wie in Anhang IC
Randnummer 81 und Anlage 1 (EventFaultType) definiert.
▼B
4.4.4 Abgelaufenes Zertifikat der externen GNSS-Ausrüstung
▼M3
GNS_31 Wenn die Fahrzeugeinheit erkennt, dass das EGF-Zertifikat
zur gegenseitigen Authentisierung nicht mehr gültig ist,
muss die Fahrzeugeinheit ein Ereignis des Typs „Versuch
Sicherheitsverletzung“ gemäß Anhang IC Randnummer 85
und Anlage 1 (EventFaultType für abgelaufenes Zertifikat
der externen GNSS-Ausrüstung) generieren und aufzeich­
nen. Die Fahrzeugeinheit verwendet weiterhin die erhalte­
nen GNSS-Positionsdaten.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 519
Abbildung 6
Schema der externen GNSS-Ausrüstung
▼B
5. FAHRZEUGEINHEIT OHNE EXTERNE GNSS-AUSRÜSTUNG
5.1. Konfiguration
In dieser Konfiguration befindet sich der GNSS-Empfänger innerhalb
der Fahrzeugeinheit, wie in Abbildung 1 beschrieben:
▼M3
GNS_32 Bei der Übermittlung von Positions-, DOP- und Satelliten­
daten dient der GNSS-Empfänger als Sender und überträgt
NMEA- oder NMEA-artige Datensätze an den als Empfänger
dienenden Prozessor der Fahrzeugeinheit mit einer Frequenz
von mindestens 1/10 Hz für die zuvor festgelegten Daten­
sätze, die mindestens die RMC-, GSA-, AMC- und ASA-Da­
tensätze umfassen müssen. Alternativ können der Prozessor
der Fahrzeugeinheit und die interne GNSS-Ausrüstung andere
Datenformate verwenden, um die Daten auszutauschen, die in
den in GNS_4, GNS_4a und GNS_5 spezifizierten NMEA-
oder NMEA-ähnlichen Datensätzen enthalten sind.
▼B
GNS_33 Eine auf dem Fahrzeug angebrachte externe GNSS-An­
tenne oder eine interne GNSS-Antenne muss mit der VU
verbunden sein.
▼M3
5.2. Übermittlung von Daten vom GNSS-Empfänger an die Fahrzeug­
einheit
GNS_34 Der Prozessor der Fahrzeugeinheit prüft die empfangenen
Daten, indem er die Informationen (z. B. Breite, Länge,
Zeit) aus dem RMC NMEA-Datensatz und dem
AMC-Datensatz extrahiert.
GNS_35 Der RMC NMEA-Datensatz gibt Auskunft darüber, ob die nicht
authentisierte Position gültig ist. Wenn die nicht authentisierte
Position nicht gültig ist, sind die Positionsdaten nicht verfügbar
und können nicht verwendet werden, um die Position des Fahr­
zeugs aufzuzeichnen. Wenn die nicht authentisierte Position gül­
tig ist, extrahiert der Prozessor der Fahrzeugeinheit auch die
HDOP-Werte aus den GSA NMEA-Datensätzen.
GNS_36 Der Prozessor der Fahrzeugeinheit extrahiert auch die Informa­
tionen (z. B. Breite, Länge, Zeit) aus dem AMC-Datensatz. Der
AMC-Datensatz gibt Auskunft darüber, ob die nicht authenti­
sierte Position gemäß GNS_4a gültig ist. Wenn die nicht au­
thentisierte Position gültig ist, extrahiert der Prozessor der Fahr­
zeugeinheit auch die HDOP-Werte aus den ASA-Datensätzen.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 520
5.3. Übermittlung von Daten von der Fahrzeugeinheit an den
GNSS-Empfänger
GNS_37 Der Prozessor der Fahrzeugeinheit stellt dem GNSS-Emp­
fänger die RTC-Zeit der Fahrzeugeinheit und die maximale
Differenz zwischen der tatsächlichen Zeit und der
RTC-Zeit der Fahrzeugeinheit gemäß GNS_3f und
GNS_3g zur Verfügung.
5.4. Fehlerbehandlung
5.4.1 Fehlende Positionsdaten des GNSS-Empfängers
GNS_38 Die Fahrzeugeinheit muss ein Ereignis des Typs „Fehlende
Positionsdaten des GNSS-Empfängers“ generieren und auf­
zeichnen, wie in Anhang IC Randnummer 81 und Anlage 1
(EventFaultType) definiert.
6. POSITIONSDATENVERARBEITUNG UND -AUFZEICHNUNG
DURCH DIE FAHRZEUGEINHEIT
Dieser Abschnitt gilt für die Konfiguration des intelligenten Fahrten­
schreibers sowohl mit als auch ohne externe GNSS-Ausrüstung.
GNS_39 Die Positionsdaten müssen in der Fahrzeugeinheit gespei­
chert werden, zusammen mit einem Merker, der angibt, ob
die Position authentisiert wurde. Wenn Positionsdaten in
der Fahrzeugeinheit aufgezeichnet werden müssen, gelten
folgende Regeln:
a) Wenn sowohl die authentisierte Position als auch die
Standardposition gültig und konsistent sind, werden
die Standardposition und deren Genauigkeit in der Fahr­
zeugeinheit aufgezeichnet und der Merker wird auf „au­
thentisiert“ gesetzt.
b) Wenn sowohl die authentisierte Position als auch die
Standardposition gültig sind, aber diese nicht konsistent
sind, werden die authentisierte Position und deren Ge­
nauigkeit in der Fahrzeugeinheit gespeichert und der
Merker wird auf „authentisiert“ gesetzt.
c) Wenn die authentisierte Position gültig und die Stan­
dardposition nicht gültig ist, werden die authentisierte
Position und deren Genauigkeit in der Fahrzeugeinheit
aufgezeichnet und der Merker wird auf „authentisiert“
gesetzt.
d) Wenn die Standardposition gültig und die authentisierte
Position nicht gültig ist, werden die Standardposition
und deren Genauigkeit in der Fahrzeugeinheit auf­
gezeichnet und der Merker wird auf „nicht authentisiert“
gesetzt.
Authentisierte Positionen und Standardpositionen gelten als
konsistent, wie in Abbildung 7 dargestellt, wenn die hori­
zontale authentisierte Position in einem Kreis liegt, dessen
Mittelpunkt die horizontale Standardposition ist und dessen
Radius der nach folgender Formel berechnete Wert R_H,
aufgerundet auf die nächste ganze Zahl, ist:
R_H = 1,74 • σ UERE • HDOP
Wobei Folgendes gilt:
— R_H ist der relative Radius eines Kreises rund um die
geschätzte horizontale Position, in Metern. Es handelt
sich dabei um einen Indikator, der verwendet wird, um
die Konsistenz zwischen der Standard- und der authen­
tisierten Position zu prüfen.
— σ UERE ist die Standardabweichung des benutzeräquiva­
lenten Bereichsfehlers (User Equivalent Range Error,
UERE), der alle Messfehler für die Zielanwendung mo­
delliert, einschließlich städtische Umgebungen. Ein kon­
stanter Wert von σ UERE = 10 Meter wird verwendet.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 521
— HDOP (Horizontal Dilution of Precision) ist die Hori­
zontalgenauigkeit, die vom GNSS-Empfänger berechnet
wird.
— σ UERE . HDOP ist die geschätzte mittlere quadratische
Abweichung im horizontalen Bereich.
Abbildung 7
Konsistenz von authentisierter Position und Standard­
positionen (nicht authentisiert)
GNS_40 Wenn der Wert des Status in einem empfangenen
AMC-Datensatz gemäß Randnummer GNS_4a auf „J“
oder „O“ oder „F“ gesetzt wird, muss die Fahrzeugeinheit
ein Ereignis des Typs „GNSS-Anomalie“ generieren und
aufzeichnen, wie in Anhang IC Randnummer 88a und An­
lage 1 (EventFaultType) definiert. Die Fahrzeugeinheit
kann zusätzliche Prüfungen durchführen, bevor sie eine
GNSS-Anomalie im Anschluss an den Empfang einer Ein­
stellung „J“ oder „O“ speichert.
7. GNSS-ZEITKONFLIKT
GNS_41 Stellt die Fahrzeugeinheit eine Abweichung zwischen der
Zeitmessfunktion der Fahrzeugeinheit und der aus den
GNSS-Signalen stammenden Zeit fest, muss die Fahrzeug­
einheit ein Ereignis des Typs „Zeitkonflikt“ gemäß An­
hang IC Randnummer 86 und Anlage 1 (EventFaultType)
generieren und aufzeichnen.
8. DATENKONFLIKT FAHRZEUGBEWEGUNG
GNS_42 Die Fahrzeugeinheit muss ein Ereignis des Typs „Daten­
konflikt Fahrzeugbewegung“ gemäß Anhang IC Randnum­
mer 84 auslösen und aufzeichnen, wenn die vom Bewe­
gungssensor berechneten Bewegungsangaben in Wider­
spruch zu den vom internen GNSS-Empfänger oder von
der externen GNSS-Ausrüstung berechneten Bewegungs­
angaben oder zu den Bewegungsangaben aus einer oder
mehreren unabhängigen Quelle(n) gemäß Anhang IC
Randnummer 26 stehen.
Das Ereignis „Datenkonflikt Fahrzeugbewegung“ muss bei
Eintritt einer der folgenden Auslösebedingungen ausgelöst
werden:
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 522
Auslösebedingung 1:
Der getrimmte Mittelwert der Geschwindigkeitsdifferenzen
zwischen den Quellen wird gemäß folgender Erläuterung
verwendet, wenn die Positionsdaten des GNSS-Empfängers
verfügbar sind und die Zündung des Fahrzeugs eingeschal­
tet ist:
— Höchstens alle 10 Sekunden wird der Absolutwert der
Differenz zwischen der vom GNSS und der vom Be­
wegungssensor kalkulierten Fahrzeuggeschwindigkeit
berechnet.
— Alle in einem die letzten 5 Minuten, in denen Fahr­
zeugbewegung stattgefunden hat, umfassenden Zeit­
fenster berechneten Werte werden herangezogen, um
den getrimmten Mittelwert zu errechnen.
— Der getrimmte Mittelwert wird als Durchschnitt von
80 % der übrigen Werte berechnet, nachdem die höchs­
ten Absolutwerte ausgeschlossen wurden.
Das Ereignis „Datenkonflikt Fahrzeugbewegung“ wird aus­
gelöst, wenn der getrimmte Mittelwert ununterbrochen für
fünf Minuten, in denen Bewegung stattfindet, über 10 km/h
liegt. (Hinweis: Durch die Verwendung des getrimmten
Mittels in den letzten 5 Minuten soll das Risiko von Mess­
ausreißern und transienten Werten gemindert werden.)
Für die Berechnung des getrimmten Mittelwerts gilt das
Fahrzeug als in Bewegung, wenn mindestens ein geschätz­
ter Wert für die Fahrzeuggeschwindigkeit entweder vom
Bewegungssensor oder vom GNSS-Empfänger nicht gleich
Null ist.
Auslösebedingung 2:
Das Ereignis „Datenkonflikt Fahrzeugbewegung“ muss
auch ausgelöst werden, wenn die folgende Bedingung er­
füllt ist:
GnssDistance > [OdometerDifference × OdometerToleran­
ceFactor + Minimum (SlipDistanceUpperlimit; (Odometer­
Difference × SlipFactor)) + GnssTolerance + FerryTrain­
Distance]
Wobei Folgendes gilt:
— GnssDistance ist die Entfernung zwischen der aktuellen
und der vorherigen Position des Fahrzeugs, mit beiden
Positionen aus gültigen authentisierten Positionsnach­
richten, ohne Berücksichtigung der Höhe
— OdometerDifference ist die Differenz zwischen dem
aktuellen Kilometerstand und dem Kilometerstand, der
der vorherigen gültigen authentisierten Positionsnach­
richt entspricht
— OdometerToleranceFactor ist gleich 1,1 (ungünstigster
Toleranzfaktor für alle Messtoleranzen des Kilometer­
zählers)
— GnssTolerance ist gleich 1 km ist (GNSS-Toleranz im
ungünstigsten Fall)
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 523
— Minimum (SlipDistanceUpperLimit; (OdometerDiffe­
rence * SlipFactor)) ist der Mindestwert zwischen:
— SlipDistanceUpperLimit ist gleich 10 km (oberer
Grenzwert der Schlupfdistanz, die durch Schlupf­
wirkungen beim Bremsen verursacht wird)
— und OdometerDifference * SlipFactor, wobei Slip­
Factor ist gleich 0,2 (maximaler Einfluss von
Schlupfwirkungen beim Bremsen)
— FerryTrainDistance wird berechnet als: FerryTrainDis­
tance = 200 km/h * tFerryTrain, wobei tFerryTrain die
Summe der Dauer in Stunden der Fährüberfahrten/Zug­
fahrten im betrachteten Zeitintervall ist. Die Dauer der
Fährüberfahrten/Zugfahrten ist definiert als die Zeitdif­
ferenz zwischen dem Merker „Ende“ und dem Merker
„Anfang“ der Fährüberfahrt/Zugfahrt.
Die oben genannten Prüfungen müssen alle 15 Minuten
durchgeführt werden, wenn die erforderlichen Positions­
daten vorhanden sind, und andernfalls, sobald die Positi­
onsdaten vorhanden sind.
Für diese Auslösebedingung gilt:
— Datum und Uhrzeit des Beginns des Ereignisses ent­
sprechen dem Datum und der Uhrzeit des Empfangs
der vorherigen Positionsnachricht,
— Datum und Uhrzeit des Endes des Ereignisses entspre­
chen dem Datum und der Uhrzeit, wenn die geprüfte
Bedingung wieder falsch wird.
Auslösebedingung 3:
Die Fahrzeugeinheit stellt eine Abweichung fest, die darin
besteht, dass in einem bestimmten Zeitraum der Bewe­
gungssensor keine Bewegung erkennt und die unabhängige
Bewegungsquelle eine Bewegung erkennt. Die Bedingun­
gen für die Aufzeichnung einer Abweichung sowie des
Zeitraums der Feststellung der Abweichung werden vom
Hersteller der Fahrzeugeinheit festgelegt, wobei die Abwei­
chung jedoch innerhalb von höchstens drei Stunden erkannt
werden muss.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 524
Anlage 13
ITS-SCHNITTSTELLE
INHALTSVERZEICHNIS
1. EINLEITUNG
1.1. Anwendungsbereich
1.2. Akronyme und Begriffsbestimmungen
2. REFERENZIERTE NORMEN
3. FUNKTIONSPRINZIPIEN DER ITS-SCHNITTSTELLE
3.1. Kommunikationseinrichtung
3.2. Verfügbare Dienste
3.3. Zugriff über die ITS-Schnittstelle
3.4. Verfügbare Daten und Notwendigkeit der Zustimmung des Fahrers
4. LISTE DER ÜBER DIE ITS-SCHNITTSTELLE VERFÜGBAREN DA­
TEN UND EINSTUFUNG ALS PERSONENBEZOGENE/NICHT PER­
SONENBEZOGENE DATEN
1. EINLEITUNG
1.1. Anwendungsbereich
ITS_01 In dieser Anlage werden die Grundlagen der Kommunikation über
die Schnittstelle des Fahrtenschreibers zu intelligenten Verkehrs­
systemen (ITS) gemäß den Artikeln 10 und 11 der Verord­
nung (EU) Nr. 165/2014 spezifiziert.
ITS_02 Die ITS-Schnittstelle ermöglicht es externen Geräten, Daten vom
Fahrtenschreiber zu erlangen, Fahrtenschreiberdienste zu nutzen
und Daten für den Fahrtenschreiber bereitzustellen.
Zu diesem Zweck können auch andere Fahrtenschreiberschnittstel­
len (z. B. CAN-Bus) verwendet werden.
Folgendes wird in dieser Anlage nicht spezifiziert:
— die Art und Weise der Erfassung und Verwaltung der über die
ITS-Schnittstelle bereitgestellten Daten im Fahrtenschreiber,
— die Darstellungsform der erfassten Daten gegenüber den auf
dem externen Gerät gehosteten Anwendungen,
— die ITS-Sicherheitsspezifikation, die über die Funktionen von
Bluetooth® hinausgehen,
— die Bluetooth®-Protokolle, die von der ITS-Schnittstelle ge­
nutzt werden.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 525
1.2. Akronyme und Begriffsbestimmungen
Folgende für diese Anlage spezifische Akronyme und Begriffsbestimmun­
gen werden verwendet:
GSM Global Navigation Satellite System (Globales Satellitenna­
vigationssystem)
ITS Intelligent Transport System (Intelligentes Verkehrssystem)
OSI Open Systems Interconnection (Offenes Kommunikations­
system)
VU Vehicle Unit (Fahrzeugeinheit)
ITS-Einheit Ein externes Gerät oder eine externe Anwendung, das bzw.
die die ITS-Schnittstelle der Fahrzeugeinheit verwendet.
2. REFERENZNORMEN
ITS_03 Diese Anlage verweist auf sämtliche oder Teile der folgenden Ver­
ordnungen und Normen und hängt von diesen ab. In den Klauseln
dieser Anlage wird auf die relevanten Normen oder die relevanten
Klauseln der Normen verwiesen. Bei Widersprüchen haben die
Klauseln dieser Anlage Vorrang.
Auf folgende Normen wird in dieser Anlage Bezug genommen:
— Bluetooth® – Core Version 5.0
— ISO 16844-7: Road vehicles – Tachograph systems – Part 7:
Parameter (Straßenfahrzeuge – Fahrtschreiber – Teil 7: Para­
meter)
— ISO/IEC 7498-1:1994: Information technology – Open Systems
Interconnection – Basic Reference Model, the Basic Model
(Informationstechnik – Kommunikation Offener Systeme –
Basis-Referenzmodell, das Basismodell)
3. FUNKTIONSPRINZIPIEN DER ITS-SCHNITTSTELLE
ITS_04 Die VU ist dafür verantwortlich, die über die ITS-Schnittstelle
übermittelten Daten ohne Einbeziehung der ITS-Schnittstelle zu
aktualisieren und auf dem neuesten Stand zu halten.
3.1. Kommunikationseinrichtung
ITS_05 Die Kommunikation über die ITS-Schnittstelle erfolgt über eine
Bluetooth®-Schnittstelle und ist mit Bluetooth® Low Energy
(Niedrigenergie) gemäß Bluetooth Version 5.0 oder höher
kompatibel.
ITS_06 Die Kommunikation zwischen der VU und der ITS-Einheit wird
nach Abschluss eines Bluetooth®-Kopplungsprozesses aufgebaut.
ITS_07 Eine sichere und verschlüsselte Kommunikation zwischen der VU
und der ITS-Einheit wird gemäß den Mechanismen der Blue­
tooth®-Spezifikation aufgebaut. In dieser Anlage werden die Ver­
schlüsselung oder andere Sicherheitsmechanismen, die über die
Funktionen von Bluetooth® hinausgehen, nicht spezifiziert.
ITS_08 Bluetooth® verwendet ein Server-/Client-Modell zur Steuerung der
Übermittlung von Daten zwischen Geräten, wobei die VU der
Server und die ITS-Einheit der Client ist.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 526
3.2. Verfügbare Dienste
ITS_09 Die Daten, die gemäß Nummer 4 über die ITS-Schnittstelle zu
übermitteln sind, werden über die in Anlage 7 und Anlage 8 ge­
nannten Dienste bereitgestellt. Darüber hinaus stellt die VU der
ITS-Einheit die Dienste bereit, die für die manuelle Dateneingabe
gemäß Anhang IC Randnummer 61 und wahlweise für andere
Dateneinträge in Echtzeit erforderlich sind.
Abbildung 1
Aufteilung der Kommunikation über die ITS-Schnittstelle gemäß den Schichten des OSI-Modells
ITS_10 Wird die Schnittstelle zum Herunterladen über den Steckanschluss
an der Vorderseite verwendet, so darf die VU die in Anlage 7
spezifizierten Download-Dienste nicht über die ITS-Bluetooth®-
Verbindung bereitstellen.
ITS_11 Wird die Kalibrierungsschnittstelle über den Steckanschluss an der
Vorderseite verwendet, so darf die VU die in Anlage 8 spezifizier­
ten Kalibrierungsdienste nicht über die ITS-Bluetooth®-Verbin­
dung bereitstellen.
3.3. Zugriff über die ITS-Schnittstelle
ITS_12 Die ITS-Schnittstelle muss einen drahtlosen Zugriff auf alle in
Anlage 7 und Anlage 8 genannten Dienste als Ersatz für eine
Kabelverbindung zum Steckanschluss an der Vorderseite für die
Kalibrierung und das Herunterladen gemäß Anlage 6 ermöglichen.
ITS_13 Die VU muss die ITS-Schnittstelle für den Nutzer entsprechend der
Kombination gültiger Fahrtenschreiberkarten, die in die VU einge­
steckt sind, verfügbar machen, wie in Tabelle 1 spezifiziert.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 527
Tabelle 1
Verfügbarkeit der ITS-Schnittstelle je nach Art der in den Fahrtenschreiber eingesteckten Karte
Verfügbarkeit der
ITS-Schnittstelle
Steckplatz Fahrer
Keine Karte Fahrerkarte Kontrollkarte Werkstattkarte Unternehmenskarte
S
te
ck
pl
at
z
B
ei
fa
hr
er
Keine Karte Nicht verfügbar Verfügbar Verfügbar Verfügbar Verfügbar
Fahrerkarte Verfügbar Verfügbar Verfügbar Verfügbar Verfügbar
Kontrollkarte Verfügbar Verfügbar Verfügbar Nicht verfügbar Nicht verfügbar
Werkstattkarte Verfügbar Verfügbar Nicht verfügbar Verfügbar Nicht verfügbar
Unternehmens­
karte
Verfügbar Verfügbar Nicht verfügbar Nicht verfügbar Verfügbar
ITS_14 Nach erfolgreicher ITS-Bluetooth®-Kopplung muss die VU die
ITS-Bluetooth®-Verbindung der spezifischen eingesteckten Fahr­
tenschreiberkarte gemäß Tabelle 2 zuweisen:
Tabelle 2
Zuweisung der ITS-Verbindung je nach Art der in den Fahrtenschreiber eingesteckten Karte
Zuweisung der
ITS-Bluetooth®-Verbindung
Steckplatz Fahrer
Keine Karte Fahrerkarte Kontrollkarte Werkstattkarte Unternehmenskarte
S
te
ck
pl
at
z
B
ei
fa
hr
er

Keine Karte Nicht verfügbar Fahrerkarte Kontrollkarte Werkstattkarte Unternehmens­
karte
Fahrerkarte Fahrerkarte Fahrerkarte (**) Kontrollkarte Werkstattkarte Unternehmens­
karte
Kontrollkarte Kontrollkarte Kontrollkarte Kontroll­
karte (*)
Nicht verfügbar Nicht verfügbar
Werkstattkarte Werkstattkarte Werkstattkarte Nicht verfügbar Werkstatt­
karte (*)
Nicht verfügbar
Unternehmens­
karte
Unternehmens­
karte
Unternehmens­
karte
Nicht verfügbar Nicht verfügbar Unternehmens­
karte (*)
(*) Die ITS-Bluetooth®-Verbindung wird der Fahrtenschreiberkarte im Steckplatz des Fahrers der VU zugewiesen.
(**) Der Nutzer wählt die Karte aus, der die ITS-Bluetooth®-Verbindung zugewiesen werden soll (eingesteckt im Steckplatz des Fahrers
oder des Beifahrers).
ITS_15 Wenn die Fahrtenschreiberkarte entnommen wird, beendet die VU
die dieser Karte zugewiesene ITS-Bluetooth®-Verbindung.
ITS_16 Die VU unterstützt die ITS-Verbindung mit mindestens einer
ITS-Einheit und kann Verbindungen mit mehreren IVS-Einheiten
gleichzeitig unterstützen.
ITS_17 Die Zugriffsrechte auf die über die ITS-Schnittstelle verfügbaren
Daten und Dienste müssen den Bestimmungen in Anhang IC
Randnummern 12 und 13 entsprechen und zusätzlich müssen die
in Abschnitt 3.4 dieser Anlage genannten Bestimmungen hinsicht­
lich der Zustimmung des Fahrers erfüllt
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 528
3.4. Verfügbare Daten und Notwendigkeit der Zustimmung des Fahrers
ITS_18 Alle über die in Nummer 3.3 genannten Dienste verfügbaren Fahr­
tenschreiberdaten müssen entweder als personenbezogen oder als
nicht personenbezogen für den Fahrer, den Beifahrer oder beide
eingestuft sein.
ITS_19 Über die ITS-Schnittstelle wird mindestens die Liste der gemäß
Abschnitt 4 als obligatorisch eingestuften Daten zur Verfügung
gestellt.
ITS_20 Die als „personenbezogen“ eingestuften Daten in Nummer 4 dürfen
nur mit Zustimmung des Fahrers zugänglich sein, der mit seiner
Zustimmung akzeptiert, dass die personenbezogenen Daten das
Fahrzeugnetz verlassen dürfen, außer in dem in Randnum­
mer ITS_25 dargelegten Fall, für den die Zustimmung des Fahrers
nicht erforderlich ist.
ITS_21 Daten, die über die gemäß Nummer 4 erfassten Daten hinausgehen
und als obligatorisch betrachtet werden, können über die
ITS_Schnittstelle verfügbar gemacht werden. Zusätzliche Daten,
die nicht in Nummer 4 aufgeführt sind, müssen vom
VU-Hersteller als „personenbezogen“ oder „nicht personenbezo­
gen“ eingestuft werden, wobei die Zustimmung des Fahrers zu
den Daten erforderlich ist, die als personenbezogen eingestuft sind,
außer in dem in Randnummer ITS_25 dargelegten Fall, für den die
Zustimmung des Fahrers nicht erforderlich ist.
ITS_22 Beim Einstecken einer Fahrerkarte, die der Fahrzeugeinheit unbe­
kannt ist, wird der Karteninhaber vom Fahrtenschreiber aufgefor­
dert, seine Zustimmung zur Übertragung personenbezogener Daten
über die ITS-Schnittstelle gemäß Anhang IC Randnummer 61 zu
erteilen.
ITS_23 Der Zustimmungsstatus (aktiviert/deaktiviert) muss im Massenspei­
cher der Fahrzeugeinheit aufgezeichnet werden.
ITS_24 Bei mehreren Fahrern dürfen nur die personenbezogenen Daten der
Fahrer, die ihre Zustimmung erteilt haben, über die ITS-Schnitt­
stelle zugänglich sein. Wenn beispielsweise im Falle eines Teams
nur der Fahrer seine Zustimmung erteilt hat, dürfen die personen­
bezogenen Daten des Beifahrers nicht zugänglich sein.
ITS_25 Wenn die VU im Kontroll-, Unternehmens- oder Kalibrierungs­
modus ist, werden die Zugriffsrechte über die ITS-Schnittstelle
gemäß Anhang IC Randnummern 12 und 13 verwaltet, sodass
die Zustimmung des Fahrers nicht notwendig ist.
4. LISTE DER ÜBER DIE ITS-SCHNITTSTELLE VERFÜGBAREN DA­
TEN UND EINSTUFUNG ALS PERSONENBEZOGENE/NICHT PER­
SONENBEZOGENE DATEN
Datenbezeichnung Datenformat Quelle
Dateneinstufung (personenbezogen/
nicht personenbezogen) Zustimmung zur Ver­
fügbarkeit der Daten
Verfügbarkeit
Fahrer Beifahrer
VehicleIdentification
Number
Anlage 8 VU nicht per­
sonenbezogen
nicht per­
sonenbezogen
keine Zustim­
mung erforderlich
obligatorisch
CalibrationDate ISO 16844-7 VU nicht per­
sonenbezogen
nicht per­
sonenbezogen
keine Zustim­
mung erforderlich
obligatorisch
TachographVehicle­
Speed
ISO 16844-7 VU personenbezo­
gen
– Zustimmung des
Fahrers
obligatorisch
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 529
Datenbezeichnung Datenformat Quelle
Dateneinstufung (personenbezogen/
nicht personenbezogen) Zustimmung zur Ver­
fügbarkeit der Daten
Verfügbarkeit
Fahrer Beifahrer
Driver1WorkingState ISO 16844-7 VU personenbezo­
gen
– Zustimmung des
Fahrers
obligatorisch
Driver2WorkingState ISO 16844-7 VU – personenbezo­
gen
Zustimmung des
Beifahrers
obligatorisch
DriveRecognize ISO 16844-7 VU nicht per­
sonenbezogen
nicht per­
sonenbezogen
keine Zustim­
mung erforderlich
obligatorisch
Driver1TimeRelated­
States
ISO 16844-7 VU personenbezo­
gen
– Zustimmung des
Fahrers
obligatorisch
Driver2TimeRelated­
States
ISO 16844-7 VU – personenbezo­
gen
Zustimmung des
Beifahrers
obligatorisch
DriverCardDriver1 ISO 16844-7 VU personenbezo­
gen
– Zustimmung des
Fahrers
obligatorisch
DriverCardDriver2 ISO 16844-7 VU – personenbezo­
gen
Zustimmung des
Beifahrers
obligatorisch
OverSpeed ISO 16844-7 VU personenbezo­
gen
– Zustimmung des
Fahrers
obligatorisch
TimeDate Anlage 8 VU nicht per­
sonenbezogen
nicht per­
sonenbezogen
keine Zustim­
mung erforderlich
obligatorisch
HighResolutionTotal­
VehicleDistance
ISO 16844-7 VU nicht per­
sonenbezogen
nicht per­
sonenbezogen
keine Zustim­
mung erforderlich
obligatorisch
HighResolutionTrip­
Distance
ISO 16844-7 VU nicht per­
sonenbezogen
nicht per­
sonenbezogen
keine Zustim­
mung erforderlich
obligatorisch
ServiceComponentI­
dentification
ISO 16844-7 VU nicht per­
sonenbezogen
nicht per­
sonenbezogen
keine Zustim­
mung erforderlich
obligatorisch
ServiceDelayCalend­
arTimeBased
ISO 16844-7 VU nicht per­
sonenbezogen
nicht per­
sonenbezogen
keine Zustim­
mung erforderlich
obligatorisch
Driver1Identification ISO 16844-7 Fah­
rer­
karte
personenbezo­
gen
– Zustimmung des
Fahrers
obligatorisch
Driver2Identification ISO 16844-7 Fah­
rer­
karte
– personenbezo­
gen
Zustimmung des
Beifahrers
obligatorisch
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 530
Datenbezeichnung Datenformat Quelle
Dateneinstufung (personenbezogen/
nicht personenbezogen) Zustimmung zur Ver­
fügbarkeit der Daten
Verfügbarkeit
Fahrer Beifahrer
NextCalibrationDate Anlage 8 VU nicht per­
sonenbezogen
nicht per­
sonenbezogen
keine Zustim­
mung erforderlich
obligatorisch
Driver1ContinuousDri­
vingTime
ISO 16844-7 VU personenbezo­
gen
– Zustimmung des
Fahrers
obligatorisch
Driver2ContinuousDri­
vingTime
ISO 16844-7 VU – personenbezo­
gen
Zustimmung des
Beifahrers
obligatorisch
Driver1Cumulative­
BreakTime
ISO 16844-7 VU personenbezo­
gen
– Zustimmung des
Fahrers
obligatorisch
Driver2Cumulative­
BreakTime
ISO 16844-7 VU – personenbezo­
gen
Zustimmung des
Beifahrers
obligatorisch
Driver1CurrentDuratio­
nOfSelectedActivity
ISO 16844-7 VU personenbezo­
gen
– Zustimmung des
Fahrers
obligatorisch
Driver2CurrentDuratio­
nOfSelectedActivity
ISO 16844-7 VU – personenbezo­
gen
Zustimmung des
Beifahrers
obligatorisch
SpeedAuthorised Anlage 8 VU nicht per­
sonenbezogen
nicht per­
sonenbezogen
keine Zustim­
mung erforderlich
obligatorisch
TachographCardSlot1 ISO 16844-7 VU nicht per­
sonenbezogen
– keine Zustim­
mung erforderlich
obligatorisch
TachographCardSlot2 ISO 16844-7 VU – nicht per­
sonenbezogen
keine Zustim­
mung erforderlich
obligatorisch
Driver1Name ISO 16844-7 Fah­
rer­
karte
personenbezo­
gen
– Zustimmung des
Fahrers
obligatorisch
Driver2Name ISO 16844-7 Fah­
rer­
karte
– personenbezo­
gen
Zustimmung des
Beifahrers
obligatorisch
OutOfScopeCondition ISO 16844-7 VU nicht per­
sonenbezogen
nicht per­
sonenbezogen
keine Zustim­
mung erforderlich
obligatorisch
ModeOfOperation ISO 16844-7 VU nicht per­
sonenbezogen
nicht per­
sonenbezogen
keine Zustim­
mung erforderlich
obligatorisch
Driver1CumulatedDri­
vingTimePreviousAnd­
CurrentWeek
ISO 16844-7 VU personenbezo­
gen
– Zustimmung des
Fahrers
obligatorisch
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 531
Datenbezeichnung Datenformat Quelle
Dateneinstufung (personenbezogen/
nicht personenbezogen) Zustimmung zur Ver­
fügbarkeit der Daten
Verfügbarkeit
Fahrer Beifahrer
Driver2CumulatedDri­
vingTimePreviousAnd­
CurrentWeek
ISO 16844-7 VU – personenbezo­
gen
Zustimmung des
Beifahrers
obligatorisch
EngineSpeed ISO 16844-7 VU personenbezo­
gen
– Zustimmung des
Fahrers
optional
RegisteringMember­
State
Anlage 8 VU nicht per­
sonenbezogen
nicht per­
sonenbezogen
keine Zustim­
mung erforderlich
obligatorisch
VehicleRegistration
Number
Anlage 8 VU nicht per­
sonenbezogen
nicht per­
sonenbezogen
keine Zustim­
mung erforderlich
obligatorisch
Driver1EndOfLastDai­
lyRestPeriod
ISO 16844-7 VU personenbezo­
gen
– Zustimmung des
Fahrers
optional
Driver2EndOfLastDai­
lyRestPeriod
ISO 16844-7 VU – personenbezo­
gen
Zustimmung des
Beifahrers
optional
Driver1EndOfLast­
WeeklyRestPeriod
ISO 16844-7 VU personenbezo­
gen
– Zustimmung des
Fahrers
optional
Driver2EndOfLast­
WeeklyRestPeriod
ISO 16844-7 VU – personenbezo­
gen
Zustimmung des
Beifahrers
optional
Driver1EndOfSecond­
LastWeeklyRestPeriod
ISO 16844-7 VU personenbezo­
gen
– Zustimmung des
Fahrers
optional
Driver2EndOfSecond­
LastWeeklyRestPeriod
ISO 16844-7 VU – personenbezo­
gen
Zustimmung des
Beifahrers
optional
Driver1TimeLastLoa­
dUnloadOperation
ISO 16844-7 VU personenbezo­
gen
– Zustimmung des
Fahrers
optional
Driver2TimeLastLoa­
dUnloadOperation
ISO 16844-7 VU – personenbezo­
gen
Zustimmung des
Beifahrers
optional
Driver1CurrentDaily­
DrivingTime
ISO 16844-7 VU personenbezo­
gen
– Zustimmung des
Fahrers
optional
Driver2CurrentDaily­
DrivingTime
ISO 16844-7 VU – personenbezo­
gen
Zustimmung des
Beifahrers
optional
Driver1CurrentWeekly­
DrivingTime
ISO 16844-7 VU personenbezo­
gen
– Zustimmung des
Fahrers
optional
Driver2CurrentWeekly­
DrivingTime
ISO 16844-7 VU – personenbezo­
gen
Zustimmung des
Beifahrers
optional
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 532
Datenbezeichnung Datenformat Quelle
Dateneinstufung (personenbezogen/
nicht personenbezogen) Zustimmung zur Ver­
fügbarkeit der Daten
Verfügbarkeit
Fahrer Beifahrer
Driver1TimeLeftUntil­
NewDailyRestPeriod
ISO 16844-7 VU personenbezo­
gen
– Zustimmung des
Fahrers
optional
Driver2TimeLeftUntil­
NewDailyRestPeriod
ISO 16844-7 VU – personenbezo­
gen
Zustimmung des
Beifahrers
optional
Driver1CardExpiry­
Date
ISO 16844-7 Fah­
rer­
karte
personenbezo­
gen
– Zustimmung des
Fahrers
optional
Driver2CardExpiry­
Date
ISO 16844-7 Fah­
rer­
karte
– personenbezo­
gen
Zustimmung des
Beifahrers
optional
Driver1CardNextMan­
datoryDownloadDate
ISO 16844-7 VU personenbezo­
gen
– Zustimmung des
Fahrers
optional
Driver2CardNextMan­
datoryDownloadDate
ISO 16844-7 VU – personenbezo­
gen
Zustimmung des
Beifahrers
optional
TachographNextMan­
datoryDownloadDate
ISO 16844-7 VU nicht per­
sonenbezogen
nicht per­
sonenbezogen
keine Zustim­
mung erforderlich
optional
Driver1TimeLeftUntil­
NewWeeklyRestPeriod
ISO 16844-7 VU personenbezo­
gen
– Zustimmung des
Fahrers
optional
Driver2TimeLeftUntil­
NewWeeklyRestPeriod
ISO 16844-7 VU – personenbezo­
gen
Zustimmung des
Beifahrers
optional
Driver1NumberOfTi­
mes9hDailyDrivingTi­
mesExceeded
ISO 16844-7 VU personenbezo­
gen
– Zustimmung des
Fahrers
optional
Driver2NumberOfTi­
mes9hDailyDrivingTi­
mesExceeded
ISO 16844-7 VU – personenbezo­
gen
Zustimmung des
Beifahrers
optional
Driver1Cumulative
UninterruptedRestTime
ISO 16844-7 VU personenbezo­
gen
– Zustimmung des
Fahrers
optional
Driver2Cumulative
UninterruptedRestTime
ISO 16844-7 VU – personenbezo­
gen
Zustimmung des
Beifahrers
optional
Driver1MinimumDai­
lyRest
ISO 16844-7 VU personenbezo­
gen
– Zustimmung des
Fahrers
optional
Driver2MinimumDai­
lyRest
ISO 16844-7 VU – personenbezo­
gen
Zustimmung des
Beifahrers
optional
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 533
Datenbezeichnung Datenformat Quelle
Dateneinstufung (personenbezogen/
nicht personenbezogen) Zustimmung zur Ver­
fügbarkeit der Daten
Verfügbarkeit
Fahrer Beifahrer
Driver1MinimumWee­
klyRest
ISO 16844-7 VU personenbezo­
gen
– Zustimmung des
Fahrers
optional
Driver2MinimumWee­
klyRest
ISO 16844-7 VU – personenbezo­
gen
Zustimmung des
Beifahrers
optional
Driver1MaximumDai­
lyPeriod
ISO 16844-7 VU personenbezo­
gen
– Zustimmung des
Fahrers
optional
Driver2MaximumDai­
lyPeriod
ISO 16844-7 VU – personenbezo­
gen
Zustimmung des
Beifahrers
optional
Driver1MaximumDai­
lyDrivingTime
ISO 16844-7 VU personenbezo­
gen
– Zustimmung des
Fahrers
optional
Driver2MaximumDai­
lyDrivingTime
ISO 16844-7 VU – personenbezo­
gen
Zustimmung des
Beifahrers
optional
Driver1NumberOfUse­
dReducedDailyRestPe­
riods
ISO 16844-7 VU personenbezo­
gen
– Zustimmung des
Fahrers
optional
Driver2NumberOfUse­
dReducedDailyRestPe­
riods
ISO 16844-7 VU – personenbezo­
gen
Zustimmung des
Beifahrers
optional
Driver1RemainingCur­
rentDrivingTime
ISO 16844-7 VU personenbezo­
gen
– Zustimmung des
Fahrers
optional
Driver2RemainingCur­
rentDrivingTime
ISO 16844-7 VU – personenbezo­
gen
Zustimmung des
Beifahrers
optional
VehiclePosition Anlage 8 VU personenbezo­
gen
personenbezo­
gen
Zustimmung des
Fahrers und des
Beifahrers
obligatorisch
ByDefaultLoadType Anlage 8 VU personenbezo­
gen
personenbezo­
gen
Zustimmung des
Fahrers und des
Beifahrers
obligatorisch
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 534
Anlage 14.
FERNKOMMUNIKATIONSFUNKTION
INHALTSVERZEICHNIS
1 EINFÜHRUNG
2 GELTUNGSBEREICH
3 AKRONYME, DEFINITIONEN UND NOTATIONEN
4 BETRIEBSSZENARIOS
4.1 Überblick
4.1.1 Voraussetzungen für den Datentransfer über die 5,8-GHz-DSRC-Schnitt­
stelle
4.1.2 Profil 1a: über eine von Hand ausgerichtete oder vorübergehend an der
Straße aufgestellte und ausgerichtete Fernabfragekommunikation
4.1.3 Profil 1b: über ein in einem Fahrzeug eingerichtetes und ausgerichtetes
Fernabfragegerät (REDCR)
4.2 Sicherheit/Integrität
5 DESIGN UND PROTOKOLLE DER FERNKOMMUNIKATION
5.1 Design
5.2 Ablauf
5.2.1 Betrieb
5.2.2 Interpretation der über die DSRC-Kommunikation empfangenen Daten
5.3 Parameter der physischen DSRC-Schnittstelle zur Fernkommunikation
5.3.1 Beschränkungen hinsichtlich des Ortes
5.3.2 Downlink- und Uplinkparameter
5.3.3 Antennendesign
5.4 DSRC-Protokollanforderungen für RTM
5.4.1 Überblick
5.4.2 Befehle
5.4.3 Abfragebefehlssequenz
5.4.4 Datenstrukturen
5.4.5 Elemente von RtmData, durchgeführte Aktionen und Definitionen
5.4.6 Mechanismus der Datenübertragung
5.4.7 Detaillierte Beschreibung der DSRC-Transaktion
5.4.8 Beschreibung der DSRC-Prüftransaktion
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 535
5.5 Reserviert für künftige Verwendung.
▼B
5.6 Datenübermittelung zwischen DSRC-VU und VU
5.6.1 Physische Verbindung und Schnittstellen
5.6.2 Anwendungsprotokoll
5.7 Fehlerbehandlung
5.7.1 Aufzeichnung und Kommunikation der Daten in der DSRC-VU
5.7.2 Fehler in der Drahtloskommunikation
6 INBETRIEBNAHME- UND REGELMÄSSIGE INSPEKTIONSPRÜ­
FUNGEN DER FERNKOMMUNIKATIONSFUNKTION
6.1 Allgemein
6.2 ECHO
6.3 Prüfungen zur Validierung sicherer Dateninhalte
1 EINFÜHRUNG
In dieser Anlage werden das Design und die Verfahren spezifiziert, die
bei der Umsetzung der Fernkommunikationsfunktion („Kommunika­
tion“) gemäß Artikel 9 der Verordnung (EU) Nr. 165/2014 (die Ver­
ordnung) befolgt werden müssen.
DSC_1 In der Verordnung (EU) Nr. 165/2014 ist festgelegt, dass der
Fahrtenschreiber mit einer Fernkommunikationsfunktion aus­
gestattet sein muss, durch die Mitarbeiter der zuständigen Kon­
trollbehörden Fahrtenschreiberinformationen vorbeifahrender
Fahrzeuge mithilfe eines Fernabfragegeräts (Remote Early De­
tection Communication Reader [REDCR]; Abfragegeräte, die
über DSRC-Schnittstellen [Dedicated Short Range Communi­
cation] mit CEN 5,8 GHz eine Drahtlosverbindung herstellen)
auslesen können.
Hierbei muss betont werden, dass diese Funktion lediglich als
Vorfilter dienen soll, um Fahrzeuge zur näheren Prüfung aus­
zuwählen, und nicht das formelle Prüfverfahren gemäß der
Verordnung (EU) Nr. 165/2014 ersetzt. Siehe Erwägungsgrund
9 in der Präambel dieser Verordnung, wo dargelegt wird, dass
die Fernkommunikation zwischen Fahrtenschreiber und Kon­
trollbehörden zu Straßenkontrollzwecken die Durchführung ge­
zielter Straßenkontrollen erleichtert.
DSC_2 Die Daten sind unter Verwendung der Kommunikation aus­
zutauschen; bei dieser handelt es sich um Drahtlosverkehr
über eine 5,8-GHz-DSRC-Drahtlosverbindung gemäß der An­
lage und geprüft gegen die geeigneten Parameter von EN 300
674-1 (Electromagnetic compatibility and Radio spectrum
Matters (ERM); Road Transport and Traffic Telematics
(RTTT); Dedicated Short Range Communication (DSRC)
transmission equipment (500 kbit/s/250 kbit/s) operating in
the 5,8 GHz Industrial, Scientific and Medical (ISM) band;
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 536
Part 1: General characteristics and test methods for Road Side
Units (RSU) and On -Board Units (OBU), Elektromagnetische
Verträglichkeit und Funkspektrumangelegenheiten (ERM) —
Straßentransport- und Verkehrstelematik (RTTT) — DSRC-
Übertragungseinrichtungen (500 kbit/s/250 kbit/s), die im
5,8-GHz-ISM-Band arbeiten — Teil 1: Allgemeine Kennwerte
und Prüfverfahren für Road Side Units (RSU) und On-Board
Units (OBU)).
DSC_3 Die Kommunikation ist ausschließlich dann mit dem Kom­
munikationsgerät herzustellen, wenn dies von dem Gerät der
zuständigen Kontrollbehörde mithilfe zulässiger Funkverbin­
dungsmittel (Remote Early Detection Communication
Reader (REDCR) angefordert wird.
DSC_4 Die Integrität der Daten ist zu schützen.
DSC_5 Der Zugang zu den übertragenen Daten ist auf die Kontroll­
behörden beschränkt, die ermächtigt sind, Verstöße gegen die
Verordnungen (EG) Nr. 561/2006 und (EU) Nr. 165/2014 zu
überprüfen, und auf Werkstätten, soweit ein Zugang für die
Überprüfung des ordnungsgemäßen Funktionierens des Fahr­
tenschreibers erforderlich ist.
DSC_6 Bei der Kommunikation dürfen nur Daten übertragen werden,
die für die Zwecke der gezielten Straßenkontrolle von Fahr­
zeugen notwendig sind, deren Fahrtenschreiber mutmaßlich
manipuliert oder missbraucht wurde.
DSC_7 Die Integrität und Sicherheit der Daten ist zu gewährleisten,
indem die Daten innerhalb der Fahrzeugeinheit (VU) gesichert
werden und indem ausschließlich die gesicherten Nutzlastdaten
und sicherheitsbezogenen Daten (siehe 5.4.4) über das 5,8-
GHz-DSRC-Fernkommunikationsmedium weitergegeben wer­
den, sodass nur befugte Personen zuständiger Kontrollbehör­
den in der Lage sind, die über die Kommunikation weiterge­
gebenen Daten zu verstehen und ihre Authentizität zu über­
prüfen. Siehe Anlage 11, Gemeinsame Sicherheitsmechanis­
men.
DSC_8 Die Daten müssen einen Zeitstempel mit dem Zeitpunkt der
letzten Aktualisierung enthalten.
DSC_9 Der Inhalt der Sicherheitsdaten darf nur den zuständigen Kon­
trollbehörden und denjenigen Parteien, mit denen sie diese
Informationen austauschen, bekannt sein und von diesen kon­
trolliert werden und liegt außerhalb der Bestimmungen der
Kommunikation, die Gegenstand dieser Anlage ist, sofern die
Kommunikation nicht vorsieht, mit jedem Paket an Nutzlast­
daten ein Paket an Sicherheitsdaten zu übermitteln.
DSC_10 Die Architektur und Geräte müssen in der Lage sein, mithilfe
der hierin angegebenen Architektur andere Datenkonzepte zu
verwenden (etwa eingebaute Wiegesysteme).
DSC_11 Zur Klarstellung: Gemäß den Bestimmungen der Verordnung
(EU) Nr. 165/2014 (Artikel 7) werden über die Kommunika­
tion keine Daten bezüglich der Identität des Fahrers übertra­
gen.
2 GELTUNGSBEREICH
In dieser Anlage wird festgelegt, wie die Mitarbeiter der zuständigen
Kontrollbehörden eine angegebene 5,8-GHz-DSRC- Drahtloskommuni­
kation verwenden, um aus der Entfernung Daten (die Daten) eines
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 537
anvisierten Fahrzeugs zu erhalten, die belegen, dass das anvisierten
Fahrzeug vermutlich gegen die Verordnung (EU) Nr. 165/2014 verstößt
und unter Umständen angehalten werden muss, um weitere Überprüfun­
gen vorzunehmen.
Die Verordnung (EU) Nr. 165/2014 schreibt vor, dass die erfassten
Daten sich auf Daten beschränken oder mit solchen im Zusammenhang
stehen müssen, die einen möglichen Verstoß eines der Datensubjekte
gemäß Definition in Artikel 9 der Verordnung (EU) Nr. 165/2014
belegen.
▼M1
In einem solchen Szenario ist die für die Kommunikation zur Verfügung
stehende Zeit begrenzt, da die Kommunikation zielgerichtet ist und in­
nerhalb einer Kurzstrecke erfolgt. Weiterhin können die zur Fahrten­
schreiberfernüberwachung (Remote Tachograph Monitoring, RTM) ge­
nutzten Daten von den zuständigen Kontrollbehörden auch für andere
Anwendungszwecke (z. B. höchstzulässige Gewichte und Abmessungen
von Nutzfahrzeugen gemäß der Richtlinie (EU) 2015/719) eingesetzt
werden; diese Maßnahmen können im Ermessen der zuständigen Kon­
trollbehörden getrennt oder aufeinanderfolgend durchgeführt werden.
▼B
In dieser Anlage wird Folgendes festgelegt:
— die zur Kommunikation genutzten Kommunikationsgeräte, -verfahren
und -protokolle
— die Normen und Verordnungen, die die Funkgeräte erfüllen müssen
— die Art, wie die Daten dem Kommunikationsgerät präsentiert werden
— die Abfrage- und Downloadverfahren sowie die Sequenz der Opera­
tionen
— die zu übertragenden Daten
— die mögliche Auslegung der über die Kommunikation übertragenen
Daten
— die Bestimmungen zu Sicherheitsdaten im Zusammenhang mit der
Kommunikation
— die Verfügbarkeit der Daten für die zuständigen Kontrollbehörden
— die Art und Weise, wie das Fernabfragegerät unterschiedliche Da­
tenkonzepte für Fracht und Flotten abfragen kann
Folgendes wird in dieser Anlage nicht festgelegt:
— die Erfassung und Verwaltung der Daten innerhalb der VU (diese
ergibt sich aus dem Produktdesign, sofern sie nicht an anderer Stelle
in der Verordnung (EU) Nr. 165/2014 festgelegt ist).
— die Art der Präsentation der erfassten Daten gegenüber dem Mit­
arbeiter der zuständigen Kontrollbehörden, ebenso wenig wie die
Kriterien, anhand derer die zuständigen Kontrollbehörden entschei­
den, welche Fahrzeuge angehalten werden (diese ergeben sich aus
dem Produktdesign, sofern sie nicht an anderer Stelle der
Verordnung (EU) Nr. 165/2014 oder in einer Grundsatzentscheidung
der zuständigen Kontrollbehörden festgelegt werden). Zur Klarstel­
lung: Durch die Kommunikation werden den zuständigen Kontroll­
behörden lediglich die Daten zur Verfügung gestellt, auf deren
Grundlage sie fundierte Entscheidungen treffen können.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 538
— Datensicherheitsbestimmungen (wie beispielsweise Verschlüsselung),
die den Inhalt der Daten betreffen (diese werden in Anlage 11
Gemeinsame Sicherheitsmechanismen spezifiziert).
— Einzelheiten von Datenkonzepten (ausgenommen RTM), die über die
gleiche Architektur und Ausrüstung erhalten werden können
— Details über das Verhalten und Management zwischen VU und
DSRC-VU, ebenso wenig wie das Verhalten innerhalb der
DSRC-VU (außer zum Bereitstellen der Daten nach Aufforderung
durch ein REDCR).
3 AKRONYME, DEFINITIONEN UND NOTATIONEN
Folgende für diese Anlage spezifische Akronyme und Definitionen wer­
den in dieser Anlage verwendet:
Antenne elektrisches Gerät, das Strom in
Funkwellen und umgekehrt umwan­
delt und zusammen mit einem Funk­
sender oder -empfänger verwendet
wird. Im Betrieb versorgt der Funk­
sender das Endgerät der Antenne
mit einem elektrischen Strom, der
in der Funkfrequenz oszilliert, und
die Antenne strahlt die Energie des
Stroms als elektromagnetische Wel­
len (Funkwellen) aus. Beim Emp­
fang fängt eine Antenne einen Teil
der Leistung der elektromagneti­
schen Welle ab, um eine kleine
Spannung an ihren Anschlüssen zu
erzeugen, die an einen Empfänger
angelegt und verstärkt wird.
Kommunikation Austausch von Informationen/Daten
zwischen DSRC-REDCR und
DSRC-VU gemäß Abschnitt 5 in
Master-Slave-Beziehung, um die
Daten zu erhalten.
Daten gesicherte Daten eines definierten
Formats (siehe 5.4.4), die vom
DSRC-REDCR abgerufen und dem
DSRC-REDCR per DSRC-VU über
eine 5,8-GHz-DSRC-Verbindung
nach Definition unter Ziffer 5 unten
bereitgestellt werden.
Verordnung (EU) Nr. 165/2014 Verordnung (EU) Nr. 165/2014 des
Europäischen Parlaments und des
Rates vom 4. Februar 2014 über
Fahrtenschreiber im Straßenverkehr,
zur Aufhebung der Verordnung
(EWG) Nr. 3821/85 des Rates über
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 539
das Kontrollgerät im Straßenverkehr
und zur Änderung der Verordnung
(EG) Nr. 561/2006 des Europäi­
schen Parlaments und des Rates
zur Harmonisierung bestimmter So­
zialvorschriften im Straßenverkehr
AID Application Identifier (Anwendungs­
kennung)
BLE Bluetooth Low Energy
BST Beacon Service Table
CIWD Card insertion while driving (Einste­
cken der Karte während des Len­
kens)
CRC Cyclic Redundancy Check (zykli­
sche Redundanzprüfung)
DSC (n) Kennung einer Anforderung an einer
bestimmten DSRC-Anlage
DSRC Dedicated Short Range Communica­
tion (Dedizierte Nahbereichskom­
munikation)
DSRC-REDCR DSRC — Remote Early Detection
Communication Reader
DSRC-VU DSRC — Vehicle Unit (Fahrzeug­
einheit, damit ist die in Anhang 1C
beschriebene „Fernabfrageausrüs­
tung“ gemeint)
DWVC Driving without valid card (Fahren
ohne gültige Karte)
EID Element Identifier (Elementken­
nung)
LLC Logical Link Control
LPDU LLC Protocol Data Unit
OWS Onboard Weighing System (Einge­
bautes Wiegesystem)
PDU Protocol Data Unit (Protokolldaten­
einheit)
REDCR Remote Early Detection Communi­
cation Reader (Fernabfragegerät, da­
mit ist das in Anhang 1C beschrie­
bene „Fernabfragegerät“ gemeint)
RTM Remote Tachograph Monitoring
(Fahrtenschreiberfernüberwachung)
SM-REDCR Security Module-Remote Early De­
tection Communication Reader (Si­
cherheitsmodul-Fernabfragegerät)
TARV Telematics Applications for Regula­
ted Vehicles [ISO 15638 series of
Standards] (Telematikanwendungen
für regulierte Fahrzeuge [ISO-Nor­
menreihe 15638])
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 540
VU Fahrzeugeinheit (Vehicle Unit, VU)
VUPM Vehicle Unit Payload Memory
(Nutzlastspeicher der Fahrzeugein­
heit)
VUSM Vehicle Unit Security Module (Fahr­
zeugeinheit-Sicherheitsmodul)
VST Vehicle Service Table (Service­
tabelle des Fahrzeugs)
WIM Weigh in motion (Wiegen unter­
wegs)
WOB Weigh on board (Wiegen an Bord)
Die in dieser Anlage definierte Spezifikation verweist auf die folgenden
Verordnungen und Normen im Ganzen oder in Teilen und hängt von
diesen ab. In den Klauseln dieser Anlage sind die relevanten Normen
oder die relevanten Klauseln der Normen angegeben. Bei Widersprüchen
haben die Klauseln dieser Anlage Vorrang. Im Falle eines Widerspruchs
und sofern in dieser Anlage nicht klar eine Spezifikation angegeben ist,
hat der Betrieb gemäß ERC 70-03 (und geprüft anhand der geeigneten
Parameter von EN 300 674-1) Vorrang, gefolgt in absteigender Reihen­
folge von EN 12795, EN 12253 EN 12834 und EN 13372, 6.2, 6.3, 6,4
und 7.1.
Auf folgende Verordnungen und Normen wird in dieser Anlage Bezug
genommen:
[1] Verordnung (EU) Nr. 165/2014 des Europäischen Parlaments und
des Rates vom 4. Februar 2014 über Fahrtenschreiber im Straßen­
verkehr, zur Aufhebung der Verordnung (EWG) Nr. 3821/85 des
Rates über das Kontrollgerät im Straßenverkehr und zur Änderung
der Verordnung (EG) Nr. 561/2006 des Europäischen Parlaments
und des Rates zur Harmonisierung bestimmter Sozialvorschriften
im Straßenverkehr
[2] Verordnung (EG) Nr. 561/2006 des Europäischen Parlaments und
des Rates vom 15. März 2006 zur Harmonisierung bestimmter
Sozialvorschriften im Straßenverkehr und zur Änderung der
Verordnungen (EWG) Nr. 3821/85 und (EG) Nr. 2135/98 des Ra­
tes sowie zur Aufhebung der Verordnung (EWG) Nr. 3820/85 des
Rates.
[3] ERC 70-03 CEPT: ECC-Empfehlung 70-03: Relating to the Use of
Short Range Devices (SRD)
[4] ISO 15638 Intelligent transport systems — Framework for coope­
rative telematics applications for regulated commercial freight
vehicles (TARV).
[5] EN 300 674-1 Electromagnetic compatibility and Radio spectrum
Matters (ERM); Road Transport and Traffic Telematics (RTTT);
Dedicated Short Range Communication (DSRC) transmission
equipment (500 kbit/s/250 kbit/s) operating in the 5,8 GHz Indus­
trial, Scientific and Medical (ISM) band; Part 1: General characte­
ristics and test methods for Road Side Units (RSU) and On-Board
Units (OBU) (Elektromagnetische Verträglichkeit und Funkspektru­
mangelegenheiten (ERM) — Straßentransport- und Verkehrstele­
matik (RTTT) — DSRC-Übertragungseinrichtungen (500 kbit/
s/250 kbit/s), die im 5,8-GHz-ISM-Band arbeiten — Teil 1: All­
gemeine Kennwerte und Prüfverfahren für Road Side Units (RSU)
und On-Board Units (OBU)).
[6] EN 12253 Road transport and traffic telematics — Dedicated
short-range communication — Physical layer using microwave at
5.8 GHz (Straßentransport- und Verkehrstelematik — Nahbereichs­
kommunikation — Datenverbindungsschicht — Bitübertragungs­
schicht für die Frequenz 5,8 GHz) (Straßentransport- und Verkehrs­
telematik (RTTT) — Nahbereichskommunikation Fahrzeug-Bake
(DSRC) — Bitübertragungsschicht für die Frequenz 5,8 GHz).
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 541
[7] EN 12795 Road transport and traffic telematics — Dedicated
short-range communication — Data link layer: medium access
and logical link control (Straßentransport- und Verkehrstelematik
— Nahbereichskommunikation — Datenverbindungsschicht — Zu­
griffsmedium und Verbindungssteuerung).
[8] EN 12834 Road transport and traffic telematics — Dedicated
short-range communication — Application layer (Straßentransport-
und Verkehrstelematik — Nahbereichskommunikation — Anwen­
dungsschicht).
[9] EN 13372 Road transport and traffic telematics — Dedicated
short-range communication — Profiles for RTTT applications
(Straßentransport- und Verkehrstelematik — Nahbereichskommuni­
kation — DSRC-Profile für RTTT-Anwendungen).
[10] ISO 14906 Electronic fee collection — Application interface de­
finition for dedicated short- range communication (Elektronische
Gebührenerhebung — Anwendungsschnittstelle zur dezidierten
Nahbereich-Kommunikation)
4 BETRIEBSSZENARIOS
4.1 Überblick
In der Verordnung (EU) Nr. 165/2014 sind spezifische und kontrollierte
Szenarios vorgesehen, innerhalb derer die Kommunikation zu verwenden
ist.
Die unterstützen Szenarios lauten:
„Kommunikationsprofil 1: Straßenkontrolle mithilfe eines drahtlosen
Nahbereich-Fernabfragegeräts, die eine physische Straßenkontrolle in
Gang setzt (Master–Slave)
Leserprofil 1a: über eine von Hand ausgerichtete oder vorübergehend
an der Straße aufgestellte und ausgerichtete Fernabfragekommunikation
Leserprofil 1b: über ein in einem Fahrzeug eingerichtetes und aus­
gerichtetes Fernabfragegerät“.
4.1.1 Voraussetzungen für den Datentransfer über die 5,8-GHz-DSRC-Schnitt­
stelle
HINWEIS: Für ein besseres Verständnis des Kontexts der Vorausset­
zungen siehe Abbildung 14.3 unten.
4.1.1.1 In der VU gespeicherte Daten
DSC_12 Die VU ist dafür verantwortlich, die in ihr zu speichernden
Daten ohne Einbeziehung der DSRC-Kommunikationsfunktion
alle 60 Sekunden zu aktualisieren und auf dem neuesten Stand
zu halten. Die Mittel, mit denen dies erreicht wird, sind eine
wesentliche Eigenschaft der VU und nicht in dieser Anlage,
sondern in Anhang 1C Abschnitt 3.19 „Fernkommunikation für
gezielte Straßenkontrollen“ der Verordnung (EU) Nr. 165/2014
angegeben.
4.1.1.2 Der DSRC-VU-Ausrüstung bereitgestellte Daten
DSC_13 Die VU ist dafür verantwortlich, die Daten des DSRC-Fahrten­
schreibers (die Daten) zu aktualisieren, sobald die in der VU
gespeicherten Daten aktualisiert werden. Dies erfolgt in dem in
4.1.1.1 (DSC_12) angegebenen Intervall und ohne Beteiligung
der DSRC-Kommunikationsfunktion.
DSC_14 Die VU-Daten dienen als Grundlage zur Einspeisung und Ak­
tualisierung der Daten; die Mittel, durch die dies erreicht wird,
sind in Anhang 1C Abschnitt 3.19 „Fernkommunikation für
gezielte Straßenkontrollen“ der festgelegt oder sind, wenn
keine solche Festlegung vorliegt, abhängig vom Produktdesign
und werden nicht in dieser Anlage spezifiziert. Zur Konzeption
der Verbindung zwischen DSRC-VU-Ausrüstung und VU
siehe Abschnitt 5.6.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 542
4.1.1.3 Inhalt der Daten
DSC_15 Inhalt und Format der Daten sind so zu gestalten, dass sie nach
Entschlüsselung in Form und Format wie in 5.4.4 dieser An­
lage (Datenstrukturen) angegeben strukturiert sind und verfüg­
bar gemacht werden.
4.1.1.4 Präsentation der Daten
DSC_16 Die Daten, die gemäß dem in 4.1.1.1 angegebenen Verfahren
regelmäßig aktualisiert worden sind, werden vor der Präsenta­
tion gegenüber der DSRC-VU gesichert und als gesicherter
Datenkonzeptwert präsentiert, um in der DSRC-VU als aktuelle
Version der Daten temporär gespeichert zu werden. Diese
Daten werden von der VUSM an die DSRC-Funktion VUPM
weitergeleitet. VUSM und VUPM sind Funktionen und nicht
zwangsläufig physische Einheiten. Die Form der physischen
Instanziierung, um diese Funktionen zu erfüllen, ist eine Frage
des Produktdesigns, sofern sie nicht an anderer Stelle in der
Verordnung (EU) Nr. 165/2014 festgelegt ist.
4.1.1.5 Sicherheitsdaten
▼M3
DSC_17 Sicherheitsdaten (DSRCSecurityData), die die vom REDCR
benötigten Daten zur Erfüllung seiner Aufgabe, die Daten zu
entschlüsseln, enthalten, müssen gemäß Anlage 11 „Gemein­
same Sicherheitsmechanismen“ zur vorübergehenden Speiche­
rung in der DSRC-VU als aktuelle Version der DSRCSecuri­
tyData in der in dieser Anlage in Nummer 5.4.4 definierten
Form bereitgestellt werden.
▼B
4.1.1.6 VUPM-Daten verfügbar zur Übermittlung per DSRC-Schnittstelle
DSC_18 Das Datenkonzept, das jederzeit in der DSRC-Funktion
VUPM zur unmittelbaren Übertragung auf Anfrage durch das
REDCR zur Verfügung stehen muss, ist in Abschnitt 5.4.4 für
die vollständigen Spezifikationen des ASN.1-Moduls definiert.
Allgemeiner Überblick über das Kommunikationsprofil 1
Dieses Profil betrifft den Anwendungsfall, in dem ein Mitarbeiter der
zuständigen Kontrollbehörden ein Nahbereich-Fernabfragegerät (5,8-
GHz-DSRC-Schnittstellen, betrieben innerhalb von ERC 70-03 und ge­
prüft gegen die geeigneten Parameter von EN 300 674-1 gemäß Ab­
schnitt 5) (REDCR), um per Fernkommunikation ein Fahrzeug zu iden­
tifizieren, das möglicherweise gegen Verordnung (EU) Nr. 165/2014
verstößt. Nach der Identifizierung entscheidet der Mitarbeiter der zustän­
digen Kontrollbehörden, der die Abfrage kontrolliert, ob das Fahrzeug
angehalten werden soll.
4.1.2 Profil 1a: über eine von Hand ausgerichtete oder vorübergehend an der
Straße aufgestellte und ausgerichtete Fernabfragekommunikation
In diesem Fall befindet sich der Mitarbeiter der zuständigen Kontroll­
behörden am Straßenrand und richtet ein auf einem Stativ befestigtes
oder tragbares Handgerät, REDCR, vom Straßenrand aus auf die Mitte
der Windschutzscheibe des anvisierten Fahrzeugs. Die Abfrage erfolgt
mithilfe von 5,8-GHz-DSRC-Schnittstellen, betrieben innerhalb von
ERC 70-03 und geprüft gegen die geeigneten Parameter von EN 300
674-1 gemäß Abschnitt 5. Siehe Abbildung 14.1 (Anwendungsfall 1).
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 543
Abbildung 14.1
Abfrage am Straßenrand mithilfe von 5,8-GHz-DSRC
4.1.3 Profil 1b: über ein in einem Fahrzeug eingerichtetes und ausgerichtetes
Fernabfragegerät (REDCR)
In diesem Fall befindet sich der Mitarbeiter der zuständigen Kontroll­
behörden in einem sich bewegenden Fahrzeug und richtet entweder ein
REDCR-Handgerät aus dem Fahrzeug auf die Mitte der Windschutz­
scheibe des anvisierten Fahrzeugs, oder das REDCR ist in oder auf
dem Fahrzeug montiert und zeigt auf die Mitte der Windschutzscheibe
des anvisierten Fahrzeugs, wenn sich das Fahrzeug mit dem Fernabfra­
gegerät in einer bestimmten Position zum anvisierten Fahrzeug befindet
(zum Beispiel unmittelbar voraus im Verkehrsfluss). Die Abfrage erfolgt
mithilfe von 5,8-GHz-DSRC-Schnittstellen, betrieben innerhalb von
ERC 70-03 und geprüft gegen die geeigneten Parameter von EN 300
674-1 gemäß Abschnitt 5. Siehe Abbildung 14.2 (Anwendungsfall 2).
Abbildung 14.2
Abfrage aus dem Fahrzeug mithilfe von 5,8-GHz-DSRC (s. o.)
4.2 Sicherheit/Integrität
Um die die Authentizität und Integrität der heruntergeladenen Daten per
Fernkommunikation überprüfen zu können, werden die gesicherten Da­
ten gemäß Anlage 11 Gemeinsame Sicherheitsmechanismen verifiziert
und entschlüsselt.
5 DESIGN UND PROTOKOLLE DER FERNKOMMUNIKATION
5.1 Design
Das Design der Fernkommunikationsfunktion im intelligenten Fahrten­
schreiber ist in Abbildung 14.3 dargestellt.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 544
Abbildung 14.3
Design der Fernkommunikationsfunktion
DSC_19 Die VU enthält die folgenden Funktionen:
— Sicherheitsmodul (VUSM). Diese in der VU vorhandene
Funktion ist für die Sicherung der Daten zuständig, die
per Fernkommunikation von der DSRC-VU an den Mit­
arbeiter der zuständigen Kontrollbehörden übermittelt wer­
den sollen.
— Die gesicherten Daten werden im VUSM-Speicher abge­
legt. In den in 4.1.1.1 (DSC_12) festgelegten Intervallen
verschlüsselt und befüllt die VU das RTMdata-Konzept
(welches die weiter unten in dieser Anlage festgelegten
Nutzlast- und Sicherheitsdatenkonzeptwerte umfasst) im
Speicher der DSRC-VU. Der Betrieb des Sicherheits­
moduls ist in Anlage 11 Gemeinsame Sicherheitsmecha­
nismen definiert und fällt nicht in den Anwendungsbereich
dieser Anlage, sofern es nicht dafür benötigt wird, das
VU-Kommunikationsgerät jeweils bei einer Änderung der
VUSM-Daten zu aktualisieren.
— Die Kommunikation zwischen VU und DSRC-VU kann
per drahtgebundener Kommunikation oder per BLE-Kom­
munikation (Bluetooth Low Energy) erfolgen; die DSRC-
VU kann in die Antenne auf der Windschutzscheibe des
Fahrzeugs integriert sein, interner Bestandteil der VU sein
oder sich irgendwo dazwischen befinden.
— Die DSRC-VU benötigt eine jederzeit verfügbare Strom­
quelle. Die Art der Stromversorgung kann im Rahmen des
Produktdesigns entschieden werden.
— Der Speicher der DSRC-VU muss nichtflüchtig sein, damit
die Daten stets in der DSRC-VU verbleiben, selbst wenn
die Fahrzeugzündung ausgeschaltet ist.
— Wenn die Kommunikation zwischen VU und DSRC-VU
per BLE erfolgt und es sich bei der Stromquelle um eine
nicht wieder aufladbare Batterie handelt, muss die Strom­
quelle der DSRC-VU bei jeder regelmäßigen Nachprüfung
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 545
ausgetauscht werden; der Hersteller der DSRC-VU-Ausrüs­
tung muss sicherstellen, dass die Stromversorgung den
Zeitraum zwischen zwei aufeinanderfolgenden regelmäßi­
gen Nachprüfungen übersteht und in diesem Zeitraum ohne
Ausfall oder Unterbrechung einen normalen Zugriff auf die
Daten per REDCR gewährleistet
— VU-RTM-„Datennutzlastspeicher“ (VUPM). Diese Funk­
tion in der VU ist für die Bereitstellung und Aktualisierung
der Daten verantwortlich. Der Inhalt der Daten („Fahrten­
schreibernutzlast“) wird in 5.4.4/5.4.5 unten definiert und
in dem in 4.1.1.1 (DSC_12) festgelegten Intervall
aktualisiert.
— DSRC-VU. Diese Funktion innerhalb der VU oder mit
dieser per Antenne in drahtgebundener oder drahtloser
(BLE) Kommunikation stehend speichert die aktuellen Da­
ten (VUPM-Daten) und steuert die Antwort auf eine Ab­
frage über das 5,8-GHz-DSRC-Medium. Eine Trennung
der DSRC-Einrichtung oder Störung der Funktion des
DSRC-Geräts während des normalen Fahrzeugbetriebs
gilt als Verstoß gegen die Verordnung (EU) Nr. 165/2014.
— Das Sicherheitsmodul (REDCR) (SM-REDCR) ist die
Funktion zur Entschlüsselung und Integritätsprüfung der
aus der VU stammenden Daten. Die Mittel, mit denen
dies erreicht wird, sind in Anlage 11 Gemeinsame Sicher­
heitsmechanismen festgelegt und nicht in dieser Anlage
definiert.
— Das DSRC-Gerät (REDCR) (DSRC-REDCR) beinhaltet ei­
nen 5,8-GHz-Sender und dazugehörige Firm- und Soft­
ware, welche die Kommunikation mit der DSRC-VU in
Überstimmung dieser Anlage gewährleisten.
— Das DSRC-REDCR fragt die DSRC-VU des anvisierten
Fahrzeugs ab, erhält die Daten (die aktuellen VUPM-Daten
des anvisierten Fahrzeugs) per DSRC-Verbindung und
speichert diese in seinem SM-REDCR ab.
▼M1
— Die DSRC-VU-Antenne muss an einer Stelle angebracht
werden, an der sie die DSRC-Kommunikation zwischen
dem Fahrzeug und der Antenne am Straßenrand optimiert,
wenn das Lesegerät 15 Meter vor dem Fahrzeug und in
2 Meter Höhe installiert und auf die horizontale und ver­
tikale Mitte der Windschutzscheibe gerichtet ist. Bei leich­
ten Fahrzeugen ist eine Anbringung im oberen Teil der
Windschutzscheibe geeignet. Bei allen anderen Fahrzeugen
muss die DSRC-Antenne entweder nahe dem unteren Teil
oder nahe dem oberen Teil der Windschutzscheibe einge­
baut sein.
▼B
DSC_20 Betrieb der Antenne und der Kommunikation erfolgt innerhalb
von ERC 70-03 und geprüft gegen die geeigneten Parameter
von EN 300 674-1 gemäß Abschnitt 5. Antenne und Kom­
munikation können über Verfahren zur Minderung der Risiken
von Funkstörungen gemäß ECC-Bericht 228 verfügen, also z.
B. mit Filtern in der CEN-DSRC 5,8 GHz-Kommunikation
ausgestattet sein,
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 546
DSC_21 Die DSRC-Antenne muss mit der DSRC-VU-Ausrüstung ent­
weder direkt in dem an oder in der Nähe der Windschutz­
scheibe angebrachten Modul oder über ein spezielles Kabel,
das durch seine Bauart eine rechtswidrige Trennung erschwert,
verbunden sein. Eine Trennung oder Störung der Funktion der
Antenne während des normalen Fahrzeugbetriebs gilt als Ver­
stoß gegen die Verordnung (EU) Nr. 165/2014. Ein absicht­
liches Verbergen oder eine sonstige Beeinträchtigung der An­
tennenfunktion ist als Verstoß gegen Verordnung (EU)
Nr. 165/2014 auszulegen.
DSC_22 ►M1 Der Formfaktor der Antenne ist nicht definiert und
kann betriebswirtschaftlich entschieden werden, solange die
angebrachte DSRC-VU die Konformitätsvorgaben in Ab­
schnitt 5 unten erfüllt. Die Antenne soll gemäß den Festlegun­
gen in DSC_19 befestigt werden und muss den in 4.1.2 und
4.1.3 beschriebenen Anwendungsfällen effizient gerecht
werden. ◄
Abbildung 14.4
Anbringung der 5,8-GHz-DSRC-Antenne an der Windschutzscheibe
regulierter Fahrzeuge (HINWEIS: Legende im Bild soll nicht
übersetzt werden, Titel der Abbildung ist ausreichend)
Der Formfaktor von REDCR und Antenne kann je nach den vom Mit­
arbeiter der zuständigen Kontrollbehörden gewählten Lese- (Stativbefes­
tigung, Handgerät, Fahrzeugbefestigung usw.) und Betriebsmodi
variieren.
Die Ergebnisse der Fernkommunikationsfunktion werden dem Mitarbei­
ter der zuständigen Kontrollbehörden mittels einer Anzeige- und/oder
Benachrichtigungsfunktion präsentiert. Eine Anzeige kann auf einem
Bildschirm, als Ausdruck, als Audiosignal oder als Kombination solcher
Benachrichtigungen erfolgen. Die Form einer solchen Anzeige und/oder
Benachrichtigung hängt von den Anforderungen der Mitarbeiter der zu­
ständigen Kontrollbehörden und dem Gerätedesign ab und ist in dieser
Anlage nicht festgelegt.
DSC_23 Design und Formfaktor des REDCR ergeben sich aus dem
kommerziellen Design innerhalb von ERC 70-03 und den
Design- und Leistungsvorgaben in dieser Anlage (Abschnitt
5.3.2), wodurch der Markt über maximale Flexibilität verfügt,
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 547
um die Ausrüstung nach den besonderen Anforderungen der
zuständigen Kontrollbehörden für deren jeweilige Abfragesze­
narios zu gestalten und bereitzustellen.
DSC_24 Design und Formfaktor der DSRC-VU und deren Positionie­
rung innerhalb oder außerhalb der VU ergeben sich aus dem
kommerziellen Design innerhalb der Vorgaben von ERC 70-03
und den in dieser Anlage (Abschnitt 5.3.2) und innerhalb die­
ses Abschnitts (5.1) angegebenen Design- und Leistungsvor­
gaben.
DSC_25 Allerdings muss die DSRC-VU auf angemessene Weise in der
Lage sein, Datenkonzeptwerte anderer intelligenter Fahrzeug­
ausrüstung über eine Verbindung und Protokolle eines offenen
Branchenstandards zu akzeptieren (zum Beispiel von Geräten
zum Wiegen an Bord), solange solche Datenkonzepte durch
eindeutige und bekannte Anwendungskennungen/Dateinamen
identifiziert sind und die Anweisungen zum Betrieb solcher
Protokolle der Europäischen Kommission zur Verfügung ge­
stellt werden und den Herstellern der relevanten Ausrüstung
ohne Kosten verfügbar gemacht werden.
5.2 Ablauf
5.2.1 Betrieb
Der Betriebsablauf ist in Abbildung 14.5 dargestellt. (HINWEIS: Soll
nicht übersetzt werden)
Abbildung 14.5
Ablauf der Fernkommunikationsfunktion
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 548
Die Schritte werden im Folgenden beschrieben:
a. Immer, wenn sich das Fahrzeug in Betrieb befindet (Zündung einge­
schaltet), stellt der Fahrtenschreiber der VU-Funktion Daten bereit.
Die VU-Funktion bereitet die Daten für die Fernkommunikations­
funktion (verschlüsselt) vor und aktualisiert die VUPM im Speicher
der DSRC-VU (gemäß Definition in 4.1.1.1 — 4.1.1.2). Die erfassten
Daten sind wie in 5.4.4 bis 5.4.5 unten dargelegt zu formatieren.
b. Jedes Mal, wenn die Daten aktualisiert werden, ist auch der im
Sicherheitsdatenkonzept definierte Zeitstempel zu aktualisieren.
c. Die VUSM-Funktion sichert die Daten gemäß den in Anlage 11
angegebenen Verfahren.
d. Jedes Mal, wenn die Daten aktualisiert werden (siehe 4.1.1.1 bis
4.1.1.2), werden die Daten an die DSRC-VU übermittelt, wo sie
alle vorherigen Daten ersetzen, damit die aktualisierten Daten (die
Daten) immer zur Verfügung stehen, um bei einer Abfrage durch ein
REDCR bereitgestellt zu werden. Wenn sie von der VU der
DSRC-VU bereitgestellt werden, müssen die Daten anhand des Da­
teinamens RTMData oder Anwendungs-ID und Attributskennung zu
identifizieren sein.
e. Wenn ein Mitarbeiter der zuständigen Kontrollbehörden ein Fahrzeug
anvisieren und von diesem die Daten erfassen möchte, muss der
Mitarbeiter der zuständigen Kontrollbehörden zuerst seine Chipkarte
in das REDCR einsetzen, um die Kommunikation zu ermöglichen
und dem SM-REDCR zu ermöglichen, die Authentizität zu überprü­
fen und die Daten zu entschlüsseln.
f. Anschließend visiert der Mitarbeiter der zuständigen Kontrollbehörde
ein Fahrzeug an und fordert per Fernkommunikation die Daten an.
Das REDCR eröffnet mit dem DSRC-VU des anvisierten Fahrzeugs
eine 5,8-GHz-DSRC-Schnittstellensitzung und fordert die Daten an.
Die Daten werden über das Drahtloskommunikationssystem als
DSRC-Attribut mithilfe des Anwendungsdienstes GET gemäß 5.4
an das REDCR übermittelt. Das Attribut enthält die verschlüsselten
Nutzdatenwerte und die DSRC-Sicherheitsdaten.
g. Die Daten werden durch das REDCR-Gerät analysiert und dem Mit­
arbeiter der zuständigen Kontrollbehörde bereitgestellt.
h. Der Mitarbeiter der zuständigen Kontrollbehörde nutzt die Daten zur
Unterstützung bei der Entscheidung, ob er oder ein anderer Mitarbei­
ter der zuständigen Kontrollbehörde das Fahrzeug für eine umfang­
reiche Überprüfung anhalten soll.
5.2.2 Interpretation der über die DSRC-Kommunikation empfangenen Daten
DSC_26 Für die über die 5,8-GHz-Schnittstelle empfangenen Daten
gelten Bedeutung und Tragweite entsprechend der Definition
in 5.4.4 und 5.4.5 unten und auch nur diese Bedeutung und
Tragweite sind im Rahmen der hierin definierten Ziele zu
verstehen. Gemäß den Bestimmungen der Verordnung (EU)
Nr. 165/2014 dürfen die Daten nur dazu verwendet werden,
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 549
einer zuständigen Kontrollbehörde zweckdienliche Informatio­
nen zur Hand zu geben, um zu entscheiden, welches Fahrzeug
zu einer physischen Überprüfung angehalten werden soll, und
müssen anschließend gemäß Artikel 9 der Verordnung (EU)
Nr. 165/2014 vernichtet werden.
5.3 Parameter der physischen DSRC-Schnittstelle zur Fernkommunika­
tion
5.3.1 Beschränkungen hinsichtlich des Ortes
DSC_27 Die Fernabfrage von Fahrzeugen über eine 5,8-GHz-DSRC-
Schnittstelle sollte nicht innerhalb von 200 Metern um eine in
Betrieb befindliche 5,8-GHz-DSRC-Brücke erfolgen.
5.3.2 Downlink- und Uplinkparameter
DSC_28 Die zur Fahrtenschreiberfernüberwachung verwendete Ausrüs­
tung muss ERC 70-03 und die in den Tabellen 14.1 und 14.2
unten definierten Parameter erfüllen und innerhalb dieser be­
trieben werden.
DSC_29 Zudem muss die zur Fahrtenschreiberfernüberwachung ver­
wendete Ausrüstung, um Kompatibilität mit den Betriebspara­
metern anderer standardisierter 5,8-GHz-DSRC-Systeme zu
gewährleisten, den Parametern aus EN 12253 und EN 13372
entsprechen.
Namentlich:
Tabelle 14.1
Downlink-Parameter
Punkt Parameter Wert(e) Anmerkung
D1 Downlink-Trägerfrequenzen Dem REDCR stehen vier
Alternativen zur Verfügung:
5,7975 GHz
5,8025 GHz
5,8075 GHz
5,8125 GHz
Innerhalb von ERC 70-03.
Die Trägerfrequenzen können vom
Implementierer des Straßenrand­
kontrollsystems ausgewählt werden
und brauchen in der DSRC-VU
nicht bekannt zu sein.
(Konsistent mit EN 12253, EN
13372)
D1a (*) Toleranz der Träger-fre­
quenzen
innerhalb von ± 5 ppm (Konsistent mit EN 12253)
D2 (*) RSU (REDCR)-Sendespek­
trumsmaske
Innerhalb von ERC 70-03.
Das REDCR muss Klasse
B,C gemäß EN 12253 ent­
sprechen.
Keine anderen spezifischen
Anforderungen innerhalb
dieses Anhangs
Parameter zur Kontrolle der Inter­
ferenz zwischen benachbarten Ab­
frageeinrichtungen (gemäß EN
12253 und EN 13372).
D3 OBU (DSRC-VU)-Mindest­
frequenzbereich
5,795 — 5,815 GHz (Konsistent mit EN 12253)
D4 (*) Max. E.I.R.P. Innerhalb von ERC 70-03
(unlizenziert) und innerhalb
der nationalen Vorschriften
Max. + 33 dBm
(Konsistent mit EN 12253)
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 550
Punkt Parameter Wert(e) Anmerkung
D4a E.I.R.P.-Winkelmaske Gemäß der deklarierten und
veröffentlichten Spezifika­
tion des Konstrukteurs der
Abfrageeinrichtung
(Konsistent mit EN 12253)
D5 Polarisation Linkszirkular (Konsistent mit EN 12253)
D5a Kreuzpolarisation XPD:
In Achsensicht: (REDCR)
RSU t ≥ 15 δB
(DSRC-VU) OBU r ≥ 10 δB
Im Bereich – 3 dB:
(REDCR) RSU t ≥ 10 δB
(DSRC-VU) OBU r ≥ 6 δB
(Konsistent mit EN 12253)
D6 (*) Modulation Zweistufige Amplitudenmo­
dulation
(Konsistent mit EN 12253)
D6a (*) Modulationsindex 0,5 … 0,9 (Konsistent mit EN 12253)
D6b Augendiagramm ≥ 90 % (Zeit) / ≥ 85 %
(Amplitude)
D7 (*) Datenverschlüsselung FM0
Bit „1“ weist lediglich zu
Beginn und Ende des
Bit-Intervalls Übergänge
auf. Bit „0“ weist gegen­
über dem Bit „1“ in der
Mitte des Bit-Intervalls ei­
nen zusätzlichen Übergang
auf.
(Konsistent mit EN 12253)
D8 (*) Bit-Rate 500 kBit/s (Konsistent mit EN 12253)
D8a Toleranz des Bit-Takts besser als ± 100 ppm (Konsistent mit EN 12253)
D9 (*) Bit-Fehlerquote (B.E.R.) zur
Kommunikation
≤ 10 – 6 wenn Vorlaufleis­
tung bei OBU (DSRC-VU)
in dem durch [D11a bis
D11b] vorgegebenen Be­
reich liegt.
(Konsistent mit EN 12253)
D10 Weckimpuls für OBU
(DSRC-VU)
OBU (DSRC-VU) muss
beim Empfang von Frames
mit 11 oder mehr Oktetten
(einschl. Präambel)
aufwachen.
Es ist kein spezielles Weckmuster
erforderlich.
DSRC-VU kam beim Empfang von
Frames mit weniger als 11 Oktetten
aufwachen.
(Konsistent mit EN 12253)
D10a Maximale Startzeit ≤ 5 ms (Konsistent mit EN 12253)
D11 Kommunikationsbereich Raum, in dem eine B.E.R.
gemäß D9a erreicht wird
(Konsistent mit EN 12253)
D11a (*) (Obere) Leistungsgrenze zur
Kommunikation.
– 24 dBm (Konsistent mit EN 12253)
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 551
Punkt Parameter Wert(e) Anmerkung
D11b (*) (Untere) Leistungsgrenze
zur Kommunikation.
Vorlaufleistung:
– 43 dBm (Mittelachse)
– 41 dBm (im Bereich von
– 45° bis + 45° entspre­
chend der Ebene parallel
zur Straßenoberfläche,
wenn die DSRC-VU später
im Fahrzeug installiert wird
(Azimuth))
(Konsistent mit EN 12253)
Erweiterte Voraussetzungen für
waagerechte Winkel bis ± 45° auf­
grund der in diesem Anhang de­
finierten Anwendungsfälle.
D12 (*) IVS-Leistungsgrenzwert
(DSRC-VU)
– 60 dBm (Konsistent mit EN 12253)
D13 Präambel Präambel vorgeschrieben. (Konsistent mit EN 12253)
D13a Präambellänge und -muster ►C2 16 Bits ± 1 Bit FM0-
kodierter „1“-Bits ◄
(Konsistent mit EN 12253)
D13b Präambelwellenform Wechselnde Hoch-/Niedrig­
sequenz mit einer Impuls­
dauer von 2 μs.
Toleranz gemäß D8a
(Konsistent mit EN 12253)
D13c Nachlaufende Bits ►C2 Die RSU (REDCR)
darf nach dem Endmerker
maximal 8 Bits
übertragen. ◄ Zur Berück­
sichtigung dieser zusätzli­
chen Bits ist keine OBU
(DSRC-VU) erforderlich.
(Konsistent mit EN 12253)
(*) — Downlink-Parameter unterliegen Konformitätsprüfung gemäß relevanter Parameterprüfung aus EN 300 674-1
Tabelle 14.2
Uplink-Parameter
Punkt Parameter Wert(e) Anmerkung
U1 (*) Unterträgerfrequenzen Eine OBU (DSRC-VU) un­
terstützt 1,5 MHz und 2,0
MHz
Eine RSU (REDCR) unter­
stützt 1,5 MHz oder 2,0
MHz oder beides U1-0: 1,5
MHz U1-1: 2,0 MHz
Auswahl der Unterträgerfrequenz
(1,5 MHz oder 2,0 MHz) abhängig
vom ausgewählten EN-13372-Pro­
fil.
U1a (*) Toleranz der Unterträgerfre­
quenzen
innerhalb von ± 0,1 % (Konsistent mit EN 12253)
U1b Nutzung von Seitenbändern Gleiche Daten auf beiden
Seiten
(Konsistent mit EN 12253)
U2 (*) OBU (DSRC-VZ)-Sende­
spektrumsmaske
Gemäß EN 12253
1) Außenbandleistung:
siehe ETSI EN 300 674-1
(Konsistent mit EN 12253)
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 552
Punkt Parameter Wert(e) Anmerkung
2) Innenbandleistung:
[U4a] dBm auf 500 kHz
3) Emission auf beliebigem
anderen Uplink-
Kanal:U2(3)-1 = – 35
dBm auf 500 kHz
U4a (*) Max.
Einseitenband-E.I.R.P.
(Mittelachse)
Zwei Optionen:
U4a-0: – 14 dBm
U4a-1: – 21 dBm
Gemäß der deklarierten und ver­
öffentlichten Spezifikation des
Konstrukteurs der Ausrüstung
U4b (*) Max.
Einseitenband-E.I.R.P. (35°)
Zwei Optionen:
— Nicht anwendbar
— – 17 dBm
Gemäß der deklarierten und ver­
öffentlichten Spezifikation des
Konstrukteurs der Ausrüstung
U5 Polarisation Linkszirkular (Konsistent mit EN 12253)
U5a Kreuzpolarisation XPD:
In Achsensicht: (REDCR)
RSU r ≥ 15 δB
(DSRC-VU) OBU t ≥ 10 δB
Bei -3 dB: (REDCR) RSU r
≥ 10 δB
(DSRC-VU) OBU t ≥ 6 δB
(Konsistent mit EN 12253)
U6 Unterträgermodulation 2-PSK
Verschlüsselte Daten, mit
Unterträger synchronisiert:
Übergänge verschlüsselter
Daten fallen mit Übergän­
gen des Unterträgers
zusammen.
(Konsistent mit EN 12253)
U6b Arbeitszyklus Arbeitszyklus:
50 % ± α, α ≤ 5 %
(Konsistent mit EN 12253)
U6c Modulation auf Träger Multiplikation von modu­
liertem Unterträger mit Trä­
ger.
(Konsistent mit EN 12253)
U7 (*) Datenverschlüsselung NRZI (kein Übergang bei
Beginn von „1“-Bit, Über­
gang bei Beginn von „0“-
Bit, kein Übergang inner­
halb des Bits)
(Konsistent mit EN 12253)
U8 (*) Bit-Rate 250 kBit/s (Konsistent mit EN 12253)
U8a Toleranz des Bit-Takts Innerhalb von ± 1 000 ππμ (Konsistent mit EN 12253)
U9 Bit-Fehlerquote (B.E.R.) für
die Kommunikation
≤ 10 –6 (Konsistent mit EN 12253)
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 553
Punkt Parameter Wert(e) Anmerkung
U11 Kommunikationsbereich Raum, innerhalb dessen
sich die DSRC-VU befin­
det, damit ihre Übertragun­
gen von dem REDCR mit
einer B.E.R. von weniger
als dem Wert empfangen
werden, der durch U9a vor­
gegeben wird.
(Konsistent mit EN 12253)
U12a (*) Umwandlungsverstärkung
(unterer Grenzwert)
1 dB für jedes Seitenband
Winkelbereich: zirkular
symmetrisch zwischen Mit­
telachse und ± 35° sowie
im Bereich von – 45° bis +
45° entsprechend der Ebene
parallel zur Straßenoberflä­
che, wenn die DSRC-VU
später im Fahrzeug instal­
liert wird (Azimuth)
Größer als der angegebene Wert­
bereich für waagerechte Winkel
bis ± 45° aufgrund der in diesem
Anhang definierten Anwendungs­
fälle.
U12b (*) Umwandlungsverstärkung
(oberer Grenzwert)
10 dB für jedes Seitenband Kleiner als der angegebene Wert­
bereich für jedes Seitenband inner­
halb eines Kreiskegels um Mittel­
achse ± mit einem Öffnungswinkel
von 45°.
U13 Präambel Präambel vorgeschrieben. (Konsistent mit EN 12253)
U13a Präambel
Länge und Muster
32 bis 36 μs lediglich mit
Unterträger moduliert, an­
schließend 8 Bits
NRZI-kodierter „0“-Bits.
(Konsistent mit EN 12253)
U13b Nachlaufende Bits ►C2 Die DSRC-VU darf
nach dem Endmerker maxi­
mal 8 Bits übertragen. ◄
Zur Berücksichtigung dieser
zusätzlichen Bits ist keine
RSU (REDCR) erforderlich.
(Konsistent mit EN 12253)
(*) — Uplink-Parameter unterliegen Konformitätsprüfung gemäß relevanter Parameterprüfung aus EN 300 674-1
5.3.3 Antennendesign
5.3.3.1 REDCR-Antenne
DSC_30 Das Design der REDCR-Antenne ergibt sich aus dem kom­
merziellen Design, innerhalb der in 5.3.2 definierten Grenzen
und angepasst zur Optimierung der Leseleistung des DSRC-
REDCR für spezielle Zwecke und Lesebedingungen, inner­
halb derer das REDCR betrieben wird.
5.3.3.2 VU-Antenne
DSC_31 Das Design der DSRC_VU-Antenne ergibt sich aus dem kom­
merziellen Design, innerhalb der in 5.3.2 definierten Grenzen
und angepasst zur Optimierung der Leseleistung des DSRC-
REDCR für spezielle Zwecke und Lesebedingungen, inner­
halb derer das REDCR betrieben wird.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 554
DSC_32 Die VU-Antenne ist an oder in der Frontscheibe des Fahr­
zeugs gemäß 5.1 oben zu befestigen.
DSC_33 In der Prüfumgebung in einer Werkstatt (siehe Abschnitt 6.3)
muss eine gemäß 5.1 oben angebrachte DSRC-VU-Antenne
erfolgreich eine Verbindung mit einer standardmäßigen Prüf­
kommunikation herstellen und eine RTM-Transaktion gemäß
dieser Anlage über eine Entfernung von 2–10 Metern, in mehr
als 99 % der Fälle, gemittelt über 1 000 Leseabfragen
bereitstellen.
5.4 DSRC-Protokollanforderungen für RTM
5.4.1 Überblick
DSC_34 Das Transaktionsprotokoll zum Herunterladen der Daten über
die 5,8-GHz-DSRC-Schnittstellenverbindung muss folgende
Schritte unterstützen. Dieser Abschnitt beschreibt den Trans­
aktionsablauf unter Idealbedingungen ohne Rücktransaktionen
oder Kommunikationsunterbrechungen.
HINWEIS Zweck der Initialisierungsphase (Schritt 1) ist es,
die Kommunikation zwischen REDCR und denjenigen
DSRC-VU, die in den 5,8-GHz-DSRC (Master-Slave)-Trans­
aktionsbereich eingetreten sind, aber noch keine Kommunika­
tion mit dem REDCR hergestellt haben, einzurichten und die
Anwendungsprozesse zu informieren.
— Schritt 1 Initialisieren. Das REDCR sendet einen Frame
mit einer „Beacon Service Table“ (BST) samt unterstütz­
ter Anwendungskennungen (AID) in der Dienstliste. In
der RTM-Anwendung ist dies einfach der Dienst mit
AID-Wert = 2 (Freight&Fleet). Die DSRC-VU wertet
die empfangene BST aus und antwortet (siehe unten)
mit der Liste unterstützter Anwendungen in der Domäne
Freight&Fleet; wenn keine Anwendungen unterstützt wer­
den, antwortet sie nicht. Wenn das REDCR nicht AID=2
anbietet, soll die DSRC-VU dem REDCR nicht
antworten.
— Schritt 2 Die DSRC-VU sendet einen Frame mit einer
Anfrage nach Zuweisung eines privaten Fensters.
— Schritt 3 Die REDCR sendet einen Frame mit Zuweisung
eines privaten Fensters.
— Schritt 4 Die DSRC-VU sendet mithilfe des zugewiese­
nen privaten Fensters einen Frame mit ihrer Fahrzeug­
diensttabelle (Vehicle Service Table, VST). Diese VST
enthält eine Liste aller unterschiedlichen Anwendungs­
instanziierungen, die diese DSRC-VU im Rahmen von
AID=2 unterstützt. Die verschiedenen Instanziierungen
sind durch einzeln generierte EID zu identifizieren, von
denen jede mit einem Anwendungskontextmarkierung-Pa­
rameterwert verbunden ist, der die Anwendung und die
unterstützte Norm angibt.
— Schritt 5 Anschließend analysiert das REDCR die ange­
botene VST und beendet entweder die Verbindung (RE­
LEASE), da das Angebot der VST nicht interessant ist (d.
h., es erhält von der DSRC-VU eine VST, die die
RTM-Transaktion nicht unterstützt), oder es erhält eine
passende VST und startet die Instanziierung der App.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 555
— Schritt 6 Dazu sendet das REDCR einen Frame mit ei­
nem Befehl zum Abruf der RTM-Daten, in dem die
RTM-Anwendung durch Angabe der Kennung zur Instan­
ziierung der RTM-Anwendung (wie von der DSRC-VU
in der VST angegeben) und soll ein privates Fenster
zuweisen.
— Schritt 7 Die DSRC-VU sendet mit dem neu zugewiese­
nen privaten Fenster einen Frame, der die in der VST
genannte adressierte Kennung zur Instanziierung der
RTM-Anwendung gefolgt von dem Attribut RtmData
(Nutzlast- + Sicherheitselement) enthält.
— Schritt 8 Wenn mehrere Dienste angefragt werden, wird
der Wert „n“ auf die nächste Dienstreferenznummer ge­
setzt und der Prozess wiederholt.
— Schritt 9 Das REDCR bestätigt den Erhalt der Daten,
indem es einen Frame sendet, der der DSRC-VU einen
RELEASE-Befehl sendet, die Sitzung zu beenden, ODER
wechselt, falls es den erfolgreichen Erhalt des LDPU
nicht validieren konnte, zurück zu Schritt 6.
Siehe Abbildung 14.6 als bildliche Darstellung des Transakti­
onsprotokolls.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 556
Abbildung 14.6
Ablauf RTM über 5,8-GHz-DSRC (HINWEIS: Abbildung soll nicht übersetzt werden)
5.4.2 Befehle
DSC_35 Nur die folgenden Befehle werden in einer RTM-Transakti­
onsphase verwendet:
— INITIALISATION.request: Vom REDCR in Form eines
Broadcast ausgegebener Befehl mit der Definition der
vom REDCR unterstützten Befehle.
— INITIALISATION.response: Antwort der DSRC-VU,
die die Verbindung bestätigt und eine Liste unterstützter
Anwendungsinstanzen und der Angaben, wie diese adres­
siert werden (EID), enthält.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 557
— GET.request: Vom REDCR an die DSRC-VU ausgege­
bener Befehl, der die zu adressierende Anwendungs­
instanziierung durch eine definierte EID, wie in der
VST erhalten, angibt und die DSRC-VU anweist, das
bzw. die ausgewählten Attribute mit den Daten zu sen­
den. Ziel des GET-Befehls ist es, dass das REDCR die
Daten von der DSRC-VU erhält.
— GET.response: Antwort der DSRC-VU mit den angefor­
derten Daten.
— ACTION.request ECHO: Befehl, der die DSRC-VU an­
weist, die von der DSRC-VU erhaltenen Daten an das
REDCR zurückzusenden. Ziel des ECHO-Befehls ist es,
Werkstätten oder Prüfeinrichtungen zur Typgenehmigung
in die Lage zu versetzen, zu prüfen, ob der DSRC-Link
funktioniert, ohne auf die Sicherheitsangaben zugreifen zu
müssen.
— ACTION.response ECHO: Antwort der DSRC VU auf
den ECHO-Befehl.
— EVENT_REPORT.request RELEASE: Befehl, der der
DSRC-VU mitteilt, dass die Transaktion beendet ist. Ziel
des RELEASE-Befehls ist es, die Sitzung mit der DSRC-
VU zu beenden. Bei Erhalt von RELEASE darf die
DSRC-VU nicht mehr auf weitere Abfragen im Rahmen
der aktuellen Verbindung antworten. Hinweis: Gemäß EN
12834 stellt eine DSRC-VU nur dann eine zweite Ver­
bindung zur selben Abfrageeinrichtung her, wenn sie sich
255 Sekunden lang außerhalb des Kommunikations­
bereichs befunden hat oder wenn sich die Beacon-ID
der Abfrageeinrichtung geändert hat.
5.4.3 Abfragebefehlssequenz
DSC_36 Aus Perspektive der Befehl-Antwort-Sequenz lässt sich die
Transaktion wie folgt beschreiben:
Sequenz Sender Empfänger Beschreibung Handlung
1 REDCR > DSRC-VU Initialisierung des
Kommunikations-Links —
Anforderung
REDCR sendet BST
2 DSRC-VU > REDCR Initialisierung des
Kommunikations-Links —
Antwort
Wenn die BST AID=2 unter­
stützt, dann fordert die
DSCR-VU ein privates Fens­
ter an
3 REDCR > DSRC-VU Gewährt ein privates Fens­
ter
Sendet Frame mit Zuweisung
eines privaten Fensters
4 DSRC-VU > REDCR Sendet VST Sendet Frame mit VST
5 REDCR > DSRC-VU Sendet GET.request für in
Attribut enthaltene Daten
für spezifische EID
6 DSRC-VU > REDCR Sendet GET.response mit
angefordertem Attribut für
spezifische EID
Sendet Attribut (RTMData,
OWSData …) mit Daten für
spezifische EID
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 558
Sequenz Sender Empfänger Beschreibung Handlung
▼M1
7 REDCR > DSRC-VU Sendet GET.request für Da­
ten anderer Attribute (falls
zutreffend)
▼B
8 DSRC-VU > REDCR Sendet GET.response mit
angefordertem Attribut
Sendet Attribut mit Daten für
spezifische EID
9 REDCR > DSRC-VU Bestätigt erfolgreichen
Empfang der Daten
Sendet RELEASE-Befehl, der
die Transaktion beendet
10 DSRC-VU Beendet Transaktion
Ein Beispiel für Transaktionssequenz und -inhalte der aus­
getauschten Frames ist in den Abschnitten 5.4.7 und 5.4.8
enthalten.
5.4.4 Datenstrukturen
DSC_37 Die semantische Struktur der Daten bei der Weitergabe an die
5,8-GHz-DSRC-Schnittstelle muss den Ausführungen in die­
ser Anlage entsprechen. Die Strukturierung dieser Daten ist in
diesem Abschnitt angegeben.
DSC_38 Die Nutzlast (RTM-Daten) besteht aus der Verkettung der
1. EncryptedTachographPayload-Daten, der Verschlüsselung
von TachographPayload gemäß ASN.1 in Abschnitt 5.4.5.
Die Verschlüsselungsmethode ist in Anlage 11
beschrieben.
2. DSRCSecurityData, angegeben in Anlage 11.
DSC_39 Die RTM-Daten werden als RTM-Attribut=1 adressiert und
im RTM-Container =10 übertragen.
DSC_40 Die RTM-ContextMark soll das unterstützte Standardteil in
der TARV-Normenreihe (RTM entspricht Teil 9)
identifizieren.
Das ASN.1-Modul für die DSRC-Daten innerhalb der
RTM-Anwendung ist wie folgt definiert:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 559
► (2) (3) M1
► (1) M3
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 560
5.4.5 Elemente von RtmData, durchgeführte Aktionen und Definitionen
DSC_41 Die durch die VU zu berechnenden und zur Aktualisierung
der gesicherten Daten in der DSRC-VU verwendeten Daten
sind nach den in Tabelle 14.3 definierten Regeln zu
berechnen:
▼M3
Tabelle 14.3
Elemente von RtmData, durchgeführte Aktionen und Definitionen
1)
RTM-Datenelement
2)
Von der VU durchzuführende
Aktion
3)
ASN.1-Datendefinition
RTM1
Kennzeichen des
Fahrzeugs
Die VU entnimmt den Wert
für das tp15638VehicleRegis­
trationPlate-Datenelement
RTM1 aus dem aufgezeich­
neten Wert des Datentyps
VehicleRegistrationIdentifica­
tion gemäß Anlage 1 Vehic­
leRegistrationIdentification.
Kennzeichen des Fahr­
zeugs als Zeichenstring
tp15638VehicleRegistration­
Plate LPN,
–Kennzeichen des Fahrzeugs
unter Verwendung der Daten­
struktur nach ISO 14906, aber
mit folgender Einschränkung
für die RTM-Anwendung:
Die SEQUENZ beginnt mit
dem Ländercode, gefolgt von
einem alphabetischen Indika­
tor, gefolgt von der Kennzei­
chennummer selbst,
die immer 14 Oktette umfasst
(aufgefüllt mit Nullen), sodass
die LPN-Typenlänge immer
17 Oktette beträgt (keine
Längendeterminante erforder­
lich), von denen 14 das „tat­
sächliche“ Kennzeichen sind.
RTM2
Geschwindigkeitsüber­
schreitung
Die VU erstellt einen boo­
leschen
Wert für das Datenelement
RTM2
tp15638SpeedingEvent.
Der Wert tp15638Speedin­
gEvent wird von der VU an­
hand der in der VU auf­
gezeichneten Anzahl an Ge­
schwindigkeitsüberschreitun­
gen innerhalb der letzten
10 Tage gemäß Definition in
Anhang IC berechnet.
1 (TRUE): wenn das
letzte Ereignis einer Ge­
schwindigkeitsüber­
schreitung innerhalb der
letzten 10 Tage beendet
wurde oder noch anhält;
0 (FALSE): in allen an­
deren Fällen.
tp15638SpeedingEvent BOO­
LEAN,
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 561
1)
RTM-Datenelement
2)
Von der VU durchzuführende
Aktion
3)
ASN.1-Datendefinition
RTM3
Lenken ohne
gültige Karte
Die VU erstellt einen boo­
leschen
Wert für das Datenelement
RTM3
tp15638DrivingWithoutVa­
lidCard.
Die VU weist der Variablen
tp15638DrivingWithoutVa­
lidCard den Wert TRUE zu,
wenn die VU in den letzten
10 Tagen mindestens ein Er­
eignis des Typs „Lenken
ohne geeignete Karte“ gemäß
Anhang IC aufgezeichnet hat.
1 (TRUE): wenn das
letzte Ereignis des Len­
kens ohne geeignete
Karte innerhalb der letz­
ten 10 Tage beendet
wurde oder noch anhält;
0 (FALSE): in allen an­
deren Fällen.
tp15638DrivingWithoutValid­
Card
BOOLEAN,
RTM4
Gültige Fahrerkarte
Die VU erstellt einen boo­
leschen Wert für das Daten­
element RTM4
tp15638DriverCard auf
Grundlage der im Steckplatz
Fahrer eingesteckten gültigen
Fahrerkarte.
1 (TRUE): wenn keine
gültige Fahrerkarte im
Steckplatz Fahrer der
VU eingesteckt ist;
0 (FALSE): wenn eine
gültige Fahrerkarte im
Steckplatz Fahrer der
VU eingesteckt ist.
tp15638DriverCard BOO­
LEAN,
RTM5
Einstecken der Karte
während
des Lenkens
Die VU generiert einen boo­
leschen Wert für das Daten­
element RTM5 tp15638Car­
dInsertion.
Die VU weist der Variablen
tp15638CardInsertion den
Wert TRUE zu, wenn die VU
in den letzten 10 Tagen
mindestens ein Ereignis des
Typs „Einstecken der Karte
während des Lenkens“ ge­
mäß Anhang IC aufgezeich­
net hat.
1 (TRUE): wenn das
letzte Ereignis „Einste­
cken der Karte während
des Lenkens“ innerhalb
der letzten 10 Tage
stattgefunden hat;
0 (FALSE): in allen an­
deren Fällen.
tp15638CardInsertion BOO­
LEAN,
RTM6
Bewegungsdatenfehler
Die VU erstellt einen boo­
leschen
Wert für das Datenelement
RTM6.
Die VU weist der Variablen
tp15638MotionDataError den
Wert TRUE zu, wenn die VU
in den letzten 10 Tagen
mindestens ein Ereignis des
Typs „Bewegungsdatenfeh­
ler“ gemäß Anhang IC auf­
gezeichnet hat.
1 (TRUE): wenn das
letzte Ereignis „Bewe­
gungsdatenfehler“ inner­
halb der letzten 10 Tage
beendet wurde oder noch
anhält;
0 (FALSE): in allen an­
deren Fällen.
tp15638MotionDataError
BOOLEAN,
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 562
1)
RTM-Datenelement
2)
Von der VU durchzuführende
Aktion
3)
ASN.1-Datendefinition
RTM7
Datenkonflikt
Fahrzeugbewegung
Die VU erstellt einen boo­
leschen
Wert für das Datenelement
RTM7.
Die VU weist der Variablen
tp15638VehicleMotionCon­
flict den Wert TRUE zu,
wenn die VU in den letzten
10 Tagen mindestens ein Er­
eignis „Datenkonflikt Fahr­
zeugbewegung“ aufgezeich­
net hat.
1 (TRUE): wenn das
letzte Ereignis „Daten­
konflikt Fahrzeugbewe­
gung“ innerhalb der
letzten 10 Tage beendet
wurde oder noch anhält;
0 (FALSE): in allen an­
deren Fällen.
tp15638VehicleMotionConflict
BOOLEAN,
RTM8
Zweite Fahrerkarte
Die VU erstellt einen boo­
leschen
Wert für das Datenelement
RTM8 auf Grundlage des
Anhangs IC (Fahrertätig­
keitsdaten TEAM und BEI­
FAHRER).
Wenn eine gültige Beifahrer­
karte in der VU vorhanden
ist, setzt die VU RTM8 auf
TRUE.
1 (TRUE): wenn eine
gültige Beifahrerkarte in
der VU vorhanden ist;
2 (FALSE): wenn keine
gültige Beifahrerkarte in
der VU vorhanden ist.
tp156382ndDriverCard BOO­
LEAN,
RTM9
Derzeitige Tätigkeit
Die VU erstellt einen boo­
leschen
Wert für das Datenelement
RTM9.
Wenn die VU als derzeitige
Tätigkeit eine andere Tätig­
keit als „LENKEN“ gemäß
Anhang IC aufzeichnet, muss
die VU RTM9 auf TRUE
setzen.
1 (TRUE): andere Tä­
tigkeit
ausgewählt;
0 (FALSE): Lenken
ausgewählt
tp15638CurrentActivityDri­
ving
BOOLEAN
RTM10
Letzter Vorgang abge­
schlossen
Die VU generiert einen boo­
leschen Wert für das Daten­
element RTM10.
Wenn die letzte Kartensit­
zung nicht korrekt gemäß
Anlage IC abgeschlossen
wird, muss die VU RTM10
auf TRUE setzen.
1 (TRUE): mindestens
eine der eingesteckten
Karten hat ein Ereignis
„Letzter Vorgang nicht
korrekt abgeschlossen“
ausgelöst;
0 (FALSE): keine der
eingesteckten Karten hat
ein Ereignis „Letzter
Vorgang nicht korrekt
abgeschlossen“ aus­
gelöst.
tp15638LastSessionClosed
BOOLEAN
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 563
1)
RTM-Datenelement
2)
Von der VU durchzuführende
Aktion
3)
ASN.1-Datendefinition
RTM11
Unterbrechung der
Stromversorgung
Die VU generiert einen
Integer-
Wert für das Datenelement
RTM11.
Die VU weist der Variablen
tp15638PowerSupplyInter­
ruption einen Wert gleich der
in den letzten 10 Tagen ge­
speicherten Anzahl der Er­
eignisse „Unterbrechung der
Stromversorgung“ gemäß
Anhang IC zu.
Wenn kein Ereignis „Unter­
brechung der Stromversor­
gung“ innerhalb der letzten
10 Tage in der VU auf­
gezeichnet wurde, wird
RTM11 auf den Wert „0“
gesetzt.
Anzahl der aufgezeich­
neten Unterbrechungen
der Stromversorgung in­
nerhalb der letzten
10 Tage.
tp15638PowerSupplyInterrup­
tion
INTEGER (0..127),
RTM12
Sensorstörung
Die VU generiert einen
Integer-Wert für das Daten­
element RTM12.
Die VU weist der Variablen
sensorFault einen der folgen­
den Werte zu:
— 1, wenn ein Ereignis des
Typs „35“H Sensorstö­
rung
in den letzten 10 Tagen
beendet wurde oder noch
anhält.
— 2, wenn ein Ereignis des
Typs
GNSS-Empfängerstörung
(intern oder extern Enum
„36“H oder
„37“H) in den letzten
10 Tagen beendet wurde
oder noch anhält.
— 3, wenn ein Ereignis des
Typs „0E“H Kommuni­
kationsfehler mit der ex­
ternen GNSS-Ausrüstung
in den letzten 10 Tagen
beendet wurde oder noch
anhält.
— 4, wenn Ereignisse so­
wohl des Typs Sensor­
störung als auch des
Typs GNSS-Empfänger­
störung in den letzten
10 Tagen beendet wur­
den oder noch anhalten.
— 5, wenn Ereignisse so­
wohl des Typs Sensor­
störungen als auch des
Typs Kommunikations­
fehler mit der externen
GNSS-Ausrüstung in den
letzten 10 Tagen beendet
wurden oder noch anhal­
ten.
– Sensorstörung ein Ok­
tett gemäß Datenglossar
tp15638SensorFault INTEGER
(0..255),
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 564
1)
RTM-Datenelement
2)
Von der VU durchzuführende
Aktion
3)
ASN.1-Datendefinition
— 6, wenn Ereignisse so­
wohl des Typs GNSS-
Empfängerstörungen als
auch des Typs Kom­
munikationsfehler mit
der externen GNSS-Aus­
rüstung in den letzten
10 Tagen beendet wur­
den oder noch anhalten.
— 7, wenn alle drei Arten
von Sensorstörungen in
den letzten 10 Tagen
beendet wurden oder
noch anhalten.
Wenn kein Ereignis in den
letzten 10 Tagen beendet
wurde oder noch anhält, setzt
die VU RTM12 auf den Wert
„0“.
RTM13
Zeiteinstellung
Für das Datenelement
RTM13 generiert die VU ei­
nen Integer-Wert (timeReal
gemäß Anlage 1) auf
Grundlage des Vorliegens
von Zeiteinstellungsdaten ge­
mäß Anhang IC.
Die VU weist RTM13 den
Zeitwert zu, an dem das
letzte Ereignis „Zeiteinstel­
lung“ erfolgt ist.
Wenn in der VU kein Ereig­
nis „Zeiteinstellung“ gemäß
Anhang IC vorhanden ist,
setzt die VU RTM13 auf den
Wert „0“.
„oldTimeValue“ der
letzten Zeiteinstellung.
tp15638TimeAdjustment
INTEGER(0..4294967295),
RTM14
Versuch
Sicherheitsverletzung
Für das Datenelement
RTM14 generiert die VU ei­
nen Integer-Wert (timeReal
gemäß Anlage 1) auf
Grundlage des Vorliegens ei­
nes Ereignisses „Versuch Si­
cherheitsverletzung“ gemäß
Anhang C.
Die VU setzt den Wert auf
den Zeitpunkt des letzten von
der VU verzeichneten sicher­
heitsverletzenden Versuchs.
Wenn in der VU kein Ereig­
nis „Versuch Sicherheitsver­
letzung“ gemäß Anhang IC
vorhanden ist, setzt die VU
RTM14 auf den Wert „0“.
Zeit des Beginns des
letzten gespeicherten Er­
eignisses „Versuch Si­
cherheitsverletzung“.
tp15638LatestBreachAttempt
INTEGER(0..4294967295),
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 565
1)
RTM-Datenelement
2)
Von der VU durchzuführende
Aktion
3)
ASN.1-Datendefinition
RTM15
Letzte Kalibrierung
Für das Datenelement
RTM15 generiert die VU ei­
nen Integer-Wert (timeReal
gemäß Anlage 1) auf
Grundlage des Vorliegens
von letzten Kalibrierungs­
daten gemäß Anhang IC und
Anlage 1.
Die VU setzt den Wert
für RTM15 auf „oldTimeVa­
lue“ des letzten Kalibrie­
rungsdatensatzes.
Wenn keine Kalibrierung
vorliegt, setzt die VU
RTM15 auf den Wert „0“.
„oldTimeValue“ des
letzten Kalibrierungs­
datensatzes.
tp15638LastCalibrationData
INTEGER(0..4294967295),
RTM16
Vorherige Kalibrierung
Für das Datenelement
RTM16 generiert die VU ei­
nen Integer-Wert (timeReal
gemäß Anlage 1) auf der
Grundlage des Kalibrierungs­
datensatzes, der der letzten
Kalibrierung vorausgeht.
Die VU setzt den Wert
für RTM16 auf „oldTimeVa­
lue“ des Kalibrierungsdaten­
satzes vor der letzten Kali­
brierung.
Wenn keine vorherige Kali­
brierung vorliegt, setzt die
VU RTM16 auf den Wert
„0“.
„oldTimeValue“ des Ka­
librierungsdatensatzes,
der dem letzten Kali­
brierungsdatensatz
vorausgeht.
tp15638PrevCalibrationData
INTEGER(0..4294967295),
RTM17
Anschlussdatum des
Fahrtenschreibers
Die VU generiert einen
Integer-Wert (timeReal ge­
mäß Anlage 1) für das Da­
tenelement RTM17.
Die VU setzt den Wert für
RTM17 auf das Datum der
ersten Kalibrierung der VU
im aktuellen Fahrzeug.
Die VU extrahiert diese Da­
ten aus VuCalibrationData
(Anlage 1) aus vuCalibrati­
onRecords, wobei Calibrati­
onPurpose gleich: „03“H ist.
Wenn keine vorherige Kali­
brierung vorliegt, setzt die
VU RTM17 auf den Wert
„0“.
Datum der ersten Kali­
brierung der VU im ak­
tuellen Fahrzeug.
tp15638DateTachoConnected
INTEGER(0..4294967295),
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 566
1)
RTM-Datenelement
2)
Von der VU durchzuführende
Aktion
3)
ASN.1-Datendefinition
RTM18
Aktuelle Geschwindig­
keit
Die VU generiert einen
Integer-
Wert für das Datenelement
RTM18.
Die VU setzt den Wert für
RTM18 auf die bei der
jüngsten Aktualisierung von
RtmData zuletzt als aktuell
aufgezeichnete Geschwindig­
keit.
Zuletzt als aktuell auf­
gezeichnete Geschwin­
digkeit
tp15638CurrentSpeed INTE­
GER (0..255),
RTM19
Zeitstempel
Die VU generiert einen
Integer-Wert für das Daten­
element RTM19 (timeReal
gemäß Anlage 1).
Die VU setzt den Wert für
RTM19 auf den Zeitpunkt
der jüngsten Aktualisierung
von RtmData.
Zeitstempel des aktuellen
Datensatzes
TachographPayload
tp15638Timestamp
INTEGER(0..4294967295),
RTM20
Zeitpunkt der Verfüg­
barkeit der letzten au­
thentisierten Fahrzeug­
position
Die VU generiert einen
Integer-Wert (timeReal ge­
mäß Anlage 1) für das Da­
tenelement RTM20.
Die VU setzt den Wert von
RTM20 auf den Zeitpunkt,
an dem die letzte authenti­
sierte Fahrzeugposition vom
GNSS-Empfänger verfügbar
war.
Wenn noch nie eine authen­
tisierte Fahrzeugposition vom
GNSS-Empfänger verfügbar
war, setzt die VU RTM20
auf den Wert „0“.
Zeitstempel der letzten
authentisierten Fahrzeug­
position
tp15638LatestAuthenticated­
Position
INTEGER(0..4294967295),
RTM21
Ununterbrochene Lenk­
zeit
Die VU generiert einen
Integer-Wert für das Daten­
element RTM21.
Die VU setzt den Wert für
RTM21 auf den Zeitpunkt
der laufenden ununterbroche­
nen Lenkzeit des Fahrers.
Ununterbrochene Lenk­
zeit des Fahrers, kodiert
als Integer-Wert.
Länge: 1 Byte
Auflösung: 2 Minuten/
Bit
Kein Offset
Datenbereich: 0 bis 250
Ein Wert von 250 gibt
an, dass die ununterbro­
chene Lenkzeit des Fah­
rers mindestens 500 Mi­
nuten beträgt.
Die Werte 251 bis 254
werden nicht genutzt.
Der Wert 255 gibt an,
dass die Informationen
nicht verfügbar sind.
tp15638ContinuousDriving­
Time INTEGER(0..255),
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 567
1)
RTM-Datenelement
2)
Von der VU durchzuführende
Aktion
3)
ASN.1-Datendefinition
RTM22
Längste tägliche Lenk­
zeit des Fahrers für die
derzeit laufende und die
vorherige RTM-Schicht,
berechnet gemäß Bei­
blatt zur Anlage 14
Die VU generiert einen
Integer-Wert für das Daten­
element RTM22.
Die VU setzt den Wert für
RTM22 auf die längere der
beiden täglichen Lenkzeiten
des Fahrers, d. h. entweder
die laufende oder die vor­
herige RTM-Schicht.
Tägliche Lenkzeit des
Fahrers, kodiert als
Integer-Wert.
Länge: 1 Byte
Auflösung: 4 Minuten/
Bit
Kein Offset
Datenbereich: 0 bis 250
Ein Wert von 250 gibt
an, dass die tägliche
Lenkzeit des Fahrers
mindestens 1000 Minu­
ten beträgt.
Die Werte 251 bis 254
werden nicht genutzt.
Der Wert 255 gibt an,
dass die Informationen
nicht verfügbar sind.
tp15638DailyDrivingTimeShift
INTEGER(0..255),
RTM23
Längste tägliche Lenk­
zeit des Fahrers inner­
halb der derzeit laufen­
den Woche, berechnet
gemäß Beiblatt zur An­
lage 14
Die VU generiert einen
Integer-Wert für das Daten­
element RTM23.
Die VU setzt den Wert für
RTM23 auf die längste tägli­
che Lenkzeit des Fahrers;
dies ist entweder die laufende
RTM-Schicht oder eine ab­
geschlossene RTM-Schicht,
die in der laufenden Woche
begonnen oder beendet
wurde.
Tägliche Lenkzeit des
Fahrers, kodiert als
Integer-Wert.
Länge: 1 Byte
Auflösung: 4 Minuten/
Bit
Kein Offset
Datenbereich: 0 bis 250
Ein Wert von 250 gibt
an, dass die tägliche
Lenkzeit des Fahrers
mindestens 1000 Minu­
ten beträgt.
Die Werte 251 bis 254
werden nicht genutzt.
Der Wert 255 gibt an,
dass die Informationen
nicht verfügbar sind.
tp15638DailyDrivingTime­
Week INTEGER(0..255),
RTM24
Wöchentliche Lenkzeit
des Fahrers, berechnet
gemäß Beiblatt zur An­
lage 14
Die VU generiert einen
Integer-Wert für das Daten­
element RTM24.
Die VU setzt den Wert für
RTM24 auf die wöchentliche
Lenkzeit des Fahrers.
Wöchentliche Lenkzeit
des Fahrers, kodiert als
Integer-Wert.
Länge: 1 Byte
Auflösung: 20 Minuten/
Bit
Kein Offset
Datenbereich: 0 bis 250
Ein Wert von 250 gibt
an, dass die wöchentli­
che Lenkzeit des Fahrers
mindestens 5000 Minu­
ten beträgt.
Die Werte 251 bis 254
werden nicht genutzt.
Der Wert 255 gibt an,
dass die Informationen
nicht verfügbar sind.
tp15638WeeklyDrivingTime
INTEGER(0..255),
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 568
1)
RTM-Datenelement
2)
Von der VU durchzuführende
Aktion
3)
ASN.1-Datendefinition
RTM25
Vierzehntägige Lenkzeit
des Fahrers, berechnet
gemäß Beiblatt zur An­
lage 14
Die VU generiert einen
Integer-Wert für das Daten­
element RTM25.
Die VU setzt den Wert für
RTM25 auf die vierzehn­
tägige Lenkzeit des Fahrers.
Vierzehntägige Lenkzeit
des Fahrers, kodiert als
Integer-Wert.
Länge: 1 Byte
Auflösung: 30 Minuten/
Bit
Kein Offset
Datenbereich: 0 bis 250
Ein Wert von 250 gibt
an, dass die ununterbro­
chene Lenkzeit des Fah­
rers mindestens
7500 Minuten beträgt.
Die Werte 251 bis 254
werden nicht genutzt.
Der Wert 255 gibt an,
dass die Informationen
nicht verfügbar sind.
tp15638FortnightlyDriving­
Time INTEGER(0..255),
Hinweis: RTM22, RTM23, RTM24 und RTM25 werden gemäß dem Beiblatt zur
dieser Anlage berechnet.
▼B
5.4.6 Mechanismus der Datenübertragung
DSC_42 Die zuvor definierten Nutzlastdaten werden vom REDCR
nach der Initialisierungsphase abgerufen und anschließend
von der DSRC-VU im zugewiesenen Fenster übertragen.
Zum Abrufen der Daten verwendet das REDCR den Befehl
GET.
▼M1
DSC_43 Bei jedem DSRC-Austausch werden die Daten mit PER
(Packed Encoding Rules) UNALIGNED verschlüsselt, mit
Ausnahme von und
, die mit OER (Octet Encoding Rules) gemäß
ISO/IEC 8825-7, Rec. ITU-T X.696 verschlüsselt werden.
▼B
5.4.7 Detaillierte Beschreibung der DSRC-Transaktion
DSC_44 Die Initialisierung erfolgt gemäß DSC_44 bis DSC_48 und
den Tabellen 14.4 bis 14.9. In der Einleitungsphase sendet
das REDCR zunächst einen Frame mit einer BST (Beacon
Service Table) gemäß EN 12834 und EN 13372, 6.2, 6.3,
6,4, und 7.1 mit den in der folgenden Tabelle 14.4 aufgeführ­
ten Einstellungen.
Tabelle 14.4
Initialisierung — BST-Frame-Einstellungen
Feld Einstellungen
Link Identifier Broadcast-Adresse
BeaconId Gemäß EN 12834
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 569
Time Gemäß EN 12834
Profile Keine Erweiterung, 0 oder 1
verwenden
MandApplications Keine Erweiterung, EID
nicht vorhanden, Parameter
nicht vorhanden, AID=2
Freight&Fleet
NonMandApplications Nicht vorhanden
ProfileList Keine Erweiterung, Anzahl
Profile in Liste = 0
Fragmentation header Keine Fragmentierung
Layer 2 settings Befehls-PDU, UI-Befehl
Ein praktisches Beispiel der in Tabelle 14.4 angegebenen
Einstellungen samt Angabe der Bit-Verschlüsselungen findet
sich in der folgenden Tabelle 14.5.
Tabelle 14.5
Initialisierung — Beispiele für die Inhalte von BST-Frames
O
kt
et
t
#
Attribut/Feld Bits in Oktett Beschreibung
1 FLAG ►C2 Anfangsmerker ◄
2 Broadcast ID Broadcast-Adresse
3 MAC Control Field PDU-Befehl
4 LLC Control field UI-Befehl
5 Fragmentation header Keine Fragmentierung
6 BST Initialisierungsanfrage
SEQUENCE {
OPTION indicator
BeaconID SEQUENCE {
ManufacturerId INTEGER (0..65535)
NonMand-Anwendungen
nicht vorhanden
Herstellerkennung
7
8
IndividualID INTEGER (0..134217727)
}
27-Bit-ID für Hersteller
verfügbar
9
10
11
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 570
O
kt
et
t
#
Attribut/Feld Bits in Oktett Beschreibung
12 Time INTEGER (0..4294967295) 32-Bit-UNIX-Realtime
13
14
15
16 Profile INTEGER (0..127, …) Keine Erweiterung. Bei­
spielprofil 0
17 MandApplications SEQUENCE
(SIZE(0..127, …))
OF {
Keine Erweiterung, An­
zahl mandApplications = 1
18 SEQUENCE {
OPTION indicator
EID nicht vorhanden
OPTION indicator
Parameter nicht vorhanden
AID DSRCApplicationEntityID } }
Keine Erweiterung. AID=2
Freight&Fleet
19 ProfileList SEQUENCE (0..127, …) OF
Profile }
Keine Erweiterung, Anzahl
Profile in Liste = 0
20 FCS Frame-Überprüfungs­
sequenz
21
22 Flag ►C2 Endmerker ◄
DSC_45 Eine DSRC-VU benötigt beim Empfang einer BST die Zu­
weisung eines privaten Fensters gemäß EN 12795 und EN
13372, 7.1.1, ohne spezifische RTM-Einstellungen. Tabelle
14.6 enthält ein Beispiel für die Bit-Verschlüsselung.
Tabelle 14.6
Initialisierung — Frame-Inhalte für die Anforderung einer Zuweisung eines privaten Fensters
O
kt
et
t
#
Attribut/Feld Bits in Oktett Beschreibung
1 FLAG ►C2 Anfangsmerker ◄
2 Private LID Link-Adresse der spezi­
fischen DSRC-VU
3
4
5
6 MAC Control Field Anforderung eines pri­
vaten Fensters
7 FCS Frame-Überprüfungs­
sequenz
8
9 Flag ►C2 Endmerker ◄
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 571
DSC_46 Das REDCR antwortet mit der Zuweisung eines privaten
Fensters, wie durch EN 12795 und EN 13372, 7.1.1 angege­
ben, ohne spezifische RTM-Einstellungen.
Tabelle 14.7 enthält ein Beispiel für die Bit-Verschlüsselung.
Tabelle 14.7
Initialisierung — Frame-Inhalte für die Anforderung einer Zuweisung eines privaten Fensters
O
kt
et
t
#
Attribut/Feld Bits in Oktett Beschreibung
1 FLAG ►C2 Anfangsmerker ◄
2 Private LID Link-Adresse der spezi­
fischen DSRC-VU
3
4
5
6 MAC Control Field Zuweisung eines privaten
Fensters
7 FCS Frame-Überprüfungs­
sequenz
8
9 Flag ►C2 Endmerker ◄
DSC_47 Wenn sie die Zuweisung des privaten Fensters erhält, sendet
die DSRC-VU ihre VST (Vehicle Service Table) gemäß EN
12834 und EN 13372, 6.2, 6.3, 6.4 und 7.1 mit den Einstel­
lungen aus Tabelle 14.8, unter Verwendung des zugewiesenen
Übertragungsfensters.
Tabelle 14.8
Initialisierung — VST-Frame-Einstellungen
Feld Einstellungen
Private LID Gemäß EN 12834
VST-Parameter Fill=0, anschließend für jede unter­
stützte Anwendung: EID vorhanden,
Parameter vorhanden,AID=2, EID
wie durch OBU generiert
Parameter Keine Erweiterung, enthält die
RTM-ContextMark
ObeConfiguration Fakultativ kann das Feld „ObeStatus“
vorliegen, es soll nicht von REDCR
verwendet werden.
Fragmentation header Keine Fragmentierung
Layer 2 settings Befehls-PDU, UI-Befehl
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 572
DSC_48 Die DSRC-VU muss die „Freight&Fleet“-Anwendung unter­
stützen, gekennzeichnet durch die Anwendungskennung „2“.
Es können weitere Anwendungskennungen unterstützt wer­
den, die aber in dieser VST nicht vorhanden sein sollen, da
die BST lediglich AID=2 erfordert. Das Feld „Applications“
enthält eine Liste der unterstützten Anwendungsinstanzen in
der DSRC-VU. Für jede unterstützte Anwendungsinstanziie­
rung ist ein Verweis auf den jeweiligen Standard gegeben:
Dieser besteht aus dem Rtm-ContextMark, zusammengesetzt
aus einer OBJEKTKENNUNG für die zugehörige Norm, den
entsprechenden Teil (9 für RTM) und möglicherweise die
Version sowie einer EID, die von der DSRC-VU generiert
wird und dieser Anwendungsinstanz zugeordnet ist.
Ein praktisches Beispiel der in Tabelle 14.8 angegebenen
Einstellungen samt Angabe der Bit-Verschlüsselungen findet
sich in Tabelle 14.9.
▼M3
Tabelle 14,9
Initialisierung – Beispiele für die Inhalte von VST-Frames
O
kt
et
t
Attribut/Feld Bits in Oktett Beschreibung
1 FLAG 0111 1110 Start-Flag
2 Private LID xxxx xxxx Link-Adresse der spezi­
fischen DSRC-VU
3 xxxx xxxx
4 xxxx xxxx
5 xxxx xxxx
6 MAC Control field 1100 0000 PDU-Befehl
7 LLC Control field 0000 0011 UI-Befehl
8 Fragmentation header 1xxx x001 Keine Fragmentierung
9 VST
SEQUENCE {
Fill BIT STRING (SIZE(4))
1001 Initialisierungsantwort
0000 Nicht verwendet und auf
0 gesetzt
10 Profile INTEGER (0..127,...)
Applications SEQUENCE OF {
0000 0000 Keine Erweiterung. Bei­
spielprofil 0
Keine Erweiterung, 1 An­
wendung
11 0000 0001
12 SEQUENCE {
OPTION indicator
OPTION indicator
AID DSRCApplicationEntityID
1 EID vorhanden
1 Parameter vorhanden
00 0010 Keine Erweiterung.
AID=2 Freight&Fleet
13 EID Dsrc-EID xxxx xxxx Gemäß OBU definiert,
kennzeichnet Anwen­
dungsinstanz.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 573
O
kt
et
t
Attribut/Feld Bits in Oktett Beschreibung
14 Parameter Container { 0000 0010 Keine Erweiterung, Con­
tainerwahl = 02,
Oktett-String
15 0000 0110 Keine Erweiterung, Länge
von Rtm-ContextMark =
6
16 Rtm-ContextMark ::= SEQUENCE {
StandardIdentifier
0000 0101 Das erste Oktett ist 05H,
die Länge.
Die nachfolgenden 5 Ok­
tette verschlüsseln die Ob­
jektkennung des unter­
stützten Standards, Teil
und Version.
{ISO (1) Standard (0)
TARV (15638) part9(9)
Version2 (2)}
17 standardIdentifier 0010 1000
18 1111 1010
19 0001 0110
20 0000 1001
21 0000 0010
22 ObeConfiguration Sequence {
OPTION indicator
0 ObeStatus nicht vorhan­
den
EquipmentClass INTEGER (0..32767) xxx xxxx Dieses Feld wird für die
23 xxxx xxxx Angaben des Herstellers
zur Software-/Hardware­
version der DSRC-
Schnittstelle verwendet.
24 ManufacturerId INTEGER (0..65535) xxxx xxxx Herstellerkennung für
DSRC-VU gemäß ISO-
14816-Register 25 xxxx xxxx
26 FCS xxxx xxxx Frame-Überprüfungs­
sequenz
27 xxxx xxxx
28 Flag 0111 1110 End-Flag
▼B
DCS_49 Anschließend liest das REDCR die Daten durch die Ausgabe
eines GET-Befehls gemäß der Definition in EN 13372, 6.2,
6.3, 6.4 und EN 12834 mit den Einstellungen gemäß Tabelle
14.10.
Tabelle 14.10
Präsentation — Frame-Einstellungen für GET-Anforderungen
Feld Einstellungen
Invoker Identifier (IID) Nicht vorhanden
Link Identifier (LID) Link-Adresse der spezifischen DSRC-
VU
Chaining Nein
Element Identifier (EID) Gemäß VST. Keine Erweiterung
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 574
Feld Einstellungen
Access Credentials Nein
AttributeIdList Keine Erweiterung, 1 Attribut, Attri­
buteID = 1 (RtmData)
Fragmentation Nein
Layer2 settings PDU-Befehl, Polled ACn-Befehl
Tabelle 14.11 zeigt ein Beispiel für das Lesen der RTM-Da­
ten.
Tabelle 14.11
Präsentation — Frame-Beispiel für GET-Anforderungen
O
kt
et
t
#
Attribut/Feld Bits in Oktett Beschreibung
1 FLAG ►C2 Anfangsmerker ◄
2 Private LID Link-Adresse der spezi­
fischen DSRC-VU
3
4
5
6 MAC Control Field PDU-Befehl
7 LLC Control field Polled ACn-Befehl, n Bit
8 Fragmentation header Keine Fragmentierung
9 Get.request
SEQUENCE {
GET-Anforderung
OPTION indicator Zugangsdaten nicht vor­
handen
OPTION indicator IID nicht vorhanden
OPTION indicator AttributeIdList vorhanden
Fill BIT STRING(SIZE(1)) Auf 0 gesetzt.
10 EID INTEGER(0..127,…) EID der RTM-Anwen­
dungsinstanz, Gemäß
VST. Keine Erweiterung
11 AttributeIdList SEQUENCE OF {
AttributeId }}
Keine Erweiterung, An­
zahl Attribute = 1
12 AttributeId=1, RtmData.
Keine Erweiterung
13 FCS Frame-Überprüfungs­
sequenz
14
15 Flag ►C2 Endmerker ◄
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 575
DSC_50 Beim Erhalt der GET-Anforderung sendet die DSRC-VU eine
GET-Antwort mit den angeforderten Daten gemäß der in EN
13372, 6.2, 6.3, 6.4 und EN 12834 definierten GET-Antwort
und den Einstellungen gemäß Tabelle 14.12.
Tabelle 14.12
Präsentation — Frame-Einstellungen für GET-Antwort
Feld Einstellungen
Invoker Identifier (IID) Nicht vorhanden
Link Identifier (LID) Gemäß EN 12834
Chaining Nein
Element Identifier (EID) Gemäß VST.
Access Credentials Nein
Fragmentation Nein
Layer2 settings Antwort-PDU, Antwort ver­
fügbar und Befehl akzeptiert,
ACn-Befehl
Tabelle 14.13 zeigt ein Beispiel für das Lesen der RTM-Da­
ten.
Tabelle 14.13
Präsentation — Beispiel für die Inhalte des Antwort-Frames
O
kt
et
t
#
Attribut/Feld Bits in Oktett Beschreibung
1 FLAG ►C2 Anfangsmerker ◄
2 Private LID Link-Adresse der spezi­
fischen DSRC-VU
3
4
5
6 MAC Control Field Antwort-PDU
7 LLC Control field Antwort verfügbar, ACn-
Befehl, n Bit
8 LLC Status field Antwort verfügbar und
Befehl akzeptiert
9 Fragmentation header Keine Fragmentierung
10 Get.response
SEQUENCE {
Get-Antwort
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 576
O
kt
et
t
#
Attribut/Feld Bits in Oktett Beschreibung
OPTION indicator IID nicht vorhanden
OPTION indicator Attributliste vorhanden
OPTION indicator Rückgabestatus nicht vor­
handen
Fill BIT STRING(SIZE(1)) Nicht verwendet
11 EID INTEGER(0..127,…) Antwort aus RTM-An­
wendungs-
instanz. Keine Erweite­
rung
12 AttributeList SEQUENCE OF { Keine Erweiterung, An­
zahl Attribute = 1
13 Attributes SEQUENCE {
AttributeId
Keine Erweiterung, Attri­
buteId=1 (RtmData)
14 AttributeValue CONTAINER { Keine Erweiterung, Con­
tainerwahl = 10 10 .
15 RtmData
16
17
… …
n }}}}
n+1 FCS Frame-Überprüfungs­
sequenz
n+2
n+3 Flag ►C2 Endmerker ◄
DSC_51 Anschließend schließt das REDCR die Verbindung durch
Ausgabe eines EVENT_REPORT, RELEASE-Befehls gemäß
EN 13372, 6.2, 6.3, 6.4 und EN 12834,7.3.8, ohne spezifische
RTM-Einstellungen. Tabelle 14.14 zeigt das Beispiel einer
Bit-Verschlüsselung des RELEASE-Befehls.
Tabelle 14.14
Beendigung. EVENT_REPORT Inhalte des Release-Frames
O
kt
et
t
#
Attribut/Feld Bits in Oktett Beschreibung
1 FLAG ►C2 Anfangsmerker ◄
2 Private LID Link-Adresse der spezi­
fischen DSRC-VU
3
4
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 577
O
kt
et
t
#
Attribut/Feld Bits in Oktett Beschreibung
5
6 MAC Control Field Der Frame enthält eine
Befehls-LPDU
7 LLC Control field UI-Befehl
8 Fragmentation header Keine Fragmentierung
9 EVENT_REPORT.request
SEQUENCE {
EVENT_REPORT (Re­
lease)
OPTION indicator Zugangsdaten nicht vor­
handen
OPTION indicator Ereignisparameter nicht
vorhanden
OPTION indicator IID nicht vorhanden
Mode BOOLEAN Keine Antwort erwartet
10 EID INTEGER (0..127,…) Keine Erweiterung, EID =
0 (System)
11 EventType INTEGER (0..127,…) } Ereignisart 0 = Release
12 FCS Frame-Überprüfungs­
sequenz
13
14 Flag ►C2 Endmerker ◄
DSC_52 Es wird nicht erwartet, dass die DSRC-VU auf den
Release-Befehl antwortet. Die Kommunikation wird dann
geschlossen.
5.4.8 Beschreibung der DSRC-Prüftransaktion
DSC_53 Vollständige Prüfungen, die eine Sicherung der Daten bein­
halten, müssen gemäß Anlage 11 Gemeinsame Sicherheits­
mechanismen durch befugtes Personal mit Zugang zu den
Sicherheitsverfahren unter Verwendung der normalen, oben
definierten GET-Befehle durchgeführt werden.
DSC_54 Inbetriebnahme und regelmäßige Inspektionen, bei denen eine
Entschlüsselung und ein Verständnis der entschlüsselten Da­
ten erforderlich sind, müssen gemäß Anlage 11 Gemeinsame
Sicherheitsmechanismen und Anlage 9 Typgenehmigung —
Mindestanforderungen an die durchzuführenden Prüfungen
durchgeführt werden.
Die grundlegende DSRC-Kommunikation kann hingegen mit
dem Befehl ECHO geprüft werden. Solche Prüfungen können
bei der Inbetriebnahme, bei regelmäßigen Inspektionen oder
auf Verlangen der zuständigen Kontrollbehörde oder gemäß
der Verordnung (EU) Nr. 165/2014 (siehe 6 unten) erforder­
lich sein.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 578
DSC_55 Zur Durchführung dieser Prüfung der grundlegenden Kom­
munikation wird der Befehl ECHO vom REDCR während
einer Sitzung ausgegeben, d. h. nach erfolgreicher Durchfüh­
rung einer Initialisierungsphase. Die Abfolge der Interaktio­
nen ähnelt deshalb derjenigen einer Abfrage:
— Schritt 1 Das REDCR sendet eine „Beacon Service
Table“ (BST) mit den Anwendungskennungen (AID) in
der unterstützten Dienstliste. In der RTM-Anwendung ist
dies einfach der Dienst mit AID-Wert = 2.
Die DSRC-VU wertet die empfangene BST aus; sofern sie
erkennt, dass die BST Freight&Fleet (AID = 2) anfragt,
antwortet die DSRC-VU. Wenn das REDCR nicht AID=2
anbietet, beendet die DSRC-VU die Transaktion mit dem
REDCR.
— Schritt 2 Die DSRC-VU sendet eine Anfrage nach Zuwei­
sung eines privaten Fensters.
— Schritt 3 Die REDCR sendet die Zuweisung eines pri­
vaten Fensters.
— Schritt 4 Die DSRC-VU sendet mithilfe des zugewiesenen
privaten Fensters ihre Fahrzeugdiensttabelle (Vehicle Ser­
vice Table, VST). Diese VST enthält eine Liste aller
unterschiedlichen Anwendungsinstanziierungen, die diese
DSRC-VU im Rahmen von AID=2 unterstützt. Die ver­
schiedenen Instanziierungen sind durch einzelne EID zu
identifizieren, von denen jede mit einem Parameterwert
verbunden ist, der die unterstützte Anwendungsinstanz
angibt.
— Schritt 5 Anschließend analysiert das REDCR die ange­
botene VST und beendet entweder die Verbindung (RE­
LEASE), weil das Angebot der VST nicht interessant ist
(d. h., es erhält von der DSRC-VU eine VST, die keine
RTM-VU ist), oder es erhält eine passende VST und
startet die Instanziierung der App.
— Schritt 6 Das REDCR gibt einen Befehl (ECHO) an die
jeweilige DSRC-VU aus und weist ein privates Fenster zu.
— Schritt 7 Die DSRC-VU sendet mithilfe des neu zugewie­
senen privaten Fensters eine ECHO-Antwort.
Die folgenden Tabellen enthalten ein praktisches Beispiel für eine
ECHO-Austauschsitzung.
DSC_56 Initialisierung erfolgt gemäß 5.4.7 (DSC_44 bis DSC_48) und
den Tabellen 14.4 bis 14.9.
DSC_57 Das REDCR gibt anschließend einen ACTION-, ECHO-Be­
fehl gemäß ISO 14906 ohne spezifische RTM-Einstellungen
aus, der 100 Datenoktetten enthält. In Tabelle 14.15 sind die
Inhalte des durch das REDCR gesendeten Frames dargestellt.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 579
Tabelle 14.15
Beispiel für ACTION-, ECHO-Anfrage-Frame
O
kt
et
t
#
Attribut/Feld Bits in Oktett Beschreibung
1 FLAG ►C2 Anfangsmerker ◄
2 Private LID Link-Adresse der spezi­
fischen DSRC-VU
3
4
5
6 MAC Control Field PDU-Befehl
7 LLC Control field Polled ACn-Befehl, n Bit
8 Fragmentation header Keine Fragmentierung
9 ACTION.request
SEQUENCE {
Action request (ECHO)
OPTION indicator Zugangsdaten nicht vor­
handen
OPTION indicator Aktionsparameter vorhan­
den
OPTION indicator IID nicht vorhanden
Mode BOOLEAN Antwort erwartet
10 EID INTEGER (0..127,…) Keine Erweiterung, EID =
0 (System)
11 ActionType INTEGER (0..127,…) Keine Erweiterung, Akti­
onstyp ECHO-Anfrage
12 ActionParameter CONTAINER { Keine Erweiterung, Con­
tainerwahl = 2
13 Keine Erweiterung. String-
Länge = 100 Oktette
14 Echo-Daten
… …
113 }}
114 FCS Frame-Überprüfungs­
sequenz
115
116 Flag ►C2 Endmerker ◄
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 580
DSC_58 Beim Erhalt der ECHO-Anforderung sendet die DSRC-VU
eine ECHO-Antwort mit 100 Datenoktetten durch Widerspie­
gelung des erhaltenen Befehls, gemäß ISO 14906, ohne spezi­
fische RTM-Einstellungen. In Tabelle 14.16 ist ein Beispiel
für eine Kodierung auf Bit-Ebene dargestellt.
Tabelle 14.16
Beispiel für ACTION-, ECHO-Anfrage-Frame
O
kt
et
t
#
Attribut/Feld Bits in Oktett Beschreibung
1 FLAG ►C2 Anfangsmerker ◄
2 Private LID Link-Adresse der spezi­
fischen VU
3
4
5
6 MAC Control Field Antwort-PDU
7 LLC Control field ACn-Befehl, n Bit
8 LLC status field Antwort verfügbar
9 Fragmentation header Keine Fragmentierung
10 ACTION.response
SEQUENCE {
ACTION-
Antwort (ECHO)
OPTION indicator IID nicht vorhanden
OPTION indicator Antwortparameter vorhan­
den
OPTION indicator Rückgabestatus nicht vor­
handen
Fill BIT STRING (SIZE (1)) Nicht verwendet
11 EID INTEGER (0..127,…) Keine Erweiterung, EID =
0 (System)
12 ResponseParameter CONTAINER { Keine Erweiterung, Con­
tainerwahl = 2
13 Keine Erweiterung.
String-Länge = 100 Ok­
tette
14 Echo-Daten
… …
113 }}
114 FCS Frame-Überprüfungs­
sequenz
115
116 Flag ►C2 Endmerker ◄
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 581
5.5 Reserviert für künftige Verwendung
▼M2
__________
▼B
5.6 Datenübermittelung zwischen DSRC-VU und VU
5.6.1 Physische Verbindung und Schnittstellen
DSC_66 Die Verbindung zwischen VU und DSRC-VU kann entweder
über eine Kabelverbindung oder eine Kurzbereich-Drahtlos­
kommunikation basierend auf Bluetooth v4.0 BLE erfolgen.
DSC_67 Unabhängig von der Wahl von Verbindung und Schnittstelle
müssen die folgenden Anforderungen erfüllt sein:
DSC_68 ►M1 a) Damit unterschiedliche Hersteller für die Lieferung
der VU und DSRC-VU und auch unterschiedlicher
Lose der DSRC-VU gewählt werden können, muss
die Verbindung zwischen VU und nicht
VU-interner DSRC-VU nach einem offenen Stan­
dard erfolgen. Die VU wird auf eine der folgenden
Arten mit der DSRC-VU verbunden: ◄
i) über ein mindestens 2 m langes Festkabel mit
geradem H11-Stecker (11-polig) nach DIN
41612 von der DSRC-VU auf eine passende
Buchse mit DIN/ISO-Zulassung vom VU-Ge­
rät
ii) über Bluetooth Low Energy (BLE)
iii) über eine standardmäßige ISO-11898- oder
SAE-J1939-Verbindung
DSC_69 b) Die Definition der Schnittstellen und Verbindung zwischen
VU und DSRC-VU muss die in 5.6.2. definierten Befehle
des Anwendungsprotokolls erfüllen, und
DSC_70 c) VU und DSRC-VU müssen die Datenübermittlung über
die Verbindung im Hinblick auf Leistung und Stromver­
sorgung unterstützen.
5.6.2 Anwendungsprotokoll
DSC_71 Das Anwendungsprotokoll zwischen VU-Fernkommunikati­
onseinrichtung und DSRC-VU ist für die regelmäßige Über­
tragung der Fernkommunikationsdaten von der VU zur DSRC
verantwortlich.
DSC_72 Die folgenden wichtigsten Befehle werden identifiziert:
1. Initialisierung des Kommunikationslinks — Anforderung
2. Initialisierung des Kommunikationslinks — Antwort
3. Senden der Daten samt Kennung der RTM-Anwendung
und der durch die RTM-Daten definierten Nutzlast
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 582
4. Quittierung der Daten
5. Beendigung des Kommunikationslinks — Anforderung
6. Beendigung des Kommunikationslinks — Antwort
DSC_73 In ASN1.0 können die vorherigen Befehle wie folgt definiert
sein:
DSC_74 Die Beschreibung der Befehle und Parameter lautet wie folgt:
— ­
dient zur Initialisierung des Kommunikationslinks. Der
Befehl wird von der VU an die DSRC-VU gesendet.
Der LinkIdentifier wird von der VU an die DSRC-VU
gesendet, um einen bestimmten Kommunikationslink zu
protokollieren.
(Hinweis: Dies dient dazu, zukünftige Links und andere An­
wendungen/Module wie Wiegen an Bord zu unterstützen).
— ­
wird von der DSRC-VU für die Antwort auf die Anfrage
zur Initialisierung des Kommunikationslinks verwendet.
Der Befehl wird von der DSRC-VU an die VU gesendet.
Der Befehl stellt das Ergebnis der Initialisierung als Ant­
wort = 1 (Erfolg) oder = 0 (Fehler) dar.
DSC_75 Die Initialisierung des Kommunikationslinks erfolgt nach In­
stallation, Kalibrierung und Anlassen des Motors/Einschalten
der VU.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 583
— wird von der VU dazu verwendet,
die signierten RCDT-Daten (d. h. die Fernkommunikati­
onsdaten) an die DSRC-VU zu senden. Die Daten werden
alle 60 Sekunden gesendet. Der Parameter DataTrans­
actionId kennzeichnet die jeweilige Datenübertragung.
Außerdem wird durch LinkIdentifier sichergestellt, dass
der entsprechende Link korrekt ist.
— wird von der
DSRC-VU gesendet, um der VU Rückmeldung über den
Erhalt der Daten infolge eines Befehls
zu geben, gekennzeichnet durch
den Parameter DataTransactionId. Der Antwortparameter
lautet 1 (Erfolg) oder = 0 (Fehler). Wenn eine VU mehr
als drei Antworten gleich 0 erhält oder wenn die VU kein
RCDT Data Acknowledgment für einen bestimmten zuvor
gesendeten RCDT-Send Data mit spezifischer DataTrans­
actionId erhält, muss die VU ein Ereignis generieren und
aufzeichnen.
— request
wird von der VU an die DSRC-VU gesendet, um einen
Link für einen spezifischen LinkIdentifier zu beenden.
DSC_76 Beim Neustart der DSRC-VU oder einer VU müssen alle
bestehenden Kommunikationslinks gelöscht werden, da auf­
grund eines abrupten Herunterfahrens einer VU „bezuglose“
Links vorhanden sein könnten.
— wird von
der DSRC-VU an die VU gesendet, um die Aufforderung
zur Beendigung des Links durch die VU für den spezi­
fischen LinkIdentifier zu bestätigen.
5.7 Fehlerbehandlung
5.7.1 Aufzeichnung und Kommunikation der Daten in der DSRC-VU
▼M3
DSC_77 Die Daten sind, stets gesichert, von der VUSM-Funktion der
DSRC-VU bereitzustellen. Die VUSM verifiziert, dass in der
DSRC-VU aufgezeichnete Daten erfolgreich an die DSRC-VU
übermittelt wurden. Die Aufzeichnung und Protokollierung
von Fehlern bei der Datenübermittlung von der VU in den
Speicher der DSRC-VU muss mit dem Typ EventFaultType
und dem Enum-Wert „0C“H für das Ereignis „Kommunika­
tionsfehler mit der Fernkommunikationsausrüstung“ zusam­
men mit dem Zeitstempel erfolgen. Die VUSM verifiziert,
dass die Daten erfolgreich an die DSRC-VU übermittelt
wurden.
DSC_78 Reserviert für künftige Verwendung.
▼B
DSC_79 Wenn die VUPM vergebens versucht, VU-Daten vom Sicher­
heitsmodul abzurufen (um diese an die VU-DSRC weiter­
zuleiten), muss sie diesen Fehler mit dem Typ EventFault­
Type und dem Enum-Kommunikationsfehlerwert „62“H Re­
mote Communication Facility samt Zeitstempel aufzeichnen.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 584
Der Kommunikationsfehler wird erkannt, wenn mehr als drei
Mal in Folge keine Nachricht
für die zugehörigen (d. h. mit der gleichen DataTransactionId
-Nachrich­
ten versehenen) eingeht.
5.7.2 Fehler in der Drahtloskommunikation
DSC_80 Die Behandlung von Kommunikationsfehlern muss mit derje­
nigen gemäß zugehörigen DSRC-Normen, nämlich EN 300
674-1, EN 12253, EN 12795, EN 12834 und den entspre­
chenden Parametern von EN 13372, übereinstimmen.
5.7.2.1 Verschlüsselungs- und Signaturfehler
DSC_81 Verschlüsselungs- und Signaturfehler sind gemäß Anlage 11
Gemeinsame Sicherheitsmechanismen zu behandeln und sind
in den Fehlernachrichten zur DSRC-Datenübermittlung nicht
vorhanden.
5.7.2.2 Aufzeichnung von Fehlern
Das DSRC-Medium ist eine dynamische Drahtloskommunikation in ei­
ner Umgebung mit unsicheren atmosphärischen und Interferenzbedin­
gungen, insbesondere in den an dieser Anwendung beteiligten Kombina­
tionen „tragbares REDCR“ und „Fahrzeug in Bewegung“. Deshalb muss
zwischen den Bedingungen „Lesefehler“ und „Fehler“ ein Unterschied
bestehen. Bei einer Transaktion über eine Drahtlosschnittstelle sind Le­
sefehler gängig; anschließend wird in der Regel ein neuer Versuch ge­
startet, d. h. die BST erneut gesendet und die Sequenz wiederholt. Meist
verläuft dieser erneute Kommunikationsversuch dann erfolgreich und die
Daten werden übertragen, sofern das Fahrzeug sich nicht in der zur
Wiederübertragung erforderlichen Zeit aus dem Empfangsbereich be­
wegt. (Eine „erfolgreiche“ Instanz eines Lesevorgangs umfasst mitunter
mehrere Versuche und Wiederholungen).
Ein Lesefehler kann auftreten, weil die Antennen nicht richtig gekoppelt
sind (Fehler beim „Ausrichten“), weil eine der Antennen abgeschirmt ist
(dies kann gewollt sein, aber auch durch die Nähe eines anderen Fahr­
zeugs verursacht sein), durch Funkstörung (insbesondere durch Wifi-
oder andere öffentliche Drahtloskommunikation im Bereich von ca. 5,8
GHz), Radarinterferenz oder schwierige atmosphärische Bedingungen (z.
B. während eines Unwetters) oder einfach dadurch, dass das Fahrzeug
den Bereich der DSRC-Kommunikation verlässt. Die einzelnen Instan­
zen der Lesefehler lassen sich nicht aufzeichnen, da die Kommunikation
schlichtweg nicht stattgefunden hat.
Wenn aber der Mitarbeiter der zuständigen Kontrollbehörde ein Fahr­
zeug anvisiert und versucht, dessen DSRC-VU abzufragen, die Daten
jedoch nicht erfolgreich übermittelt werden, kann dieser Fehler auf
eine gewollte Manipulation zurückzuführen sein. Deshalb muss der Mit­
arbeiter der zuständigen Kontrollbehörde den Fehler protokollieren und
die an der Maßnahme beteiligten Kollegen über einen möglichen Ver­
stoß informieren. Die Kollegen können dann das Fahrzeug anhalten und
physisch überprüfen. Da aber keine erfolgreiche Kommunikation statt­
gefunden hat, kann die DSRC-VU keine Daten über den Fehler liefern.
Eine solche Protokollierung ist deshalb abhängig vom Design des
REDCR-Geräts.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 585
Ein „Lesefehler“ ist technisch gesehen etwas anderes als ein „Fehler“ In
diesem Kontext bedeutet „Fehler“, dass ein falscher Wert erfasst wurde.
Die an die DSRC-VU gelieferten Daten sind bereits gesichert und
müssen deshalb durch den Lieferanten der Daten verifiziert werden
(siehe 5.4).
Anschließend über die Luftschnittstelle übermittelte Daten werden durch
zyklische Redundanzprüfungen (CRC) auf der Kommunikationsebene
geprüft. Wenn diese Prüfung erfolgreich verläuft, sind die Daten korrekt.
Andernfalls werden die Daten erneut übertragen. Die Wahrscheinlich­
keit, dass Daten eine CRC-Prüfung fälschlicherweise erfolgreich beste­
hen, ist statistisch so verschwindend gering, dass sie unberücksichtigt
bleiben kann.
Wenn die CRC-Prüfung fehlschlägt und keine Zeit für ein erneutes
Senden und Empfangen der korrekten Daten mehr bleibt, führt dies nicht
zu einem Fehler, sondern zu einer Instanziierung einer bestimmten Art
von Lesefehler.
Die einzige aussagekräftige „Fehlerinformation“, die sich aufzeichnen
lässt, ist die Anzahl erfolgreicher Initiierungen von Transaktionen, die
nicht zu einer erfolgreichen Datenübermittlung an das REDCR geführt
haben.
DSC_82 Das REDCR hat deshalb die Anzahl der Fälle mit Zeitstempel
aufzuzeichnen, in denen die „Initialisierungsphase“ einer
DSRC-Abfrage erfolgreich verläuft, die Transaktion aber ab­
bricht, bevor das REDCR die Daten erfolgreich abrufen
konnte. Diese Daten sind dem Mitarbeiter der zuständigen
Kontrollbehörde zur Verfügung zu stellen und im Speicher
des REDCR-Geräts abzulegen. Wie dies geschieht, ist eine
Frage des Produktdesigns oder der Festlegung durch die zu­
ständige Kontrollbehörde.
Die einzige aussagekräftige „Fehlerinformation“, die sich auf­
zeichnen lässt, ist die Anzahl der Fälle, in der das REDCR die
empfangenen Daten nicht entschlüsseln konnte. Dies bezieht
sich allerdings nur auf die Effizienz der REDCR-Software.
Unter Umständen werden Daten technisch entschlüsselt, er­
geben aber keinen semantischen Sinn.
DSC_83 Deshalb muss das REDCR mit einem Zeitstempel die Anzahl
der Fälle mit Zeitstempel aufzeichnen, in denen das Gerät
vergeblich versucht hat, die über die DSRC-Schnittstelle emp­
fangenen Daten zu entschlüsseln.
6 INBETRIEBNAHME- UND REGELMÄSSIGE INSPEKTIONSPRÜ­
FUNGEN DER FERNKOMMUNIKATIONSFUNKTION
6.1 Allgemein
DSC_84 Für die Fernkommunikationsfunktion sind zwei Arten von
Prüfungen vorgesehen:
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 586
1) ECHO-Prüfung, um den Drahtloskommunikationskanal
DSRC-REDCR >>-:-
2) Ende-zu-Ende-Sicherheitsprüfung, um zu gewährleisten,
dass eine Werkstattkarte auf die von der VU erzeugten
verschlüsselten und signierten und über den Drahtloskom­
munikationskanal übermittelten Dateninhalte zugreifen
kann.
6.2 ECHO
Die Spezifikationen dieses Abschnitts geben an, wie geprüft wird, dass
die Verbindung DSRC-REDCR >>-:-
sicht aktiv ist.
Ziel des ECHO-Befehls ist es, Werkstätten oder Prüfeinrichtungen zur
Typgenehmigung in die Lage zu versetzen, zu prüfen, ob der DSRC-
Link funktioniert, ohne auf die Sicherheitsangaben zugreifen zu müssen.
Die Ausrüstung des Prüfers muss deshalb nur in der Lage sein, eine
DSRC-Kommunikation (durch Senden einer BST mit AID=2) einzulei­
ten, anschließend den Befehl ECHO zu senden und, bei funktionierender
DSRC, die ECHO-Antwort zu empfangen. Zu Einzelheiten siehe 5.4.8.
Wenn diese Antwort korrekt empfangen wird, kann bestätigt werden,
dass die DSRC-Verbindung (DSRC-REDCR >>-:-
funktioniert.
6.3 Prüfungen zur Validierung sicherer Dateninhalte
DSC_85 Mit dieser Prüfung wird der sichere Ende-zu-Ende-Datenfluss
überprüft. Für diese Prüfung wird ein DSRC-Prüflesegerät
benötigt. Dieses DSRC-Prüflesegerät bietet die gleiche Funk­
tionalität und wird mit denselben Spezifikationen wie das
Lesegerät der Kontrollbehörden eingerichtet. Der einzige Un­
terschied besteht darin, dass anstelle einer Kontrollkarte eine
Werkstattkarte benutzt wird, um den Benutzer des DSRC-
Prüflesegeräts zu authentisieren. Die Prüfung kann im An­
schluss an die Erstaktivierung eines intelligenten Fahrten­
schreibers oder am Ende des Kalibrierungsverfahrens durch­
geführt werden. Nach der Aktivierung generiert die Fahrzeug­
einheit die gesicherten Früherkennungsdaten und übermittelt
diese an die DSRC-VU.
DSC_86 Das Werkstattpersonal positioniert das DSRC-Prüflesegerät in
einem Abstand von 2–10 Metern vor dem Fahrzeug.
DSC_87 Anschließend steckt das Werkstattpersonal eine Werkstatt­
karte in das DSRC-Prüflesegerät ein und fragt von der Fahr­
zeugeinheit die Früherkennungsdaten ab. Nach erfolgreicher
Abfrage greift das Werkstattpersonal auf die empfangenen
Daten zu, um zu überprüfen, ob deren Integrität erfolgreich
validiert und die Daten entschlüsselt wurden.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 587
Beiblatt
Regeln für die Berechnung der täglichen, wöchentlichen und vierzehntägigen
Lenkzeit
1. Grundlegende Berechnungsregeln
Die VU berechnet die tägliche Lenkzeit, die wöchentliche Lenkzeit und die
vierzehntägige Lenkzeit anhand der einschlägigen Daten, die in einer in den
Fahrersteckplatz (Steckplatz 1, Kartenleser 1) der Fahrzeugeinheit eingesteck­
ten Fahrerkarte (oder Werkstattkarte) gespeichert sind, sowie anhand der aus­
gewählten Fahrertätigkeiten, während diese Karte in die VU eingesteckt ist.
Es werden keine Lenkzeiten berechnet, während keine Fahrerkarte (oder
Werkstattkarte) eingesteckt ist.
UNBEKANNTE Zeiträume, die in dem für die Berechnungen erforderlichen
Zeitraum aufgefunden werden, müssen UNTERBRECHUNG/RUHE gleich­
gestellt werden.
UNBEKANNTE Zeiträume und Tätigkeiten mit negativer Dauer (d. h. der
Beginn der Tätigkeit erfolgt nach dem Ende der Tätigkeit), die durch Zeit­
überschneidungen zwischen zwei verschiedenen Fahrzeugeinheiten oder eine
Zeiteinstellung bedingt sind, werden nicht berücksichtigt.
Auf der Fahrerkarte aufgezeichnete Tätigkeiten, die Zeiträumen mit der Be­
dingung „KONTROLLGERÄT NICHT ERFORDERLICH“ gemäß Anhang IC
Begriffsbestimmung gg entsprechen, sind wie folgt zu interpretieren:
— UNTERBRECHUNG/RUHE muss als „UNTERBRECHUNG“ oder
„RUHE“ berechnet werden.
— ARBEIT und LENKEN sind als „ARBEIT“ zu betrachten.
— BEREITSCHAFT ist als „BEREITSCHAFT“ zu betrachten.
Im Zusammenhang mit diesem Beiblatt geht die VU davon aus, dass am
Anfang der Aufzeichnungen der Kartentätigkeiten eine tägliche Ruhezeit
vorliegt.
2. Begriffe
Die folgenden Begriffe gelten ausschließlich für diese Anlage und dienen
dazu, die Berechnung der Lenkzeiten durch die VU und deren spätere Über­
mittlung durch die Fernkommunikationseinrichtung zu spezifizieren.
a) „RTM-Schicht“ ist der Zeitraum zwischen dem Ende einer täglichen Ruhe­
zeit und dem Ende der unmittelbar darauf folgenden täglichen Ruhezeit.
Die VU startet nach Beendigung einer täglichen Ruhezeit eine neue
RTM-Schicht.
Die laufende RTM-Schicht ist der Zeitraum seit dem Ende der letzten
täglichen Ruhezeit.
b) „Kumulierte Lenkzeit“ ist die Summe der Dauer aller LENKEN-Tätigkei­
ten des Fahrers in einem Zeitraum, in dem nicht die Bedingung „KON­
TROLLGERÄT NICHT ERFORDERLICH“ gilt.
c) „Tägliche Lenkzeit“ ist die kumulierte Lenkzeit innerhalb einer
RTM-Schicht.
d) „Wöchentliche Lenkzeit“ ist die kumulierte Lenkzeit während der laufen­
den Woche.
e) „Ununterbrochene Ruhezeit“ ist jeder ununterbrochene Zeitraum „UNTER­
BRECHUNG/RUHE“.
f) „Vierzehntätige Lenkzeit“ ist die kumulierte Lenkzeit der vorangegangenen
und der laufenden Woche.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 588
g) „Tägliche Ruhezeit“ ist ein Zeitraum „UNTERBRECHUNG/RUHE“, der
entweder
— eine regelmäßige tägliche Ruhezeit,
— eine aufgeteilte tägliche Ruhezeit oder
— eine reduzierte tägliche Ruhezeit sein kann.
Im Zusammenhang mit Anlage 14 gilt, dass bei der Berechnung wöchent­
licher Ruhezeiten durch eine VU diese wöchentlichen Ruhezeiten als täg­
liche Ruhezeiten zu betrachten sind.
h) „Regelmäßige tägliche Ruhezeit“ ist eine ununterbrochene Ruhezeit von
mindestens 11 Stunden.
In Ausnahmefällen kann bei einer aktivierten Bedingung „FÄHRÜBER­
FAHRT/ZUGFAHRT“ die regelmäßige tägliche Ruhezeit höchstens zwei­
mal durch andere Tätigkeiten als Ruhezeiten mit einer maximalen kumu­
lierten Dauer von einer Stunde unterbrochen werden, d. h. die regelmäßige
tägliche Ruhezeit einschließlich Zeiten einer Fährüberfahrt/Zugfahrt darf in
diesem Fall in zwei oder drei Teile aufgeteilt werden. Die VU berechnet
dann eine regelmäßige tägliche Ruhezeit, wenn die gemäß Nummer 3
berechnete kumulierte Ruhezeit mindestens 11 Stunden beträgt.
Wenn eine regelmäßige tägliche Ruhezeit unterbrochen wurde,
— bezieht die VU die während dieser Unterbrechungen aufgetretene
Lenktätigkeit nicht in die Berechnung der täglichen Lenkzeit ein und
— startet die VU am Ende der regelmäßigen täglichen Ruhezeit, die un­
terbrochen wurde, eine neue RTM-Schicht.
Abbildung 1.
Beispiel für eine tägliche Ruhezeit, die aufgrund von Fährüberfahrten/Zugfahrten unterbrochen wurden
i) „Reduzierte tägliche Ruhezeit“ ist eine ununterbrochene Ruhezeit von min­
destens 9 Stunden, aber weniger als 11 Stunden.
j) „Aufgeteilte tägliche Ruhezeit“ ist eine tägliche Ruhezeit, die in zwei
Teilen genommen wird:
— Der erste Teil ist eine ununterbrochene Ruhezeit von mindestens
3 Stunden, aber weniger als 9 Stunden.
— Der zweite Teil ist eine ununterbrochene Ruhezeit von mindestens
9 Stunden.
In Ausnahmefällen kann bei Geltung einer Bedingung „FÄHRÜBER­
FAHRT/ZUGFAHRT“ während eines oder beider Teile einer aufgeteilten
täglichen Ruhezeit die aufgeteilte tägliche Ruhezeit höchstens zweimal
durch andere Tätigkeiten mit einer maximalen kumulierten Dauer von einer
Stunde unterbrochen werden, d. h.
— der erste Teil der aufgeteilten täglichen Ruhezeit kann ein- oder zwei­
mal unterbrochen werden, oder
— der zweite Teil der aufgeteilten täglichen Ruhezeit kann ein- oder
zweimal unterbrochen werden, oder
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 589
— der erste Teil der aufgeteilten täglichen Ruhezeit kann einmal unter­
brochen werden und der zweite Teil der aufgeteilten täglichen Ruhezeit
kann einmal unterbrochen werden.
Die VU berechnet dann eine aufgeteilte tägliche Ruhezeit, wenn die gemäß
Nummer 3 berechnete kumulierte Ruhezeit:
— mindestens 3 Stunden und weniger als 11 Stunden für die erste Ruhe­
zeit und mindestens 9 Stunden für die zweite Ruhezeit beträgt, sofern
die erste Ruhezeit durch eine „FÄHRÜBERFAHRT/ZUGFAHRT“ un­
terbrochen wurde;
— mindestens 3 Stunden und weniger als 9 Stunden für die erste Ruhezeit
und mindestens 9 Stunden für die zweite Ruhezeit beträgt, sofern die
erste Ruhezeit nicht durch eine „FÄHRÜBERFAHRT/ZUGFAHRT“
unterbrochen wurde;
Abbildung 2.
Beispiel für eine aufgeteilte tägliche Ruhezeit, die aufgrund von Fährüberfahrten/Zugfahrten unterbrochen
wurden
Wenn die aufgeteilte tägliche Ruhezeit unterbrochen wurde,
— bezieht die VU die während dieser Unterbrechungen aufgetretene
Lenktätigkeit nicht in die Berechnung der täglichen Lenkzeit ein und
— startet die VU am Ende der aufgeteilten täglichen Ruhezeit, die unter­
brochen wurde, eine neue RTM-Schicht.
k) „Woche“ ist der Zeitraum in UTC-Zeit zwischen Montag, 00.00 Uhr, und
Sonntag, 24.00 Uhr.
3. Berechnung der täglichen Ruhezeit bei Unterbrechung aufgrund von Fährüber­
fahrten/Zugfahrten
Die VU berechnet die kumulierte Ruhezeit bei Unterbrechung der Ruhezeit
aufgrund von Fährüberfahrten/Zugfahrten gemäß den folgenden Schritten:
a) Schritt 1
Die VU erkennt Unterbrechungen der Ruhezeit vor der Aktivierung des
Merkers „FÄHRÜBERFAHRT/ZUGFAHRT (ANFANG)“ gemäß Abbil­
dung 3 und bewertet bei Vorliegen dieses Falls gemäß Abbildung 4 für
jede erkannte Unterbrechung, ob die folgenden Bedingungen erfüllt sind:
— die Unterbrechung führt dazu, dass die Gesamtdauer der erkannten
Unterbrechungen, einschließlich bei Vorliegen von Unterbrechungen
während des ersten Teils einer aufgeteilten täglichen Ruhezeit aufgrund
einer Fährüberfahrt/Zugfahrt, eine Gesamtdauer von einer Stunde über­
schreitet,
— die Unterbrechung führt dazu, dass die Gesamtanzahl der erkannten
Unterbrechungen, einschließlich bei Vorliegen von Unterbrechungen
während des ersten Teils einer aufgeteilten täglichen Ruhezeit aufgrund
einer Fährüberfahrt/Zugfahrt, mehr als zwei Unterbrechungen beträgt,
— eine „Eingabe des Orts des Beginns des Arbeitstages“ ist nach dem
Ende der Unterbrechung gespeichert.
Wenn keine der oben genannten Bedingungen erfüllt ist, wird die ununter­
brochene Ruhezeit unmittelbar vor der Unterbrechung zur kumulierten
Ruhezeit hinzugerechnet.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 590
Wenn mindestens eine der oben genannten Bedingungen erfüllt ist, muss
die VU entweder die Berechnung der kumulierten Ruhezeit gemäß Schritt 2
beenden oder Unterbrechungen der Ruhezeit im Anschluss an den Merker
„FÄHRÜBERFAHRT/ZUGFAHRT (ANFANG)“ gemäß Schritt 3
erkennen.
b) Schritt 2
Für jede gemäß Schritt 1 erkannte Unterbrechung bewertet die VU, ob die
Berechnung der kumulierten Ruhezeit beendet werden sollte. Die VU be­
endet den Berechnungsprozess, wenn zwei ununterbrochene Ruhezeiten
vor Aktivierung des Merkers „FÄHRÜBERFAHRT/ZUGFAHRT (AN­
FANG)“ zur kumulierten Ruhezeit hinzugerechnet wurden, einschließlich
Ruhezeiten im ersten Teil einer aufgeteilten täglichen Ruhezeit, die eben­
falls durch Fährüberfahrten/Zugfahrten unterbrochen wird. Andernfalls
fährt die VU gemäß Schritt 3 fort.
c) Schritt 3
Wenn die VU nach der Durchführung von Schritt 2 die Berechnung der
kumulierten Ruhezeit fortsetzt, erkennt die VU Unterbrechungen nach der
Deaktivierung der Bedingung „FÄHRÜBERFAHRT/ZUGFAHRT“ gemäß
Abbildung 3 und bei Vorliegen dieses Falls gemäß Abbildung 4.
Hinsichtlich jeder erkannten Unterbrechung bewertet die VU, ob die Unter­
brechung bewirkt, dass die kumulierte Zeit aller erkannten Unterbrechun­
gen eine Gesamtzeit von einer Stunde überschreitet; in diesem Fall wird
die Berechnung der kumulierten Ruhezeit am Ende der ununterbrochenen
Ruhezeit vor der Unterbrechung beendet. Andernfalls werden die ununter­
brochenen Ruhezeiten, die nach den jeweiligen Unterbrechungen anfallen,
bei der Berechnung der täglichen Ruhezeit hinzugerechnet, bis die Bedin­
gung in Schritt 4 erfüllt ist.
d) Schritt 4
Die Berechnung der kumulierten Ruhezeit endet, wenn die VU infolge der
Schritte 1 und 3 der Ruhezeit, für die die Bedingung „FÄHRÜBER­
FAHRT/ZUGFAHRT“ aktiviert ist, höchstens zwei ununterbrochene Ruhe­
zeiten hinzugefügt hat, einschließlich bei Vorliegen von Unterbrechungen
während des ersten Teils einer aufgeteilten täglichen Ruhezeit aufgrund
von Fährüberfahrten/Zugfahrten.
Abbildung 3.
Verarbeitung von Ruhezeiten durch die VU, um festzustellen, ob eine unterbrochene Ruhezeit als regel­
mäßige tägliche Ruhezeit oder als erster Teil einer aufgeteilten täglichen Ruhezeit berechnet wird
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 591
Abbildung 4.
Verarbeitung von Ruhezeiten durch die VU, um festzustellen, ob eine unterbrochene Ruhezeit als zweiter
Teil einer aufgeteilten täglichen Ruhezeit berechnet wird
Abbildung 5.
Beispiel für eine mehr als zweimal unterbrochene tägliche Ruhezeit mit der Folge, dass die Ruhezeit H
nicht in die Berechnung einbezogen wird
Abbildung 6.
Beispiel für tägliche Ruhezeit, bei der der Zeitraum der Fährüberfahrt/Zugfahrt nach dem Ende des
Arbeitszeitraums beginnt
Abbildung 7.
Beispiel für eine mehr als zweimal unterbrochene tägliche Ruhezeit mit der Folge, dass die Ruhezeit B
nicht in die Berechnung einbezogen wird
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 592
Abbildung 8.
Beispiel für eine aufgeteilte tägliche Ruhezeit, die einmal während der ersten Ruhezeit und einmal während
der zweiten Ruhezeit unterbrochen wird
4. Berechnung der täglichen, wöchentlichen und vierzehntägigen Lenkzeiten
Die VU berechnet die tägliche(n) Lenkzeit(en) für die laufende RTM-Schicht
und die vorausgehenden RTM-Schichten. Die während der Unterbrechungen
der täglichen Ruhezeiten auftretenden Lenkzeiten werden bei der Berechnung
der täglichen Lenkzeit nicht hinzugerechnet, wenn diese Unterbrechungen auf
eine Fährüberfahrt/Zugfahrt zurückzuführen sind und die Anforderungen ge­
mäß Nummer 2 Buchstaben h und j und Nummer 3 erfüllt sind. Sofern die
VU jedoch keine vollständige regelmäßige oder aufgeteilte tägliche Ruhezeit
gemäß Nummer 3 berechnet hat, sind die während der Unterbrechungen auf­
tretenden Lenkzeiten zu der täglichen Lenkzeit für die laufende RTM-Schicht
hinzuzurechnen.
Die VU berechnet auch die wöchentlichen und die vierzehntägigen Lenkzei­
ten. Die Lenkzeiten, die während der Unterbrechungen der täglichen Ruhe­
zeiten aufgrund von Fährüberfahrten/Zugfahrten auftreten, werden bei der
Berechnung der wöchentlichen und der vierzehntägigen Lenkzeiten
hinzugerechnet.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 593
Anlage 15
MIGRATION: VERWALTUNG GLEICHZEITIG VORHANDENER
AUSRÜSTUNGSGENERATIONEN UND -VERSIONEN
▼B
INHALTSVERZEICHNIS
1. BEGRIFFSBESTIMMUNGEN
2. ALLGEMEINE BESTIMMUNGEN
2.1. Übersicht über die Umstellung
▼M3
2.2. Interoperabilität zwischen VU und Karten
▼B
2.3. Interoperabilität zwischen VU und Bewegungssensoren
2.4. Interoperabilität zwischen Fahrzeugeinheiten, Fahrtenschreiberkarten und
Geräte für das Herunterladen von Daten
2.4.1 Direktes Herunterladen von der Karte durch das IDE
2.4.2 Herunterladen von der Karte über eine Fahrzeugeinheit
2.4.3 Datendownload von Fahrzeugeinheiten
2.5. Interoperabilität zwischen VU und Kalibrierungsgeräten
3. WESENTLICHE SCHRITTE IM ZEITRAUM VOR DEM EINFÜH­
RUNGSDATUM
4. BESTIMMUNGEN FÜR DEN ZEITRAUM NACH DEM EINFÜH­
RUNGSDATUM
▼M3
5. AUFZEICHNUNG VON GRENZÜBERSCHREITUNGEN IN FAHR­
TENSCHREIBERN DER ERSTEN GENERATION UND IN FAHR­
TENSCHREIBERN DER ZWEITEN GENERATION VERSION 1
▼B
1. BEGRIFFSBESTIMMUNGEN
Im Sinne dieser Anlage gelten folgende Begriffsbestimmungen:
Intelligentes Fahrtenschreibersystem: gemäß Definition in diesem An­
hang (Kapitel 1: Begriffsbestimmung bbb);
Fahrtenschreibersystem der 1. Generation: gemäß Definition in dieser
Verordnung (Artikel 2: Begriffsbestimmung 1);
Fahrtenschreibersystem der 2. Generation: gemäß Definition in dieser
Verordnung (Artikel 2: Begriffsbestimmung 7);
Einführungsdatum: gemäß Definition in diesem Anhang (Kapitel 1: Be­
griffsbestimmung ccc);
Intelligent Dedicated Equipment (IDE): Gerät, das zum Herunterladen
von Daten verwendet wird, wie in Anlage 7 dieses Anhangs definiert.
▼M3
2. ALLGEMEINE BESTIMMUNGEN
2.1. Übersicht über die Umstellung
Die Einleitung dieses Anhangs bietet eine Übersicht über die Umstellung
von Fahrtenschreibersystemen der ersten Generation auf solche der zwei­
ten Generation und die Einführung von Kontrollgeräten und Fahrtenschrei­
berkarten der zweiten Generation Version 2.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 594
Über die Bestimmungen dieser Einleitung hinaus wird auf Folgendes
hingewiesen:
— Bewegungssensoren der ersten Generation sind nicht interoperabel mit
Fahrzeugeinheiten der zweiten Generation.
— Nur Bewegungssensoren der zweiten Generation können in Fahrzeuge
eingebaut werden, die mit Fahrzeugeinheiten jeder Version der zweiten
Generation ausgerüstet sind.
— Geräte zum Herunterladen von Daten und zur Kalibrierung müssen
beide Generationen oder Versionen von Kontrollgeräten und Fahrten­
schreiberkarten unterstützen.
2.2. Interoperabilität zwischen VU und Karten
Fahrtenschreiberkarten der ersten Generation sind interoperabel mit Fahr­
zeugeinheiten der ersten Generation (gemäß Anhang IB der Verord­
nung (EWG) Nr. 3821/85); Fahrtenschreiberkarten der zweiten Generation
wiederum sind interoperabel mit jeder Version von Fahrzeugeinheiten der
zweiten Generation (gemäß Anhang IC dieser Verordnung). Zusätzlich
gelten die nachfolgenden Bestimmungen.
MIG_001 Mit Ausnahme der in den Randnummern MIG_004 und
MIG_005 genannten Fälle dürfen Fahrtenschreiberkarten der
ersten Generation bis zu ihrem Ablaufdatum in Fahrzeugein­
heiten jeder Version der zweiten Generation weiterverwendet
werden. Ihre Inhaber können jedoch die Ersetzung durch
Fahrtenschreiberkarten der zweiten Generation fordern, sobald
diese verfügbar sind.
MIG_002 Fahrzeugeinheiten jeder Version der zweiten Generation müs­
sen in der Lage sein, eingesteckte gültige Fahrer-, Kontroll-
und Unternehmenskarten der ersten Generation zu nutzen.
MIG_003 Diese Fähigkeit kann in solchen Fahrzeugeinheiten durch
Werkstätten endgültig unterdrückt werden, sodass Fahrten­
schreiberkarten der ersten Generation nicht mehr akzeptiert
werden. Dies darf erst geschehen, nachdem die Europäische
Kommission ein Verfahren eingeleitet hat, das Werkstätten
hierzu auffordert, beispielsweise während der regelmäßigen
Nachprüfung der Fahrtenschreiber.
MIG_004 Fahrzeugeinheiten der zweiten Generation dürfen nur Werk­
stattkarten der zweiten Generation nutzen können.
MIG_005 Zur Bestimmung der Betriebsart dürfen Fahrzeugeinheiten je­
der Version der zweiten Generation nur die Art der gültigen
eingesteckten Karten berücksichtigen, nicht aber ihre Genera­
tion oder Version.
MIG_006 Jede gültige Fahrtenschreiberkarte jeder Version der zweiten
Generation muss in Fahrzeugeinheiten der ersten Generation
genauso genutzt werden können wie eine Fahrtenschreiber­
karte gleicher Art der ersten Generation.
2.3. Interoperabilität zwischen VU und Bewegungssensoren
Bewegungssensoren der ersten Generation sind interoperabel mit Fahr­
zeugeinheiten der ersten Generation; Bewegungssensoren der zweiten Ge­
neration wiederum sind interoperabel mit Fahrzeugeinheiten jeder Version
der zweiten Generation. Zusätzlich gelten die nachfolgenden Bestimmun­
gen.
MIG_007 Fahrzeugeinheiten jeder Version der zweiten Generation kön­
nen nicht mit Bewegungssensoren der ersten Generation ge­
koppelt und verwendet werden.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 595
MIG_008 Bewegungssensoren der zweiten Generation können entweder
ausschließlich mit Fahrzeugeinheiten jeder Version der zwei­
ten Generation gekoppelt und verwendet werden oder mit
beiden Generationen von Fahrzeugeinheiten
2.4. Interoperabilität zwischen Fahrzeugeinheiten, Fahrtenschreiberkarten
und Geräten für das Herunterladen von Daten
MIG_009 Geräte für das Herunterladen von Daten können mit allen
Generationen und Versionen von Fahrzeugeinheiten und Fahr­
tenschreiberkarten verwendet werden.
2.4.1 Direktes Herunterladen von der Karte durch das IDE
MIG_010 Daten werden durch das IDE von den in ihre Kartenlesegeräte
eingesteckten Fahrtenschreiberkarten einer Generation unter
Verwendung der Sicherheitsmechanismen und Daten­
download-Protokolle dieser Generation heruntergeladen; he­
runtergeladene Daten müssen das für diese Generation und
Version festgelegte Format aufweisen.
MIG_011 Damit auch Nicht-EU-Kontrollbehörden Fahrer kontrollieren
können, muss es möglich sein, Fahrerkarten (und Werkstatt­
karten) jeder Version der zweiten Generation genauso herun­
terzuladen wie Fahrerkarten (und Werkstattkarten) der ersten
Generation. Heruntergeladen werden können müssen unter
anderem:
— nicht signierte EF IC und ICC (optional),
— nicht signierte EF (erste Generation) Card_Certificate und
CA_Certificate,
— sonstige Anwendungsdaten-EF (innerhalb der DF Tacho­
graph), die durch das Download-Protokoll von Karten der
ersten Generation angefordert werden. Diese Informatio­
nen werden entsprechend den Sicherheitsmechanismen
der ersten Generation durch eine digitale Signatur
gesichert.
Die entsprechenden Downloads dürfen keine Anwen­
dungsdaten-EF umfassen, die nur in Fahrerkarten (und
Werkstattkarten) von Version 1 oder Version 2 der zwei­
ten Generation vorhanden sind (Anwendungsdaten-EF in­
nerhalb der DF Tachograph_G2).
2.4.2 Herunterladen von der Karte über eine Fahrzeugeinheit
MIG_012 Für den Datendownload von einer Karte jeder Version der
zweiten Generation, die in eine Fahrzeugeinheit der ersten
Generation eingesteckt ist, wird das Datendownload-Protokoll
der ersten Generation verwendet. Die Karte antwortet auf Be­
fehle der Fahrzeugeinheit in genau der gleichen Weise wie
eine Karte der ersten Generation; heruntergeladene Daten
müssen das gleiche Format aufweisen wie Daten, die von
einer Karte der ersten Generation heruntergeladen werden.
MIG_013 Für den Datendownload von einer Karte der ersten Genera­
tion, die in eine Fahrzeugeinheit jeder Version der zweiten
Generation eingesteckt ist, wird das in Anlage 7 dieses An­
hangs definierte Datendownload-Protokoll verwendet. Die
Fahrzeugeinheit sendet Befehle an die Karte in genau der
gleichen Weise wie eine Fahrzeugeinheit der ersten Genera­
tion; heruntergeladene Daten müssen das für Karten der ersten
Generation definierte Format einhalten.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 596
2.4.3 Datendownload von Fahrzeugeinheiten
MIG_014 Außerhalb des Rahmens von Fahrerkontrollen durch eine
Nicht-EU-Kontrollbehörde werden für den Datendownload
von Fahrzeugeinheiten der zweiten Generation die Sicherheits­
mechanismen der zweiten Generation und das in Anlage 7
dieses Anhangs für die entsprechende Version angegebene
Datendownload-Protokoll verwendet.
MIG_015 Damit auch Nicht-EU-Kontrollbehörden Fahrer kontrollieren
können, ist es optional möglich, Daten von Fahrzeugeinheiten
jeder Version der zweiten Generation unter Verwendung der
Sicherheitsmechanismen der ersten Generation herunterzula­
den. Die heruntergeladenen Daten müssen in dem Fall das
gleiche Format aufweisen wie Daten, die von einer Fahrzeug­
einheit der ersten Generation heruntergeladen werden. Diese
Funktion kann durch entsprechende Menübefehle ausgewählt
werden.
2.5. Interoperabilität zwischen VU und Kalibrierungsgeräten
MIG_016 Kalibrierungsgeräte müssen in der Lage sein, Fahrtenschreiber
jeder Generation oder Version unter Verwendung des Kali­
brierungsprotokolls der entsprechenden Generation oder Ver­
sion zu kalibrieren. Kalibrierungsgeräte können mit allen Ge­
nerationen und Versionen von Fahrzeugeinheiten kompatibel
sein.
3. WESENTLICHE SCHRITTE IM ZEITRAUM VOR DEM EINFÜH­
RUNGSDATUM
MIG_017 Prüfschlüssel und Zertifikate müssen den Herstellern zum
Zeitpunkt der Veröffentlichung dieses Anhangs zur Verfügung
stehen.
MIG_018 Interoperabilitätsprüfungen mit Version 2 von Fahrzeugeinhei­
ten und Version 2 von Fahrtenschreiberkarten müssen bei
Anfrage durch die Hersteller spätestens 15 Monate vor dem
Einführungsdatum gestartet werden können.
MIG_019 Für Version 2 von Fahrtenschreibern, Fahrtenschreiberkarten
und Bewegungssensoren der zweiten Generation werden die­
selben Schlüssel und Zertifikate wie für Geräte der zweiten
Generation Version 1 verwendet.
MIG_020 Die Mitgliedstaaten müssen Werkstattkarten der zweiten Ge­
neration Version 2 spätestens 1 Monat vor dem Einführungs­
datum ausgeben können.
MIG_021 Die Mitgliedstaaten müssen alle Arten von Fahrtenschreiber­
karten der zweiten Generation Version 2 spätestens 1 Monat
vor dem Einführungsdatum ausgeben können.
4. BESTIMMUNGEN FÜR DEN ZEITRAUM NACH DEM EINFÜH­
RUNGSDATUM
MIG_022 Die Mitgliedstaaten dürfen mit Wirkung ab dem Einführungs­
datum nur noch Fahrtenschreiberkarten der zweiten Genera­
tion Version 2 ausgeben.
MIG_023 Hersteller von Fahrzeugeinheiten/Bewegungssensoren dürfen
so lange Fahrzeugeinheiten/Bewegungssensoren der ersten
Generation fertigen, wie diese in der Praxis eingesetzt werden,
sodass defekte Komponenten ersetzt werden können.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 597
MIG_023a Mit Wirkung vom Einführungsdatum müssen Fahrzeugeinhei­
ten oder externe GNSS-Einrichtungen der zweiten Generation
Version 1 mit einer Funktionsstörung durch Fahrzeugeinheiten
oder externe GNSS-Einrichtungen der zweiten Generation
Version 2 ersetzt werden.
MIG_024 Hersteller von Fahrzeugeinheiten/Bewegungssensoren können
die Beibehaltung einer Typgenehmigung von Fahrzeugeinhei­
ten/Bewegungssensoren der ersten Generation oder von Fahr­
zeugeinheiten der zweiten Generation Version 1, die bereits
über eine Typgenehmigung verfügen, beantragen und
erlangen.
5. AUFZEICHNUNG VON GRENZÜBERSCHREITUNGEN IN FAHR­
TENSCHREIBERN DER ERSTEN GENERATION UND IN FAHRTEN­
SCHREIBERN DER ZWEITEN GENERATION VERSION 1
MIG_025 Das Symbol des Landes und gegebenenfalls der Region, in
das der Fahrer nach dem Überschreiten einer Grenze eines
Mitgliedstaats gemäß Artikel 34 Absatz 7 der Verord­
nung (EU) Nr. 165/2014 einreist, ist als Ort des Beginns
der täglichen Arbeitszeit im Einklang mit der manuellen Ein­
gabe von Orten, wie in Anhang IC Nummer 60 der Verord­
nung (EU) Nr. 165/2014 und Anhang IB Nummer 50 der
Verordnung (EWG) Nr. 3821/85 festgelegt, einzutragen.
▼M3
02016R0799 — DE — 21.08.2023 — 003.002 — 598
Anlage 16
ADAPTER FÜR FAHRZEUGE DER KLASSEN M1 UND N1
INHALTSVERZEICHNIS
1. ABKÜRZUNGEN UND REFERENZDOKUMENTE
1.1. Abkürzungen
1.2. Referenznormen
2. ALLGEMEINE EIGENSCHAFTEN UND FUNKTIONEN DES ADAP­
TERS
2.1. Allgemeine Beschreibung des Adapters
2.2. Funktionen
2.3. Sicherheit
3. VORSCHRIFTEN FÜR DAS KONTROLLGERÄT BEI NUTZUNG EI­
NES ADAPTERS
4. BAUART UND FUNKTIONSMERKMALE DES ADAPTERS
4.1. Entgegennahme und Anpassung eingehender Geschwindigkeitsimpulse
4.2. Einspeisung der Eingangsimpulse in den eingebetteten Bewegungssensor
4.3. Eingebetteter Bewegungssensor
4.4. Sicherheitsanforderungen
4.5. Leistungsmerkmale
4.6. Werkstoffe
4.7. Markierungen
5. EINBAU DES KONTROLLGERÄTS BEI NUTZUNG EINES ADAP­
TERS
5.1. Einbau
5.2. Plombierung
6. EINBAUPRÜFUNGEN, NACHPRÜFUNGEN UND REPARATUREN
6.1. Regelmäßige Nachprüfungen
7. TYPGENEHMIGUNG FÜR DAS KONTROLLGERÄT BEI NUTZUNG
EINES ADAPTERS
7.1. Allgemeines
7.2. Funktionszertifikat
1. ABKÜRZUNGEN UND REFERENZDOKUMENTE
1.1. Abkürzungen
NF Noch festzulegen
VU Fahrzeugeinheit
1.2. Referenznormen
ISO 16844-3 Road vehicles — Tachograph systems — Part 3: Motion
sensor interface (Straßenfahrzeuge — Fahrtschreiber (Kontrollgeräte) —
Teil 3: Schnittstelle Bewegungssensor)
2. ALLGEMEINE EIGENSCHAFTEN UND FUNKTIONEN DES ADAP­
TERS
2.1. Allgemeine Beschreibung des Adapters
ADA_001 Der Adapter stellt gesicherte, permanent die Fahrzeug­
geschwindigkeit und die zurückgelegte Wegstrecke darstellende
Daten für eine angeschlossene VU bereit.
Der Adapter ist nur für die Fahrzeuge bestimmt, die mit Kon­
trollgeräten nach Maßgabe dieser Verordnung ausgestattet sein
müssen.
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 599
Der Adapter wird nur in den unter Begriffsbestimmung yy)
„Adapter“ von Anhang IC bestimmten Fahrzeugen eingebaut
und genutzt, in denen der Einbau eines bestehenden Bewe­
gungssensors anderer Art, der ansonsten den Bestimmungen
dieses Anhangs und dessen Anlagen 1 bis 16 entspricht, me­
chanisch unmöglich ist.
Der Adapter wird nicht mechanisch mit einem bewegten Fahr­
zeugteil verbunden, sondern an die durch integrierte Sensoren
oder alternative Schnittstellen generierten Geschwindigkeits-/
Entfernungsimpulse angeschlossen.
ADA_002 Ein typgenehmigter Bewegungssensor (gemäß den Bestimmun­
gen dieses Anhangs IC Abschnitt 8 –Typgenehmigung von
Kontrollgeräten und Fahrtenschreiberkarten) ist im Adapter­
gehäuse anzubringen, das daneben einen Impulskonverter ent­
hält, der die Eingangsimpulse in den eingebetteten Bewegungs­
sensor einspeist. Der eingebettete Bewegungssensor ist an die
VU anzuschließen, sodass die Schnittstelle zwischen der VU
und dem Adapter den Anforderungen der Norm ISO 16844-3
entspricht.
2.2. Funktionen
ADA_003 Der Adapter muss folgende Funktionen erfüllen:
— Entgegennahme und Anpassung der eingehenden Ge­
schwindigkeitsimpulse,
— Einspeisung der Eingangsimpulse in den eingebetteten Be­
wegungssensor,
— sämtliche Funktionen des eingebetteten Bewegungssensors
unter Bereitstellung gesicherter Bewegungsdaten an die VU.
2.3. Sicherheit
ADA_004 Für den Adapter erfolgt keine Sicherheitszertifizierung gemäß
den in Anlage 10 dieses Anhangs definierten allgemeinen Si­
cherheitsanforderungen für Bewegungssensoren. Stattdessen
gelten die in Abschnitt 4.4 dieses Anhangs festgelegten sicher­
heitsbezogenen Anforderungen.
3. VORSCHRIFTEN FÜR DAS KONTROLLGERÄT BEI NUTZUNG EI­
NES ADAPTERS
Die Vorschriften in den folgenden Kapiteln geben Hinweise für die Aus­
legung der Vorschriften dieses Anhangs bei der Nutzung eines Adapters.
Die entsprechenden Randnummern von Anhang IC sind in Klammern
angegeben.
ADA_005 Das Kontrollgerät eines mit einem Adapter ausgestatteten Fahr­
zeugs muss — sofern in dieser Anlage nicht anders angegeben
— allen Bestimmungen dieser Anlage entsprechen.
ADA_006 Ist ein Adapter eingebaut, so besteht das Kontrollgerät aus
Verbindungskabeln, dem Adapter (anstelle eines Bewegungs­
sensors) und einer VU [01].
ADA_007 Die Funktion zur Feststellung von Ereignissen und/oder Stö­
rungen des Kontrollgeräts wird wie folgt geändert:
— Das Ereignis „Unterbrechung der Stromversorgung“ wird,
sofern sich das Kontrollgerät nicht in der Betriebsart Kali­
brierung befindet, von der VU bei einer 200 Millisekunden
überschreitenden Unterbrechung der Stromversorgung des
eingebetteten Bewegungssensors ausgelöst [79].
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 600
— Das Ereignis „Datenfehler Bewegung“ wird von der VU
bei einer Unterbrechung des normalen Datenflusses zwi­
schen dem eingebetteten Bewegungssensor und der VU
und/oder bei einem Datenintegritäts- oder Datenauthentizi­
tätsfehler während des Datenaustauschs zwischen dem ein­
gebetteten Bewegungssensor und der VU ausgelöst [83].
— Das Ereignis „Versuch Sicherheitsverletzung“ wird, sofern
sich das Kontrollgerät nicht in der Betriebsart Kalibrierung
befindet, von der VU bei jedem anderen die Sicherheit des
eingebetteten Bewegungssensors berührenden Ereignis aus­
gelöst [85].
— Die Störung „Kontrollgerät“ wird, sofern sich das Kontroll­
gerät nicht in der Betriebsart Kalibrierung befindet, von der
VU bei jeder Störung des eingebetteten Bewegungssensors
ausgelöst [88].
ADA_008 Die mit dem eingebetteten Bewegungssensor zusammenhän­
genden Störungen des Adapters müssen durch das Kontroll­
gerät feststellbar sein [88].
ADA_009 Die Kalibrierungsfunktion der VU muss die automatische Kop­
pelung des eingebetteten Bewegungssensors mit der Fahrzeug­
einheit erlauben [202, 204].
4. BAUART UND FUNKTIONSMERKMALE DES ADAPTERS
4.1. Entgegennahme und Anpassung eingehender Geschwindigkeitsimpulse
ADA_011 Die Eingangsschnittstelle des Adapters nimmt Frequenzimpulse
entgegen, die die Fahrzeuggeschwindigkeit und die zurück­
gelegte Wegstrecke darstellen. Elektrische Eigenschaften der
Eingangsimpulse: Durch den Hersteller NF. Erforderlichenfalls
kann die korrekte Verbindung der Eingangsschnittstelle des
Adapters mit dem Fahrzeug durch Anpassungen ermöglicht
werden, zu denen ausschließlich der Adapterhersteller und die
zugelassene Werkstatt, die den Adapter einbaut, befugt sind.
▼M3
ADA_012 Die Eingangsschnittstelle des Adapters muss gegebenenfalls
die Frequenzimpulse der eingehenden Geschwindigkeits­
impulse mit einem festen Faktor multiplizieren oder durch ei­
nen festen Faktor dividieren können, um das Signal an einen
Wert in der durch diesen Anhang festgelegten Spanne für den
Parameter „Kfactor“ (2 400 bis 25 000 Imp/km) anzupassen.
Dieser feste Faktor darf nur vom Adapterhersteller und der
zugelassenen Werkstatt, die den Adapter einbaut, programmiert
werden.
▼B
4.2. Einspeisung der Eingangsimpulse in den eingebetteten Bewegungssensor
ADA_013 Die Eingangsimpulse werden — gegebenenfalls wie oben aus­
geführt angepasst — in den eingebetteten Bewegungssensor
eingespeist, sodass jeder Eingangsimpuls vom Bewegungssen­
sor erfasst wird.
4.3. Eingebetteter Bewegungssensor
ADA_014 Der eingebettete Bewegungssensor wird durch die Eingangs­
impulse stimuliert und kann auf diese Weise — als wäre er
mechanisch mit einem bewegten Fahrzeugteil verbunden —
Bewegungsdaten generieren, die die Fahrzeugbewegung exakt
darstellen.
ADA_015 Die Kenndaten des eingebetteten Bewegungssensors werden
von der VU zur Identifizierung des Adapters genutzt [95].
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 601
ADA_016 Die im eingebetteten Bewegungssensor gespeicherten Einbau­
daten werden als Informationen zum Einbau des Adapters be­
trachtet [122].
4.4. Sicherheitsanforderungen
ADA_017 Das Adaptergehäuse muss so konstruiert sein, dass es nicht
geöffnet werden kann. Es muss plombiert sein, damit jeder
Versuch der physischen Manipulation leicht erkennbar ist (z.
B. durch Sichtprüfung, siehe ADA_035). Für die Plomben
gelten die gleichen Bestimmungen wie für Bewegungssensor­
plomben [398 bis 406]
ADA_018 Die Entfernung des eingebetteten Bewegungssensors aus dem
Adapter darf nicht ohne Zerstörung der Plombe(n) des Adap­
tergehäuses oder der Plombe zwischen dem Bewegungssensor
und dem Adaptergehäuse möglich sein (siehe ADA_034).
ADA_019 Der Adapter stellt sicher, dass nur vom Adaptereingang stam­
mende Bewegungsdaten angenommen und verarbeitet werden.
4.5. Leistungsmerkmale
ADA_020 Der Adapter muss in dem vom Hersteller festgelegten Tem­
peraturbereich voll einsatzbereit sein.
ADA_021 Der Adapter muss bei einer Luftfeuchtigkeit von 10 % bis
90 % voll einsatzbereit sein [214].
ADA_022 Der Adapter muss gegen Überspannung, Falschpolung der
Stromversorgung und Kurzschluss geschützt sein [216].
ADA_023 Der Adapter muss entweder
— auf ein Magnetfeld, das die Ermittlung von Fahrzeugbewe­
gungsdaten stört, reagieren — unter diesen Umständen re­
gistriert und speichert die Fahrzeugeinheit eine Sensorstö­
rung [88] — oder
— über einen Sensor verfügen, der vor Magnetfeldern ge­
schützt oder dagegen unempfindlich ist [217].
ADA_024 Der Adapter muss der internationalen UN/ECE-Regelung R 10
zur elektromagnetischen Verträglichkeit entsprechen und gegen
elektrostatische Entladungen und Störgrößen geschützt sein
[218].
4.6. Werkstoffe
ADA_025 Der Adapter muss den Schutzgrad (vom Hersteller in Abhän­
gigkeit von der Einbauposition NF) erfüllen [220, 221].
ADA_026 Das Adaptergehäuse muss gelb sein.
4.7. Markierungen
ADA_027 Am Adapter ist ein Typenschild mit folgenden Angaben
anzubringen:
— Name und Anschrift des Adapterherstellers,
— Teilnummer und Baujahr des Adapters,
— Prüfzeichen des Adaptertyps oder des Typs des Kontroll­
geräts, das den Adapter enthält,
— Einbaudatum des Adapters,
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 602
— Identifizierungsnummer des Fahrzeugs, in das der Adapter
eingebaut ist.
ADA_028 Das Typenschild muss daneben folgende Angaben enthalten
(sofern diese nicht unmittelbar an der Außenseite des einge­
betteten Bewegungssensors ersichtlich sind):
— Name des Herstellers des eingebetteten Bewegungssensors,
— Teilnummer und Baujahr des eingebetteten Bewegungssen­
sors,
— Prüfzeichen des eingebetteten Bewegungssensors.
5. EINBAU DES KONTROLLGERÄTS BEI NUTZUNG EINES ADAP­
TERS
5.1. Einbau
ADA_029 Der Einbau von Adaptern in Fahrzeuge darf nur von Fahrzeug­
herstellern oder zugelassenen Werkstätten, die zum Einbau, zur
Aktivierung und zur Kalibrierung digitaler und intelligenter
Fahrtenschreiber autorisiert sind, vorgenommen werden.
ADA_030 Die zugelassenen Werkstätten, die den Einbau von Adaptern
vornehmen, passen die Eingangsschnittstelle an und wählen
gegebenenfalls das Umrechnungsverhältnis für das Eingangs­
signal.
ADA_031 Die zugelassenen Werkstätten, die den Einbau von Adaptern
vornehmen, plombieren das Adaptergehäuse.
ADA_032 Der Adapter muss möglichst nahe an dem Fahrzeugteil an­
gebracht werden, das ihm die Eingangsimpulse bereitstellt.
ADA_033 Die Anschlusskabel für den Adapter müssen rot (Stromversor­
gung) und schwarz (Masse) sein.
5.2. Plombierung
ADA_034 Für die Plombierung gelten folgende Vorschriften:
— Das Adaptergehäuse muss plombiert sein (siehe ADA_017).
— Das Gehäuse des eingebetteten Bewegungssensors muss
plombiert sein, es sei denn, der eingebettete Bewegungs­
sensor kann nicht ohne Zerstörung der Plombe(n) des
Adaptergehäuses entfernt werden (siehe ADA_018).
— Die Befestigung des Adaptergehäuses am Fahrzeug muss
plombiert sein.
— Die Verbindung zwischen dem Adapter und dem Gerät,
dass diesem seine Eingangsimpulse bereitstellt, muss (so­
weit nach vernünftigem Ermessen möglich) an beiden En­
den plombiert sein.
6. EINBAUPRÜFUNGEN, NACHPRÜFUNGEN UND REPARATUREN
6.1. Regelmäßige Nachprüfungen
ADA_035 Bei Verwendung eines Adapters ist bei jeder regelmäßigen
Nachprüfung (d. h. entsprechend den Randnummern [409]
bis [413] von Anhang 1C) des Kontrollgeräts Folgendes zu
überprüfen:
— Vorhandensein der entsprechenden Prüfzeichen auf dem
Adapter,
— Unversehrtheit der Plomben des Adapters und seiner An­
schlüsse,
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 603
— Einbau des Adapters gemäß der Angabe auf dem Einbau­
schild,
— Einbau des Adapters gemäß den Adapter- und/oder Fahr­
zeugherstellerspezifikationen,
— Zulässigkeit des Einbaus eines Adapters in das überprüfte
Fahrzeug.
ADA_036 Bestandteil dieser Überprüfungen müssen eine Kalibrierung
sowie ein Austausch der Plomben unabhängig von deren Zu­
stand sein.
7. TYPGENEHMIGUNG FÜR DAS KONTROLLGERÄT BEI NUTZUNG
EINES ADAPTERS
7.1. Allgemeines
ADA_037 Kontrollgeräte sind zusammen mit dem Adapter zur Typgeneh­
migung vorzulegen [425].
ADA_038 Adapter können entweder als eigenständiges Gerät oder als
Bauteil eines Kontrollgeräts zur Typgenehmigung vorgelegt
werden.
ADA_039 Die Typgenehmigung muss Funktionsprüfungen umfassen, die
sich auch auf den Adapter erstrecken. Die positiven Ergebnisse
der einzelnen Prüfungen werden in einem geeigneten Zertifikat
ausgewiesen [426].
7.2. Funktionszertifikat
ADA_040 Ein Funktionszertifikat für einen Adapter oder ein Kontroll­
gerät, das einen Adapter einschließt, wird dem Adapterherstel­
ler erst erteilt, nachdem die folgenden Mindestfunktionsprüfun­
gen erfolgreich bestanden wurden:
Nr. Prüfung Beschreibung
Anforderungsentspre­
chung
1. Administrative Prüfung
1.1 Dokumentation Richtigkeit der Do­
kumentation zum
Adapter
2. Sichtprüfung
2.1. Übereinstimmung des Adapters mit der Doku­
mentation
2.2. Kennung/Markierungen des Adapters ADA_027,
ADA_028
2.3 Werkstoffe des Adapters [219] bis [223]
ADA_026
2.4. Plombierung ADA_017,
ADA_018,
ADA_034
3. Funktionsprüfungen
3.1 Einspeisung der Geschwindigkeitsimpulse in den
eingebetteten Bewegungssensor
ADA_013
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 604
Nr. Prüfung Beschreibung
Anforderungsentspre­
chung
3.2 Entgegennahme und Anpassung eingehender Ge­
schwindigkeitsimpulse
ADA_011,
ADA_012
3.3 Messgenauigkeit Wegstrecke/Geschwindigkeit [30] bis [35], [217]
4. Umweltprüfungen
4.1 Prüfergebnisse des Her­
stellers
Ergebnisse der Um­
weltprüfung des
Herstellers.
ADA_020,
ADA_021,
ADA_022,
ADA_024
5. EMV
5.1 Störaussendung und Stör­
anfälligkeit
Prüfung auf Einhal­
tung der Richtlinie
2006/28/EG
ADA_024
5.2 Prüfergebnisse des Her­
stellers
Ergebnisse der Um­
weltprüfung des
Herstellers.
ADA_024
▼B
02016R0799 — DE — 21.08.2023 — 003.002 — 605
Anlage 17
ÜBERGANGSBESTIMMUNGEN FÜR DIE ANWENDUNG VON OSNMA
BEI FAHRTENSCHREIBERN
1. BEGRIFFSBESTIMMUNGEN UND AKRONYME
1.1. Begriffsbestimmungen
„Diensterklärung der Authentisierung von Navigationsnachrichten im
Offenen Dienst von Galileo (OSNMA)“ bezeichnet die Erklärung der
Europäischen Kommission, dass Galileo-OSNMA in die Betriebsphase
eintritt.
Übergangsfahrzeugeinheit: Fahrzeugeinheit, die den Vorschriften dieser
Anlage entspricht.
Übergangsfahrzeugeinheiten müssen gemäß dem SIS ICD und den für die
öffentliche Prüfphase von OSNMA geltenden Leitlinien für den
OSNMA-Empfänger gebaut sein. Sie enthalten einen GNSS-Empfänger,
der in der Lage ist, OSNMA während der öffentlichen Prüfphase zu
nutzen.
Übergangsfahrzeugeinheiten sind jedoch nicht in der Lage, die nach der
Erklärung der OSNMA-Dienste verfügbaren Navigationsnachrichten zu
authentisieren, da das kryptografische Material in der Fahrzeugeinheit ak­
tualisiert werden muss. Damit sie mit der Verwendung von OSNMA
beginnen können und alle Anforderungen des Anhangs IC und seiner
Anlagen 1 bis 16 erfüllen, muss eine geeignete Softwareaktualisierung
durchgeführt werden. Vor der Aktualisierung müssen Übergangsfahrzeug­
einheiten die OSNMA-bezogenen Funktionen gemäß dieser Anlage imple­
mentieren. Funktionen, die nicht mit OSNMA in Zusammenhang stehen,
bleiben unverändert.
Mit der geeigneten Softwareaktualisierung implementieren die Übergangs­
fahrzeugeinheiten die für die Betriebsphase von OSNMA geltenden Leit­
linien für OSNMA-Empfänger und das SIS ICD und erfüllen alle Anfor­
derungen des Anhangs IC sowie seiner Anlagen 1 bis 16 unter Verwen­
dung von OSNMA während der Betriebsphase.
Übergangsfahrtenschreiber: Fahrtenschreiber einschließlich einer Über­
gangsfahrzeugeinheit.
1.2. Akronyme
ICD Interface Control Document (Schnittstellenkontroll­
dokument)
OSNMA Galileo Open Service Navigation Message Authen­
tication (Authentisierung von Navigationsnachrich­
ten im Offenen Dienst von Galileo)
SIS Signal in Space (Raumsignal)
VU Vehicle Unit (Fahrzeugeinheit)
▼M4
02016R0799 — DE — 21.08.2023 — 003.002 — 606
2. ALLGEMEINE ERWÄGUNGEN IM ZUSAMMENHANG MIT OSNMA
Damit erstmals zugelassene Fahrzeuge ab dem in Anhang IC Abschnitt 1
Buchstabe ccc der Durchführungsverordnung (EU) 2016/799 festgelegten
Einführungstermin mit der zweiten Version von intelligenten Fahrten­
schreibern ausgerüstet werden können, müssen Fahrzeugeinheiten vor
der Erklärung der OSNMA-Dienste bauartgenehmigt, hergestellt und ver­
marktet werden. Für diese Fahrzeugeinheiten, die als Übergangsfahrzeug­
einheiten bezeichnet werden, müssen die OSNMA-bezogenen Anforderun­
gen des Anhangs IC und seiner Anlagen 1 bis 16 angepasst werden, um
bauartgenehmigt und in der Praxis verwendet werden zu können.
In den Bestimmungen dieser Anlage sind die besonderen Anforderungen
festgelegt, die für Übergangsfahrzeugeinheiten gelten. Sie gelten nur für
Fahrzeugeinheiten mit einem internen GNSS-Empfänger.
3. ANFORDERUNGEN AN DEN GNSS-EMPFÄNGER VON ÜBER­
GANGSFAHRTENSCHREIBERN
TRA_001 Die Übergangsfahrzeugeinheiten müssen über einen
GNSS-Empfänger verfügen, der in der Lage ist, OSNMA während der
öffentlichen Prüfphase zu nutzen.
TRA_002 Die Anforderungen in Anlage 12 gelten für GNSS-Empfänger
in Übergangsfahrzeugeinheiten, mit folgenden Auslegungen:
— Das SIS ICD und die OSNMA-Empfänger-Leitlinien sind die Doku­
mente, die für die öffentliche Prüfphase verfügbar sind:
— Das Nutzer-ICD der Galileo Open Service Navigation Message
Authentication (OSNMA) für die Prüfphase, Ausgabe 1.0, Novem­
ber 2021,
— die Leitlinien der Galileo Open Service Navigation Message
Authentication (OSNMA) für Empfänger für die Prüfphase, Aus­
gabe 1.0, November 2021,
— OSNMA ist der Dienst, der in der öffentlichen Prüfphase zur Ver­
fügung steht.
— SIS ist das Signal im Raum, das in der öffentlichen Testphase zur
Verfügung steht.
TRA_003 Der GNSS-Empfänger in Übergangsfahrzeugeinheiten muss so
ausgelegt sein, dass er nach einer Aktualisierung seiner Software, die
durch eine Softwareaktualisierung einer Fahrzeugeinheit erfolgt, vollstän­
dig den Anforderungen von Anhang 12 entspricht, wobei OSNMA wäh­
rend der Betriebsphase verwendet wird.
4. ANFORDERUNGEN AN ÜBERGANGSFAHRZEUGEINHEITEN
Übergangsfahrzeugeinheiten können das in der öffentlichen Prüfphase ver­
fügbare OSNMA-Signal eventuell verarbeiten, sind jedoch nicht in der
Lage, den während der Betriebsphase der OSNMA verfügbaren Authen­
tisierungsstatus der Navigationsnachrichten durch das Signal im Raum zu
melden, bis eine entsprechende Softwareaktualisierung vorgenommen
wird. Es wird daher davon ausgegangen, dass die vom
GNSS-Empfänger bereitgestellten Standardpositionen stets authentisiert
werden.
Es gelten die Anforderungen des Anhangs IC und seiner Anlagen 1 bis 16
mit folgenden Auslegungen:
▼M4
02016R0799 — DE — 21.08.2023 — 003.002 — 607
TRA_004 Anhang IC Nummer 3.9.15 „Zeitkonflikt“, Randnummer 86,
ist wie folgt zu verstehen:
Dieses Ereignis wird, sofern sich das Kontrollgerät nicht in der Betriebs­
art Kalibrierung befindet, ausgelöst, wenn die Fahrzeugeinheit eine Ab­
weichung zwischen der Zeit der Zeitmessfunktion der Fahrzeugeinheit und
der Zeit feststellt, die aus den vom internen GNSS-Empfänger oder der
externen GNSS-Ausrüstung übertragenen Standardpositionen stammt. Eine
„Zeitabweichung“ wird erkannt, wenn die Zeitdifferenz entsprechend der
in Randnummer 41a festgelegten Zeitgenauigkeit ± 3 Sekunden über­
schreitet, wobei letzterer Wert um die maximale Zeitabweichung pro
Tag erhöht wird. Dieses Ereignis wird gemeinsam mit dem Wert der
Systemuhr der Fahrzeugeinheit aufgezeichnet. Die Fahrzeugeinheit führt
die Prüfung auf Auslösung des Ereignisses „Zeitkonflikt“ unmittelbar vor
dem Zeitpunkt durch, an dem die Fahrzeugeinheit die Systemuhr der
Fahrzeugeinheit gemäß Randnummer 211 automatisch neu einstellt.
TRA_005 Anhang IC Nummer 3.9.18 „GNSS-Anomalie“, Randnummer
88a, ist wie folgt zu verstehen:
Dieses Ereignis wird, sofern sich das Kontrollgerät nicht in der Betriebs­
art Kalibrierung befindet, ausgelöst, wenn der GNSS-Empfänger einen
Angriff gemäß Anlage 12 erkennt . Nachdem ein Ereignis „GNSS-Ano­
malie“ ausgelöst wurde, erzeugt die Fahrzeugeinheit in den nächsten 10
Minuten keine weiteren „GNSS-Anomalie“-Ereignisse.
TRA_006 Anhang IC Nummer 3.12.5 Aufzeichnung und Speicherung
von Daten im Massenspeicher, Daten und Orte, an denen der Arbeitstag
beginnet, endet und/oder an denen eine kumulierte Lenkzeit von 3 Stun­
den erreicht wird, Randnummer 110 ist wie folgt zu verstehen:
Zusammen mit jedem Ort bzw. jeder Position registriert das Kontrollgerät
und speichert in seinem Massenspeicher:
— Nummer der Fahrerkarte und/oder Beifahrerkarte und den ausstellen­
den Mitgliedstaat,
— Kartengeneration,
— Datum und Uhrzeit der Eingabe,
— Art der Eingabe (Beginn, Ende oder kumulierte Lenkzeit von 3 Stun­
den),
— die damit verbundene GNSS-Genauigkeit, Datum und Uhrzeit, falls
zutreffend,
— Kilometerstand,
— Merker, der angibt, dass die Position als authentisiert angenommen
wurde.
TRA_007 Anhang IC Nummer 3.12.17 Aufzeichnung und Speicherung
von Daten im Massenspeicher, Grenzüberschreitungen, Randnummer
133b, ist wie folgt zu verstehen:
Zusammen mit den Ländern und der Position zeichnet das Kontrollgerät die
folgenden Informationen auf und speichert sie in seinem Massenspeicher:
— Nummer der Fahrerkarte und/oder Beifahrerkarte und den ausstellen­
den Mitgliedstaat,
— Kartengeneration,
— die damit verbundene GNSS-Genauigkeit, Datum und Uhrzeit,
— Merker, der angibt, dass die Position als authentisiert angenommen
wurde,
— Kilometerstand des Fahrzeugs zum Zeitpunkt der Feststellung der
Grenzüberschreitung.
▼M4
02016R0799 — DE — 21.08.2023 — 003.002 — 608
TRA_008 Anhang IC Nummer 3.12.18 Aufzeichnung und Speicherung
von Daten im Massenspeicher, Be-/Entladevorgänge, Randnummer 133g,
ist wie folgt zu verstehen:
Zusammen mit der Art des Vorgangs und der Position zeichnet das Kon­
trollgerät folgende Informationen auf und speichert sie in seinem Massen­
speicher:
— Nummer der Fahrerkarte und/oder Beifahrerkarte und den ausstellen­
den Mitgliedstaat,
— Kartengeneration,
— Datum und Uhrzeit des Be-/Entladevorgangs,
— die damit verbundene GNSS-Genauigkeit, Datum und Uhrzeit, falls
zutreffend,
— Merker, der angibt, dass die Position als authentisiert angenommen
wurde,
— Kilometerstand.
TRA_009 Anhang IC Nummer 3.23 Zeiteinstellung, Randnummer 211,
ist wie folgt zu verstehen:
Die Zeit der Systemuhr der Fahrzeugeinheit wird automatisch in variablen
Zeitabständen neu eingestellt. Die nächste automatische Zeiteinstellung
muss zwischen 72 Stunden und 168 Stunden nach der vorherigen erfolgen
und nachdem die Fahrzeugeinheit über eine gültige Standard positions­
nachricht gemäß Anlage 12 auf die GNSS-Zeit zugreifen kann. Die Zeit­
einstellung darf jedoch nie über die kumulierte maximale Zeitabweichung
pro Tag, wie vom Hersteller der Fahrzeugeinheit gemäß Randnummer 41b
berechnet, hinausgehen. Wenn die Differenz zwischen der von der System­
uhr der Fahrzeugeinheit und der vom GNSS-Empfänger stammenden Zeit
größer als die kumulierte maximale Zeitabweichung pro Tag ist, muss bei
der Zeiteinstellung die Zeit der Systemuhr der Fahrzeugeinheit so nahe
wie möglich an die Zeit des GNSS-Empfängers angeglichen werden. Die
Zeiteinstellung darf nur erfolgen, wenn die vom GNSS-Empfänger stam­
mende Zeit unter Verwendung von Standard positionsnachrichten gemäß
Anlage 12 erlangt wird. Die Zeitreferenz für die automatische Zeiteinstel­
lung der Systemuhr der Fahrzeugeinheit ist die Zeit, die in der Standard­
positionsnachricht bereitgestellt wird.
TRA_010 Anhang IC Nummer 3.23 Zeiteinstellung, Randnummer 212,
ist wie folgt zu verstehen:
In der Betriebsart Kalibrierung ermöglicht es die Funktion Zeiteinstellung
ferner, eine Einstellung der aktuellen Uhrzeit auszulösen.
Werkstätten können die Zeit auf folgende Weise einstellen:
— entweder durch Schreiben eines Zeitwerts in die Fahrzeugeinheit unter
Verwendung des Dienstes WriteDataByIdentifier gemäß Anlage 8 Ab­
schnitt 6.2,
— oder durch Anfordern einer Anpassung der Systemuhr der Fahrzeug­
einheit an die vom GNSS-Empfänger bereitgestellte Zeit. Dies darf nur
erfolgen, wenn die vom GNSS-Empfänger stammende Zeit unter Ver­
wendung von Standardpositionsnachrichten erlangt wird. In letzterem
Fall muss der Dienst RoutineControl gemäß Anlage 8 Abschnitt 8 ge­
nutzt werden.
▼M4
02016R0799 — DE — 21.08.2023 — 003.002 — 609
TRA_011 Anlage 4 Nummer 2. Die Spezifikation der Datenblöcke, Ab­
satz 1 siebter Gedankenstrich, ist wie folgt zu verstehen:
Wenn das Piktogramm nach dem Längen- und Breitengrad einer auf­
gezeichneten Position oder nach dem Zeitstempel des Zeitpunkts der Po­
sitionsbestimmung gedruckt wurde, gibt dieses Piktogramm an, dass
diese Position als authentisch angenommen wurde.
TRA_012 Anlage 8 Nummer 8.1 Dienst RoutineControl (Zeiteinstellung),
Nachrichtenbeschreibung, Randnummer CPR_065a, ist wie folgt zu
verstehen:
Der Dienst RoutineControl (TimeAdjustment) ermöglicht es, eine Anpas­
sung der Systemuhr der Fahrzeugeinheit an die vom GNSS-Empfänger
bereitgestellte Zeit auszulösen.
Die Fahrzeugeinheit muss sich im Modus KALIBRIERUNG befinden, da­
mit der Dienst RoutineControl (TimeAdjustment) ausgeführt werden kann.
Voraussetzung: Es ist sichergestellt, dass die Fahrzeugeinheit Standard­
positionsnachrichten vom GNSS-Empfänger empfangen kann.
Während die Zeiteinstellung läuft, antwortet die Fahrzeugeinheit auf die
Anforderung RoutineControl, Unterfunktion requestRoutineResults mit
routineInfo = 0x78.
Anmerkung: Die Zeiteinstellung kann einige Zeit in Anspruch nehmen.
Das Diagnoseprüfgerät fordert den Zeiteinstellungsstatus unter Verwen­
dung der Unterfunktion requestRoutineResults an.
TRA_013 In Anlage 12 Nummer 3 Vom GNSS-Empfänger gelieferte
Datensätze, Randnummer GNS_4a:
Daten, die in den vom GNSS-Empfänger gelieferten AMC-Datensätzen
enthalten sind, dürfen von der Fahrzeugeinheit nicht verwendet werden
, mit Ausnahme der folgenden Statuswerte:
J = Jamming oder O = anderer GNSS-Angriff (anhand von implementier­
ten Konsistenzprüfungen gemäß GNS_3a),
V = ungültig (authentisierte Position aus anderem Grund nicht verfüg­
bar).
TRA_014 In Anlage 12 Nummer 3 Vom GNSS-Empfänger gelieferte
Datensätze, Randnummer GNS_5:
Daten, die in den vom GNSS-Empfänger gelieferten ASA-Datensätzen ent­
halten sind, dürfen, falls vorhanden, von der Fahrzeugeinheit nicht ver­
wendet werden.
TRA_015 In Anlage 12 Nummer 5.2 Fahrzeugeinheit ohne externe
GNSS-Ausrüstung, Übermittlung von Daten vom GNSS-Empfänger an
die Fahrzeugeinheit, Randnummern GNS_34 und 36:
Der Prozessor der Fahrzeugeinheit darf keine aus dem AMC-Datensatz
gewonnenen Informationen verwenden, mit Ausnahme der folgenden Sta­
tuswerte:
J = Jamming oder O = anderer GNSS-Angriff (anhand von implementier­
ten Konsistenzprüfungen gemäß GNS_3a),
V = ungültig (authentisierte Position aus anderem Grund nicht verfüg­
bar).
Der Prozessor der Fahrzeugeinheit darf keine aus dem ASA-Datensatz
gewonnenen Informationen verwenden.
▼M4
02016R0799 — DE — 21.08.2023 — 003.002 — 610
TRA_016 Anlage 12 Nummer 6 Positionsdatenverarbeitung und -auf­
zeichnung durch die Fahrzeugeinheit, Randnummer GNS_39, ist wie folgt
zu verstehen:
Die Positionsdaten müssen in der Fahrzeugeinheit gespeichert werden,
zusammen mit einem Merker, der angibt, ob die Position als authentisiert
angenommen wurde. Wenn Positionsdaten in der Fahrzeugeinheit auf­
gezeichnet werden müssen, gilt folgende Regel:
a) Wenn die Standardposition gültig ist, werden die Standardposition und
deren Genauigkeit in der Fahrzeugeinheit aufgezeichnet und der Mer­
ker wird auf ‚authentisiert‘ gesetzt.
TRA_017 Anlage 12 Nummer 6 Positionsdatenverarbeitung und -auf­
zeichnung durch die Fahrzeugeinheit, Randnummer GNS_40, ist wie folgt
zu verstehen:
Wenn der Statuswert in einem empfangenen AMC-Datensatz gemäß
Randnummer GNS_4a auf „J“ oder „O“ gesetzt wird, muss die Fahrzeug­
einheit ein Ereignis des Typs GNSS-Anomalie generieren und aufzeich­
nen, wie in Anhang IC Randnummer 88a und Anlage 1 (EventFaultType)
definiert. Die Fahrzeugeinheit kann zusätzliche Prüfungen durchführen,
bevor sie eine GNSS-Anomalie im Anschluss an den Empfang einer Ein­
stellung „J“ oder „O“ speichert.
TRA_018 Anlage 12 Nummer 8 Datenkonflikt Fahrzeugbewegung,
Randnummer GNS_42, Triggerbedingung 2, erster und zweiter Gedanken­
strich nach der Formel sind wie folgt zu verstehen:
— GnssDistance ist die Entfernung zwischen der aktuellen und der vor­
herigen Position des Fahrzeugs, mit beiden Positionen aus gültigen
Standard positionsnachrichten, ohne Berücksichtigung der Höhe,
— OdometerDifference ist die Differenz zwischen dem aktuellen Kilo­
meterstand und dem Kilometerstand, der der vorherigen gültigen Stan­
dard positionsnachricht entspricht.
TRA_019 Anlage 14 Nummer 5.4.5 DSRC-Protokollanforderungen für
RTM-Elemente von RtmData, durchgeführte Aktionen und Definitionen,
Randnummer DSC_41, Tabelle 14.3, zweites Feld in der Zeile RTM20, ist
folgendermaßen zu verstehen:
Die VU generiert einen Integer-Wert (timeReal gemäß Anlage 1) für das
Datenelement RTM20.
Die VU setzt den Wert von RTM20 auf den Zeitpunkt, an dem die letzte
Standard fahrzeugposition vom GNSS-Empfänger verfügbar war.
Wenn noch nie eine Standard fahrzeugposition vom GNSS-Empfänger ver­
fügbar war, setzt die VU RTM20 auf den Wert „0“.
TRA_020 Der Hersteller einer bauartgenehmigten Übergangsfahrzeugein­
heit unterrichtet die Kommission über seine Softwareversionen. Die Kom­
mission veröffentlicht diese Softwareversionen auf einer öffentlich zugäng­
lichen Website.
▼M4
02016R0799 — DE — 21.08.2023 — 003.002 — 611
5. BESONDERE BESTIMMUNGEN FÜR DIE BAUARTGENEHMIGUNG
UND DIE VERWENDUNG VON ÜBERGANGSFAHRTENSCHREI­
BERN
TRA_021 Übergangsfahrzeugeinheiten müssen nach den Anforderungen
des Anhangs IC und seiner Anlagen 1 bis 16, ergänzt durch die Bestim­
mungen dieser Anlage, bauartgenehmigt werden.
TRA_022 Bauartgenehmigungsbögen für Übergangsfahrzeugeinheiten
und Übergangsfahrtenschreiber dürfen nur bis zum 31. Dezember 2023
oder bis zum Datum der Diensterklärung der OSNMA beantragt werden,
je nachdem, welcher Zeitpunkt der spätere ist.
TRA_023 Übergangsfahrzeugeinheiten dürfen nur in Fahrzeuge eingebaut
werden, die bis zum 31. Mai 2024 oder fünf Monate nach dem Datum der
Diensterklärung der OSNMA, je nachdem, welcher Zeitpunkt der spätere
ist, erstmals zugelassen werden.
▼M4
02016R0799 — DE — 21.08.2023 — 003.002 — 612
ANLAGE II
PRÜFZEICHEN UND TYPGENEHMIGUNGSBOGEN
I. PRÜFZEICHEN
1. Das Prüfzeichen besteht
a) aus einem Rechteck, in dem der Buchstabe „e“, gefolgt von der Kennzahl
oder dem Kennbuchstaben des Landes, das die Typgenehmigung erteilt
hat, und zwar
Belgien 6
Bulgarien 34
Tschechische Republik 8
Dänemark 18
Deutschland 1
Estland 29
Irland 24
Griechenland 23
Spanien 9
Frankreich 2
Kroatien 25
Italien 3
Zypern CY
Lettland 32
Litauen 36
Luxemburg 13
Ungarn 7
Malta MT
Niederlande 4
Österreich 12
Polen 20
Portugal 21
Rumänien 19
Slowenien 26
Slowakei 27
Finnland 17
Schweden 5
Vereinigtes Königreich 11
angebracht ist, und
▼M1
b) aus einer Typgenehmigungsnummer, die der Nummer des für das Muster
des Kontrollgeräts oder des Schaublatts oder der Fahrtenschreiberkarte
ausgestellten Typgenehmigungsbogens entspricht und an einer beliebigen
Stelle in der Nähe des Rechtecks anzubringen ist.
▼C1
02016R0799 — DE — 21.08.2023 — 003.002 — 613
2. Das Prüfzeichen wird auf dem Typenschild eines jeden Gerätes, auf jedem
Schaublatt und auf jeder Fahrtenschreiberkarte angebracht. Das Prüfzeichen
muss unverwischbar und gut lesbar sein.
3. Die nachstehend angegebenen Abmessungen des Prüfzeichens ( 1 ) sind in Mil­
limetern ausgedrückt und stellen die Mindestabmessungen dar. Die Relationen
zwischen diesen Abmessungen müssen eingehalten werden.
▼C1
( 1 ) Diese Zahlen sind lediglich als Beispiel angeführt.
02016R0799 — DE — 21.08.2023 — 003.002 — 614
II. TYPGENEHMIGUNGSBOGEN FÜR ANALOGE FAHRTENSCHREIBER
Der Mitgliedstaat, der eine Typgenehmigung erteilt hat, stellt dem Antragsteller
einen Typgenehmigungsbogen nach folgendem Muster aus. Für die Unterrichtung
der anderen Mitgliedstaaten über erteilte Typgenehmigungen bzw. deren etwai­
gen Entzug verwendet jeder Mitgliedstaat Kopien dieses Dokuments.
TYPGENEHMIGUNGSBOGEN
Name der zuständigen Behörde
Mitteilung betreffend ( 1 ):
— die Typgenehmigung für das Muster eines Kontrollgeräts
— den Entzug der Typgenehmigung für das Muster eines Kontrollgeräts
— die Genehmigung für ein Musterschaublatt
— den Entzug der Genehmigung für ein Schaublatt
Nr. der Typgenehmigung
...................................
1. Fabrik- oder Handelsmarke
2. Bezeichnung des Musters
3. Name des Herstellers …
5. Zur Typgenehmigung vorgelegt am
6. Prüfstelle
7. Datum und Nummer der Prüfung(en)
8. Datum der Typgenehmigung
9. Datum des Entzugs der Typgenehmigung
10. Muster des Gerätes (oder der Geräte), für das (die) das Schaublatt zulässig ist
11. Ort
12. Datum
13. Anlagen (Beschreibungen usw.)
14. Bemerkungen (ggf. auch Position von Plomben)
(Unterschrift)
▼C1
( 1 ) Unzutreffendes streichen.
02016R0799 — DE — 21.08.2023 — 003.002 — 615
III. TYPGENEHMIGUNGSBOGEN FÜR DIGITALE FAHRTENSCHREIBER
Der Mitgliedstaat, der eine Typgenehmigung erteilt hat, stellt dem Antragsteller
einen Typgenehmigungsbogen nach folgendem Muster aus. Für die Unterrichtung
der anderen Mitgliedstaaten über erteilte Typgenehmigungen bzw. deren etwai­
gen Entzug verwendet jeder Mitgliedstaat Kopien dieses Dokuments.
TYPGENEHMIGUNGSBOGEN FÜR DIGITALE FAHRTENSCHREIBER
Name der zuständigen Behörde
Mitteilung betreffend ( 1 ):
□ die Genehmigung für: □ den Entzug der Typgenehmigung für
□ das Muster eines Kontrollgeräts
□ die Kontrollgerätkomponente ( 2 )
□ eine Fahrerkarte
□ eine Werkstattkarte
□ eine Unternehmenskarte
□ eine Kontrollkarte
Nr. der Typgenehmigung
1. Hersteller- oder Handelsmarke:
2. Modellbezeichnung
3. Name des Herstellers
4. Anschrift des Herstellers
▼M1
5. Zur Typgenehmigung vorgelegt am
▼C1
6. Prüfstelle(n)
7. Datum und Nummer des Prüfprotokolls
8. Datum der Typgenehmigung
9. Datum des Entzugs der Typgenehmigung
10. Muster des Kontrollgeräts (oder der Kontrollgeräte), für das (die) die Kom­
ponente bestimmt ist
11. Ort
12. Datum
13. Anlagen (Beschreibungen usw.)
14. Bemerkungen (ggf. auch Position von Plomben)
(Unterschrift)
▼C1
( 1 ) Zutreffendes ankreuzen.
( 2 ) Komponente angeben, auf die sich die Mitteilung bezieht.
02016R0799 — DE — 21.08.2023 — 003.002 — 616
IV. TYPGENEHMIGUNGSBOGEN FÜR INTELLIGENTE FAHRTENSCHREIBER
Der Mitgliedstaat, der eine Typgenehmigung erteilt hat, stellt dem Antragsteller
einen Typgenehmigungsbogen nach folgendem Muster aus. Für die Unterrichtung
der anderen Mitgliedstaaten über erteilte Typgenehmigungen bzw. deren etwai­
gen Entzug verwendet jeder Mitgliedstaat Kopien dieses Dokuments.
TYPGENEHMIGUNGSBOGEN FÜR INTELLIGENTE FAHRTENSCHREIBER
Name der zuständigen Behörde
Mitteilung betreffend ( 1 ):
□ die Genehmigung für: □ den Entzug der Typgenehmigung für
□ das Muster eines Kontrollgeräts
□ die Kontrollgerätkomponente ( 2 )
□ eine Fahrerkarte
□ eine Werkstattkarte
□ eine Unternehmenskarte
□ eine Kontrollkarte
Nr. der Typgenehmigung
1. Hersteller- oder Handelsmarke:
2. Modellbezeichnung
3. Name des Herstellers
4. Anschrift des Herstellers
▼M1
5. Zur Typgenehmigung vorgelegt am
▼C1
6. a) Prüflabor für die Funktionszertifizierung
b) Prüflabor für die Sicherheitszertifizierung
c) Prüflabor für die Interoperabilitätszertifizierung
7. a) Datum und Nummer des Funktionszertifikats
b) Datum und Nummer des Sicherheitszertifikats
c) Datum und Nummer des Interoperabilitätszertifikats
8. Datum der Typgenehmigung
9. Datum des Entzugs der Typgenehmigung
10. Muster des Kontrollgeräts (oder der Kontrollgeräte), für das (die) die Kom­
ponente bestimmt ist
11. Ort
12. Datum
13. Anlagen (Beschreibungen usw.)
14. Bemerkungen (ggf. auch Position von Plomben)
(Unterschrift)
▼C1
( 1 ) Zutreffendes ankreuzen.
( 2 ) Komponente angeben, auf die sich die Mitteilung bezieht.


Full & Egal Universal Law Academy