umwelt-online: Durchführungsverordnung (EU) 2016/799 zur Durchführung der Verordnung (EU) Nr. 165/2014 zur Festlegung der Vorschriften über Bauart, Prüfung, Einbau, Betrieb und Reparatur von Fahrtenschreibern und ihren Komponenten (5)

zurück

.

1. Einleitung

Diese Anlage enthält die technischen Anforderungen für die von der Fahrzeugeinheit verwendeten GNSS-Daten, 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 erfassen, im Sinne der Durchführung von Artikel 8.

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.2. Akronyme und Notationen

In dieser Anlage werden folgende Akronyme verwendet:

2. Spezifikation 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 im Offenen Dienst von Galileo zu unterstützen, sofern dieser Dienst vom Galileo-System erbracht und von den Herstellern der GNSS-Empfänger unterstützt wird. Für intelligente Fahrtenschreiber, die auf den Markt gebracht wurden, bevor die vorstehenden Bedingungen erfüllt sind und die nicht fähig sind, die Authentisierung im Offenen Dienst von Galileo zu unterstützen, ist jedoch keine Nachrüstung vorgeschrieben.

3. NMEA-Datensätze¹⁸

In diesem Abschnitt werden die NMEA-Datensätze beschrieben, die für das Funktionieren des intelligenten Fahrtenschreibers verwendet werden. Dieser Abschnitt gilt für die Konfiguration des intelligenten Fahrtenschreibers sowohl mit als auch ohne externe GNSS-Ausrüstung.

GNS_4 Die Standortdaten 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.1):

Abbildung 2 Struktur des RMC-Datensatzes

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

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

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

Abbildung 3 Struktur des GSA-Datensatzes

GNS_6 Der GSA-Datensatz muss unter der Datensatznummer '02' bis '06' gespeichert werden.

GNS_7 Die maximale Größe der NMEA-Datensätze (z.B. RMC, GSa 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 4):

1. Einen handelsüblichen GNSS-Empfänger, um die Positionsdaten über die GNSS-Datenschnittstelle bereitzustellen. Die GNSS-Datenschnittstelle kann beispielsweise der Norm NMEa V4.10 entsprechen; der GNSS-Empfänger dient dann als Sender und überträgt NMEA-Datensätze an den GNSS Secure Transceiver mit einer Frequenz von 1Hz für die zuvor festgelegten NMEA-Datensätze, die mindestens die RMC- und GSA-Datensätze umfassen müssen. Die Implementierung der GNSS-Datenschnittstelle wählt der Hersteller der externen GNSS-Ausrüstung.
2. 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.
3. 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.
4. 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 drei 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 VU.

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

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

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 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 10 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 VU fordert von der externen GNSS-Ausrüstung die Standortdaten samt DOP-Daten an (aus dem GSa NMEA-Datensatz). Der VU Secure Transceiver verwendet die Befehle SELECT und READ RECORD(S) 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 und den Datensatznummern '02', '03', '04', '05' und '06' für den GSa NMEA-Datensatz.
2. Die zuletzt empfangenen Standortdaten 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 VU Secure Transceiver, indem er die APDU-Antwortnachricht im Secure Messaging (reiner Authentisierungsmodus) verwendet, wie in Anlage 11 Abschnitt 11.5 beschrieben.
4. Der VU Secure Transceiver prüft die Authentizität und Integrität der erhaltenen Antwort. Im Falle eines positiven Ergebnisses werden die Standortdaten über die GNSS-Datenschnittstelle an den VU-Prozessor übertragen.
5. Der VU-Prozessor prüft die empfangenen Daten, indem er die Informationen (z.B. Breite, Länge, Zeit) aus dem RMC NMEA-Datensatz extrahiert. Der RMC NMEA-Datensatz gibt Auskunft darüber, ob die Position gültig ist. Wenn die Position nicht gültig ist, sind die Standortdaten noch nicht verfügbar und können nicht zur Aufzeichnung der Fahrzeugposition verwendet werden. Wenn die Position gültig ist, extrahiert der VU-Prozessor auch die HDOP-Werte aus den GSa NMEA-Datensätzen und berechnet den Mindestwert für das verfügbare Satellitensystem (z.B. wenn die Ortung verfügbar ist).
6. Der VU-Prozessor speichert die empfangenen und verarbeiteten Informationen wie Breite, Länge, Zeit und Geschwindigkeit in der VU, in dem in Anlage 1 (Datenglossar) definierten Format als GeoCoordinates, zusammen mit dem HDOP-Wert, der als kleinster der in den verfügbaren GNSS-Systemen erfassten HDOP-Werte berechnet wurde.

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 '6a 83' zurück.
• Wenn die externe GNSS-Ausrüstung eine Manipulation erkannt hat, muss sie die Statusbytes '66 90' zurücksenden.

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

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 seinen gesamten Speicher löschen, einschließlich des kryptografischen Materials. Gemäß GNS_25 und GNS_26 muss die VU einen Eingriff erkennen, wenn die Antwort den Status '6690' aufweist. Die VU generiert dann ein Ereignis des Typs EventFault type Enum '19'H Tamper detection of GNSS (Manipulationserkennung beim GNSS). Alternativ kann die externe GNSS-Ausrüstung auch auf keine externen Anfragen mehr antworten.

4.4.3 Fehlende Positionsdaten des GNSS-Empfängers¹⁸

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

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

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

Abbildung 4 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 Der GNSS-Empfänger dient als Sender und überträgt NMEA-Datensätze an den als Empfänger dienenden VU-Prozessor mit einer Frequenz von mindestens 1/10 Hz für die zuvor festgelegten NMEA-Datensätze, die mindestens die RMC- und GSA-Datensätze umfassen müssen.

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

5.2. Fehlerbehandlung

5.2.1 Fehlende Positionsdaten des GNSS-Empfängers¹⁸

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

6. GNSS-Zeitkonflikt¹⁸

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

7. Datenkonflikt Fahrzeugbewegung

GNS_35 Die VU muss einen Datenkonflikt Fahrzeugbewegung (siehe Randnummer 84 in diesem Anhang) mit einem Zeitstempel der aktuellen Zeit auslösen und aufzeichnen, falls die vom Bewegungssensor errechneten Bewegungsdaten von den vom internen GNSS-Empfänger oder der externen GNSS-Ausrüstung errechneten Bewegungsdaten abweicht. Zur Erfassung derartiger Abweichungen wird der Medianwert der Geschwindigkeitsdifferenzen zwischen den verschiedenen Quellen gemäß folgender Erläuterung verwendet:

• 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 fünf Minuten, in denen Bewegung stattgefunden hat, umfassenden Zeitfenster berechneten Werte werden herangezogen, um den Medianwert zu errechnen.
• Der Medianwert wird als Durchschnitt von 80 % der übrigen Werte berechnet, nachdem die höchsten Absolutwerte ausgeschlossen wurden.

Der Datenkonflikt Fahrzeugbewegung wird ausgelöst, wenn der Medianwert ununterbrochen für fünf Minuten, in denen Bewegung stattfindet, über 10 km/h liegt. Fakultativ können andere unabhängige Quellen für die Ermittlung von Fahrzeugbewegungsdaten herangezogen werden, um eine noch verlässlichere Erkennung der Manipulation des Fahrtenschreibers zu gewährleisten. (Hinweis: Der Medianwert der letzten 5 Minuten wird verwendet, um dem Risiko von Messausreißern und transienter Messwerte mindern.) Dieses Ereignis darf nicht ausgelöst werden, wenn folgende Bedingungen erfüllt sind: a) während einer Fährüberfahrt/Zugfahrt, b) wenn die Positionsinformation vom GNSS-Empfänger nicht verfügbar ist und c) der Kalibrierungsmodus aktiv ist.

_______

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

In dieser Anlage werden das Design und die Verfahren spezifiziert, die bei der Umsetzung der Schnittstelle zu intelligenten Verkehrssystemen (ITS), wie in Artikel 10 der Verordnung (EU) Nr. 165/2014 (die Verordnung) vorgeschrieben, eingehalten werden müssen.

In der Verordnung wird festgelegt, dass Fahrtenschreiber von Fahrzeugen mit genormten Schnittstellen ausgerüstet werden können, die im Betriebsmodus die Nutzung der vom Fahrtenschreiber aufgezeichneten oder erzeugten Daten durch externe Geräte ermöglichen, sofern die folgenden Voraussetzungen erfüllt sind:

1. Die Schnittstelle beeinträchtigt die Authentizität und Integrität der Daten des Fahrtenschreibers nicht.
2. Die Schnittstelle entspricht den Einzelvorschriften nach Artikel 11 der Verordnung.
3. Das an die Schnittstelle angeschlossene externe Gerät kann auf personenbezogene Daten, einschließlich Ortsbestimmungsdaten, nur zugreifen, wenn der Fahrer, auf den sich die Daten beziehen, nachweisbar seine Zustimmung erteilt hat.

2. Anwendungsbereich¹⁸

In dieser Anlage soll festgelegt werden, wie Anwendungen, die auf externen Geräten gehostet werden, mittels Bluetooth®-Verbindung Daten (die Daten) von einem Fahrtenschreiber abrufen können.

Die Daten, die über diese Schnittstelle zur Verfügung stehen, sind in Anhang 1 des vorliegenden Dokuments beschrieben. Diese Schnittstelle verbietet es nicht, sonstige Schnittstellen (z.B. per CAN-Bus) zu implementieren, mit denen die Daten der VU auf andere Fahrzeugverarbeitungseinheiten übertragen werden.

In dieser Anlage wird Folgendes festgelegt:

• Die Daten, die über die ITS-Schnittstelle zur Verfügung gestellt werden
• Das Bluetooth®-Profil, das für die Datenübertragung genutzt wird
• Die Abfrage- und Downloadverfahren sowie die Sequenz der Operationen
• Den Koppelungsmechanismus zwischen Fahrtenschreiber und externem Gerät
• Den Zustimmungsmechanismus, der dem Fahrer zur Verfügung steht

Folgendes wird in dieser Anlagenicht spezifiziert:

• Erfassung und Verwaltungder Daten innerhalb der VU (dies ist an anderer Stelle inder Verordnung festgelegt oder ergibt sich aus dem Produktdesign).
• Die Darstellungsform der erfassten Daten gegenüber der auf dem externen Gerät gehosteten Anwendung.
• Datensicherheitsbestimmungen, die über Bluetooth® hinausgehen (wie beispielsweise Verschlüsselung) und den Inhaltder Daten betreffen (diese werden an anderer Stelleder Verordnung spezifiziert [Anlage 11 Gemeinsame Sicherheitsmechanismen]).
• Die Bluetooth®-Protokolle, die durch die ITS-Schnittstelle genutzt werden.

2.1. Akronyme, Definitionen und Notationen

Folgende für diese Anlage spezifische Akronyme und Definitionen werden in dieser Anlage verwendet:

3. Referenzierte Verordnungen und Normen

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.

Auf folgende Verordnungen und Normen wird in dieser Anlage Bezug genommen:

• 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
• 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.
• ISO 16844-4: Road vehicles - Tachograph systems - Part 4: Can interface (Straßenfahrzeuge - Fahrtschreiber (Kontrollgeräte) - Teil 4: CAN-Schnittstelle)
• ISO 16844-7: Road vehicles - Tachograph systems - Part 7: Parameters (Straßenfahrzeuge - Fahrtschreiber (Kontrollgeräte) - Teil 7: Parameter).
• Bluetooth® - Serial Port Profile - V1.2
• Bluetooth® - Core Version 4.2
• NMEa 0183 Protokoll V4.1

4. Funktionsprinzipien der Schnittstelle

4.1. Voraussetzungen für den Datentransfer über die ITS-Schnittstelle

Die VU ist dafür verantwortlich, die in ihr zu speichernden Daten ohne Einbeziehung der ITS-Schnittstelle zu aktualisieren und auf dem neusten Stand zu halten. Die Mittel, durch die dies erreicht wird, sind VU-intern und werden anderweitig in der Verordnung spezifiziert; diese Anlage enthält keine entsprechende Spezifikation.

4.1.1 Die Daten, die über die ITS-Schnittstelle zur Verfügung gestellt werden

Die VU ist dafür verantwortlich, die Daten in regelmäßigen Abständen, die in den VU-Verfahren festgelegt sind, ohne Einbeziehung der ITS-Schnittstelle zu aktualisieren. Die VU-Daten dienen als Grundlage zur Einspeisung und Aktualisierungder Daten; die Mittel, durch die dies erreicht wird, werden anderweitig inder Verordnung spezifiziert oder, wenn keine entsprechende Spezifikation vorliegt, sind abhängig vom Produktdesign; sie werden nicht in dieser Anlage spezifiziert.

4.1.2 Inhalt der Daten

Der Inhaltder Daten entspricht den Festlegungen aus Anhang 1 dieser Anlage.

4.1.3 ITS-Anwendungen

ITS-Anwendungen nutzen die über die ITS-Schnittstelle bereitgestellten Daten beispielsweise zur Optimierung der Verwaltung der Fahrertätigkeiten unter Einhaltung der Verordnung, zur Feststellung möglicher Störungen des Fahrtenschreibers oder zur Verwendung der GNSS-Daten. Die Spezifikation der Anwendungen fällt nicht in den Aufgabenbereich dieser Anlage.

4.2. Kommunikationseinrichtung¹⁸

Der Austauschder Daten mittels der ITS-Schnittstelle erfolgt über eine Bluetooth®-Schnittstelle, die mit Version 4.2 oder höher kompatibel ist. Bluetooth® wird im lizenzfreien ISM-Band (Industrial, Scientific and Medical Band) zwischen 2,4 und 2,485 GHz betrieben. Bluetooth® 4.2 bietet verbesserte Datenschutz- und Sicherheitsmechanismen und steigert sowohl Geschwindigkeit als auch Zuverlässigkeit von Datenübertragungen. Für die Zwecke dieser Spezifikation wird ein Bluetooth®-Gerät der Klasse 2 mit einer Reichweite bis zu 10 Metern genutzt. Weitere Informationen zu Bluetooth® 4.2 finden sich unter www.bluetooth.com (https://www.bluetooth.org/en-us/specification/adopted-specifications?_ga=1.215147412.2083380574.1435305676).

DieKommunikation mit der Kommunikationseinrichtung wird nach Abschluss eines Koppelungsprozesses durch ein autorisiertes Gerät aufgebaut. Da bei Bluetooth® über ein Master/Slave-Modell gesteuert wird, wann und wo Geräte Daten senden können, übernimmt der Fahrtenschreiber die Master-Rolle, während dem externen Gerät die Slave-Rolle zugewiesen wird.

Kommt ein externes Gerät erstmalig in den Sendebereich der VU, kann der Bluetooth®-Koppelungsprozess begonnen werden (siehe auch Anhang 2). Die Geräte tauschen ihre Adressen, Namen, Profile sowie einen gemeinsamen geheimen Schlüssel aus, was es ihnen ermöglicht, sich zukünftig miteinander zu verbinden, wenn sie sich in Reichweite befinden. Nach Abschluss dieses Schritts wird dem externen Gerät vertraut und es kann Datendownloads vom Fahrtenschreiber veranlassen. Zusätzliche Verschlüsselungsmechanismen, die über die Funktionen von Bluetooth® hinausgehen, sind nicht vorgesehen. Sollten allerdings zusätzliche Sicherheitsmaßnahmen erforderlich sein, so müssen diese Anlage 11 Gemeinsame Sicherheitsmechanismen entsprechen.

Das typische Kommunikationsprinzip ist in der folgenden Abbildung dargestellt:

Für die Datenübertragung von der VU auf das externe Gerät wird das SPP (Serial Port Profile) von Bluetooth® genutzt.

4.3. PIN-Autorisierung¹⁸

Aus Sicherheitsgründen verlangt die VU ein Autorisierungssystem mittels PIN-Code, das von der Bluetooth-Koppelung getrennt ist. Jede VU muss PIN-Codes mit einer Länge von mindestens 4 Ziffern zur Authentisierung erzeugen können. Jedes Mal, wenn ein externes Gerät eine Koppelung mit der VU vornimmt, muss der korrekte PIN-Code angegeben werden, bevor es Daten empfängt.

Bei erfolgreicher Eingabe der PIN wird das Gerät auf die Whitelist gesetzt. Die Whitelist muss mindestens 64 mit der gegebenen VU gekoppelte Geräte speichern können.

Wird der PIN-Code dreimal hintereinander falsch eingegeben, wird das Gerät vorübergehend auf die Blacklist gesetzt. Solange es sich auf der Blacklist befindet, wird jeder neue Versuch des Geräts zurückgewiesen. Bei wiederholter dreifacher Fehleingabe des PIN-Codes verlängert sich die Sperrzeit zunehmend (siehe Tabelle 1). Durch die Eingabe des korrekten PIN-Codes werden die Sperrzeit und die Anzahl an Versuchen zurückgesetzt. Abbildung 1 in Anhang 2 zeigt das Ablaufdiagramm eines PIN-Validierungsversuchs.

Tabelle 1: Sperrzeit in Abhängigkeit der Menge der Fehleingaben des PIN-Codes in Folge

Wird der PIN-Code fünfzehnmal hintereinander (5 x 3) falsch eingegeben, wird die ITS-Einheit dauerhaft auf die Blacklist gesetzt. Eine dauerhafte Sperrung kann nur durch Eingabe des korrekten PUC-Codes aufgehoben werden.

Der PUC-Code besteht aus 8 Ziffern und wird zusammen mit der VU durch den Hersteller bereitgestellt. Bei zehnmaliger Fehleingabe des PUC-Codes in Folge wird die ITS-Einheit unwiderruflich auf die Blacklist gesetzt.

Der Hersteller kann es optional ermöglichen, den PIN-Code direkt über die VU zu ändern, der PUC-Code jedoch muss unabänderlich sein. Besteht die Möglichkeit zur Änderung des PIN-Codes, so muss der aktuelle PIN-Code direkt in der VU eingegeben werden.

Darüber hinaus müssen alle Geräte in der Whitelist gespeichert bleiben, bis der Benutzer sie manuell entfernt (beispielsweise über die Mensch-Maschine-Schnittstelle der VU oder mit anderen Mitteln). Verlorene oder gestohlene ITS-Einheiten können dabei von der Whitelist entfernt werden. Ebenso müssen alle ITS-Einheiten, die den Bluetooth-Verbindungsbereich für mehr als 24 Stunden verlassen, automatisch aus der Whitelist der VU gelöscht werden und beim nächsten Verbindungsaufbau erneut den korrekten PIN-Code angeben.

Das Format der Nachrichten zwischen der VU-Schnittstelle und der VU ist nicht vorgegeben, sondern kann vom Hersteller festgelegt werden. Letzterer muss allerdings sicherstellen, dass das Nachrichtenformat zwischen der ITS-Einheit und der VU-Schnittstelle eingehalten wird (siehe ASN.1-Spezifikationen).

Bei allen Datenanforderungen müssen die Sicherheitsangaben des Senders vor jeglicher Verarbeitung ordnungsgemäß verifiziert werden. Abbildung 2 von Anhang 2 zeigt das Ablaufdiagramm für dieses Verfahren. Alle Geräte auf der Blacklist müssen automatisch abgelehnt werden; Geräte, die weder auf der Blacklist noch auf der Whitelist verzeichnet sind, müssen eine PIN-Aufforderung erhalten, der das betreffende Gerät entsprechen muss, bevor es die Datenanforderung erneut senden kann.

4.4. Nachrichtenformat¹⁸

Alle zwischen ITS-Gerät und der VU-Schnittstelle ausgetauschten Nachrichten sind mit einer dreiteiligen Struktur formatiert, die sich zusammensetzt aus dem Kopf, bestehend aus einem Zielbyte (TGT), einem Quellbyte (SRC) und einem Längenbyte (LEN),

dem Datenfeld, bestehend aus einem Service-Identifier-Byte (SID) und einer variablen Anzahl von Datenbytes (maximal 255).

Das Prüfsummenbyte ist die 1-Byte-Summenreihe modulo 256 aller Bytes der Nachricht außer CS selbst.

Die Nachricht muss dem Big-Endian-Format entsprechen.

Tabelle 2: Allgemeines Nachrichtenformat

Kopf

TGT und SRC: die Kennung der Ziel- (TGT) und Quellgeräte (SRC) der Nachricht. Die Standardkennung der VU-Schnittstelle lautet "EE" und kann nicht geändert werden. Für ihre erste Nachricht des Kommunikationsvorgangs nutzt die ITS-Einheit die Standardkennung "A0". Anschließend weist die VU-Schnittstelle der ITS-Einheit eine eindeutige Kennung zu und setzt die ITS-Einheit für zukünftige Nachrichten im Verlauf des Vorgangs über diese Kennung in Kenntnis.

Das LEN-Byte berücksichtigt nur den "DATA"-Teil des Datenfelds (siehe Tabelle 2), die ersten 4 Bytes sind impliziert.

Die VU-Schnittstelle bestätigt die Authentizität des Senders der Nachricht durch Gegenkontrolle der eigenen IDList anhand der Bluetooth-Daten, indem sie überprüft, ob sich die ITS-Einheit, die unter der angegebenen Kennung eingetragen ist, aktuell innerhalb der Reichweite der Bluetooth-Verbindung befindet.

Datenfeld

Neben der SID enthält das Datenfeld weitere Parameter: einen Anfrageübertragungsparameter (Transfer Request Parameter, TRTP) sowie Zählbytes.

Falls mehr Daten zu verarbeiten sind als Raum in einer Einzelnachricht zur Verfügung steht, werden sie in mehrere Teilnachrichten aufgeteilt. Jede Teilnachricht weist den gleichen Kopf und die gleiche SID auf, enthält aber einen 2-Byte-Zähler, d. h. Counter Current (CC) und Counter Max (CM), zur Angabe der Teilnachrichtnummer. Damit Fehlerprüfung und Abbruch möglich sind, bestätigt das Empfangsgerät jede Teilnachricht. Das Empfangsgerät kann die Teilnachricht annehmen, ihre erneute Übertragung anfordern sowie das Sendegerät zum Neubeginn oder zum Abbruch der Übertragung auffordern.

Bei Nichtverwendung wird CC und CM der Wert 0xFF zugewiesen.

Beispielsweise wird die nachstehende Nachricht

wie folgt übertragen:

...

Tabelle 3 enthält die Nachrichten, die die VU und die ITS-Einheit austauschen können sollen. Der Inhalt jedes Parameters ist als Hexadezimalwert angegeben. Zur besseren Übersichtlichkeit sind CC und CM in dieser Tabelle nicht angegeben. Für das vollständige Format siehe oben.

Tabelle 3: Detaillierter Inhalt der Nachricht

RequestPIN (SID 01)

Diese Nachricht wird durch die VU-Schnittstelle ausgegeben, wenn eine ITS-Einheit, die weder auf der Whitelist noch auf der Blacklist eingetragen ist, eine Datenanforderung sendet.

SendITSID (SID 02)

Diese Nachricht wird durch die VU-Schnittstelle immer dann ausgegeben, wenn ein neues Gerät eine Anforderung sendet. Dieses Gerät verwendet die Standardkennung "A0", bevor ihm für den Kommunikationsvorgang eine eindeutige Kennung zugewiesen wird.

SendPIN (SID 03)

Diese Nachricht wird durch die ITS-Einheit ausgegeben, um durch die VU-Schnittstelle auf die Whitelist gesetzt zu werden. Beim Inhalt dieser Nachricht handelt es sich um einen aus 4 Ganzzahlen zwischen 0 und 9 bestehenden Code.

PairingResult (SID 04)

Diese Nachricht wird durch die VU-Schnittstelle ausgegeben, um die ITS-Einheit darüber in Kenntnis zu setzen, ob der übermittelte PIN-Code korrekt war. Beim Inhalt der Nachricht handelt es sich um eine boolesche Variable mit dem Wert "True", wenn der PIN-Code korrekt war, und andernfalls mit dem Wert "False".

SendPUC (SID 05)

Diese Nachricht wird durch die ITS-Einheit ausgegeben, um von der der Blacklist der VU-Schnittstelle gelöscht zu werden. Beim Inhalt dieser Nachricht handelt es sich um einen aus 8 Ganzzahlen zwischen 0 und 9 bestehenden Code.

BanLiftingResult (SID 06)

Diese Nachricht wird durch die VU-Schnittstelle ausgegeben, um die ITS-Einheit darüber in Kenntnis zu setzen, ob der übermittelte PUC-Code korrekt war. Beim Inhalt der Nachricht handelt es sich um eine boolesche Variable mit dem Wert "True", wenn der PUC-Code korrekt war, und andernfalls mit dem Wert "False".

RequestRejected (SID 07)

Diese Nachricht wird durch die VU-Schnittstelle als Antwort auf alle Nachrichten einer auf der Blacklist befindlichen ITS-Einheit mit Ausnahme von "SendPUC" ausgegeben. In der Nachricht wird angegeben, wie lange die ITS-Einheit noch auf der Blacklist verbleibt; dies geschieht im Sequenzformat "Zeit" gemäß Anhang 3.

RequestData (SID 08)

Diese Nachricht für den Zugriff auf Daten wird durch die ITS-Einheit ausgegeben. Mit dem Byte Transfer Request Parameter (TRTP) wird der benötigte Datentyp angegeben. Es gibt verschiedene Datentypen:

• standardTachData (TRTP 01): als nicht persönlich eingestufte, vom Fahrtenschreiber verfügbare Daten.
• personalTachData (TRTP 02): als persönlich eingestufte, vom Fahrtenschreiber verfügbare Daten.
• gnssData (TRTP 03): GNSS-Daten (immer persönlich).
• standardEventData (TRTP 04): als nicht persönlich eingestufte Daten zu aufgezeichneten Ereignissen.
• personalEventData (TRTP 05): als persönlich eingestufte Daten zu aufgezeichneten Ereignissen.
• standardFaultData (TRTP 06): als nicht persönlich eingestufte Daten zu aufgezeichneten Störungen.
• manufacturerData (TRTP 07): durch den Hersteller zur Verfügung gestellte Daten.

Für weitere Informationen zu den Inhalten jedes Datentyps siehe Anhang 3 dieser Anlage.

Nähere Informationen zum Format und Inhalt der GNSS-Daten entnehmen Sie Anlage 12.

Siehe Anhang IB und IC für weitere Informationen zu Ereignisdatencodes und Störungen.

RequestAccepted (SID 09)

Diese Nachricht wird durch die VU-Schnittstelle ausgegeben, wenn die "RequestData"-Nachricht einer ITS-Einheit akzeptiert wurde. Diese Nachricht beinhaltet einen 1-Byte-TREP, nämlich das TRTP-Byte der zugehörigen RequestData-Nachricht, sowie alle Daten des angeforderten Typs.

DataUnavailable (SID 0A)

Diese Nachricht wird durch die VU-Schnittstelle ausgegeben, wenn aus bestimmten Gründen die angeforderten Daten nicht zur Übermittlung an eine auf der Whitelist befindliche ITS-Einheit verfügbar sind. Diese Nachricht beinhaltet einen 1-Byte-TREP (den TRTP der angeforderten Daten) sowie einen der in Tabelle 3 aufgeführten 1-Byte-Fehlercodes. Folgende Codes stehen zur Verfügung:

• No data available (10): Die VU-Schnittstelle kann aus nicht näher angegebenen Gründen nicht auf die VU-Daten zugreifen.
• Personal data not shared (11): Die ITS-Einheit versucht, persönliche Daten abzurufen, die nicht freigegeben sind.

NegativeAnswer (SID 0B)

Diese Nachrichten werden durch die VU-Schnittstelle ausgegeben, wenn eine Anfrage aus einem anderen Grund als der Nichtverfügbarkeit der Daten nicht erfüllt werden kann. Ursache für diese Art von Nachrichten sind im Allgemeinen - aber nicht immer - fehlerhafte Anfrageformate (Länge, SID, ITSID ...). Der TRTP im Datenfeld beinhaltet die SID der Anfrage. Das Datenfeld enthält einen Code zur Identifizierung des Grunds für eine negative Antwort. Folgende Codes stehen zur Verfügung:

• General Reject (Code: 10)
• Die Aktion ist aus einem Grund nicht möglich, der weder unten noch in Abschnitt (Nummer des AbschnittsDataUnavailable eintragen) angegeben ist.
• Service not supported (Code: 11)
• Die SID der Anfrage wird nicht verstanden.
• Sub function not supported (Code: 12)
• Der TRTP der Anfrage wird nicht verstanden. Möglicherweise fehlt er oder liegt außerhalb der akzeptierten Werte.
• Incorrect message length (Code: 13)
• Die Länge der erhaltenen Nachricht ist nicht korrekt (Abweichung zwischen dem LEN-Byte und der tatsächlichen Nachrichtenlänge).
• Conditions not correct or request sequence error (Code: 22)
• Der angeforderte Dienst ist nicht aktiv, oder die Reihenfolge der Anforderungsnachrichten ist nicht korrekt.
• Request out of range (Code: 33)
• Der Parameterdatensatz der Anforderung (Datenfeld) ist ungültig.
• Response pending (Code: 78)
• Die angeforderte Aktion kann nicht rechtzeitig abgeschlossen werden, und die VU ist nicht bereit, eine weitere Anforderung anzunehmen.
• ITSID Mismatch (Code: FB)
• Die SRCITSID stimmt nach Abgleich mit den Bluetooth-Informationen nicht mit dem zugehörigen Gerät überein.
• ITSID Not Found (Code: FC)
• Die SRCITSID ist keinem Gerät zugewiesen.

In den Zeilen 1 bis 72 ( FormatMessageModule) des ASN.1-Codes in Anhang 3 wird das Nachrichtenformat wie in Tabelle 3 beschrieben spezifiziert. Nähere Angaben zum Nachrichteninhalt werden weiter unten gemacht.

4.5. Zustimmung des Fahrers

Alle verfügbaren Daten werden als allgemein oder persönlich klassifiziert. Auf persönliche Daten darf nur zugegriffen werden, wenn das Einverständnis des Fahrers vorliegt, dass die persönlichen Daten des Fahrtenschreibers das Fahrzeugnetzwerk zugunsten von Drittanbieteranwendungen verlassen dürfen.

Die Zustimmung des Fahrers wird beim ersten Einstecken einer bestimmten Fahrer- oder Werkstattkarte gegeben, die der Fahrzeugeinheit zu diesem Zeitpunkt unbekannt ist; hierzu wird der Karteninhaber aufgefordert, der Ausgabe persönlicher Fahrtenschreiberdaten über die optionale ITS-Schnittstelle zuzustimmen (siehe auch Anhang IC Abschnitt 3.6.2).

Der Zustimmungsstatus (aktiviert/deaktiviert) wird im Speicher des Fahrtenschreibers aufgezeichnet.

Bei mehreren Fahrern werden nur die persönlichen Daten derjenigen Fahrer mit der ITS-Schnittstelle ausgetauscht, die hierzu ihre Zustimmung gegeben haben. Gibt es beispielsweise zwei Fahrer für ein Fahrzeug und hat nur einer von ihnen zugestimmt, dass seine persönlichen Daten weitergegeben werden, so werden die persönlichen Daten des anderen Fahrers nicht weitergegeben.

4.6. Abrufen allgemeiner Daten

Abbildung 3 von Anhang 2 zeigt die Ablaufdiagramme einer gültigen Anforderung seitens der ITS-Einheit für den Zugriff auf allgemeine Daten. Die ITS-Einheit ist ordnungsgemäß auf der Whitelist eingetragen und fordert keine persönlichen Daten an, weshalb keine weitere Verifizierung erforderlich ist. Die Diagramme setzen voraus, dass das in Abbildung 2 von Anhang 2 dargestellte korrekte Verfahren bereits befolgt wurde. Sie entsprechen dem grauen KastenREQUEST TREATMENT (Verarbeitung anfordern) in Abbildung 2.

Unter den verfügbaren Daten gelten folgende Daten als allgemein:

• standard TachData (TRTP 01)
• Standard EventData (TRTP 04)
• standardFaultData (TRTP 06)

4.7. Abrufen persönlicher Daten

Abbildung 4 von Anhang 2 zeigt das Ablaufdiagramm die Verarbeitung von Anfragen zu persönlichen Daten. Wie bereits angegeben, übermittelt die VU-Schnittstelle nur dann persönliche Daten, wenn der Fahrer hierzu seine ausdrückliche Zustimmung gegeben hat (siehe auch 4.5). Andernfalls muss die Anforderung automatisch zurückgewiesen werden.

Unter den verfügbaren Daten gelten folgende Daten als persönlich:

• personalTachData (TRTP 02)
• gnssData (TRTP 03)
• personalEventData (TRTP 05)
• manufacturerData (TRTP 07)

4.8. Abrufen von Ereignis- und Störungsdaten

ITS-Einheiten müssen Ereignisdaten anfordern können, die die Liste aller unerwarteten Ereignisse beinhalten. Diese Daten gelten als allgemein oder persönlich, siehe Anhang 3. Der Inhalt jedes Ereignisses entspricht der in Anhang 1 dieser Anlage bereitgestellten Dokumentation.

.

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_2Die Daten sind unter Verwendungder 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_3Die 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ätder Daten ist zu schützen.

DSC_5 Der Zugang zu den übertragenenDaten 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 Beider 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, indemdie 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 überdie Kommunikation weitergegebenen Daten zu verstehen und ihre Authentizität zu überprüfen. Siehe Anlage 11, Gemeinsame Sicherheitsmechanismen.

DSC_8Die 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 überdie 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 dieKommunikation 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 zurKommunikation genutzten Kommunikationsgeräte, -verfahren und -protokolle
• die Normen und Verordnungen, die die Funkgeräte erfüllen müssen
• die Art, wiedie Daten demKommunikationsgerät präsentiert werden
• die Abfrage- und Downloadverfahren sowie die Sequenz der Operationen
• die zu übertragendenDaten
• die mögliche Auslegung der überdie Kommunikation übertragenen Daten
• die Bestimmungen zu Sicherheitsdaten im Zusammenhang mit derKommunikation
• die Verfügbarkeit der Daten für die zuständigen Kontrollbehörden
• die Art und Weise, wie dasFernabfragegerät unterschiedliche Datenkonzepte für Fracht und Flotten abfragen kann

Folgendes wird in dieser Anlagenicht 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: Durchdie Kommunikation werden den zuständigen Kontrollbehörden lediglichdie Daten zur Verfügung gestellt, auf deren Grundlagesie fundierte Entscheidungen treffen können.
• Datensicherheitsbestimmungen (wie beispielsweise Verschlüsselung), die den Inhaltder 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 Aktualisierungder 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-FunktionVUPM weitergeleitet.VUSM undVUPM 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 (Sicherheitsdaten), die die vomREDCR benötigten Daten zur Erfüllung seiner Aufgabe, die Daten zu entschlüsseln, enthalten, müssen gemäß Anlage 11 Gemeinsame Sicherheitsmechanismen bereitgestellt und als ein Datenkonzeptwert zur vorübergehenden Speicherung in derDSRC-VU als aktuelle Version derSicherheitsdaten in der in dieser Anlage Abschnitt 5.4.4 definierten Form präsentiert 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, oderdas 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 derDSRC-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 Inhaltder 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, welchedie Kommunikation mit der DSRC-VU in Überstimmung dieser Anlage gewährleisten.
• Das DSRC-REDCR fragt dieDSRC-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 vonREDCR 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 desREDCR 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 derDSRC-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 dieDSRC-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 bereitetdie 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 erfasstenDaten sind wie in 5.4.4 bis 5.4.5 unten dargelegt zu formatieren.
2. Jedes Mal, wenndie 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, wenndie 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 DateinamensRTMData 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 demSM-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 demDSRC-VU des anvisierten Fahrzeugs eine 5,8-GHz-DSRC-Schnittstellensitzung und fordertdie Daten an.Die Daten werden über das Drahtloskommunikationssystem als DSRC-Attribut mithilfe des Anwendungsdienstes GET gemäß 5.4 andas REDCR übermittelt. Das Attribut enthält die verschlüsselten Nutzdatenwerte und die DSRC-Sicherheitsdaten.
7. Die Daten werden durch dasREDCR-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ürfendie 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 derREDCR-Antenne ergibt sich aus dem kommerziellen Design, innerhalb der in 5.3.2 definierten Grenzen und angepasst zur Optimierung der Leseleistung desDSRC-REDCR für spezielle Zwecke und Lesebedingungen, innerhalb derer dasREDCR betrieben wird.

5.3.3.2. VU-Antenne

DSC_31 Das Design derDSRC_VU-Antenne ergibt sich aus dem kommerziellen Design, innerhalb der in 5.3.2 definierten Grenzen und angepasst zur Optimierung der Leseleistung desDSRC-REDCR für spezielle Zwecke und Lesebedingungen, innerhalb derer dasREDCR 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 Herunterladender 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. DasREDCR 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). DieDSRC-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 dasREDCR nicht AID="2" anbietet, soll die DSRC-VU dem REDCR nicht antworten.
• Schritt 2 DieDSRC-VU sendet einen Frame mit einer Anfrage nach Zuweisung eines privaten Fensters.
• Schritt 3 DieREDCR sendet einen Frame mit Zuweisung eines privaten Fensters.
• Schritt 4 DieDSRC-VU sendet mithilfe des zugewiesenen privaten Fensters einen Frame mit ihrer Fahrzeugdiensttabelle (Vehicle Service table, VST). Diese VST enthält eine Liste aller unterschiedlichen Anwendungsinstanziierungen, die dieseDSRC-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 dasREDCR 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 DieDSRC-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 AttributRtmData (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 DasREDCR bestätigt den Erhalt der Daten, indem es einen Frame sendet, der derDSRC-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 dieDSRC-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 denDaten zu senden. Ziel des GET-Befehls ist es, dass dasREDCR die Daten von der DSRC-VU erhält.
• GET.response: Antwort der DSRC-VU mit den angeforderten Daten.
• ACTION.request ECHO: Befehl, der dieDSRC-VU anweist, die von derDSRC-VU erhaltenen Daten an dasREDCR 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 derDSRC-VU mitteilt, dass die Transaktion beendet ist. Ziel des RELEASE-Befehls ist es, die Sitzung mit derDSRC-VU zu beenden. Bei Erhalt von RELEASE darf dieDSRC-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¹⁸

(1) RTM-Datenelement	(2) Von der VU durchzuführende Aktion		(3) ASN.1- Datendefinition
RTM1 Kennzeichen des Fahrzeugs	Die VU legt den Wert destp15638vehicleRegistrationPlate- Datenelements RTM1 aus dem aufgezeichneten Wert des DatentypsVehicleRegistrationIdentification gemäß Anlage 1VehicleRegistrationIdentification	Amtliches Kennzeichen des Fahrzeugs als Zeichenstring
RTM2 Geschwindigkeits- überschreitung	Die VU erstellt einen booleschen Wert für das Datenelement RTM2 tp15638Speeding Event. Der Wert tp15638Speeding Event wird von der VU anhand der in der VU verzeichneten Anzahl an Geschwindigkeitsüberschreitungen an einem der letzten 10 Tage des Auftretens gemäß Definition in Anhang 1C berechnet. Wenn es in den letzten 10 Tagen des Auftretens mindestens ein tp15638Speeding Event gab, wird der Wert tp15638Speeding Event auf TRUE gesetzt. ELSE: Wenn es in den letzten 10 Tagen des Auftretens keine Ereignisse gab, wird tp15638Speeding Event auf FALSE gesetzt.	1 (TRUE) - Gibt "irregularities in speed" in den letzten 10 Tagen des Auftretens an
RTM3 Fahren ohne gültige Karte	Die VU erstellt einen booleschen Wert für das Datenelement RTM3 tp15638Driving WithoutValid Card. Die VU weist der Variablen tp15638Driving WithoutValid Card den Wert TRUE zu, wenn die VU in den letzten 10 Tagen des Auftretens mindestens ein Ereignis des Typs "Fahren ohne gültige Karte" gemäß Anhang 1C aufgezeichnet hat. ELSE: Wenn es in den letzten 10 Tagen des Auftretens keine Ereignisse gab, wird die Variable tp15638Driving WithoutValid Card auf FALSE gesetzt.	1 (TRUE) = gibt "invalid card usage1" an
RTM4 Gültige Fahrerkarte	Die VU erstellt einen booleschen Wert für das Datenelement RTM4 tp15638Driver Card auf Grundlage der in der VU gespeicherten Daten und gemäß Anlage 1. Wenn keine Fahrerkarte vorhanden ist, muss die VU die Variable auf TRUE setzen ELSE: Wenn eine gültige Fahrerkarte vorhanden ist, setzt die VU die Variable auf FALSE	0 (FALSE) = Gibt Gültige Fahrerkarte
RTM5 Einstecken der Karte während des Lenkens	Die VU generiert einen booleschen Wert für das Datenelement RTM5. Die VU weist der Variablen tp15638CardInsertion den Wert TRUE zu, wenn die VU in den letzten 10 Tagen des Auftretens mindestens ein Ereignis des Typs "Einstecken der Karte während des Lenkens" gemäß Anhang 1C aufgezeichnet hat. ELSE: Wenn es in den letzten 10 Tagen des Auftretens keine derartigen Ereignisse gab, wird die Variable tp15638CardInsertion auf FALSE gesetzt.	1 (TRUE) = Gibt "card insertion while driving" innerhalb der letzten 10 Tage des Auftretens an
RTM6 Bewegungsdatenfehler	Die VU erstellt einen booleschen Wert für das Datenelement RTM6. Die VU weist der Variablen tp15638Motion DataError den Wert TRUE zu, wenn die VU in den letzten 10 Tagen des Auftretens mindestens ein Ereignis des Typs "Bewegungsdatenfehler" gemäß Anhang 1C aufgezeichnet hat. ELSE: Wenn es in den letzten 10 Tagen des Auftretens keine derartigen Ereignisse gab, wird die Variable tp15638Motion DataError auf FALSE gesetzt.	1 (TRUE) = gibt "motion data error" in den letzten 10 Tagen des Auftretens an
RTM7 Datenkonflikt Fahrzeugbewegung	Die VU erstellt einen booleschen Wert für das Datenelement RTM7. Die VU weist der Variablen tp15638vehicle MotionConflict den Wert TRUE zu, wenn die VU in den letzten 10 Tagen des Auftretens mindestens ein Ereignis des Typs Datenkonflikt Fahrzeugbewegung (Wert "0A"H) aufgezeichnet hat. ELSE: Wenn es in den letzten 10 Tagen des Auftretens keine Ereignisse gab, wird die Variable tp15638vehicle MotionConflict auf FALSE gesetzt.	1 (TRUE) = gibt "motion Conflict" in den letzten 10 Tagen des Auftretens an
RTM8 Zweite Fahrerkarte	Die VU erstellt einen booleschen Wert für das Datenelement RTM8 auf Grundlage des Anhangs 1C (Fahrertätigkeitsdaten TEAM oder BEIFAHRER). Wenn eine zweite gültige Fahrerkarte vorhanden ist, setzt die VU die Variable auf TRUE ELSE: Wenn keine gültige zweite Fahrerkarte vorhanden ist, setzt die VU die Variable auf FALSE	1 (TRUE) = gibt "second driver card inserted" an
RTM9 Derzeitige Aktivität	Die VU erstellt einen booleschen Wert für das Datenelement RTM9. Wenn die VU als derzeitige Aktivität eine andere Aktivität als "LENKEN" gemäß Anlage 1C aufzeichnet, muss die VU die Variable auf TRUE setzen ELSE: Wenn die derzeitige Aktivität in der VU als "LENKEN" aufgezeichnet wird, muss die VU die Variable auf FALSE setzen	1 (TRUE) = andere Aktivität ausgewählt; 0 (FALSE) = Lenken ausgewählt
RTM10 Letzter Vorgang abgeschlossen	Die VU generiert einen booleschen Wert für das Datenelement RTM10. Wenn die letzte Kartensitzung nicht korrekt gemäß Anlage 1C abgeschlossen wird, muss die VU die Variable auf TRUE setzen. ELSE: Wenn die letzte Kartensitzung korrekt abgeschlossen wurde, setzt die VU die Variable auf FALSE	1 (TRUE) = nicht korrekt abgeschlossen 0 (FALSE) = korrekt abgeschlossen
RTM11 Unterbrechung der Stromversorgung	Die VU generiert einen Integer-Wert für das Datenelement RTM11. Die VU weist der Variablen tp15638Power SupplyInterruption einen Wert gleich der längsten Unterbrechung der Stromversorgung gemäß Artikel 9 der Verordnung (EU) Nr. 165/2014 des Typs "Unterbrechung der Stromversorgung" im Sinne von Anhang 1C zu. ELSE: Wenn es in den letzten 10 Tagen des Auftretens nicht zu einer Unterbrechung der Stromversorgung gekommen ist, wird der Integer-Wert auf 0 gesetzt.	- Anzahl der Unterbrechungen der Stromversorgung in den in den letzten 10 Tagen des Auftretens
RTM12 Sensorstörung	Die VU generiert einen Integer-Wert für das Datenelement RTM12. Die VU weist der Variablen sensorFault einen der folgenden Werte zu: 1 wenn in den letzten 10 Tagen ein Ereignis des Typs "35"H Sensorstörung aufgezeichnet worden ist, 2 wenn in den letzten 10 Tagen ein Ereignis des Typs GNSS-Empfängerstörung (intern oder extern Enum "36"H oder "37"H) aufgezeichnet worden ist, 3 wenn in den letzten 10 Tagen ein Ereignis des Typs "0E"H Kommunikationsfehler mit der externen GNSS-Ausrüstung aufgezeichnet worden ist, 4 wenn in den letzten 10 Tagen sowohl Sensorstörungen als auch GNSS-Empfängerstörungen aufgezeichnet worden sind, 5 wenn in den letzten 10 Tagen sowohl Sensorstörungen als auch Kommunikationsfehler mit der externen GNSS-Ausrüstung aufgezeichnet worden sind, 6 wenn in den letzten 10 Tagen sowohl GNSS-Empfängerstörungen als auch Kommunikationsfehler mit der externen GNSS-Ausrüstung aufgezeichnet worden sind, 7 wenn in den letzten 10 Tagen alle drei Arten von Sensorstörungen aufgezeichnet worden sind; wenn in den letzten 10 Tagen keine Ereignisse aufgezeichnet worden sind, ist der Wert 0 zuzuweisen.	Sensorstörung ein Oktett gemäß Datenglossar
RTM13 Zeiteinstellung	Für das Datenelement RTM13 generiert die VU einen Integer-Wert (time Real gemäß Anlage 1) auf Grundlage des Vorliegens von Zeiteinstellungsdaten gemäß Anhang 1C. Die VU weist den Zeitwert zu, an dem die letzte Zeiteinstellung erfolgt ist. ELSE: Wenn in der VU kein Ereignis "Zeiteinstellung" gemäß Anhang 1C vorhanden ist, muss die VU einen Wert von 0 festlegen.	Zeitpunkt von "last adjustment"
RTM14 Sicherheitsverletzender Versuch	Für das Datenelement RTM14 generiert die VU einen Integer-Wert (time Real gemäß Anlage 1) auf Grundlage des Vorliegens eines Ereignisses "Versuch Sicherheitsverletzung" gemäß Anhang 1C. Die VU setzt den Wert auf den Zeitpunkt des letzten von der VU verzeichneten sicherheitsverletzenden Versuchs. ELSE: Wenn in der VU kein Ereignis "Versuch Sicherheitsverletzung" gemäß Anhang 1C vorhanden ist, muss die VU einen Wert von 0x00FF festlegen.	Zeitpunkt von "latest breach attempt" - Standardwert =0x00FF
RTM15 Letzte Kalibrierung	Für das Datenelement RTM15 generiert die VU einen Integer-Wert (time Real gemäß Anlage 1) auf Grundlage des Vorliegens von letzten Kalibrierungsdaten gemäß Anhang 1C. Die VU setzt den Wert auf den Zeitpunkt der letzten beiden Kalibrierungen (RTM15 und RTM16) in VuCalibrationData gemäß Anlage 1 Die VU setzt den Wert für RTM15 auf time Real des letzten Kalibrierungsdatensatzes.	Zeitpunkt des letzten Kalibrierungsdatensatzes
RTM16 Vorherige Kalibrierung	Für das Datenelement RTM16 generiert die VU einen Integer-Wert (time Real gemäß Anlage 1) des Kalibrierungsdatensatzes vor der letzten Kalibrierung. ELSE: Wenn keine vorherige Kalibrierung vorliegt, setzt die VU den Wert von RTM16 auf 0.	Zeitpunkt von "previous calibration" Daten
RTM17 Anschlussdatum des Fahrtenschreibers	Für das Datenelement RTM17 generiert die VU einen Integer-Wert (time Real gemäß Anlage 1). Die VU setzt den Wert auf den Zeitpunkt der Erstinstallation der VU. Die VU extrahiert diese Daten aus den VuCalibrationData (Anlage 1) der vu CalibrationRecords, wobei Calibration Purpose gleich: "03"H	Anschlussdatum des Fahrtenschreibers
RTM18 Aktuelle Geschwindigkeit	Die VU generiert einen Integer-Wert für das Datenelement RTM18 Die VU setzt den Wert für RTM16 auf die bei der jüngsten Aktualisierung von RtmData zuletzt als aktuell aufgezeichnete Geschwindigkeit.	Zuletzt als aktuell aufgezeichnete Geschwindigkeit
RTM19 Zeitstempel	Für das Datenelement RTM19 generiert die VU einen Integer-Wert (time Real gemäß Anlage 1). Die VU setzt den Wert für RTM19 auf den Zeitpunkt der jüngsten Aktualisierung von RtmData.	Zeitstempel von "currentTachographPayloadrecord"

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 1Das 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.
  DieDSRC-VU wertet die empfangene BST aus; sofern sie erkennt, dass die BST Freight&Fleet (AID = 2) anfragt, antwortet dieDSRC-VU. Wenn dasREDCR nicht AID="2" anbietet, beendet dieDSRC-VU die Transaktion mit demREDCR.
• Schritt 2 DieDSRC-VU sendet eine Anfrage nach Zuweisung eines privaten Fensters.
• Schritt 3 Die REDCR sendet die Zuweisung eines privaten Fensters.
• Schritt 4 DieDSRC-VU sendet mithilfe des zugewiesenen privaten Fensters ihre Fahrzeugdiensttabelle (Vehicle Service table, VST). Diese VST enthält eine Liste aller unterschiedlichen Anwendungsinstanziierungen, die dieseDSRC-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 dasREDCR die angebotene VST und beendet entweder die Verbindung (RELEASE), weil das Angebot der VST nicht interessant ist (d. h., es erhält von derDSRC-VU eine VST, die keine RTM-VU ist), oder es erhält eine passende VST und startet die Instanziierung der App.
• Schritt 6 DasREDCR gibt einen Befehl (ECHO) an die jeweiligeDSRC-VU aus und weist ein privates Fenster zu.
• Schritt 7 DieDSRC-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 dieDSRC-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 - gestrichen -^{18 20}

5.6 Datenübermittelung zwischen DSRC-VU und VU

5.6.1 Physische Verbindung und Schnittstellen¹⁸

DSC_66 Die Verbindung zwischenVU undDSRC-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_77Die Daten sind, stets gesichert, von derVUSM-Funktion derDSRC-VU bereitzustellen. DieVUSM stellt sicher, dass die Aufzeichnung der Daten in der DSRC-VU korrekt verläuft. Die Aufzeichnung und Protokollierung von Fehlern bei der Datenübermittlung von der VU in den Speicher derDSRC-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.

DSC_78 Die VU führt eine Datei, die durch einen eindeutigen, von den Kontrolleuren leicht zuzuordnenden Namen gekennzeichnet ist, um VU-interne Kommunikationsfehler zu protokollieren.

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 dieDSRC-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 REDCRdie 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 empfangenenDaten 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 dasREDCR 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 DrahtloskommunikationskanalDSRC-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 VerbindungDSRC-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.

.

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 Präambel dieses Anhangs bietet eine Übersicht über die Umstellung von Fahrtenschreibersystemen der 1. Generation auf solche der 2. Generation.

Über die Bestimmungen dieser Präambel hinaus gilt Folgendes:

• Bewegungssensoren der 1. Generation sind nicht interoperabel mit Fahrzeugeinheiten der 2. Generation.
• Bewegungssensoren der 2. Generation werden zum selben Zeitpunkt in Fahrzeugen eingebaut wie Fahrzeugeinheiten der 2. Generation.
• Geräte zum Herunterladen von Daten und zur Kalibrierung müssen weiterentwickelt werden, um beide Generationen von Kontrollgeräten und Fahrtenschreiberkarten zu unterstützen.

2.2. Interoperabilität zwischen VU und Karten¹⁸

Fahrtenschreiberkarten der 1. Generation sind interoperabel mit Fahrzeugeinheiten der 1. Generation (gemäß Anhang IB der Verordnung (EWG) Nr. 3821/85/EWG); Fahrtenschreiberkarten der 2. Generation wiederum sind interoperabel mit Fahrzeugeinheiten der 2. 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 1. Generation bis zu ihrem Ablaufdatum in Fahrzeugeinheiten der 2. Generation weiterverwendet werden. Ihre Inhaber können jedoch die Ersetzung durch Fahrtenschreiberkarten der 2. Generation fordern, sobald diese verfügbar sind.

MIG_002 Fahrzeugeinheiten der 2. Generation müssen in der Lage sein, eingesteckte gültige Fahrer-, Kontroll- und Unternehmenskarten der 1. Generation zu nutzen.

MIG_003 Diese Fähigkeit kann in solchen Fahrzeugeinheiten durch Werkstätten endgültig unterdrückt werden, sodass Fahrtenschreiberkarten der 1. 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 2. Generation dürfen nur Werkstattkarten der 2. Generation nutzen können.

MIG_005 Zur Bestimmung der Betriebsart dürfen Fahrzeugeinheiten der 2. Generation nur die Art der gültigen eingesteckten Karten berücksichtigen, nicht aber ihre Generation.

MIG_006 Jede gültige Fahrtenschreiberkarte der 2. Generation muss in Fahrzeugeinheiten der 1. Generation genauso genutzt werden können wie eine Fahrtenschreiberkarte gleicher Art der 1. Generation.

2.3. Interoperabilität zwischen VU und Bewegungssensoren

Bewegungssensoren der 1. Generation sind interoperabel mit Fahrzeugeinheiten der 1. Generation; Bewegungssensoren der 2. Generation wiederum sind interoperabel mit Fahrzeugeinheiten der 2. Generation. Zusätzlich gelten die nachfolgenden Bestimmungen.

MIG_007 Fahrzeugeinheiten der 2. Generation können nicht mit Bewegungssensoren der 1. Generation gekoppelt und verwendet werden.

MIG_008 Bewegungssensoren der 2. Generation können entweder ausschließlich mit Fahrzeugeinheiten der 2. Generation gekoppelt und verwendet werden oder mit beiden Generationen von Fahrzeugeinheiten.

2.4. Interoperabilität zwischen Fahrzeugeinheiten, Fahrtenschreiberkarten und Geräte für das Herunterladen von Daten

MIG_009 Geräte für das Herunterladen von Daten können entweder ausschließlich mit einer Generation von Fahrzeugeinheiten verwendet werden oder mit beiden.

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 festgelegte Format aufweisen.

MIG_011 Damit auch Nicht-EU-Kontrollbehörden Fahrer kontrollieren können, muss es möglich sein, Fahrer- (und Werkstatt-) Karten der 2. Generation genauso herunterzuladen wie Karten der 1. Generation. Heruntergeladen werden können müssen unter anderem:

• nicht signierte EF ic und icc (optional),
• nicht signierte EF (1. Generation) Card_Certificate und CA_Certificate,
• sonstige Anwendungsdaten-EF (innerhalb der DF Tachograph), die durch das Download-Protokoll von Karten der 1. Generation angefordert werden. Diese Information wird entsprechend den Sicherheitsmechanismen der 1. Generation durch eine digitale Signatur gesichert.

Die entsprechenden Downloads dürfen keine Anwendungsdaten-EF umfassen, die nur in Fahrer- (und Werkstatt-)Karten der 2. 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 der 2. Generation, die in eine Fahrzeugeinheit der 1. Generation eingesteckt ist, wird das Datendownload-Protokoll der 1. Generation verwendet. Die Karte antwortet auf Befehle der Fahrzeugeinheit in genau der gleichen Weise wie eine Karte der 1. Generation; heruntergeladene Daten müssen das gleiche Format aufweisen wie Daten, die von einer Karte der 1. Generation heruntergeladen werden.

MIG_013 Für den Datendownload von einer Karte der 1. Generation, die in eine Fahrzeugeinheit der 2. 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 1. 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 2. Generation die Sicherheitsmechanismen der 2. Generation und das in Anlage 7 dieses Anhangs angegebene Datendownload-Protokoll verwendet.

MIG_015 Damit auch Nicht-EU-Kontrollbehörden Fahrer kontrollieren können, ist es optional möglich, Daten von Fahrzeugeinheiten der 2. Generation unter Verwendung der Sicherheitsmechanismen der 1. Generation herunterzuladen. Die heruntergeladenen Daten müssen in dem Fall das gleiche Format aufweisen wie Daten, die von einer Fahrzeugeinheit der 1. 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 unter Verwendung des Kalibrierungsprotokolls der entsprechenden Generation zu kalibrieren. Kalibrierungsgeräte können entweder ausschließlich mit Fahrtenschreibern einer einzigen Generation verwendet werden oder mit beiden.

3. Wesentliche Schritte im Zeitraum vor dem Einführungsdatum

MIG_017 Prüfschlüssel und Zertifikate müssen den Herstellern spätestens 30 Monate vor dem Einführungsdatum zur Verfügung stehen.

MIG_018 Die Interoperabilitätsprüfungen müssen bei Anfrage durch die Hersteller spätestens 15 Monate vor dem Einführungsdatum gestartet werden können.

MIG_019 Offizielle Schlüssel und Zertifikate müssen den Herstellern spätestens 12 Monate vor dem Einführungsdatum zur Verfügung stehen.

MIG_020 Die Mitgliedstaaten müssen Werkstattkarten der 2. Generation spätestens 3 Monate vor dem Einführungsdatum ausgeben können.

MIG_021 Die Mitgliedstaaten müssen alle Arten von Fahrtenschreiberkarten der 2. Generation spätestens 1 Monat vor dem Einführungsdatum ausgeben können.

4. Bestimmungen für den Zeitraum nach dem Einführungsdatum

MIG_022 Nach dem Einführungsdatum dürfen die Mitgliedstaaten nur noch Fahrtenschreiberkarten der 2. Generation ausgeben.

MIG_023 Hersteller von Fahrzeugeinheiten/Bewegungssensoren dürfen so lange Fahrzeugeinheiten/Bewegungssensoren der 1. Generation fertigen, wie diese in der Praxis eingesetzt werden, sodass defekte Komponenten ersetzt werden können.

MIG_024 Hersteller von Fahrzeugeinheiten/Bewegungssensoren können die Beibehaltung einer Typgenehmigung von Fahrzeugeinheiten/Bewegungssensoren der 1. Generation, die bereits über eine Typgenehmigung verfügen, beantragen und erlangen.

.

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" (4.000 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:

.

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