zurück

.

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 werden müssen, um die sichere und korrekte Übertragung der Positionsbestimmungsinformationen zu gewährleisten.

Die wichtigsten Artikel dieser Verordnung (EU) Nr. 165/2014, die diese Anforderungen regeln, sind: "Artikel 8 Aufzeichnung des Fahrzeugstandorts an bestimmten Punkten bzw. Zeitpunkten während der täglichen Arbeitszeit", "Artikel 10 Schnittstelle zu intelligenten Verkehrssystemen" und "Artikel 11 Einzelvorschriften für intelligente Fahrtenschreiber".

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

Abbildung 1 Verschiedene Konfigurationen für den GNSS-Empfänger.

1.1.1. Referenzdokumente

Referenzdokumente zu dieser Anlage:

NMEA NMEA (National Marine Electronics Association - Nationale Vereinigung für Marineelektronik) 0183 Interface Standard, V4.11

1.2. Akronyme und Notationen

In dieser Anlage werden folgende Akronyme verwendet:

2. Grundlegende Merkmale des GNSS-Empfängers

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 wesentliche Voraussetzung für den effektiven Betrieb des intelligenten Fahrtenschreibers. 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äischen Erweiterung des geostationären Navigationssystems (EGNOS) bereitgestellt werden, verlangt werden ¹. Bei dem im Rahmen des Galileo-Programms eingerichteten System handelt es sich um ein unabhängiges globales Satellitennavigationssystem, bei dem im Rahmen von EGNOS eingerichteten System hingegen um ein regionales Satellitennavigationssystem zur Verbesserung der Qualität des GPS-Signals.

GNS_2 Die Hersteller müssen gewährleisten, dass die GNSS-Empfänger in den intelligenten Fahrtenschreibern mit den durch die Galileo- und EGNOS-Systeme bereitgestellten Positionsbestimmungsdiensten kompatibel sind. Die Hersteller können außerdem die Kompatibilität mit anderen Satellitennavigationssystemen gewährleisten.

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üfungen 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 kombinierte Überwachung von automatischer Verstärkungsregelung (Automatic Gain Control, AGC) und Träger-Rauschdichte-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ötzlicher Sprünge und eines Verhaltens, das nicht mit der Fahrzeugdynamik vereinbar ist
• Konsistenz von Zeit und Frequenz, einschließlich Uhrzeitsprünge und -abweichungen, die nicht im Einklang mit den Eigenschaften der Empfängeruhr stehen

GNS_3b Die Europäische Kommission erarbeitet und genehmigt die folgenden 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 Anforderungen und Verfahren in den Empfängern aufgeführt sind, um eine sichere Implementierung von OSNMA zu gewährleisten, und die Empfehlungen zur Verbesserung der OSNMA-Leistung enthalten.

Die in Fahrtenschreiber integrierten GNSS-Empfänger, ob intern oder extern, müssen gemäß dem SIS-ICD und den Leitlinien für OSNMA-Empfänger gebaut sein.

GNS_3c Der GNSS-Empfänger liefert Positionsnachrichten (in diesem Anhang und seinen Anlagen als authentisierte Positionsnachrichten bezeichnet), die ausschließlich unter Verwendung von Satelliten erstellt werden, für die die Authentizität der Navigationsnachrichten erfolgreich verifiziert wurde.

GNS_3d Der GNSS-Empfänger liefert auch Standardpositionsnachrichten, die unter Verwendung der sichtbaren Satelliten erstellt werden, unabhängig davon, ob diese authentisiert sind.

GNS_3e Der GNSS-Empfänger verwendet die Echtzeituhr (RTC) der Fahrzeugeinheit als Zeitreferenz für die für OSNMA erforderliche 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 Randnummer 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 werden. Dieser Abschnitt gilt für die Konfiguration des intelligenten Fahrtenschreibers sowohl mit als auch ohne externe GNSS-Ausrüstung.

GNS_4 Die Standardpositionsdaten basieren auf dem von der NMEA empfohlenen minimalen spezifischen Datensatz (Recommended Minimum Specific, RMC) für das GNSS, 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 RMC-Datensatz weist folgendes Format auf (gemäß Norm NMEA V4.11):

Abbildung 2 Struktur des RMC-Datensatzes

Der Navigationsstatus ist optional und möglicherweise nicht im RMC-Datensatz enthalten.

Der Status zeigt an, ob das GNSS-Signal verfügbar ist. Solange 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 Fahrzeugeinheit aufzuzeichnen.

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

GNS_4a Die authentisierten Positionsdaten basieren auf einem NMEA-artigen Datensatz, dem authentisierten minimalen spezifischen 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

Der Navigationsstatus ist optional und möglicherweise nicht im AMC-Datensatz enthalten.

Der Status zeigt an, ob eine authentisierte GNSS-Position verfü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 aufzuzeichnen. Wenn der Statuswert auf "J" (Jamming), "O" (anderer GNSS-Angriff) oder "F" (fehlgeschlagene Authentisierung 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 verwendet werden, um die Signalverfügbarkeit und -genauigkeit von Standardpositionen zu bestimmen und aufzuzeichnen. Die HDOP dient insbesondere dazu, die Genauigkeit der aufgezeichneten Standortdaten anzugeben (siehe 4.2.2). Die Fahrzeugeinheit speichert den Wert der Horizontalgenauigkeit (HDOP), der als niedrigster der in den verfügbaren GNSS-Systemen erfassten HDOP-Werte berechnet wird.

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

Abbildung 4 Struktur des GSA-Datensatzes (Standardpositionen)

Die System-ID ist optional und möglicherweise nicht im GSA-Datensatz enthalten.

In entsprechender Weise kann der NMEA-ähnliche Datensatz für authentisierte aktive Satelliten (Authenticated Active Satellites, 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)

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 Datensatznummer "02" bis "06" gespeichert, und der ASA-Datensatznummer 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).

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.

GNS_9 Die externe GNSS-Ausrüstung muss folgende Komponenten umfassen (siehe Abbildung 6):

1. Einen handelsüblichen GNSS-Empfänger, um die Positionsdaten über die GNSS-Datenschnittstelle bereitzustellen. Die GNSS-Datenschnittstelle kann beispielsweise 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 mindestens die RMC, AMC, RMC- und ASA-Datensätze umfassen müssen. Die Implementierung der GNSS-Datenschnittstelle wählt der Hersteller der externen GNSS-Ausrüstung.

1. Eine Sende- und Empfangseinheit (GNSS Secure Transceiver) 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üstung verfügen.
2. Ein Gehäusesystem mit Funktion zur Manipulationserkennung, in dem der GNSS-Empfänger und der GNSS Secure Transceiver untergebracht sind. Die Funktion zur Manipulationserkennung muss den Sicherheitsmaßnahmen gemäß dem Schutzprofil des intelligenten Fahrtenschreibers entsprechen.
3. Eine auf dem Fahrzeug angebrachte und durch das Gehäusesystem mit dem GNSS-Empfänger verbundene GNSS-Antenne.

GNS_10 Die externe GNSS-Ausrüstung besitzt mindestens die folgenden externen Schnittstellen:

1. die Schnittstelle zu der auf dem Fahrzeug angebrachten GNSS-Antenne, falls eine externe Antenne verwendet wird.
2. 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 Verbindung zur externen GNSS-Ausrüstung unterstützen.

GNS_12 Hinsichtlich der physischen Aspekte der Kommunikation mit der externen GNSS-Ausrüstung muss die Fahrzeugeinheit 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 Transceivers 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-Zertifikats,
• das EUR-Zertifikat, dessen Gültigkeitsdauer direkt der Gültigkeitsdauer des zur Verifizierung des MSCA_VU-EGF-Zertifikats zu verwendenden EUR-Zertifikats vorausgeht, falls vorhanden,
• das Linkzertifikat, das diese beiden EUR-Zertifikate verbindet, sofern vorhanden,
• die erweiterte Seriennummer der externen GNSS-Ausrüstung,
• die Kennung des Betriebssystems der GNSS-Ausrüstung,
• die Typgenehmigungsnummer der externen GNSS-Ausrü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 ¹⁸

GNS_14 Das Protokoll der Kommunikation zwischen der externen GNSS-Ausrüstung und der Fahrzeugeinheit muss die folgenden 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 Kopplung, gegenseitigen Authentisierung und Sitzungsschlüsselvereinbarung zwischen der externen GNSS-Ausrüstung 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.

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.

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

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.

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

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 Dateikennung "2F30" gemäß Beschreibung in Tabelle 1 verwenden.

GNS_19 Der GNSS Secure Transceiver muss die vom GNSS-Empfä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.

GNS_19a Der GNSS Secure Transceiver muss die von der Fahrzeugeinheit kommenden Daten in der Elementardatei EF VU speichern. Es handelt sich hierbei um einen linearen Datensatz von fester Länge mit der Kennung "2F30" im Hexadezimalformat.

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 notwendig sind. Von diesem Aspekt abgesehen bleiben das Innendesign und die Implementierung des GNSS Secure Transceivers dem Hersteller überlassen.

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

GNS_21 Die Dateistruktur geht aus Tabelle 1 hervor. Für die Zugriffsbedingungen (ALW, NEV, SM-MAC) siehe Anlage 2 Kapitel 3.5.

Tabelle 1: Dateistruktur

4.2.2 Sichere Übertragung von GNSS-Daten ¹⁸

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:

1. Der Koppelungsprozess ist gemäß der Beschreibung in Anlage 11, Gemeinsame Sicherheitsmechanismen, abgeschlossen.
2. Die regelmäßige gegenseitige Authentisierung und Sitzungsschlüsselvereinbarung zwischen VU und externer GNSS-Ausrüstung gemäß Anlage 11 ist erfolgt. Die gemeinsamen Sicherheitsmechanismen wurden mit der angegebenen Häufigkeit angewandt.

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 Secure Transceiver der Fahrzeugeinheit verwendet die Befehle SELECT (Auswählen) und READ RECORD(S) (Datensatz/Datensätze lesen) gemäß ISO/IEC 7816-4:2013 im Secure Messaging (reiner Authentisierungsmodus), wie in Anlage 11 Abschnitt 11.5 beschrieben, mit der Dateikennung "2F2F" und der Datensatznummer "01" für den RMC NMEA-Datensatz, den Datensatznummern "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 (reiner 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 Positionsdaten über die GNSS-Datenschnittstelle an den Prozessor der Fahrzeugeinheit übermittelt.
5. Der Prozessor der Fahrzeugeinheit prüft die empfangenen Daten, indem er die Informationen (z.B. Breite, Länge, Zeit) aus dem RMC NMEA-Datensatz extrahiert. Der RMC NMEA-Datensatz gibt Auskunft darüber, ob die nicht authentisierte Position gültig ist. Wenn die nicht authentisierte Position gültig ist, extrahiert der Prozessor der Fahrzeugeinheit auch die HDOP-Werte aus den GSA NMEA-Datensätzen und berechnet den Mindestwert für das verfügbare Satellitensystem (z.B. wenn die Ortung verfügbar ist).
6. Der Prozessor der Fahrzeugeinheit extrahiert auch die Informationen (z.B. Breite, Länge, Zeit) aus dem AMC-Datensatz. Der AMC-Datensatz gibt Auskunft darüber, ob die authentisierte Position nicht gültig ist oder ob das GNSS-Signal angegriffen wurde. Wenn die Position gültig ist, extrahiert der Prozessor der Fahrzeugeinheit auch die HDOP-Werte aus den ASA-Datensätzen und berechnet den Mindestwert für das verfügbare Satellitensystem (d. h. wenn die Ortung verfügbar ist).

GNS_23a Die Fahrzeugeinheit schreibt auch die RTC-Zeit der Fahrzeugeinheit und die maximale Differenz zwischen der tatsächlichen Zeit und der RTC-Zeit der Fahrzeugeinheit nach Bedarf unter Verwendung der Befehle SELECT (Auswählen) und WRITE RECORD(S) (Datensatz/Datensätze schreiben) gemäß ISO/IEC 7816-4:2013 im Secure Messaging (reiner Authentisierungsmodus), wie in Anlage 11 Abschnitt 11.5 beschrieben, mit der Dateikennung "2F30" und den Datensatznummern "01" für VuRtcTime und "02" für MaximalTimeDifference.

4.2.3 Struktur des Befehls Read Record

Dieser Abschnitt beschreibt die Struktur des Befehls Read Record im Einzelnen. Secure Messaging (reiner Authentisierungsmodus) wird gemäß der Beschreibung in Anlage 11 (Gemeinsame Sicherheitsmechanismen) hinzugefügt.

GNS_24 Der Befehl muss das Secure Messaging (reiner Authentisierungsmodus) unterstützen, siehe Anlage 11.

GNS_25 Befehlsnachricht

GNS_26 Der in P1 angegebene Datensatz wird zum aktuellen Datensatz.

• 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ücksenden.

4.2.4. Struktur des Befehls WriteRecord

Dieser Abschnitt beschreibt die Struktur des Befehls Write Record (Datensatz schreiben) im Einzelnen. Secure Messaging (reiner Authentisierungsmodus) wird gemäß der Beschreibung in Anlage 11 (Gemeinsame Sicherheitsmechanismen) hinzugefügt.

GNS_26a Der Befehl muss das Secure Messaging (reiner Authentisierungsmodus) unterstützen, siehe Anlage 11.

GNS_26b Befehlsnachricht

GNS_26c Der in P1 angegebene Datensatz wird zum aktuellen Datensatz.

• 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ücksenden.

4.2.5 Sonstige Befehle

GNS_27 Der GNSS Secure Transceiver muss die folgenden, in Anlage 2 spezifizierten Befehle für Fahrtenschreiber der 2. Generation unterstützen:

4.3. Kopplung, gegenseitige Authentisierung und Sitzungsschlüsselvereinbarung der externen GNSS-Ausrüstung mit der Fahrzeugeinheit

Kopplung, gegenseitige Authentisierung und Sitzungsschlüsselvereinbarung zwischen externer GNSS-Ausrüstung und Fahrzeugeinheit werden 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 ¹⁸

GNS_28 Ein Ereignis "Kommunikationsfehler mit der externen GNSS-Ausrüstung" muss in der Fahrzeugeinheit aufgezeichnet werden, wie in Anhang IC Randnummer 82 und Anlage 1 (EventFaultType) definiert. In diesem Kontext wird ein Kommunikationsfehler ausgelöst, wenn der Secure Transceiver der Fahrzeugeinheit im Anschluss an eine Anforderungsnachricht gemäß 4.2 keine Antwortnachricht erhält.

4.4.2 Verletzung der physischen Integrität der externen GNSS-Ausrüstung ¹⁸

GNS_29 Wenn bei der externen GNSS-Ausrüstung eine Sicherheitsverletzung 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 Manipulationserkennung beim GNSS) definiert. Alternativ kann die externe GNSS-Ausrüstung auf Anforderungen der VU ohne Secure Messaging und mit dem Status "6A88" antworten.

4.4.3 Fehlende Positionsdaten des GNSS-Empfängers ¹⁸

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.

4.4.4 Abgelaufenes Zertifikat der externen GNSS-Ausrüstung ¹⁸

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 aufzeichnen. Die Fahrzeugeinheit verwendet weiterhin die erhaltenen GNSS-Positionsdaten.

Abbildung 6: Schema der externen GNSS-Ausrüstung

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:

GNS_32 Bei der Übermittlung von Positions-, DOP- und Satellitendaten 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 Datensätze, die mindestens die RMC-, GSA-, AMC- und ASA-Datensä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.

GNS_33 Eine auf dem Fahrzeug angebrachte externe GNSS-Antenne oder eine interne GNSS-Antenne muss mit der VU verbunden sein.

5.2. Übermittlung von Daten vom GNSS-Empfänger an die Fahrzeugeinheit

5.2.1 Fehlende Positionsdaten des GNSS-Empfängers ¹⁸

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 Fahrzeugs aufzuzeichnen. Wenn die nicht authentisierte Position gültig 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 Informationen (z.B. Breite, Länge, Zeit) aus dem AMC-Datensatz. Der AMC-Datensatz gibt Auskunft darüber, ob die nicht authentisierte Position gemäß GNS_4a gültig ist. Wenn die nicht authentisierte Position gültig ist, extrahiert der Prozessor der Fahrzeugeinheit auch die HDOP-Werte aus den ASA-Datensätzen.

5.3. Übermittlung von Daten von der Fahrzeugeinheit an den GNSS-Empfänger

GNS_37 Der Prozessor der Fahrzeugeinheit stellt dem GNSS-Empfä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 aufzeichnen, 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 Fahrtenschreibers sowohl mit als auch ohne externe GNSS-Ausrüstung.

GNS_39 Die Positionsdaten müssen in der Fahrzeugeinheit gespeichert werden, zusammen mit einem Merker, der angibt, ob die Position authentisiert wurde. Wenn Positionsdaten in der Fahrzeugeinheit aufgezeichnet werden müssen, gelten folgende Regeln:

1. Wenn sowohl die authentisierte Position als auch die Standardposition gültig und konsistent sind, werden die Standardposition und deren Genauigkeit in der Fahrzeugeinheit aufgezeichnet und der Merker wird auf "authentisiert" gesetzt.
2. Wenn sowohl die authentisierte Position als auch die Standardposition gültig sind, aber diese nicht konsistent sind, werden die authentisierte Position und deren Genauigkeit in der Fahrzeugeinheit gespeichert und der Merker wird auf "authentisiert" gesetzt.
3. Wenn die authentisierte Position gültig und die Standardposition nicht gültig ist, werden die authentisierte Position und deren Genauigkeit in der Fahrzeugeinheit aufgezeichnet und der Merker wird auf "authentisiert" gesetzt.
4. Wenn die Standardposition gültig und die authentisierte Position nicht gültig ist, werden die Standardposition und deren Genauigkeit in der Fahrzeugeinheit aufgezeichnet und der Merker wird auf "nicht authentisiert" gesetzt.

Authentisierte Positionen und Standardpositionen gelten als konsistent, wie in Abbildung 7 dargestellt, wenn die horizontale 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 authentisierten Position zu prüfen.
• s_UERE ist die Standardabweichung des benutzeräquivalenten Bereichsfehlers (User Equivalent Range Error, UERE), der alle Messfehler für die Zielanwendung modelliert, einschließlich städtische Umgebungen. Ein konstanter Wert von σ_UERE = 10 Meter wird verwendet.
• HDOP (Horizontal Dilution of Precision) ist die Horizontalgenauigkeit, die vom GNSS-Empfänger berechnet wird.
• s_UERE . HDOP ist die geschätzte mittlere quadratische Abweichung im horizontalen Bereich.

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 Anlage 1 (EventFaultType) definiert. Die Fahrzeugeinheit kann zusätzliche Prüfungen durchführen, bevor sie eine GNSS-Anomalie im Anschluss an den Empfang einer Einstellung "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 Fahrzeugeinheit ein Ereignis des Typs "Zeitkonflikt" gemäß Anhang IC Randnummer 86 und Anlage 1 (EventFaultType) generieren und aufzeichnen.

8. Datenkonflikt Fahrzeugbewegung

GNS_42 Die Fahrzeugeinheit muss ein Ereignis des Typs "Datenkonflikt Fahrzeugbewegung" gemäß Anhang IC Randnummer 84 auslösen und aufzeichnen, wenn die vom Bewegungssensor berechneten Bewegungsangaben in Widerspruch zu den vom internen GNSS-Empfänger oder von der externen GNSS-Ausrüstung berechneten Bewegungsangaben 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:

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

• Höchstens alle 10 Sekunden wird der Absolutwert der Differenz zwischen der vom GNSS und der vom Bewegungssensor kalkulierten Fahrzeuggeschwindigkeit berechnet.
• Alle in einem die letzten 5 Minuten, in denen Fahrzeugbewegung stattgefunden hat, umfassenden Zeitfenster 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öchsten Absolutwerte ausgeschlossen wurden.

Das Ereignis "Datenkonflikt Fahrzeugbewegung" wird ausgelö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 Messausreißern und transienten Werten gemindert werden).

Für die Berechnung des getrimmten Mittelwerts gilt das Fahrzeug als in Bewegung, wenn mindestens ein geschätzter 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 erfüllt ist:

GnssDistance > [OdometerDifference × OdometerToleranceFactor + Minimum(SlipDistanceUpperlimit; ( OdometerDifference × SlipFactor)) + GnssTolerance + FerryTrainDistance]

Wobei Folgendes gilt:

• GnssDistance ist die Entfernung zwischen der aktuellen und der vorherigen Position des Fahrzeugs, mit beiden Positionen aus gültigen authentisierten Positionsnachrichten, ohne Berücksichtigung der Höhe
• OdometerDifference ist die Differenz zwischen dem aktuellen Kilometerstand und dem Kilometerstand, der der vorherigen gültigen authentisierten Positionsnachricht entspricht
• OdometerToleranceFactor ist gleich 1,1 (ungünstigster Toleranzfaktor für alle Messtoleranzen des Kilometerzählers)
• GnssTolerance ist gleich 1 km ist (GNSS-Toleranz im ungünstigsten Fall)
• Minimum (SlipDistanceUpperLimit; (OdometerDifference * SlipFactor)) ist der Mindestwert zwischen:
  • SlipDistanceUpperLimit ist gleich 10 km (oberer Grenzwert der Schlupfdistanz, die durch Schlupfwirkungen beim Bremsen verursacht wird)
  • und OdometerDifference * SlipFactor, wobei SlipFactor ist gleich 0,2 (maximaler Einfluss von Schlupfwirkungen beim Bremsen)
• FerryTrainDistance wird berechnet als: FerryTrainDistance = 200 km/h * tFerryTrain, wobei tFerryTrain die Summe der Dauer in Stunden der Fährüberfahrten/Zugfahrten im betrachteten Zeitintervall ist. Die Dauer der Fährüberfahrten/Zugfahrten ist definiert als die Zeitdifferenz 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 Positionsdaten vorhanden sind, und andernfalls, sobald die Positionsdaten vorhanden sind.

Für diese Auslösebedingung gilt:

• Datum und Uhrzeit des Beginns des Ereignisses entsprechen dem Datum und der Uhrzeit des Empfangs der vorherigen Positionsnachricht,
• Datum und Uhrzeit des Endes des Ereignisses entsprechen 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 Bewegungssensor keine Bewegung erkennt und die unabhängige Bewegungsquelle eine Bewegung erkennt. Die Bedingungen für die Aufzeichnung einer Abweichung sowie des Zeitraums der Feststellung der Abweichung werden vom Hersteller der Fahrzeugeinheit festgelegt, wobei die Abweichung jedoch innerhalb von höchstens drei Stunden erkannt werden muss.

_______

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 Satellitennavigationssysteme 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. Nr. L 347 vom 20.12.2013 S. 1).

.

1. Einleitung

1.1. Anwendungsbereich

ITS_01 In dieser Anlage werden die Grundlagen der Kommunikation über die Schnittstelle des Fahrtenschreibers zu intelligenten Verkehrssystemen (ITS) gemäß den Artikeln 10 und 11 der Verordnung (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 Fahrtenschreiberschnittstellen (z.B. CAN-Bus) verwendet werden.

Folgendes wird in dieser Anlagenicht 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 genutzt werden.

1.2. Akronyme und Begriffsbestimmungen

Folgende für diese Anlage spezifische Akronyme und Begriffsbestimmungen werden verwendet:

2. Referenznormen ¹⁸

ITS_03 Diese Anlage verweist auf sämtliche oder Teile der folgenden Verordnungen 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: Parameter)
• 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 Bluetooth®-Spezifikation aufgebaut. In dieser Anlage werden die Verschlü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.

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 genannten 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 spezifizierten Kalibrierungsdienste nicht über die ITS-Bluetooth®-Verbindung 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 eingesteckt sind, verfügbar machen, wie in Tabelle 1 spezifiziert.

Tabelle 1: Verfügbarkeit der ITS-Schnittstelle je nach Art der in den Fahrtenschreiber eingesteckten Karte

ITS_14 Nach erfolgreicher ITS-Bluetooth®-Kopplung muss die VU die ITS-Bluetooth®-Verbindung der spezifischen eingesteckten Fahrtenschreiberkarte gemäß Tabelle 2 zuweisen:

Tabelle 2: Zuweisung der ITS-Verbindung je nach Art der in den Fahrtenschreiber eingesteckten Karte

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 hinsichtlich der Zustimmung des Fahrers erfüllt

3.4. Verfügbare Daten und Notwendigkeit der Zustimmung des Fahrers

ITS_18 Alle über die in Nummer 3.3 genannten Dienste verfügbaren Fahrtenschreiberdaten 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 Randnummer 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 personenbezogen" 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 unbekannt ist, wird der Karteninhaber vom Fahrtenschreiber aufgefordert, 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 Massenspeicher 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-Schnittstelle zugänglich sein. Wenn beispielsweise im Falle eines Teams nur der Fahrer seine Zustimmung erteilt hat, dürfen die personenbezogenen Daten des Beifahrers nicht zugänglich sein.

ITS_25 Wenn die VU im Kontroll-, Unternehmens- oder Kalibrierungsmodus 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 Daten und Einstufung als Personenbezogene/nicht Personenbezogene Daten

.

2) Nach Zustimmung des Fahrers verfügbare ununterbrochene GNSS-Daten

Siehe Anlage 12 - GNSS.

3) Ohne Zustimmung des Fahrers verfügbare Ereigniscodes

4) Mit Zustimmung des Fahrers verfügbare Ereigniscodes

5) Ohne Zustimmung des Fahrers verfügbare Störungsdatencodes

Diese Störung wird bei folgenden Fehlern ausgelöst, sofern sich das Kontrollgerät nicht in der Betriebsart Kalibrierung befindet:

• Interne Störung VU
• 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 Ausrüstung zur Fernkommunikation
• Störung der ITS-Schnittstelle (falls zutreffend)

6) Herstellerspezifische Ereignisse und Störungen ohne Zustimmung des Fahrers

.

Abbildung 1 Ablaufdiagramm für PIN-Validierungsversuch

Abbildung 2 Ablaufdiagramm für die Autorisierungsverifizierung der ITS-Einheit

Abbildung 3 Ablaufdiagramm zur Verarbeitung der Anforderung als nicht persönlich klassifizierter Daten (nach korrektem PIN-Zugriff)

Abbildung 4 Ablaufdiagramm zur Verarbeitung der Anforderung als persönlich klassifizierter Daten (nach korrektem PIN-Zugriff)

Abbildung 5 Ablaufdiagramm für PUC-Validierungsversuch

.

.

1 Einführung

In dieser Anlage werden das Design und die Verfahren spezifiziert, die bei der Umsetzung der Fernkommunikationsfunktion ("Kommunikation") gemäß Artikel 9 der Verordnung (EU) Nr. 165/2014 (die Verordnung) befolgt werden müssen.

DSC_1 In der Verordnung (EU) Nr. 165/2014 ist festgelegt, dass der Fahrtenschreiber mit einer Fernkommunikationsfunktion ausgestattet sein muss, durch die Mitarbeiter der zuständigen Kontrollbehörden Fahrtenschreiberinformationen vorbeifahrender Fahrzeuge mithilfe eines Fernabfragegeräts (Remote Early Detection Communication Reader [REDCR]; Abfragegeräte, die über DSRC-Schnittstellen [Dedicated Short Range Communication] 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 auszuwä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 Kontrollbehörden zu Straßenkontrollzwecken die Durchführung gezielter Straßenkontrollen erleichtert.

DSC_2 Die Daten sind unter Verwendung der Kommunikation auszutauschen; bei dieser handelt es sich um Drahtlosverkehr über eine 5,8-GHz-DSRC-Drahtlosverbindung gemäß der Anlage 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; 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 Kommunikationsgerät herzustellen, wenn dies von dem Gerät der zuständigen Kontrollbehörde mithilfe zulässiger Funkverbindungsmittel (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 Kontrollbehö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 Fahrtenschreibers erforderlich ist.

DSC_6 Bei der Kommunikation dürfen nur Daten übertragen werden, die für die Zwecke der gezielten Straßenkontrolle von Fahrzeugen 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 werden, sodass nur befugte Personen zuständiger Kontrollbehörden in der Lage sind, die über die Kommunikation weitergegebenen Daten zu verstehen und ihre Authentizität zu überprüfen. Siehe Anlage 11, Gemeinsame Sicherheitsmechanismen.

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 Kontrollbehörden und denjenigen Parteien, mit denen sie diese Informationen austauschen, bekannt sein und von diesen kontrolliert werden und liegt außerhalb der Bestimmungen der Kommunikation, die Gegenstand dieser Anlage ist, sofern die Kommunikation nicht vorsieht, mit jedem Paket an Nutzlastdaten 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 Kommunikation keine Daten bezüglich der Identität des Fahrers übertragen.

2 Geltungsbereich ¹⁸

In dieser Anlage wird festgelegt, wie die Mitarbeiter der zuständigen Kontrollbehörden eine angegebene 5,8-GHz-DSRC- Drahtloskommunikation verwenden, um aus der Entfernung Daten (die Daten) eines 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üfungen 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.

In einem solchen Szenario ist die für die Kommunikation zur Verfügung stehende Zeit begrenzt, da die Kommunikation zielgerichtet ist und innerhalb einer Kurzstrecke erfolgt. Weiterhin können die zur Fahrtenschreiberfernüberwachung (Remote Tachograph Monitoring, RTM) genutzten 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 Kontrollbehörden getrennt oder aufeinanderfolgend durchgeführt werden.

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 Operationen
• 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 Datenkonzepte 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 Mitarbeiter der zuständigen Kontrollbehörden, ebenso wenig wie die Kriterien, anhand derer die zuständigen Kontrollbehörden entscheiden, 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 Klarstellung: Durch die Kommunikation werden den zuständigen Kontrollbehörden lediglich die Daten zur Verfügung gestellt, auf deren Grundlage sie fundierte Entscheidungen treffen können.
• 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 werden in dieser Anlage verwendet:

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 Reihenfolge 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ßenverkehr, zur Aufhebung der Verordnung (EWG) Nr. 3821/85/EWG 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/EWG und (EG) Nr. 2135/98 des Rates 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 cooperative 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 Industrial, Scientific and Medical (ISM) band; 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)).

[6] EN 12253 Road transport and traffic telematics - Dedicated short-range communication - Physical layer using microwave at 5.8 GHz (Straßentransport- und Verkehrstelematik - Nahbereichskommunikation - Datenverbindungsschicht - Bitübertragungsschicht für die Frequenz 5,8 GHz) (Straßentransport- und Verkehrstelematik (RTTT) - Nahbereichskommunikation Fahrzeug-Bake (DSRC) - Bitübertragungsschicht für die Frequenz 5,8 GHz).

[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 - Zugriffsmedium und Verbindungssteuerung).

[8] EN 12834 Road transport and traffic telematics - Dedicated short-range communication - Application layer (Straßentransport- und Verkehrstelematik - Nahbereichskommunikation - Anwendungsschicht).

[9] EN 13372 Road transport and traffic telematics - Dedicated short-range communication - Profiles for RTTT applications (Straßentransport- und Verkehrstelematik - Nahbereichskommunikation - DSRC-Profile für RTTT-Anwendungen).

[10] ISO 14906 Electronic fee collection - Application interface definition 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 ausgerichtetes Fernabfragegerät".

4.1.1 Voraussetzungen für den Datentransfer über die 5,8-GHz-DSRC-Schnittstelle

HINWEIS: Für ein besseres Verständnis des Kontexts der Voraussetzungen 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-Fahrtenschreibers (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 Aktualisierung 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.

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 Anlage (Datenstrukturen) angegeben strukturiert sind und verfügbar 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äsentation 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

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 "Gemeinsame Sicherheitsmechanismen" zur vorübergehenden Speicherung in der DSRC-VU als aktuelle Version der DSRCSecurityData in der in dieser Anlage in Nummer 5.4.4 definierten Form bereitgestellt werden.

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 geprüft gegen die geeigneten Parameter von EN 300 674-1 gemäß Abschnitt 5) (REDCR), um per Fernkommunikation ein Fahrzeug zu identifizieren, das möglicherweise gegen Verordnung (EU) Nr. 165/2014 verstößt. Nach der Identifizierung entscheidet der Mitarbeiter der zuständigen 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 Kontrollbehö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).

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 Kontrollbehörden in einem sich bewegenden Fahrzeug und richtet entweder ein REDCR-Handgerät aus dem Fahrzeug auf die Mitte der Windschutzscheibe 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 Fernabfragegerä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 Daten gemäß Anlage 11 Gemeinsame Sicherheitsmechanismen verifiziert und entschlüsselt.

5 Design und Protokolle der Fernkommunikation

5.1 Design ¹⁸

Das Design der Fernkommunikationsfunktion im intelligenten Fahrtenschreiber ist in Abbildung 14.3 dargestellt.

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 Mitarbeiter der zuständigen Kontrollbehörden übermittelt werden sollen.
• Die gesicherten Daten werden im VUSM-Speicher abgelegt. 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 Sicherheitsmoduls ist in Anlage 11 Gemeinsame Sicherheitsmechanismen 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-Kommunikation (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 Stromquelle. 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 Stromquelle der DSRC-VU bei jeder regelmäßigen Nachprüfung ausgetauscht werden; der Hersteller der DSRC-VU-Ausrüstung muss sicherstellen, dass die Stromversorgung den Zeitraum zwischen zwei aufeinanderfolgenden regelmäßigen 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 Funktion in der VU ist für die Bereitstellung und Aktualisierung der Daten verantwortlich. Der Inhalt der Daten ("Fahrtenschreibernutzlast") 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 Daten (VUPM-Daten) und steuert die Antwort auf eine Abfrage ü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 Sicherheitsmechanismen festgelegt und nicht in dieser Anlage definiert.
• Das DSRC-Gerät (REDCR) (DSRC-REDCR) beinhaltet einen 5,8-GHz-Sender und dazugehörige Firm- und Software, 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.
• 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 vertikale Mitte der Windschutzscheibe gerichtet ist. Bei leichten 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 eingebaut sein.

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

DSC_21 Die DSRC-Antenne muss mit der DSRC-VU-Ausrüstung entweder direkt in dem an oder in der Nähe der Windschutzscheibe 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 Verstoß gegen die Verordnung (EU) Nr. 165/2014. Ein absichtliches Verbergen oder eine sonstige Beeinträchtigung der Antennenfunktion ist als Verstoß gegen Verordnung (EU) Nr. 165/2014 auszulegen.

DSC_22 Der Formfaktor der Antenne ist nicht definiert und kann betriebswirtschaftlich entschieden werden, solange die angebrachte DSRC-VU die Konformitätsvorgaben in Abschnitt 5 unten erfüllt. Die Antenne soll gemäß den Festlegungen 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 Mitarbeiter der zuständigen Kontrollbehörden gewählten Lese- (Stativbefestigung, Handgerät, Fahrzeugbefestigung usw.) und Betriebsmodi variieren.

Die Ergebnisse der Fernkommunikationsfunktion werden dem Mitarbeiter 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 zustä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, um die Ausrüstung nach den besonderen Anforderungen der zuständigen Kontrollbehörden für deren jeweilige Abfrageszenarios zu gestalten und bereitzustellen.

DSC_24 Design und Formfaktor der DSRC-VU und deren Positionierung 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 dieses Abschnitts (5.1) angegebenen Design- und Leistungsvorgaben.

DSC_25 Allerdings muss die DSRC-VU auf angemessene Weise in der Lage sein, Datenkonzeptwerte anderer intelligenter Fahrzeugausrü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 gestellt 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

Die Schritte werden im Folgenden beschrieben:

1. Immer, wenn sich das Fahrzeug in Betrieb befindet (Zündung eingeschaltet), stellt der Fahrtenschreiber der VU-Funktion Daten bereit. Die VU-Funktion bereitet die Daten für die Fernkommunikationsfunktion (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.
2. Jedes Mal, wenn die Daten aktualisiert werden, ist auch der im Sicherheitsdatenkonzept definierte Zeitstempel zu aktualisieren.
3. Die VUSM-Funktion sichert die Daten gemäß den in Anlage 11 angegebenen Verfahren.
4. 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 Dateinamens RTMData oder Anwendungs-ID und Attributskennung zu identifizieren sein.
5. 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.
6. 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.
7. Die Daten werden durch das REDCR-Gerät analysiert und dem Mitarbeiter der zuständigen Kontrollbehörde bereitgestellt.
8. Der Mitarbeiter der zuständigen Kontrollbehörde nutzt die Daten zur Unterstützung bei der Entscheidung, ob er oder ein anderer Mitarbeiter der zuständigen Kontrollbehörde das Fahrzeug für eine umfangreiche Ü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, einer zuständigen Kontrollbehörde zweckdienliche Informationen 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 Fernkommunikation

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üstung muss ERC 70-03 und die in den Tabellen 14.1 und 14.2 unten definierten Parameter erfüllen und innerhalb dieser betrieben werden.

DSC_29 Zudem muss die zur Fahrtenschreiberfernüberwachung verwendete Ausrüstung, um Kompatibilität mit den Betriebsparametern 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

Tabelle 14.2 Uplink-Parameter

5.3.3 Antennendesign

5.3.3.1 REDCR-Antenne

DSC_30 Das Design der REDCR-Antenne ergibt sich aus dem kommerziellen Design, innerhalb der in 5.3.2 definierten Grenzen und angepasst zur Optimierung der Leseleistung des DSRC-REDCR für spezielle Zwecke und Lesebedingungen, innerhalb derer das REDCR betrieben wird.

5.3.3.2. VU-Antenne

DSC_31 Das Design der DSRC_VU-Antenne ergibt sich aus dem kommerziellen Design, innerhalb der in 5.3.2 definierten Grenzen und angepasst zur Optimierung der Leseleistung des DSRC-REDCR für spezielle Zwecke und Lesebedingungen, innerhalb derer das REDCR betrieben wird.

DSC_32 Die VU-Antenne ist an oder in der Frontscheibe des Fahrzeugs 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üfkommunikation 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 Transaktionsablauf 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)-Transaktionsbereich eingetreten sind, aber noch keine Kommunikation 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ützter 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 werden, 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-VUsendet mithilfe des zugewiesenen privaten Fensters einen Frame mit ihrer Fahrzeugdiensttabelle (Vehicle Service Table, VST). Diese VST enthält eine Liste aller unterschiedlichen Anwendungsinstanziierungen, 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-Parameterwert verbunden ist, der die Anwendung und die unterstützte Norm angibt.
• Schritt 5 Anschließend analysiert das REDCR die angebotene VST und beendet entweder die Verbindung (RELEASE), 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.
• Schritt 6 Dazu sendet das REDCR einen Frame mit einem Befehl zum Abruf der RTM-Daten, in dem die RTM-Anwendung durch Angabe der Kennung zur Instanziierung 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 zugewiesenen 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 gesetzt 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 Transaktionsprotokolls.

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-Transaktionsphase 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 adressiert werden (EID), enthält.
• GET.request: Vom REDCR an die DSRC-VU ausgegebener Befehl, der die zu adressierende Anwendungsinstanziierung 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 senden. 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 angeforderten Daten.
• ACTION.request ECHO: Befehl, der die DSRC-VU anweist, 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 Verbindung zur selben Abfrageeinrichtung her, wenn sie sich 255 Sekunden lang außerhalb des Kommunikationsbereichs 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:

Ein Beispiel für Transaktionssequenz und -inhalte der ausgetauschten 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 dieser Anlage entsprechen. Die Strukturierung dieser Daten ist in diesem Abschnitt angegeben.

DSC_38 Die Nutzlast (RTM-Daten) besteht aus der Verkettung der

1. Encrypted TachographPayload-Daten, der Verschlüsselung von Tachograph Payload gemäß ASN.1 in Abschnitt 5.4.5. Die Verschlüsselungsmethode ist in Anlage 11 beschrieben.
2. DSRCSecurity Data, 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-Context Mark 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:

1. Wenn ein LPN einen Alphabet Indicator 'Latin Alphabet No2' oder 'latin Cyrillic Alphabet' enthält, werden die Sonderzeichen von der Fernabfrageeinrichtung unter Anwendung besonderer Regeln gemäß ISO/DIS 14 906,2 neu abgebildet.

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:

Tabelle 14.3 Elemente von RtmData, durchgeführte Aktionen und Definitionen ¹⁸

Hinweis: RTM22, RTM23, RTM24 und RTM25 werden gemäß dem Beiblatt zur dieser Anlage berechnet.

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.

DSC_43 Bei jedem DSRC-Austausch werden die Daten mit PER (Packed Encoding Rules) UNALIGNED verschlüsselt, mit Ausnahme von TachographPayload und OwsPayload;, die mit OER (Octet Encoding Rules) gemäß ISO/IEC 8825-7, Rec. ITU-T X.696 verschlüsselt werden.

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ührten Einstellungen.

Tabelle 14.4 Initialisierung - BST-Frame-Einstellungen

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

DSC_45 Eine DSRC-VU benötigt beim Empfang einer BST die Zuweisung 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

DSC_46 Das REDCR antwortet mit der Zuweisung eines privaten Fensters, wie durch EN 12795 und EN 13372, 7.1.1 angegeben, 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

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 Einstellungen aus Tabelle 14.8, unter Verwendung des zugewiesenen Übertragungsfensters.

Tabelle 14.8 Initialisierung - VST-Frame-Einstellungen

DSC_48 Die DSRC-VU muss die "Freight&Fleet"-Anwendung unterstützen, gekennzeichnet durch die Anwendungskennung "2". Es können weitere Anwendungskennungen unterstützt werden, 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 Anwendungsinstanziierung ist ein Verweis auf den jeweiligen Standard gegeben: Dieser besteht aus dem Rtm-Context Mark, 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.

Tabelle 14.9 Initialisierung - Beispiele für die Inhalte von VST-Frames ¹⁸

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

Tabelle 14.11 zeigt ein Beispiel für das Lesen der RTM-Daten.

Tabelle 14.11 Präsentation - Frame-Beispiel für GET-Anforderungen

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

Tabelle 14.13 zeigt ein Beispiel für das Lesen der RTM-Daten.

Tabelle 14.13 Präsentation - Beispiel für die Inhalte des Antwort-Frames

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

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 beinhalten, müssen gemäß Anlage 11 Gemeinsame Sicherheitsmechanismen 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 Daten 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) erforderlich sein.

DSC_55 Zur Durchführung dieser Prüfung der grundlegenden Kommunikation wird der Befehl ECHO vom REDCR während einer Sitzung ausgegeben, d. h. nach erfolgreicher Durchführung einer Initialisierungsphase. Die Abfolge der Interaktionen ä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 Zuweisung eines privaten Fensters.
• Schritt 3 Die REDCR sendet die Zuweisung eines privaten Fensters.
• Schritt 4 Die DSRC-VU sendet mithilfe des zugewiesenen privaten Fensters ihre Fahrzeugdiensttabelle (Vehicle Service Table, VST). Diese VST enthält eine Liste aller unterschiedlichen Anwendungsinstanziierungen, die diese DSRC-VU im Rahmen von AID="2" unterstützt. Die verschiedenen 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 angebotene VST und beendet entweder die Verbindung (RELEASE), 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 zugewiesenen 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-Befehl 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.

Tabelle 14.15 Beispiel für ACTION-, ECHO-Anfrage-Frame

DSC_58 Beim Erhalt der ECHO-Anforderung sendet die DSRC-VU eine ECHO-Antwort mit 100 Datenoktetten durch Widerspiegelung des erhaltenen Befehls, gemäß ISO 14906, ohne spezifische 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

5.5 Reserviert für künftige Verwendung. ^{18 20}

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-Drahtloskommunikation 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 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 Standard erfolgen. Die VU wird auf eine der folgenden Arten mit der DSRC-VU verbunden:

1. ü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-Gerät
2. über Bluetooth Low Energy (BLE)
3. ü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 Stromversorgung unterstützen.

5.6.2 Anwendungsprotokoll

DSC_71 Das Anwendungsprotokoll zwischen VU-Fernkommunikationseinrichtung und DSRC-VU ist für die regelmäßige Übertragung 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
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:

• RCDT-Communication Link Initialization - Request 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 Anwendungen/Module wie Wiegen an Bord zu unterstützen).
• RCDT-Communication Link Initialization - Response 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 Antwort = 1 (Erfolg) oder = 0 (Fehler) dar.

DSC_75 Die Initialisierung des Kommunikationslinks erfolgt nach Installation, Kalibrierung und Anlassen des Motors/Einschalten der VU.

• RCDT-Send Data wird von der VU dazu verwendet, die signierten RCDT-Daten (d. h. die Fernkommunikationsdaten) an die DSRC-VU zu senden. Die Daten werden alle 60 Sekunden gesendet. Der Parameter DataTransaction Id kennzeichnet die jeweilige Datenübertragung. Außerdem wird durch LinkIdentifier sichergestellt, dass der entsprechende Link korrekt ist.
• RCDT-Data Acknowledgment wird von der DSRC-VU gesendet, um der VU Rückmeldung über den Erhalt der Daten infolge eines Befehls RCDT-Send Data zu geben, gekennzeichnet durch den Parameter DataTransaction Id. 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 DataTransaction Id erhält, muss die VU ein Ereignis generieren und aufzeichnen.
• RCDT-Communication Link Termination request 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 aufgrund eines abrupten Herunterfahrens einer VU "bezuglose" Links vorhanden sein könnten.

• RCDT-Communication Link Termination - Response wird von der DSRC-VU an die VU gesendet, um die Aufforderung zur Beendigung des Links durch die VU für den spezifischen LinkIdentifier zu bestätigen.

5.7 Fehlerbehandlung

5.7.1 Aufzeichnung und Kommunikation der Daten in der DSRC-VU ¹⁸

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 "Kommunikationsfehler mit der Fernkommunikationsausrüstung" zusammen 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.

DSC_79 Wenn die VUPM vergebens versucht, VU-Daten vom Sicherheitsmodul abzurufen (um diese an die VU-DSRC weiterzuleiten), muss sie diesen Fehler mit dem Typ Event FaultType und dem Enum-Kommunikationsfehlerwert "62"H Remote Communication Facility samt Zeitstempel aufzeichnen. Der Kommunikationsfehler wird erkannt, wenn mehr als drei Mal in Folge keine Nachricht RCDT Data Acknowledgement für die zugehörigen (d. h. mit der gleichen DataTransactionId in den Send-Data- und Acknowledgement-Nachrichten versehenen) RCDT Send Data eingeht.

5.7.2 Fehler in der Drahtloskommunikation

DSC_80 Die Behandlung von Kommunikationsfehlern muss mit derjenigen gemäß zugehörigen DSRC-Normen, nämlich EN 300 674-1, EN 12253, EN 12795, EN 12834 und den entsprechenden 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 einer Umgebung mit unsicheren atmosphärischen und Interferenzbedingungen, insbesondere in den an dieser Anwendung beteiligten Kombinationen "tragbares REDCR" und "Fahrzeug in Bewegung". Deshalb muss zwischen den Bedingungen "Lesefehler" und "Fehler" ein Unterschied bestehen. Bei einer Transaktion über eine Drahtlosschnittstelle sind Lesefehler gängig; anschließend wird in der Regel ein neuer Versuch gestartet, 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 bewegt. (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 Fahrzeugs 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 Instanzen der Lesefehler lassen sich nicht aufzeichnen, da die Kommunikation schlichtweg nicht stattgefunden hat.

Wenn aber der Mitarbeiter der zuständigen Kontrollbehörde ein Fahrzeug 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 Mitarbeiter der zuständigen Kontrollbehörde den Fehler protokollieren und die an der Maßnahme beteiligten Kollegen über einen möglichen Verstoß informieren. Die Kollegen können dann das Fahrzeug anhalten und physisch überprüfen. Da aber keine erfolgreiche Kommunikation stattgefunden hat, kann die DSRC-VU keine Daten über den Fehler liefern. Eine solche Protokollierung ist deshalb abhängig vom Design des REDCR-Geräts.

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 Wahrscheinlichkeit, dass Daten eine CRC-Prüfung fälschlicherweise erfolgreich bestehen, 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 abbricht, 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 zuständige Kontrollbehörde.

Die einzige aussagekräftige "Fehlerinformation", die sich aufzeichnen 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, ergeben 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 empfangenen Daten zu entschlüsseln.

6 Inbetriebnahme- und regelmäßige Inspektionsprüfungen der Fernkommunikationsfunktion

6.1 Allgemein

DSC_84 Für die Fernkommunikationsfunktion sind zwei Arten von Prüfungen vorgesehen:

1. ECHO-Prüfung, um den Drahtloskommunikationskanal DSRC-REDCR > > -:- < DSRC-VU wireless zu überprüfen.
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 Drahtloskommunikationskanal übermittelten Dateninhalte zugreifen kann.

6.2 ECHO

Die Spezifikationen dieses Abschnitts geben an, wie geprüft wird, dass die Verbindung DSRC-REDCR > > -:- < DSRC-VU in funktioneller Hinsicht 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) einzuleiten, 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 > > -:- < DSRC-VU) korrekt 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 Funktionalität und wird mit denselben Spezifikationen wie das Lesegerät der Kontrollbehörden eingerichtet. Der einzige Unterschied 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 Anschluss an die Erstaktivierung eines intelligenten Fahrtenschreibers oder am Ende des Kalibrierungsverfahrens durchgeführt werden. Nach der Aktivierung generiert die Fahrzeugeinheit 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 Werkstattkarte in das DSRC-Prüflesegerät ein und fragt von der Fahrzeugeinheit 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.

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, Kartenler 1) der Fahrzeugeinheit eingesteckten Fahrerkarte (oder Werkstattkarte) gespeichert sind, sowie anhand der ausgewä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 gleichgestellt 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 Bedingung "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 Übermittlung durch die Fernkommunikationseinrichtung zu spezifizieren.

1. "RTM-Schicht" ist der Zeitraum zwischen dem Ende einer täglichen Ruhezeit 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.

2. "Kumulierte Lenkzeit" ist die Summe der Dauer aller LENKEN-Tätigkeiten des Fahrers in einem Zeitraum, in dem nicht die Bedingung "KONTROLLGERÄT NICHT ERFORDERLICH" gilt.
3. "Tägliche Lenkzeit" ist die kumulierte Lenkzeit innerhalb einer RTM-Schicht.
4. "Wöchentliche Lenkzeit" ist die kumulierte Lenkzeit während der laufenden Woche.
5. "Ununterbrochene Ruhezeit" ist jeder ununterbrochene Zeitraum "UNTERBRECHUNG/RUHE".
6. "Vierzehntätige Lenkzeit" ist die kumulierte Lenkzeit der vorangegangenen und der laufenden Woche.
7. "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öchentlicher Ruhezeiten durch eine VU diese wöchentlichen Ruhezeiten als tägliche Ruhezeiten zu betrachten sind.

8. "Regelmäßige tägliche Ruhezeit" ist eine ununterbrochene Ruhezeit von mindestens 11 Stunden.

   In Ausnahmefällen kann bei einer aktivierten Bedingung "FÄHRÜBERFAHRT/ZUGFAHRT" die regelmäßige tägliche Ruhezeit höchstens zweimal durch andere Tätigkeiten als Ruhezeiten mit einer maximalen kumulierten 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 unterbrochen wurde, eine neue RTM-Schicht.

   Abbildung 1. Beispiel für eine tägliche Ruhezeit, die aufgrund von Fährüberfahrten/Zugfahrten unterbrochen wurden
   

9. "Reduzierte tägliche Ruhezeit" ist eine ununterbrochene Ruhezeit von mindestens 9 Stunden, aber weniger als 11 Stunden.
10. "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ÜBERFAHRT/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 zweimal unterbrochen werden, oder
    • der zweite Teil der aufgeteilten täglichen Ruhezeit kann ein- oder zweimal unterbrochen werden, oder
    • der erste Teil der aufgeteilten täglichen Ruhezeit kann einmal unterbrochen 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 Ruhezeit und mindestens 9 Stunden für die zweite Ruhezeit beträgt, sofern die erste Ruhezeit durch eine "FÄHRÜBERFAHRT/ZUGFAHRT" unterbrochen 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
    

11. 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 unterbrochen wurde, eine neue RTM-Schicht.
12. "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überfahrten/Zugfahrten

Die VU berechnet die kumulierte Ruhezeit bei Unterbrechung der Ruhezeit aufgrund von Fährüberfahrten/Zugfahrten gemäß den folgenden Schritten:

1. Schritt 1

   Die VU erkennt Unterbrechungen der Ruhezeit vor der Aktivierung des Merkers "FÄHRÜBERFAHRT/ZUGFAHRT (ANFANG)" gemäß Abbildung 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 überschreitet,
   • 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 ununterbrochene Ruhezeit unmittelbar vor der Unterbrechung zur kumulierten Ruhezeit hinzugerechnet.

   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.

2. Schritt 2
   Für jede gemäß Schritt 1 erkannte Unterbrechung bewertet die VU, ob die Berechnung der kumulierten Ruhezeit beendet werden sollte. Die VU beendet den Berechnungsprozess, wenn zwei ununterbrochene Ruhezeiten vor Aktivierung des Merkers "FÄHRÜBERFAHRT/ZUGFAHRT (ANFANG)" zur kumulierten Ruhezeit hinzugerechnet wurden, einschließlich Ruhezeiten im ersten Teil einer aufgeteilten täglichen Ruhezeit, die ebenfalls durch Fährüberfahrten/Zugfahrten unterbrochen wird. Andernfalls fährt die VU gemäß Schritt 3 fort.
3. 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 Unterbrechung bewirkt, dass die kumulierte Zeit aller erkannten Unterbrechungen 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 ununterbrochenen Ruhezeiten, die nach den jeweiligen Unterbrechungen anfallen, bei der Berechnung der täglichen Ruhezeit hinzugerechnet, bis die Bedingung in Schritt 4 erfüllt ist.

4. 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ÜBERFAHRT/ZUGFAHRT" aktiviert ist, höchstens zwei ununterbrochene Ruhezeiten 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 regelmäßige tägliche Ruhezeit oder als erster Teil einer aufgeteilten täglichen Ruhezeit berechnet wird

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

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 gemäß 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 auftretenden Lenkzeiten zu der täglichen Lenkzeit für die laufende RTM-Schicht hinzuzurechnen.

Die VU berechnet auch die wöchentlichen und die vierzehntägigen Lenkzeiten. Die Lenkzeiten, die während der Unterbrechungen der täglichen Ruhezeiten aufgrund von Fährüberfahrten/Zugfahrten auftreten, werden bei der Berechnung der wöchentlichen und der vierzehntägigen Lenkzeiten hinzugerechnet.

.

1. Begriffsbestimmungen

Im Sinne dieser Anlage gelten folgende Begriffsbestimmungen:

Intelligentes Fahrtenschreibersystem: gemäß Definition in diesem Anhang (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: Begriffsbestimmung ccc);

Intelligent Dedicated Equipment (IDE): Gerät, das zum Herunterladen von Daten verwendet wird, wie in Anlage 7 dieses Anhangs definiert.

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 zweiten Generation und die Einführung von Kontrollgeräten und Fahrtenschreiberkarten der zweiten Generation Version 2.

Ü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 Fahrtenschreiberkarten unterstützen.

2.2. Interoperabilität zwischen VU und Karten ¹⁸

Fahrtenschreiberkarten der ersten Generation sind interoperabel mit Fahrzeugeinheiten der ersten Generation (gemäß Anhang IB der Verordnung (EWG) Nr. 3821/85/EWG); 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 Fahrzeugeinheiten 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üssen 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 Fahrtenschreiberkarten 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 Werkstattkarten der zweiten Generation nutzen können.

MIG_005 Zur Bestimmung der Betriebsart dürfen Fahrzeugeinheiten jeder Version der zweiten Generation nur die Art der gültigen eingesteckten Karten berücksichtigen, nicht aber ihre Generation 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 Fahrtenschreiberkarte gleicher Art der ersten Generation.

2.3. Interoperabilität zwischen VU und Bewegungssensoren

Bewegungssensoren der ersten Generation sind interoperabel mit Fahrzeugeinheiten der ersten Generation; Bewegungssensoren der zweiten Generation wiederum sind interoperabel mit Fahrzeugeinheiten jeder Version der zweiten Generation. Zusätzlich gelten die nachfolgenden Bestimmungen.

MIG_007 Fahrzeugeinheiten jeder Version der zweiten Generation können nicht mit Bewegungssensoren der ersten Generation gekoppelt und verwendet werden.

MIG_008 Bewegungssensoren der zweiten Generation können entweder ausschließlich mit Fahrzeugeinheiten jeder Version der zweiten 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 Fahrtenschreiberkarten 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 Datendownload-Protokolle dieser Generation heruntergeladen; heruntergeladene 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 Werkstattkarten) jeder Version der zweiten Generation genauso herunterzuladen 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 Tachograph), die durch das Download-Protokoll von Karten der ersten Generation angefordert werden. Diese Informationen werden entsprechend den Sicherheitsmechanismen der ersten Generation durch eine digitale Signatur gesichert.
  Die entsprechenden Downloads dürfen keine Anwendungsdaten-EF umfassen, die nur in Fahrerkarten (und Werkstattkarten) von Version 1 oder Version 2 der zweiten Generation vorhanden sind (Anwendungsdaten-EF innerhalb 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 Befehle 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 Generation, die in eine Fahrzeugeinheit jeder Version der zweiten Generation eingesteckt ist, wird das in Anlage 7 dieses Anhangs definierte Datendownload-Protokoll verwendet. Die Fahrzeugeinheit sendet Befehle an die Karte in genau der gleichen Weise wie eine Fahrzeugeinheit der ersten Generation; heruntergeladene Daten müssen das für Karten der ersten Generation definierte Format einhalten.

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 Sicherheitsmechanismen 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 herunterzuladen. Die heruntergeladenen Daten müssen in dem Fall das gleiche Format aufweisen wie Daten, die von einer Fahrzeugeinheit 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 Kalibrierungsprotokolls der entsprechenden Generation oder Version zu kalibrieren. Kalibrierungsgeräte können mit allen Generationen und Versionen von Fahrzeugeinheiten kompatibel sein.

3. Wesentliche Schritte im Zeitraum vor dem Einführungsdatum

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 Fahrzeugeinheiten 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 dieselben Schlüssel und Zertifikate wie für Geräte der zweiten Generation Version 1 verwendet.

MIG_020 Die Mitgliedstaaten müssen Werkstattkarten der zweiten Generation Version 2 spätestens 1 Monat vor dem Einführungsdatum ausgeben können.

MIG_021 Die Mitgliedstaaten müssen alle Arten von Fahrtenschreiberkarten 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ührungsdatum

MIG_022 Die Mitgliedstaaten dürfen mit Wirkung ab dem Einführungsdatum nur noch Fahrtenschreiberkarten der zweiten Generation 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.

MIG_023a Mit Wirkung vom Einführungsdatum müssen Fahrzeugeinheiten 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 Fahrzeugeinheiten/Bewegungssensoren der ersten Generation oder von Fahrzeugeinheiten der zweiten Generation Version 1, die bereits über eine Typgenehmigung verfügen, beantragen und erlangen.

5. Aufzeichnung von Grenzüberschreitungen in Fahrtenschreibern der ersten Generation und in Fahrtenschreibern 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 Verordnung (EU) Nr. 165/2014 einreist, ist als Ort des Beginns der täglichen Arbeitszeit im Einklang mit der manuellen Eingabe von Orten, wie in Anhang IC Nummer 60 der Verordnung (EU) Nr. 165/2014 und Anhang IB Nummer 50 der Verordnung (EWG) Nr. 3821/85/EWG festgelegt, einzutragen.

.

1. Abkürzungen und Referenzdokumente

1.1. Abkürzungen

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 Adapters

2.1. Allgemeine Beschreibung des Adapters

ADA_001 Der Adapter stellt gesicherte, permanent die Fahrzeuggeschwindigkeit und die zurückgelegte Wegstrecke darstellende Daten für eine angeschlossene VU bereit.

Der Adapter ist nur für die Fahrzeuge bestimmt, die mit Kontrollgeräten nach Maßgabe dieser Verordnung ausgestattet sein müssen.

Der Adapter wird nur in den unter Begriffsbestimmung yy) "Adapter" von Anhang IC bestimmten Fahrzeugen eingebaut und genutzt, in denen der Einbau eines bestehenden Bewegungssensors anderer Art, der ansonsten den Bestimmungen dieses Anhangs und dessen Anlagen 1 bis 16 entspricht, mechanisch unmöglich ist.

Der Adapter wird nicht mechanisch mit einem bewegten Fahrzeugteil verbunden, sondern an die durch integrierte Sensoren oder alternative Schnittstellen generierten Geschwindigkeits-/Entfernungsimpulse angeschlossen.

ADA_002 Ein typgenehmigter Bewegungssensor (gemäß den Bestimmungen dieses Anhangs IC Abschnitt 8 -Typgenehmigung von Kontrollgeräten und Fahrtenschreiberkarten) ist im Adaptergehäuse anzubringen, das daneben einen Impulskonverter enthält, der die Eingangsimpulse in den eingebetteten Bewegungssensor 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 Geschwindigkeitsimpulse,
• Einspeisung der Eingangsimpulse in den eingebetteten Bewegungssensor,
• 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 Sicherheitsanforderungen für Bewegungssensoren. Stattdessen gelten die in Abschnitt 4.4 dieses Anhangs festgelegten sicherheitsbezogenen Anforderungen.

3. Vorschriften für das Kontrollgerät bei Nutzung eines Adapters

Die Vorschriften in den folgenden Kapiteln geben Hinweise für die Auslegung 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 Fahrzeugs 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 Bewegungssensors) 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 Kalibrierung befindet, von der VU bei einer 200 Millisekunden überschreitenden Unterbrechung der Stromversorgung des eingebetteten Bewegungssensors ausgelöst [79].
• Das Ereignis "Datenfehler Bewegung" wird von der VU bei einer Unterbrechung des normalen Datenflusses zwischen dem eingebetteten Bewegungssensor und der VU und/oder bei einem Datenintegritäts- oder Datenauthentizitätsfehler während des Datenaustauschs zwischen dem eingebetteten 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 ausgelöst [85].
• Die Störung "Kontrollgerät" wird, sofern sich das Kontrollgerä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ängenden Störungen des Adapters müssen durch das Kontrollgerät feststellbar sein [88].

ADA_009 Die Kalibrierungsfunktion der VU muss die automatische Koppelung des eingebetteten Bewegungssensors mit der Fahrzeugeinheit 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ückgelegte 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.

ADA_012 Die Eingangsschnittstelle des Adapters muss gegebenenfalls die Frequenzimpulse der eingehenden Geschwindigkeitsimpulse mit einem festen Faktor multiplizieren oder durch einen 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.

4.2. Einspeisung der Eingangsimpulse in den eingebetteten Bewegungssensor

ADA_013 Die Eingangsimpulse werden - gegebenenfalls wie oben ausgeführt angepasst - in den eingebetteten Bewegungssensor eingespeist, sodass jeder Eingangsimpuls vom Bewegungssensor erfasst wird.

4.3. Eingebetteter Bewegungssensor

ADA_014 Der eingebettete Bewegungssensor wird durch die Eingangsimpulse 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].

ADA_016 Die im eingebetteten Bewegungssensor gespeicherten Einbaudaten werden als Informationen zum Einbau des Adapters betrachtet [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 Bewegungssensorplomben [398 bis 406]

ADA_018 Die Entfernung des eingebetteten Bewegungssensors aus dem Adapter darf nicht ohne Zerstörung der Plombe(n) des Adaptergehä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 stammende Bewegungsdaten angenommen und verarbeitet werden.

4.5. Leistungsmerkmale

ADA_020 Der Adapter muss in dem vom Hersteller festgelegten Temperaturbereich 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 Fahrzeugbewegungsdaten stört, reagieren - unter diesen Umständen registriert und speichert die Fahrzeugeinheit eine Sensorstörung [88] - oder
• über einen Sensor verfügen, der vor Magnetfeldern geschü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ängigkeit 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 Kontrollgeräts, das den Adapter enthält,
• Einbaudatum des Adapters,
• 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 eingebetteten Bewegungssensors ersichtlich sind):

• Name des Herstellers des eingebetteten Bewegungssensors,
• Teilnummer und Baujahr des eingebetteten Bewegungssensors,
• Prüfzeichen des eingebetteten Bewegungssensors.

5. Einbau des Kontrollgeräts bei Nutzung eines Adapters

5.1. Einbau

ADA_029 Der Einbau von Adaptern in Fahrzeuge darf nur von Fahrzeugherstellern 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 Eingangssignal.

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 angebracht werden, das ihm die Eingangsimpulse bereitstellt.

ADA_033 Die Anschlusskabel für den Adapter müssen rot (Stromversorgung) 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 Bewegungssensor 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 (soweit nach vernünftigem Ermessen möglich) an beiden Enden 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 Anschlüsse,
• Einbau des Adapters gemäß der Angabe auf dem Einbauschild,
• Einbau des Adapters gemäß den Adapter- und/oder Fahrzeugherstellerspezifikationen,
• 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 Zustand 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 Typgenehmigung 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 Kontrollgerät, das einen Adapter einschließt, wird dem Adapterhersteller erst erteilt, nachdem die folgenden Mindestfunktionsprüfungen erfolgreich bestanden wurden:

.

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 aktualisiert werden muss. Damit sie mit der Verwendung von OSNMA beginnen können und alle Anforderungen des Anhang IC und seiner Anlagen 1 bis 16 erfüllen, muss eine geeignete Softwareaktualisierung durchgeführt werden. Vor der Aktualisierung müssen Übergangsfahrzeugeinheiten die OSNMA-bezogenen Funktionen gemäß dieser Anlage implementieren. Funktionen, die nicht mit OSNMA in Zusammenhang stehen, bleiben unverändert.

Mit der geeigneten Softwareaktualisierung implementieren die Übergangsfahrzeugeinheiten die für die Betriebsphase von OSNMA geltenden Leitlinien für OSNMA-Empfänger und das SIS ICD und erfüllen alle Anforderungen des Anhangs IC sowie seiner Anlagen 1 bis 16 unter Verwendung von OSNMA während der Betriebsphase.

Übergangsfahrtenschreiber: Fahrtenschreiber einschließlich einer Übergangsfahrzeugeinheit.

1.2. Akronyme

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 Fahrtenschreibern ausgerüstet werden können, müssen Fahrzeugeinheiten vor der Erklärung der OSNMA-Dienste bauartgenehmigt, hergestellt und vermarktet werden. Für diese Fahrzeugeinheiten, die als Übergangsfahrzeugeinheiten bezeichnet werden, müssen die OSNMA-bezogenen Anforderungen 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 Übergangsfahrtenschreibern

4. Anforderungen an Übergangsfahrzeugeinheiten

Übergangsfahrzeugeinheiten können das in der öffentlichen Prüfphase verfügbare OSNMA-Signal eventuell verarbeiten, sind jedoch nicht in der Lage, den während der Betriebsphase der OSNMA verfügbaren Authentisierungsstatus 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:

5. Besondere Bestimmungen für die Bauartgenehmigung und die Verwendung von Übergangsfahrtenschreibern

.

I. Prüfzeichen ¹⁸

1. Das Prüfzeichen besteht

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

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

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 ¹ sind in Millimetern ausgedrückt und stellen die Mindestabmessungen dar. Die Relationen zwischen diesen Abmessungen müssen eingehalten werden.

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 etwaigen Entzug verwendet jeder Mitgliedstaat Kopien dieses Dokuments.

Typgenehmigungsbogen

Name der zuständigen Behörde ...

Mitteilung betreffend ²:

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

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

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 etwaigen Entzug verwendet jeder Mitgliedstaat Kopien dieses Dokuments.

Typgenehmigungsbogen für digitale Fahrtenschreiber

Name der zuständigen Behörde ...

Mitteilung betreffend ³:

Nr. der Typgenehmigung

...

1. Hersteller- oder Handelsmarke: ...

2. Modellbezeichnung ...

3. Name des Herstellers ...

4. Anschrift des Herstellers ...

5. Zur Typgenehmigung vorgelegt am ...

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 Komponente bestimmt ist

11. Ort ...

12. Datum ...

13. Anlagen (Beschreibungen usw.) ...

14. Bemerkungen (ggf. auch Position von Plomben)

(Unterschrift)

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 etwaigen Entzug verwendet jeder Mitgliedstaat Kopien dieses Dokuments.

Typgenehmigungsbogen für intelligente Fahrtenschreiber

Name der zuständigen Behörde ...

Mitteilung betreffend ³:

Nr. der Typgenehmigung

...

1. Hersteller- oder Handelsmarke: ...

2. Modellbezeichnung ...

3. Name des Herstellers ...

4. Anschrift des Herstellers ...

5. Zur Typgenehmigung vorgelegt am ...

6.

1. Prüflabor für die Funktionszertifizierung ...
2. Prüflabor für die Sicherheitszertifizierung ...
3. Prüflabor für die Interoperabilitätszertifizierung ...

7.

1. Datum und Nummer des Funktionszertifikats ...
2. Datum und Nummer des Sicherheitszertifikats ...
3. 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 Komponente bestimmt ist

11. Ort ...

12. Datum ...

13. Anlagen (Beschreibungen usw.) ...

14. Bemerkungen (ggf. auch Position von Plomben)

(Unterschrift)

ENDE