Anlage 14. VO (EU) 2016/799
FERNKOMMUNIKATIONSFUNKTION
INHALTSVERZEICHNIS
-
1
-
EINFÜHRUNG
In dieser Anlage werden das Design und die Verfahren spezifiziert, die bei der Umsetzung der Fernkommunikationsfunktion ( „Kommunikation” ) gemäß Artikel 9 der Verordnung (EU) Nr. 165/2014 (die Verordnung) befolgt werden müssen.- DSC_1
- In der Verordnung (EU) Nr. 165/2014 ist festgelegt, dass der Fahrtenschreiber mit einer Fernkommunikationsfunktion ausgestattet sein muss, durch die Mitarbeiter der zuständigen Kontrollbehörden Fahrtenschreiberinformationen vorbeifahrender Fahrzeuge mithilfe eines Fernabfragegeräts (Remote Early Detection Communication Reader [REDCR]; Abfragegeräte, die über DSRC-Schnittstellen [Dedicated Short Range Communication] mit CEN 5,8 GHz eine Drahtlosverbindung herstellen) auslesen können.
Hierbei muss betont werden, dass diese Funktion lediglich als Vorfilter dienen soll, um Fahrzeuge zur näheren Prüfung auszuwählen, und nicht das formelle Prüfverfahren gemäß der Verordnung (EU) Nr. 165/2014 ersetzt. Siehe Erwägungsgrund 9 in der Präambel dieser Verordnung, wo dargelegt wird, dass die Fernkommunikation zwischen Fahrtenschreiber und Kontrollbehörden zu Straßenkontrollzwecken die Durchführung gezielter Straßenkontrollen erleichtert.
- DSC_2
- Die Daten sind unter Verwendung der Kommunikation auszutauschen; bei dieser handelt es sich um Drahtlosverkehr über eine 5,8-GHz-DSRC-Drahtlosverbindung gemäß der Anlage und geprüft gegen die geeigneten Parameter von EN 300 674-1 (Electromagnetic compatibility and Radio spectrum Matters (ERM); Road Transport and Traffic Telematics (RTTT); Dedicated Short Range Communication (DSRC) transmission equipment (500 kbit/s/250 kbit/s) operating in the 5,8 GHz Industrial, Scientific and Medical (ISM) band; Part 1: General characteristics and test methods for Road Side Units (RSU) and On -Board Units (OBU), Elektromagnetische Verträglichkeit und Funkspektrumangelegenheiten (ERM) — Straßentransport- und Verkehrstelematik (RTTT) — DSRC-Übertragungseinrichtungen (500 kbit/s/250 kbit/s), die im 5,8-GHz-ISM-Band arbeiten — Teil 1: Allgemeine Kennwerte und Prüfverfahren für Road Side Units (RSU) und On-Board Units (OBU)).
- DSC_3
- Die Kommunikation ist ausschließlich dann mit dem Kommunikationsgerät herzustellen, wenn dies von dem Gerät der zuständigen Kontrollbehörde mithilfe zulässiger Funkverbindungsmittel (Remote Early Detection Communication Reader (REDCR) angefordert wird.
- DSC_4
- Die Integrität der Daten ist zu schützen.
- DSC_5
- Der Zugang zu den übertragenen Daten ist auf die Kontrollbehörden beschränkt, die ermächtigt sind, Verstöße gegen die Verordnungen (EG) Nr. 561/2006 und (EU) Nr. 165/2014 zu überprüfen, und auf Werkstätten, soweit ein Zugang für die Überprüfung des ordnungsgemäßen Funktionierens des Fahrtenschreibers erforderlich ist.
- DSC_6
- Bei der Kommunikation dürfen nur Daten übertragen werden, die für die Zwecke der gezielten Straßenkontrolle von Fahrzeugen notwendig sind, deren Fahrtenschreiber mutmaßlich manipuliert oder missbraucht wurde.
- DSC_7
- Die Integrität und Sicherheit der Daten ist zu gewährleisten, indem die Daten innerhalb der Fahrzeugeinheit (VU) gesichert werden und indem ausschließlich die gesicherten Nutzlastdaten und sicherheitsbezogenen Daten (siehe 5.4.4) über das 5,8-GHz-DSRC-Fernkommunikationsmedium weitergegeben werden, sodass nur befugte Personen zuständiger Kontrollbehörden in der Lage sind, die über die Kommunikation weitergegebenen Daten zu verstehen und ihre Authentizität zu überprüfen. Siehe Anlage 11, Gemeinsame Sicherheitsmechanismen.
- DSC_8
- Die Daten müssen einen Zeitstempel mit dem Zeitpunkt der letzten Aktualisierung enthalten.
- DSC_9
- Der Inhalt der Sicherheitsdaten darf nur den zuständigen Kontrollbehörden und denjenigen Parteien, mit denen sie diese Informationen austauschen, bekannt sein und von diesen kontrolliert werden und liegt außerhalb der Bestimmungen der Kommunikation, die Gegenstand dieser Anlage ist, sofern die Kommunikation nicht vorsieht, mit jedem Paket an Nutzlastdaten ein Paket an Sicherheitsdaten zu übermitteln.
- DSC_10
- Die Architektur und Geräte müssen in der Lage sein, mithilfe der hierin angegebenen Architektur andere Datenkonzepte zu verwenden (etwa eingebaute Wiegesysteme).
- DSC_11
- Zur Klarstellung: Gemäß den Bestimmungen der Verordnung (EU) Nr. 165/2014 (Artikel 7) werden über die Kommunikation keine Daten bezüglich der Identität des Fahrers übertragen.
- 2
- GELTUNGSBEREICH
In dieser Anlage wird festgelegt, wie die Mitarbeiter der zuständigen Kontrollbehörden eine angegebene 5,8-GHz-DSRC- Drahtloskommunikation verwenden, um aus der Entfernung Daten (die Daten) eines anvisierten Fahrzeugs zu erhalten, die belegen, dass das anvisierten Fahrzeug vermutlich gegen die Verordnung (EU) Nr. 165/2014 verstößt und unter Umständen angehalten werden muss, um weitere Überprüfungen vorzunehmen. Die Verordnung (EU) Nr. 165/2014 schreibt vor, dass die erfassten Daten sich auf Daten beschränken oder mit solchen im Zusammenhang stehen müssen, die einen möglichen Verstoß eines der Datensubjekte gemäß Definition in Artikel 9 der Verordnung (EU) Nr. 165/2014 belegen. In einem solchen Szenario ist die für die Kommunikation zur Verfügung stehende Zeit begrenzt, da die Kommunikation zielgerichtet ist und innerhalb einer Kurzstrecke erfolgt. Weiterhin können die zur Fahrtenschreiberfernüberwachung (Remote Tachograph Monitoring, RTM) genutzten Daten von den zuständigen Kontrollbehörden auch für andere Anwendungszwecke (z. B. höchstzulässige Gewichte und Abmessungen von Nutzfahrzeugen gemäß der Richtlinie (EU) 2015/719) eingesetzt werden; diese Maßnahmen können im Ermessen der zuständigen Kontrollbehörden getrennt oder aufeinanderfolgend durchgeführt werden. In dieser Anlage wird Folgendes festgelegt:- —
die zur Kommunikation genutzten Kommunikationsgeräte, -verfahren und -protokolle
- —
die Normen und Verordnungen, die die Funkgeräte erfüllen müssen
- —
die Art, wie die Daten dem Kommunikationsgerät präsentiert werden
- —
die Abfrage- und Downloadverfahren sowie die Sequenz der Operationen
- —
die zu übertragenden Daten
- —
die mögliche Auslegung der über die Kommunikation übertragenen Daten
- —
die Bestimmungen zu Sicherheitsdaten im Zusammenhang mit der Kommunikation
- —
die Verfügbarkeit der Daten für die zuständigen Kontrollbehörden
- —
die Art und Weise, wie das Fernabfragegerät unterschiedliche Datenkonzepte für Fracht und Flotten abfragen kann
- —
die Erfassung und Verwaltung der Daten innerhalb der VU (diese ergibt sich aus dem Produktdesign, sofern sie nicht an anderer Stelle in der Verordnung (EU) Nr. 165/2014 festgelegt ist).
- —
die Art der Präsentation der erfassten Daten gegenüber dem Mitarbeiter der zuständigen Kontrollbehörden, ebenso wenig wie die Kriterien, anhand derer die zuständigen Kontrollbehörden entscheiden, welche Fahrzeuge angehalten werden (diese ergeben sich aus dem Produktdesign, sofern sie nicht an anderer Stelle der Verordnung (EU) Nr. 165/2014 oder in einer Grundsatzentscheidung der zuständigen Kontrollbehörden festgelegt werden). Zur Klarstellung: Durch die Kommunikation werden den zuständigen Kontrollbehörden lediglich die Daten zur Verfügung gestellt, auf deren Grundlage sie fundierte Entscheidungen treffen können.
- —
Datensicherheitsbestimmungen (wie beispielsweise Verschlüsselung), die den Inhalt der Daten betreffen (diese werden in Anlage 11 Gemeinsame Sicherheitsmechanismen spezifiziert).
- —
Einzelheiten von Datenkonzepten (ausgenommen RTM), die über die gleiche Architektur und Ausrüstung erhalten werden können
- —
Details über das Verhalten und Management zwischen VU und DSRC-VU, ebenso wenig wie das Verhalten innerhalb der DSRC-VU (außer zum Bereitstellen der Daten nach Aufforderung durch ein REDCR).
- 3
- AKRONYME, DEFINITIONEN UND NOTATIONEN
Folgende für diese Anlage spezifische Akronyme und Definitionen werden in dieser Anlage verwendet:- Antenne
- elektrisches Gerät, das Strom in Funkwellen und umgekehrt umwandelt und zusammen mit einem Funksender oder -empfänger verwendet wird. Im Betrieb versorgt der Funksender das Endgerät der Antenne mit einem elektrischen Strom, der in der Funkfrequenz oszilliert, und die Antenne strahlt die Energie des Stroms als elektromagnetische Wellen (Funkwellen) aus. Beim Empfang fängt eine Antenne einen Teil der Leistung der elektromagnetischen Welle ab, um eine kleine Spannung an ihren Anschlüssen zu erzeugen, die an einen Empfänger angelegt und verstärkt wird.
- Kommunikation
- Austausch von Informationen/Daten zwischen DSRC-REDCR und DSRC-VU gemäß Abschnitt 5 in Master-Slave-Beziehung, um die Daten zu erhalten.
- Daten
- gesicherte Daten eines definierten Formats (siehe 5.4.4), die vom DSRC-REDCR abgerufen und dem DSRC-REDCR per DSRC-VU über eine 5,8-GHz-DSRC-Verbindung nach Definition unter Ziffer 5 unten bereitgestellt werden.
- Verordnung (EU) Nr. 165/2014
- Verordnung (EU) Nr. 165/2014 des Europäischen Parlaments und des Rates vom 4. Februar 2014 über Fahrtenschreiber im Straßenverkehr, zur Aufhebung der Verordnung (EWG) Nr. 3821/85 des Rates über 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
- AID
- Application Identifier (Anwendungskennung)
- BLE
- Bluetooth Low Energy
- BST
- Beacon Service Table
- CIWD
- Card insertion while driving (Einstecken der Karte während des Lenkens)
- CRC
- Cyclic Redundancy Check (zyklische Redundanzprüfung)
- DSC (n)
- Kennung einer Anforderung an einer bestimmten DSRC-Anlage
- DSRC
- Dedicated Short Range Communication (Dedizierte Nahbereichskommunikation)
- DSRC-REDCR
- DSRC — Remote Early Detection Communication Reader
- DSRC-VU
- DSRC — Vehicle Unit (Fahrzeugeinheit, damit ist die in Anhang 1C beschriebene „Fernabfrageausrüstung” gemeint)
- DWVC
- Driving without valid card (Fahren ohne gültige Karte)
- EID
- Element Identifier (Elementkennung)
- LLC
- Logical Link Control
- LPDU
- LLC Protocol Data Unit
- OWS
- Onboard Weighing System (Eingebautes Wiegesystem)
- PDU
- Protocol Data Unit (Protokolldateneinheit)
- REDCR
- Remote Early Detection Communication Reader (Fernabfragegerät, damit ist das in Anhang 1C beschriebene „Fernabfragegerät” gemeint)
- RTM
- Remote Tachograph Monitoring (Fahrtenschreiberfernüberwachung)
- SM-REDCR
- Security Module-Remote Early Detection Communication Reader (Sicherheitsmodul-Fernabfragegerät)
- TARV
- Telematics Applications for Regulated Vehicles [ISO 15638 series of Standards] (Telematikanwendungen für regulierte Fahrzeuge [ISO-Normenreihe 15638])
- VU
- Fahrzeugeinheit (Vehicle Unit, VU)
- VUPM
- Vehicle Unit Payload Memory (Nutzlastspeicher der Fahrzeugeinheit)
- VUSM
- Vehicle Unit Security Module (Fahrzeugeinheit-Sicherheitsmodul)
- VST
- Vehicle Service Table (Servicetabelle des Fahrzeugs)
- WIM
- Weigh in motion (Wiegen unterwegs)
- WOB
- Weigh on board (Wiegen an Bord)
- [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 des Rates über das Kontrollgerät im Straßenverkehr und zur Änderung der Verordnung (EG) Nr. 561/2006 des Europäischen Parlaments und des Rates zur Harmonisierung bestimmter Sozialvorschriften im Straßenverkehr
- [2]
- Verordnung (EG) Nr. 561/2006 des Europäischen Parlaments und des Rates vom 15. März 2006 zur Harmonisierung bestimmter Sozialvorschriften im Straßenverkehr und zur Änderung der Verordnungen (EWG) Nr. 3821/85 und (EG) Nr. 2135/98 des Rates sowie zur Aufhebung der Verordnung (EWG) Nr. 3820/85 des Rates.
- [3]
- ERC 70-03 CEPT: ECC-Empfehlung 70-03: Relating to the Use of Short Range Devices (SRD)
- [4]
- ISO 15638 Intelligent transport systems — Framework for cooperative telematics applications for regulated commercial freight vehicles (TARV).
- [5]
- EN 300 674-1 Electromagnetic compatibility and Radio spectrum Matters (ERM); Road Transport and Traffic Telematics (RTTT); Dedicated Short Range Communication (DSRC) transmission equipment (500 kbit/s/250 kbit/s) operating in the 5,8 GHz Industrial, Scientific and Medical (ISM) band; Part 1: General characteristics and test methods for Road Side Units (RSU) and On-Board Units (OBU) (Elektromagnetische Verträglichkeit und Funkspektrumangelegenheiten (ERM) — Straßentransport- und Verkehrstelematik (RTTT) — DSRC-Übertragungseinrichtungen (500 kbit/s/250 kbit/s), die im 5,8-GHz-ISM-Band arbeiten — Teil 1: Allgemeine Kennwerte und Prüfverfahren für Road Side Units (RSU) und On-Board Units (OBU)).
- [6]
- EN 12253 Road transport and traffic telematics — Dedicated short-range communication — Physical layer using microwave at 5.8 GHz (Straßentransport- und Verkehrstelematik — Nahbereichskommunikation — Datenverbindungsschicht — Bitübertragungsschicht für die Frequenz 5,8 GHz) (Straßentransport- und Verkehrstelematik (RTTT) — Nahbereichskommunikation Fahrzeug-Bake (DSRC) — Bitübertragungsschicht für die Frequenz 5,8 GHz).
- [7]
- EN 12795 Road transport and traffic telematics — Dedicated short-range communication — Data link layer: medium access and logical link control (Straßentransport- und Verkehrstelematik — Nahbereichskommunikation — Datenverbindungsschicht — Zugriffsmedium und Verbindungssteuerung).
- [8]
- EN 12834 Road transport and traffic telematics — Dedicated short-range communication — Application layer (Straßentransport- und Verkehrstelematik — Nahbereichskommunikation — Anwendungsschicht).
- [9]
- EN 13372 Road transport and traffic telematics — Dedicated short-range communication — Profiles for RTTT applications (Straßentransport- und Verkehrstelematik — Nahbereichskommunikation — DSRC-Profile für RTTT-Anwendungen).
- [10]
- ISO 14906 Electronic fee collection — Application interface definition for dedicated short- range communication (Elektronische Gebührenerhebung — Anwendungsschnittstelle zur dezidierten Nahbereich-Kommunikation)
- 4
- BETRIEBSSZENARIOS
- 4.1
- Überblick
In der Verordnung (EU) Nr. 165/2014 sind spezifische und kontrollierte Szenarios vorgesehen, innerhalb derer die Kommunikation zu verwenden ist. Die unterstützen Szenarios lauten:Kommunikationsprofil 1: Straßenkontrolle mithilfe eines drahtlosen Nahbereich-Fernabfragegeräts, die eine physische Straßenkontrolle in Gang setzt (Master–Slave)
Leserprofil 1a: über eine von Hand ausgerichtete oder vorübergehend an der Straße aufgestellte und ausgerichtete Fernabfragekommunikation
Leserprofil 1b: über ein in einem Fahrzeug eingerichtetes und ausgerichtetes Fernabfragegerät.
- 4.1.1
- Voraussetzungen für den Datentransfer über die 5,8-GHz-DSRC-Schnittstelle
HINWEIS: Für ein besseres Verständnis des Kontexts der Voraussetzungen siehe Abbildung 14.3 unten.
- 4.1.1.1
- In der VU gespeicherte Daten
- DSC_12
- Die VU ist dafür verantwortlich, die in ihr zu speichernden Daten ohne Einbeziehung der DSRC-Kommunikationsfunktion alle 60 Sekunden zu aktualisieren und auf dem neuesten Stand zu halten. Die Mittel, mit denen dies erreicht wird, sind eine wesentliche Eigenschaft der VU und nicht in dieser Anlage, sondern in Anhang 1C Abschnitt 3.19 Fernkommunikation für gezielte Straßenkontrollen der Verordnung (EU) Nr. 165/2014 angegeben.
- 4.1.1.2
- Der DSRC-VU-Ausrüstung bereitgestellte Daten
- DSC_13
- Die VU ist dafür verantwortlich, die Daten des DSRC-Fahrtenschreibers (die Daten) zu aktualisieren, sobald die in der VU gespeicherten Daten aktualisiert werden. Dies erfolgt in dem in 4.1.1.1 (DSC_12) angegebenen Intervall und ohne Beteiligung der DSRC-Kommunikationsfunktion.
- DSC_14
- Die VU-Daten dienen als Grundlage zur Einspeisung und Aktualisierung der Daten; die Mittel, durch die dies erreicht wird, sind in Anhang 1C Abschnitt 3.19 Fernkommunikation für gezielte Straßenkontrollen der festgelegt oder sind, wenn keine solche Festlegung vorliegt, abhängig vom Produktdesign und werden nicht in dieser Anlage spezifiziert. Zur Konzeption der Verbindung zwischen DSRC-VU-Ausrüstung und VU siehe Abschnitt 5.6.
- 4.1.1.3
- Inhalt der Daten
- DSC_15
- Inhalt und Format der Daten sind so zu gestalten, dass sie nach Entschlüsselung in Form und Format wie in 5.4.4 dieser Anlage (Datenstrukturen) angegeben strukturiert sind und verfügbar gemacht werden.
- 4.1.1.4
- Präsentation der Daten
- DSC_16
- Die Daten, die gemäß dem in 4.1.1.1 angegebenen Verfahren regelmäßig aktualisiert worden sind, werden vor der Präsentation gegenüber der DSRC-VU gesichert und als gesicherter Datenkonzeptwert präsentiert, um in der DSRC-VU als aktuelle Version der Daten temporär gespeichert zu werden. Diese Daten werden von der VUSM an die DSRC-Funktion VUPM weitergeleitet. VUSM und VUPM sind Funktionen und nicht zwangsläufig physische Einheiten. Die Form der physischen Instanziierung, um diese Funktionen zu erfüllen, ist eine Frage des Produktdesigns, sofern sie nicht an anderer Stelle in der Verordnung (EU) Nr. 165/2014 festgelegt ist.
- 4.1.1.5
- Sicherheitsdaten
- DSC_17
- Sicherheitsdaten (DSRCSecurityData), die die vom REDCR benötigten Daten zur Erfüllung seiner Aufgabe, die Daten zu entschlüsseln, enthalten, müssen gemäß Anlage 11 „Gemeinsame Sicherheitsmechanismen” zur vorübergehenden Speicherung in der DSRC-VU als aktuelle Version der DSRCSecurityData in der in dieser Anlage in Nummer 5.4.4 definierten Form bereitgestellt werden.
- 4.1.1.6
- VUPM-Daten verfügbar zur Übermittlung per DSRC-Schnittstelle
- DSC_18
- Das Datenkonzept, das jederzeit in der DSRC-Funktion VUPM zur unmittelbaren Übertragung auf Anfrage durch das REDCR zur Verfügung stehen muss, ist in Abschnitt 5.4.4 für die vollständigen Spezifikationen des ASN.1-Moduls definiert.
Allgemeiner Überblick über das Kommunikationsprofil 1
Dieses Profil betrifft den Anwendungsfall, in dem ein Mitarbeiter der zuständigen Kontrollbehörden ein Nahbereich-Fernabfragegerät (5,8-GHz-DSRC-Schnittstellen, betrieben innerhalb von ERC 70-03 und geprüft gegen die geeigneten Parameter von EN 300 674-1 gemäß Abschnitt 5) (REDCR), um per Fernkommunikation ein Fahrzeug zu identifizieren, das möglicherweise gegen Verordnung (EU) Nr. 165/2014 verstößt. Nach der Identifizierung entscheidet der Mitarbeiter der zuständigen Kontrollbehörden, der die Abfrage kontrolliert, ob das Fahrzeug angehalten werden soll.- 4.1.2
- Profil 1a: über eine von Hand ausgerichtete oder vorübergehend an der Straße aufgestellte und ausgerichtete Fernabfragekommunikation
In diesem Fall befindet sich der Mitarbeiter der zuständigen Kontrollbehörden am Straßenrand und richtet ein auf einem Stativ befestigtes oder tragbares Handgerät, REDCR, vom Straßenrand aus auf die Mitte der Windschutzscheibe des anvisierten Fahrzeugs. Die Abfrage erfolgt mithilfe von 5,8-GHz-DSRC-Schnittstellen, betrieben innerhalb von ERC 70-03 und geprüft gegen die geeigneten Parameter von EN 300 674-1 gemäß Abschnitt 5. Siehe Abbildung 14.1 (Anwendungsfall 1).Abbildung 14.1
- 4.1.3
- Profil 1b: über ein in einem Fahrzeug eingerichtetes und ausgerichtetes Fernabfragegerät (REDCR)
In diesem Fall befindet sich der Mitarbeiter der zuständigen Kontrollbehörden in einem sich bewegenden Fahrzeug und richtet entweder ein REDCR-Handgerät aus dem Fahrzeug auf die Mitte der Windschutzscheibe des anvisierten Fahrzeugs, oder das REDCR ist in oder auf dem Fahrzeug montiert und zeigt auf die Mitte der Windschutzscheibe des anvisierten Fahrzeugs, wenn sich das Fahrzeug mit dem Fernabfragegerät in einer bestimmten Position zum anvisierten Fahrzeug befindet (zum Beispiel unmittelbar voraus im Verkehrsfluss). Die Abfrage erfolgt mithilfe von 5,8-GHz-DSRC-Schnittstellen, betrieben innerhalb von ERC 70-03 und geprüft gegen die geeigneten Parameter von EN 300 674-1 gemäß Abschnitt 5. Siehe Abbildung 14.2 (Anwendungsfall 2).Abbildung 14.2
- 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
- DSC_19
- Die VU enthält die folgenden Funktionen:
- —
Sicherheitsmodul (VUSM). Diese in der VU vorhandene Funktion ist für die Sicherung der Daten zuständig, die per Fernkommunikation von der DSRC-VU an den Mitarbeiter der zuständigen Kontrollbehörden übermittelt werden sollen.
- —
Die gesicherten Daten werden im VUSM-Speicher abgelegt. In den in 4.1.1.1 (DSC_12) festgelegten Intervallen verschlüsselt und befüllt die VU das RTMdata-Konzept (welches die weiter unten in dieser Anlage festgelegten Nutzlast- und Sicherheitsdatenkonzeptwerte umfasst) im Speicher der DSRC-VU. Der Betrieb des Sicherheitsmoduls ist in Anlage 11 Gemeinsame Sicherheitsmechanismen definiert und fällt nicht in den Anwendungsbereich dieser Anlage, sofern es nicht dafür benötigt wird, das VU-Kommunikationsgerät jeweils bei einer Änderung der VUSM-Daten zu aktualisieren.
- —
Die Kommunikation zwischen VU und DSRC-VU kann per drahtgebundener Kommunikation oder per BLE-Kommunikation (Bluetooth Low Energy) erfolgen; die DSRC-VU kann in die Antenne auf der Windschutzscheibe des Fahrzeugs integriert sein, interner Bestandteil der VU sein oder sich irgendwo dazwischen befinden.
- —
Die DSRC-VU benötigt eine jederzeit verfügbare Stromquelle. Die Art der Stromversorgung kann im Rahmen des Produktdesigns entschieden werden.
- —
Der Speicher der DSRC-VU muss nichtflüchtig sein, damit die Daten stets in der DSRC-VU verbleiben, selbst wenn die Fahrzeugzündung ausgeschaltet ist.
- —
Wenn die Kommunikation zwischen VU und DSRC-VU per BLE erfolgt und es sich bei der Stromquelle um eine nicht wieder aufladbare Batterie handelt, muss die Stromquelle der DSRC-VU bei jeder regelmäßigen Nachprüfung ausgetauscht werden; der Hersteller der DSRC-VU-Ausrüstung muss sicherstellen, dass die Stromversorgung den Zeitraum zwischen zwei aufeinanderfolgenden regelmäßigen Nachprüfungen übersteht und in diesem Zeitraum ohne Ausfall oder Unterbrechung einen normalen Zugriff auf die Daten per REDCR gewährleistet
- —
VU-RTM- „Datennutzlastspeicher” (VUPM). Diese Funktion in der VU ist für die Bereitstellung und Aktualisierung der Daten verantwortlich. Der Inhalt der Daten ( „Fahrtenschreibernutzlast” ) wird in 5.4.4/5.4.5 unten definiert und in dem in 4.1.1.1 (DSC_12) festgelegten Intervall aktualisiert.
- —
DSRC-VU. Diese Funktion innerhalb der VU oder mit dieser per Antenne in drahtgebundener oder drahtloser (BLE) Kommunikation stehend speichert die aktuellen Daten (VUPM-Daten) und steuert die Antwort auf eine Abfrage über das 5,8-GHz-DSRC-Medium. Eine Trennung der DSRC-Einrichtung oder Störung der Funktion des DSRC-Geräts während des normalen Fahrzeugbetriebs gilt als Verstoß gegen die Verordnung (EU) Nr. 165/2014.
- —
Das Sicherheitsmodul (REDCR) (SM-REDCR) ist die Funktion zur Entschlüsselung und Integritätsprüfung der aus der VU stammenden Daten. Die Mittel, mit denen dies erreicht wird, sind in Anlage 11 Gemeinsame Sicherheitsmechanismen festgelegt und nicht in dieser Anlage definiert.
- —
Das DSRC-Gerät (REDCR) (DSRC-REDCR) beinhaltet einen 5,8-GHz-Sender und dazugehörige Firm- und Software, welche die Kommunikation mit der DSRC-VU in Überstimmung dieser Anlage gewährleisten.
- —
Das DSRC-REDCR fragt die DSRC-VU des anvisierten Fahrzeugs ab, erhält die Daten (die aktuellen VUPM-Daten des anvisierten Fahrzeugs) per DSRC-Verbindung und speichert diese in seinem SM-REDCR ab.
- —
Die DSRC-VU-Antenne muss an einer Stelle angebracht werden, an der sie die DSRC-Kommunikation zwischen dem Fahrzeug und der Antenne am Straßenrand optimiert, wenn das Lesegerät 15 Meter vor dem Fahrzeug und in 2 Meter Höhe installiert und auf die horizontale und vertikale Mitte der Windschutzscheibe gerichtet ist. Bei leichten Fahrzeugen ist eine Anbringung im oberen Teil der Windschutzscheibe geeignet. Bei allen anderen Fahrzeugen muss die DSRC-Antenne entweder nahe dem unteren Teil oder nahe dem oberen Teil der Windschutzscheibe eingebaut sein.
- DSC_20
- Betrieb der Antenne und der Kommunikation erfolgt innerhalb von ERC 70-03 und geprüft gegen die geeigneten Parameter von EN 300 674-1 gemäß Abschnitt 5. Antenne und Kommunikation können über Verfahren zur Minderung der Risiken von Funkstörungen gemäß ECC-Bericht 228 verfügen, also z. B. mit Filtern in der CEN-DSRC 5,8 GHz-Kommunikation ausgestattet sein,
- DSC_21
- Die DSRC-Antenne muss mit der DSRC-VU-Ausrüstung entweder direkt in dem an oder in der Nähe der Windschutzscheibe angebrachten Modul oder über ein spezielles Kabel, das durch seine Bauart eine rechtswidrige Trennung erschwert, verbunden sein. Eine Trennung oder Störung der Funktion der Antenne während des normalen Fahrzeugbetriebs gilt als Verstoß gegen die Verordnung (EU) Nr. 165/2014. Ein absichtliches Verbergen oder eine sonstige Beeinträchtigung der Antennenfunktion ist als Verstoß gegen Verordnung (EU) Nr. 165/2014 auszulegen.
- DSC_22
- Der Formfaktor der Antenne ist nicht definiert und kann betriebswirtschaftlich entschieden werden, solange die angebrachte DSRC-VU die Konformitätsvorgaben in Abschnitt 5 unten erfüllt. Die Antenne soll gemäß den Festlegungen in DSC_19 befestigt werden und muss den in 4.1.2 und 4.1.3 beschriebenen Anwendungsfällen effizient gerecht werden.
Abbildung 14.4
Der Formfaktor von REDCR und Antenne kann je nach den vom Mitarbeiter der zuständigen Kontrollbehörden gewählten Lese- (Stativbefestigung, Handgerät, Fahrzeugbefestigung usw.) und Betriebsmodi variieren. Die Ergebnisse der Fernkommunikationsfunktion werden dem Mitarbeiter der zuständigen Kontrollbehörden mittels einer Anzeige- und/oder Benachrichtigungsfunktion präsentiert. Eine Anzeige kann auf einem Bildschirm, als Ausdruck, als Audiosignal oder als Kombination solcher Benachrichtigungen erfolgen. Die Form einer solchen Anzeige und/oder Benachrichtigung hängt von den Anforderungen der Mitarbeiter der zuständigen Kontrollbehörden und dem Gerätedesign ab und ist in dieser Anlage nicht festgelegt.- DSC_23
- Design und Formfaktor des REDCR ergeben sich aus dem kommerziellen Design innerhalb von ERC 70-03 und den Design- und Leistungsvorgaben in dieser Anlage (Abschnitt 5.3.2), wodurch der Markt über maximale Flexibilität verfügt, um die Ausrüstung nach den besonderen Anforderungen der zuständigen Kontrollbehörden für deren jeweilige Abfrageszenarios zu gestalten und bereitzustellen.
- DSC_24
- Design und Formfaktor der DSRC-VU und deren Positionierung innerhalb oder außerhalb der VU ergeben sich aus dem kommerziellen Design innerhalb der Vorgaben von ERC 70-03 und den in dieser Anlage (Abschnitt 5.3.2) und innerhalb dieses Abschnitts (5.1) angegebenen Design- und Leistungsvorgaben.
- DSC_25
- Allerdings muss die DSRC-VU auf angemessene Weise in der Lage sein, Datenkonzeptwerte anderer intelligenter Fahrzeugausrüstung über eine Verbindung und Protokolle eines offenen Branchenstandards zu akzeptieren (zum Beispiel von Geräten zum Wiegen an Bord), solange solche Datenkonzepte durch eindeutige und bekannte Anwendungskennungen/Dateinamen identifiziert sind und die Anweisungen zum Betrieb solcher Protokolle der Europäischen Kommission zur Verfügung gestellt werden und den Herstellern der relevanten Ausrüstung ohne Kosten verfügbar gemacht werden.
- 5.2
- Ablauf
- 5.2.1
- Betrieb
Der Betriebsablauf ist in Abbildung 14.5 dargestellt. (HINWEIS: Soll nicht übersetzt werden)Abbildung 14.5
Die Schritte werden im Folgenden beschrieben:- a.
- Immer, wenn sich das Fahrzeug in Betrieb befindet (Zündung eingeschaltet), stellt der Fahrtenschreiber der VU-Funktion Daten bereit. Die VU-Funktion bereitet die Daten für die Fernkommunikationsfunktion (verschlüsselt) vor und aktualisiert die VUPM im Speicher der DSRC-VU (gemäß Definition in 4.1.1.1 — 4.1.1.2). Die erfassten Daten sind wie in 5.4.4 bis 5.4.5 unten dargelegt zu formatieren.
- b.
- Jedes Mal, wenn die Daten aktualisiert werden, ist auch der im Sicherheitsdatenkonzept definierte Zeitstempel zu aktualisieren.
- c.
- Die VUSM-Funktion sichert die Daten gemäß den in Anlage 11 angegebenen Verfahren.
- d.
- Jedes Mal, wenn die Daten aktualisiert werden (siehe 4.1.1.1 bis 4.1.1.2), werden die Daten an die DSRC-VU übermittelt, wo sie alle vorherigen Daten ersetzen, damit die aktualisierten Daten (die Daten) immer zur Verfügung stehen, um bei einer Abfrage durch ein REDCR bereitgestellt zu werden. Wenn sie von der VU der DSRC-VU bereitgestellt werden, müssen die Daten anhand des Dateinamens RTMData oder Anwendungs-ID und Attributskennung zu identifizieren sein.
- e.
- Wenn ein Mitarbeiter der zuständigen Kontrollbehörden ein Fahrzeug anvisieren und von diesem die Daten erfassen möchte, muss der Mitarbeiter der zuständigen Kontrollbehörden zuerst seine Chipkarte in das REDCR einsetzen, um die Kommunikation zu ermöglichen und dem SM-REDCR zu ermöglichen, die Authentizität zu überprüfen und die Daten zu entschlüsseln.
- f.
- Anschließend visiert der Mitarbeiter der zuständigen Kontrollbehörde ein Fahrzeug an und fordert per Fernkommunikation die Daten an. Das REDCR eröffnet mit dem DSRC-VU des anvisierten Fahrzeugs eine 5,8-GHz-DSRC-Schnittstellensitzung und fordert die Daten an. Die Daten werden über das Drahtloskommunikationssystem als DSRC-Attribut mithilfe des Anwendungsdienstes GET gemäß 5.4 an das REDCR übermittelt. Das Attribut enthält die verschlüsselten Nutzdatenwerte und die DSRC-Sicherheitsdaten.
- g.
- Die Daten werden durch das REDCR-Gerät analysiert und dem Mitarbeiter der zuständigen Kontrollbehörde bereitgestellt.
- h.
- Der Mitarbeiter der zuständigen Kontrollbehörde nutzt die Daten zur Unterstützung bei der Entscheidung, ob er oder ein anderer Mitarbeiter der zuständigen Kontrollbehörde das Fahrzeug für eine umfangreiche Überprüfung anhalten soll.
- 5.2.2
- Interpretation der über die DSRC-Kommunikation empfangenen Daten
- DSC_26
- Für die über die 5,8-GHz-Schnittstelle empfangenen Daten gelten Bedeutung und Tragweite entsprechend der Definition in 5.4.4 und 5.4.5 unten und auch nur diese Bedeutung und Tragweite sind im Rahmen der hierin definierten Ziele zu verstehen. Gemäß den Bestimmungen der Verordnung (EU) Nr. 165/2014 dürfen die Daten nur dazu verwendet werden, einer zuständigen Kontrollbehörde zweckdienliche Informationen zur Hand zu geben, um zu entscheiden, welches Fahrzeug zu einer physischen Überprüfung angehalten werden soll, und müssen anschließend gemäß Artikel 9 der Verordnung (EU) Nr. 165/2014 vernichtet werden.
- 5.3
- Parameter der physischen DSRC-Schnittstelle zur Fernkommunikation
- 5.3.1
- Beschränkungen hinsichtlich des Ortes
- DSC_27
- Die Fernabfrage von Fahrzeugen über eine 5,8-GHz-DSRC-Schnittstelle sollte nicht innerhalb von 200 Metern um eine in Betrieb befindliche 5,8-GHz-DSRC-Brücke erfolgen.
- 5.3.2
- Downlink- und Uplinkparameter
- DSC_28
- Die zur Fahrtenschreiberfernüberwachung verwendete Ausrüstung muss ERC 70-03 und die in den Tabellen 14.1 und 14.2 unten definierten Parameter erfüllen und innerhalb dieser betrieben werden.
- DSC_29
- Zudem muss die zur Fahrtenschreiberfernüberwachung verwendete Ausrüstung, um Kompatibilität mit den Betriebsparametern anderer standardisierter 5,8-GHz-DSRC-Systeme zu gewährleisten, den Parametern aus EN 12253 und EN 13372 entsprechen.
| Punkt | Parameter | Wert(e) | Anmerkung |
|---|---|---|---|
| D1 | Downlink-Trägerfrequenzen | Dem REDCR stehen vier Alternativen zur Verfügung: 5,7975 GHz 5,8025 GHz 5,8075 GHz 5,8125 GHz | Innerhalb von ERC 70-03. Die Trägerfrequenzen können vom Implementierer des Straßenrandkontrollsystems ausgewählt werden und brauchen in der DSRC-VU nicht bekannt zu sein. (Konsistent mit EN 12253, EN 13372) |
| D1a(*) | Toleranz der Träger-frequenzen | innerhalb von ± 5 ppm | (Konsistent mit EN 12253) |
| D2(*) | RSU (REDCR)-Sendespektrumsmaske | Innerhalb von ERC 70-03. Das REDCR muss Klasse B,C gemäß EN 12253 entsprechen. Keine anderen spezifischen Anforderungen innerhalb dieses Anhangs | Parameter zur Kontrolle der Interferenz zwischen benachbarten Abfrageeinrichtungen (gemäß EN 12253 und EN 13372). |
| D3 | OBU (DSRC-VU)-Mindestfrequenzbereich | 5,795 — 5,815 GHz | (Konsistent mit EN 12253) |
| D4(*) | Max. E.I.R.P. | Innerhalb von ERC 70-03 (unlizenziert) und innerhalb der nationalen Vorschriften Max. + 33 dBm | (Konsistent mit EN 12253) |
| D4a | E.I.R.P.-Winkelmaske | Gemäß der deklarierten und veröffentlichten Spezifikation des Konstrukteurs der Abfrageeinrichtung | (Konsistent mit EN 12253) |
| D5 | Polarisation | Linkszirkular | (Konsistent mit EN 12253) |
| D5a | Kreuzpolarisation | XPD: In Achsensicht: (REDCR) RSU t ≥ 15 δB (DSRC-VU) OBU r ≥ 10 δB Im Bereich – 3 dB: (REDCR) RSU t ≥ 10 δB (DSRC-VU) OBU r ≥ 6 δB | (Konsistent mit EN 12253) |
| D6(*) | Modulation | Zweistufige Amplitudenmodulation | (Konsistent mit EN 12253) |
| D6a(*) | Modulationsindex | 0,5 … 0,9 | (Konsistent mit EN 12253) |
| D6b | Augendiagramm | ≥ 90 % (Zeit) / ≥ 85 % (Amplitude) | |
| D7(*) | Datenverschlüsselung | FM0 Bit „1” weist lediglich zu Beginn und Ende des Bit-Intervalls Übergänge auf. Bit „0” weist gegenüber dem Bit „1” in der Mitte des Bit-Intervalls einen zusätzlichen Übergang auf. | (Konsistent mit EN 12253) |
| D8(*) | Bit-Rate | 500 kBit/s | (Konsistent mit EN 12253) |
| D8a | Toleranz des Bit-Takts | besser als ± 100 ppm | (Konsistent mit EN 12253) |
| D9(*) | Bit-Fehlerquote (B.E.R.) zur Kommunikation | ≤ 10 – 6 wenn Vorlaufleistung bei OBU (DSRC-VU) in dem durch [D11a bis D11b] vorgegebenen Bereich liegt. | (Konsistent mit EN 12253) |
| D10 | Weckimpuls für OBU (DSRC-VU) | OBU (DSRC-VU) muss beim Empfang von Frames mit 11 oder mehr Oktetten (einschl. Präambel) aufwachen. | Es ist kein spezielles Weckmuster erforderlich. DSRC-VU kam beim Empfang von Frames mit weniger als 11 Oktetten aufwachen. (Konsistent mit EN 12253) |
| D10a | Maximale Startzeit | ≤ 5 ms | (Konsistent mit EN 12253) |
| D11 | Kommunikationsbereich | Raum, in dem eine B.E.R. gemäß D9a erreicht wird | (Konsistent mit EN 12253) |
| D11a(*) | (Obere) Leistungsgrenze zur Kommunikation. | – 24 dBm | (Konsistent mit EN 12253) |
| D11b(*) | (Untere) Leistungsgrenze zur Kommunikation. | Vorlaufleistung: – 43 dBm (Mittelachse) – 41 dBm (im Bereich von – 45° bis + 45° entsprechend der Ebene parallel zur Straßenoberfläche, wenn die DSRC-VU später im Fahrzeug installiert wird (Azimuth)) | (Konsistent mit EN 12253) Erweiterte Voraussetzungen für waagerechte Winkel bis ± 45° aufgrund der in diesem Anhang definierten Anwendungsfälle. |
| D12(*) | IVS-Leistungsgrenzwert (DSRC-VU) | – 60 dBm | (Konsistent mit EN 12253) |
| D13 | Präambel | Präambel vorgeschrieben. | (Konsistent mit EN 12253) |
| D13a | Präambellänge und -muster | 16 Bits ± 1 Bit FM0-kodierter „1” -Bits | (Konsistent mit EN 12253) |
| D13b | Präambelwellenform | Wechselnde Hoch-/Niedrigsequenz mit einer Impulsdauer von 2 μs. Toleranz gemäß D8a | (Konsistent mit EN 12253) |
| D13c | Nachlaufende Bits | Die RSU (REDCR) darf nach dem Endmerker maximal 8 Bits übertragen. Zur Berücksichtigung dieser zusätzlichen Bits ist keine OBU (DSRC-VU) erforderlich. | (Konsistent mit EN 12253) |
| Punkt | Parameter | Wert(e) | Anmerkung |
|---|---|---|---|
| U1(**) | Unterträgerfrequenzen | Eine OBU (DSRC-VU) unterstützt 1,5 MHz und 2,0 MHz Eine RSU (REDCR) unterstützt 1,5 MHz oder 2,0 MHz oder beides U1-0: 1,5 MHz U1-1: 2,0 MHz | Auswahl der Unterträgerfrequenz (1,5 MHz oder 2,0 MHz) abhängig vom ausgewählten EN-13372-Profil. |
| U1a(**) | Toleranz der Unterträgerfrequenzen | innerhalb von ± 0,1 % | (Konsistent mit EN 12253) |
| U1b | Nutzung von Seitenbändern | Gleiche Daten auf beiden Seiten | (Konsistent mit EN 12253) |
| U2(**) | OBU (DSRC-VZ)-Sendespektrumsmaske | Gemäß EN 12253
| (Konsistent mit EN 12253) |
| U4a(**) | Max. Einseitenband-E.I.R.P. (Mittelachse) | Zwei Optionen: U4a-0: – 14 dBm U4a-1: – 21 dBm | Gemäß der deklarierten und veröffentlichten Spezifikation des Konstrukteurs der Ausrüstung |
| U4b(**) | Max. Einseitenband-E.I.R.P. (35°) | Zwei Optionen:
| Gemäß der deklarierten und veröffentlichten Spezifikation des Konstrukteurs der Ausrüstung |
| U5 | Polarisation | Linkszirkular | (Konsistent mit EN 12253) |
| U5a | Kreuzpolarisation | XPD: In Achsensicht: (REDCR) RSU r ≥ 15 δB (DSRC-VU) OBU t ≥ 10 δB Bei -3 dB: (REDCR) RSU r ≥ 10 δB (DSRC-VU) OBU t ≥ 6 δB | (Konsistent mit EN 12253) |
| U6 | Unterträgermodulation | 2-PSK Verschlüsselte Daten, mit Unterträger synchronisiert: Übergänge verschlüsselter Daten fallen mit Übergängen des Unterträgers zusammen. | (Konsistent mit EN 12253) |
| U6b | Arbeitszyklus | Arbeitszyklus: 50 % ± α, α ≤ 5 % | (Konsistent mit EN 12253) |
| U6c | Modulation auf Träger | Multiplikation von moduliertem Unterträger mit Träger. | (Konsistent mit EN 12253) |
| U7(**) | Datenverschlüsselung | NRZI (kein Übergang bei Beginn von „1” -Bit, Übergang bei Beginn von „0” -Bit, kein Übergang innerhalb des Bits) | (Konsistent mit EN 12253) |
| U8(**) | Bit-Rate | 250 kBit/s | (Konsistent mit EN 12253) |
| U8a | Toleranz des Bit-Takts | Innerhalb von ± 1000 ππμ | (Konsistent mit EN 12253) |
| U9 | Bit-Fehlerquote (B.E.R.) für die Kommunikation | ≤ 10–6 | (Konsistent mit EN 12253) |
| U11 | Kommunikationsbereich | Raum, innerhalb dessen sich die DSRC-VU befindet, damit ihre Übertragungen von dem REDCR mit einer B.E.R. von weniger als dem Wert empfangen werden, der durch U9a vorgegeben wird. | (Konsistent mit EN 12253) |
| U12a(**) | Umwandlungsverstärkung (unterer Grenzwert) | 1 dB für jedes Seitenband Winkelbereich: zirkular symmetrisch zwischen Mittelachse und ± 35° sowie | |
| im Bereich von – 45° bis + 45° entsprechend der Ebene parallel zur Straßenoberfläche, wenn die DSRC-VU später im Fahrzeug installiert wird (Azimuth) | Größer als der angegebene Wertbereich für waagerechte Winkel bis ± 45° aufgrund der in diesem Anhang definierten Anwendungsfälle. | ||
| U12b(**) | Umwandlungsverstärkung (oberer Grenzwert) | 10 dB für jedes Seitenband | Kleiner als der angegebene Wertbereich für jedes Seitenband innerhalb eines Kreiskegels um Mittelachse ± mit einem Öffnungswinkel von 45°. |
| U13 | Präambel | Präambel vorgeschrieben. | (Konsistent mit EN 12253) |
| U13a | Präambel Länge und Muster | 32 bis 36 μs lediglich mit Unterträger moduliert, anschließend 8 Bits NRZI-kodierter „0” -Bits. | (Konsistent mit EN 12253) |
| U13b | Nachlaufende Bits | Die DSRC-VU darf nach dem Endmerker maximal 8 Bits übertragen. Zur Berücksichtigung dieser zusätzlichen Bits ist keine RSU (REDCR) erforderlich. | (Konsistent mit EN 12253) |
- 5.3.3
- Antennendesign
- 5.3.3.1
- REDCR-Antenne
- DSC_30
- Das Design der REDCR-Antenne ergibt sich aus dem kommerziellen Design, innerhalb der in 5.3.2 definierten Grenzen und angepasst zur Optimierung der Leseleistung des DSRC-REDCR für spezielle Zwecke und Lesebedingungen, innerhalb derer das REDCR betrieben wird.
- 5.3.3.2
- VU-Antenne
- DSC_31
- Das Design der DSRC_VU-Antenne ergibt sich aus dem kommerziellen Design, innerhalb der in 5.3.2 definierten Grenzen und angepasst zur Optimierung der Leseleistung des DSRC-REDCR für spezielle Zwecke und Lesebedingungen, innerhalb derer das REDCR betrieben wird.
- DSC_32
- Die VU-Antenne ist an oder in der Frontscheibe des Fahrzeugs gemäß 5.1 oben zu befestigen.
- DSC_33
- In der Prüfumgebung in einer Werkstatt (siehe Abschnitt 6.3) muss eine gemäß 5.1 oben angebrachte DSRC-VU-Antenne erfolgreich eine Verbindung mit einer standardmäßigen Prüfkommunikation herstellen und eine RTM-Transaktion gemäß dieser Anlage über eine Entfernung von 2–10 Metern, in mehr als 99 % der Fälle, gemittelt über 1000 Leseabfragen bereitstellen.
- 5.4
- DSRC-Protokollanforderungen für RTM
- 5.4.1
- Überblick
- DSC_34
- Das Transaktionsprotokoll zum Herunterladen der Daten über die 5,8-GHz-DSRC-Schnittstellenverbindung muss folgende Schritte unterstützen. Dieser Abschnitt beschreibt den Transaktionsablauf unter Idealbedingungen ohne Rücktransaktionen oder Kommunikationsunterbrechungen.
HINWEIS Zweck der Initialisierungsphase (Schritt 1) ist es, die Kommunikation zwischen REDCR und denjenigen DSRC-VU, die in den 5,8-GHz-DSRC (Master-Slave)-Transaktionsbereich eingetreten sind, aber noch keine Kommunikation mit dem REDCR hergestellt haben, einzurichten und die Anwendungsprozesse zu informieren.
- — Schritt 1
- Initialisieren. Das REDCR sendet einen Frame mit einer „Beacon Service Table” (BST) samt unterstützter Anwendungskennungen (AID) in der Dienstliste. In der RTM-Anwendung ist dies einfach der Dienst mit AID-Wert = 2 (Freight&Fleet). Die DSRC-VU wertet die empfangene BST aus und antwortet (siehe unten) mit der Liste unterstützter Anwendungen in der Domäne Freight&Fleet; wenn keine Anwendungen unterstützt werden, antwortet sie nicht. Wenn das REDCR nicht AID=2 anbietet, soll die DSRC-VU dem REDCR nicht antworten.
- — Schritt 2
- Die DSRC-VU sendet einen Frame mit einer Anfrage nach Zuweisung eines privaten Fensters.
- — Schritt 3
- Die REDCR sendet einen Frame mit Zuweisung eines privaten Fensters.
- — Schritt 4
- Die DSRC-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 diese DSRC-VU im Rahmen von AID=2 unterstützt. Die verschiedenen Instanziierungen sind durch einzeln generierte EID zu identifizieren, von denen jede mit einem Anwendungskontextmarkierung-Parameterwert verbunden ist, der die Anwendung und die unterstützte Norm angibt.
- — Schritt 5
- Anschließend analysiert das REDCR die angebotene VST und beendet entweder die Verbindung (RELEASE), da das Angebot der VST nicht interessant ist (d. h., es erhält von der DSRC-VU eine VST, die die RTM-Transaktion nicht unterstützt), oder es erhält eine passende VST und startet die Instanziierung der App.
- — Schritt 6
- Dazu sendet das REDCR einen Frame mit einem Befehl zum Abruf der RTM-Daten, in dem die RTM-Anwendung durch Angabe der Kennung zur Instanziierung der RTM-Anwendung (wie von der DSRC-VU in der VST angegeben) und soll ein privates Fenster zuweisen.
- — Schritt 7
- Die DSRC-VU sendet mit dem neu zugewiesenen privaten Fenster einen Frame, der die in der VST genannte adressierte Kennung zur Instanziierung der RTM-Anwendung gefolgt von dem Attribut RtmData (Nutzlast- + Sicherheitselement) enthält.
- — Schritt 8
- Wenn mehrere Dienste angefragt werden, wird der Wert „n” auf die nächste Dienstreferenznummer gesetzt und der Prozess wiederholt.
- — Schritt 9
- Das REDCR bestätigt den Erhalt der Daten, indem es einen Frame sendet, der der DSRC-VU einen RELEASE-Befehl sendet, die Sitzung zu beenden, ODER wechselt, falls es den erfolgreichen Erhalt des LDPU nicht validieren konnte, zurück zu Schritt 6.
Siehe Abbildung 14.6 als bildliche Darstellung des Transaktionsprotokolls.
Abbildung 14.6
- 5.4.2
- Befehle
- DSC_35
- Nur die folgenden Befehle werden in einer RTM-Transaktionsphase verwendet:
- — INITIALISATION.request:
- Vom REDCR in Form eines Broadcast ausgegebener Befehl mit der Definition der vom REDCR unterstützten Befehle.
- — INITIALISATION.response:
- Antwort der DSRC-VU, die die Verbindung bestätigt und eine Liste unterstützter Anwendungsinstanzen und der Angaben, wie diese adressiert werden (EID), enthält.
- — GET.request:
- Vom REDCR an die DSRC-VU ausgegebener Befehl, der die zu adressierende Anwendungsinstanziierung durch eine definierte EID, wie in der VST erhalten, angibt und die DSRC-VU anweist, das bzw. die ausgewählten Attribute mit den Daten zu senden. Ziel des GET-Befehls ist es, dass das REDCR die Daten von der DSRC-VU erhält.
- — GET.response:
- Antwort der DSRC-VU mit den angeforderten Daten.
- — ACTION.request ECHO:
- Befehl, der die DSRC-VU anweist, die von der DSRC-VU erhaltenen Daten an das REDCR zurückzusenden. Ziel des ECHO-Befehls ist es, Werkstätten oder Prüfeinrichtungen zur Typgenehmigung in die Lage zu versetzen, zu prüfen, ob der DSRC-Link funktioniert, ohne auf die Sicherheitsangaben zugreifen zu müssen.
- — ACTION.response ECHO:
- Antwort der DSRC VU auf den ECHO-Befehl.
- — EVENT_REPORT.request RELEASE:
- Befehl, der der DSRC-VU mitteilt, dass die Transaktion beendet ist. Ziel des RELEASE-Befehls ist es, die Sitzung mit der DSRC-VU zu beenden. Bei Erhalt von RELEASE darf die DSRC-VU nicht mehr auf weitere Abfragen im Rahmen der aktuellen Verbindung antworten. Hinweis: Gemäß EN 12834 stellt eine DSRC-VU nur dann eine zweite Verbindung zur selben Abfrageeinrichtung her, wenn sie sich 255 Sekunden lang außerhalb des Kommunikationsbereichs befunden hat oder wenn sich die Beacon-ID der Abfrageeinrichtung geändert hat.
- 5.4.3
- Abfragebefehlssequenz
- DSC_36
- Aus Perspektive der Befehl-Antwort-Sequenz lässt sich die Transaktion wie folgt beschreiben:
Sequenz Sender Empfänger Beschreibung Handlung 1 REDCR > DSRC-VU Initialisierung des Kommunikations-Links — Anforderung REDCR sendet BST 2 DSRC-VU > REDCR Initialisierung des Kommunikations-Links — Antwort Wenn die BST AID=2 unterstützt, dann fordert die DSCR-VU ein privates Fenster an 3 REDCR > DSRC-VU Gewährt ein privates Fenster Sendet Frame mit Zuweisung eines privaten Fensters 4 DSRC-VU > REDCR Sendet VST Sendet Frame mit VST 5 REDCR > DSRC-VU Sendet GET.request für in Attribut enthaltene Daten für spezifische EID 6 DSRC-VU > REDCR Sendet GET.response mit angefordertem Attribut für spezifische EID Sendet Attribut (RTMData, OWSData …) mit Daten für spezifische EID 7 REDCR > DSRC-VU Sendet GET.request für Daten anderer Attribute (falls zutreffend) 8 DSRC-VU > REDCR Sendet GET.response mit angefordertem Attribut Sendet Attribut mit Daten für spezifische EID 9 REDCR > DSRC-VU Bestätigt erfolgreichen Empfang der Daten Sendet RELEASE-Befehl, der die Transaktion beendet 10 DSRC-VU Beendet Transaktion Ein Beispiel für Transaktionssequenz und -inhalte der 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.
- EncryptedTachographPayload-Daten, der Verschlüsselung von TachographPayload gemäß ASN.1 in Abschnitt 5.4.5. Die Verschlüsselungsmethode ist in Anlage 11 beschrieben.
- 2.
- DSRCSecurityData, angegeben in Anlage 11.
- DSC_39
- Die RTM-Daten werden als RTM-Attribut=1 adressiert und im RTM-Container =10 übertragen.
- DSC_40
- Die RTM-ContextMark soll das unterstützte Standardteil in der TARV-Normenreihe (RTM entspricht Teil 9) identifizieren.
Das ASN.1-Modul für die DSRC-Daten innerhalb der RTM-Anwendung ist wie folgt definiert:
- 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 entnimmt den Wert für das tp15638VehicleRegistrationPlate-Datenelement RTM1 aus dem aufgezeichneten Wert des Datentyps
VehicleRegistrationIdentification gemäß Anlage 1 VehicleRegistrationIdentification.
Kennzeichen des Fahrzeugs als Zeichenstring tp15638VehicleRegistrationPlate LPN,
--Kennzeichen des Fahrzeugs unter Verwendung der Datenstruktur nach ISO 14906, aber mit folgender Einschränkung für die RTM-Anwendung:
Die SEQUENZ beginnt mit dem Ländercode, gefolgt von einem alphabetischen Indikator, gefolgt von der Kennzeichennummer selbst,
die immer 14 Oktette umfasst (aufgefüllt mit Nullen), sodass die LPN-Typenlänge immer 17 Oktette beträgt (keine Längendeterminante erforderlich), von denen 14 das „tatsächliche” Kennzeichen sind.
RTM2
Geschwindigkeitsüberschreitung
Die VU erstellt einen booleschen
Wert für das Datenelement RTM2
tp15638SpeedingEvent.
Der Wert tp15638SpeedingEvent wird von der VU anhand der in der VU aufgezeichneten Anzahl an Geschwindigkeitsüberschreitungen innerhalb der letzten 10 Tage gemäß Definition in Anhang IC berechnet.
1 (TRUE): wenn das letzte Ereignis einer Geschwindigkeitsüberschreitung innerhalb der letzten 10 Tage beendet wurde oder noch anhält;
0 (FALSE): in allen anderen Fällen.
tp15638SpeedingEvent BOOLEAN, RTM3
Lenken ohne
gültige Karte
Die VU erstellt einen booleschen
Wert für das Datenelement RTM3
tp15638DrivingWithoutValidCard.
Die VU weist der Variablen tp15638DrivingWithoutValidCard den Wert TRUE zu, wenn die VU in den letzten 10 Tagen mindestens ein Ereignis des Typs „Lenken ohne geeignete Karte” gemäß Anhang IC aufgezeichnet hat.
1 (TRUE): wenn das letzte Ereignis des Lenkens ohne geeignete Karte innerhalb der letzten 10 Tage beendet wurde oder noch anhält;
0 (FALSE): in allen anderen Fällen.
tp15638DrivingWithoutValidCard
BOOLEAN,
RTM4
Gültige Fahrerkarte
Die VU erstellt einen booleschen Wert für das Datenelement RTM4
tp15638DriverCard auf Grundlage der im Steckplatz Fahrer eingesteckten gültigen Fahrerkarte.
1 (TRUE): wenn keine gültige Fahrerkarte im Steckplatz Fahrer der VU eingesteckt ist;
0 (FALSE): wenn eine gültige Fahrerkarte im Steckplatz Fahrer der VU eingesteckt ist.
tp15638DriverCard BOOLEAN, RTM5
Einstecken der Karte während
des Lenkens
Die VU generiert einen booleschen Wert für das Datenelement RTM5 tp15638CardInsertion.
Die VU weist der Variablen tp15638CardInsertion den Wert TRUE zu, wenn die VU in den letzten 10 Tagen mindestens ein Ereignis des Typs „Einstecken der Karte während des Lenkens” gemäß Anhang IC aufgezeichnet hat.
1 (TRUE): wenn das letzte Ereignis „Einstecken der Karte während des Lenkens” innerhalb der letzten 10 Tage stattgefunden hat;
0 (FALSE): in allen anderen Fällen.
tp15638CardInsertion BOOLEAN, RTM6
Bewegungsdatenfehler
Die VU erstellt einen booleschen
Wert für das Datenelement RTM6.
Die VU weist der Variablen tp15638MotionDataError den Wert TRUE zu, wenn die VU in den letzten 10 Tagen mindestens ein Ereignis des Typs „Bewegungsdatenfehler” gemäß Anhang IC aufgezeichnet hat.
1 (TRUE): wenn das letzte Ereignis „Bewegungsdatenfehler” innerhalb der letzten 10 Tage beendet wurde oder noch anhält;
0 (FALSE): in allen anderen Fällen.
tp15638MotionDataError BOOLEAN, RTM7
Datenkonflikt
Fahrzeugbewegung
Die VU erstellt einen booleschen
Wert für das Datenelement RTM7.
Die VU weist der Variablen tp15638VehicleMotionConflict den Wert TRUE zu, wenn die VU in den letzten 10 Tagen mindestens ein Ereignis „Datenkonflikt Fahrzeugbewegung” aufgezeichnet hat.
1 (TRUE): wenn das letzte Ereignis „Datenkonflikt Fahrzeugbewegung” innerhalb der letzten 10 Tage beendet wurde oder noch anhält;
0 (FALSE): in allen anderen Fällen.
tp15638VehicleMotionConflict
BOOLEAN,
RTM8
Zweite Fahrerkarte
Die VU erstellt einen booleschen
Wert für das Datenelement RTM8 auf Grundlage des Anhangs IC (Fahrertätigkeitsdaten TEAM und BEIFAHRER).
Wenn eine gültige Beifahrerkarte in der VU vorhanden ist, setzt die VU RTM8 auf TRUE.
1 (TRUE): wenn eine gültige Beifahrerkarte in der VU vorhanden ist;
2 (FALSE): wenn keine gültige Beifahrerkarte in der VU vorhanden ist.
tp156382ndDriverCard BOOLEAN, RTM9
Derzeitige Tätigkeit
Die VU erstellt einen booleschen
Wert für das Datenelement RTM9.
Wenn die VU als derzeitige Tätigkeit eine andere Tätigkeit als „LENKEN” gemäß Anhang IC aufzeichnet, muss die VU RTM9 auf TRUE setzen.
1 (TRUE): andere Tätigkeit
ausgewählt;
0 (FALSE): Lenken ausgewählt
tp15638CurrentActivityDriving
BOOLEAN
RTM10
Letzter Vorgang abgeschlossen
Die VU generiert einen booleschen Wert für das Datenelement RTM10.
Wenn die letzte Kartensitzung nicht korrekt gemäß Anlage IC abgeschlossen wird, muss die VU RTM10 auf TRUE setzen.
1 (TRUE): mindestens eine der eingesteckten Karten hat ein Ereignis „Letzter Vorgang nicht korrekt abgeschlossen” ausgelöst;
0 (FALSE): keine der eingesteckten Karten hat ein Ereignis „Letzter Vorgang nicht korrekt abgeschlossen” ausgelöst.
tp15638LastSessionClosed
BOOLEAN
RTM11
Unterbrechung der
Stromversorgung
Die VU generiert einen Integer-
Wert für das Datenelement RTM11.
Die VU weist der Variablen tp15638PowerSupplyInterruption einen Wert gleich der in den letzten 10 Tagen gespeicherten Anzahl der Ereignisse „Unterbrechung der Stromversorgung” gemäß Anhang IC zu.
Wenn kein Ereignis „Unterbrechung der Stromversorgung” innerhalb der letzten 10 Tage in der VU aufgezeichnet wurde, wird RTM11 auf den Wert „0” gesetzt.
Anzahl der aufgezeichneten Unterbrechungen der Stromversorgung innerhalb der letzten 10 Tage. tp15638PowerSupplyInterruption
INTEGER (0..127),
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 ein Ereignis des Typs „35” H Sensorstörung
in den letzten 10 Tagen beendet wurde oder noch anhält.
- —
2, wenn ein Ereignis des Typs GNSS-Empfängerstörung (intern oder extern Enum „36” H oder
„37” H) in den letzten 10 Tagen beendet wurde oder noch anhält.
- —
3, wenn ein Ereignis des Typs „0E” H Kommunikationsfehler mit der externen GNSS-Ausrüstung in den letzten 10 Tagen beendet wurde oder noch anhält.
- —
4, wenn Ereignisse sowohl des Typs Sensorstörung als auch des Typs GNSS-Empfängerstörung in den letzten 10 Tagen beendet wurden oder noch anhalten.
- —
5, wenn Ereignisse sowohl des Typs Sensorstörungen als auch des Typs Kommunikationsfehler mit der externen GNSS-Ausrüstung in den letzten 10 Tagen beendet wurden oder noch anhalten.
- —
6, wenn Ereignisse sowohl des Typs GNSS-Empfängerstörungen als auch des Typs Kommunikationsfehler mit der externen GNSS-Ausrüstung in den letzten 10 Tagen beendet wurden oder noch anhalten.
- —
7, wenn alle drei Arten von Sensorstörungen in den letzten 10 Tagen beendet wurden oder noch anhalten.
Wenn kein Ereignis in den letzten 10 Tagen beendet wurde oder noch anhält, setzt die VU RTM12 auf den Wert „0” .
– Sensorstörung ein Oktett gemäß Datenglossar tp15638SensorFault INTEGER (0..255), RTM13
Zeiteinstellung
Für das Datenelement RTM13 generiert die VU einen Integer-Wert (timeReal gemäß Anlage 1) auf Grundlage des Vorliegens von Zeiteinstellungsdaten gemäß Anhang IC.
Die VU weist RTM13 den Zeitwert zu, an dem das letzte Ereignis „Zeiteinstellung” erfolgt ist.
Wenn in der VU kein Ereignis „Zeiteinstellung” gemäß Anhang IC vorhanden ist, setzt die VU RTM13 auf den Wert „0” .
„oldTimeValue” der letzten Zeiteinstellung. tp15638TimeAdjustment
INTEGER(0..4294967295),
RTM14
Versuch
Sicherheitsverletzung
Für das Datenelement RTM14 generiert die VU einen Integer-Wert (timeReal gemäß Anlage 1) auf Grundlage des Vorliegens eines Ereignisses „Versuch Sicherheitsverletzung” gemäß Anhang C.
Die VU setzt den Wert auf den Zeitpunkt des letzten von der VU verzeichneten sicherheitsverletzenden Versuchs.
Wenn in der VU kein Ereignis „Versuch Sicherheitsverletzung” gemäß Anhang IC vorhanden ist, setzt die VU RTM14 auf den Wert „0” .
Zeit des Beginns des letzten gespeicherten Ereignisses „Versuch Sicherheitsverletzung” . tp15638LatestBreachAttempt
INTEGER(0..4294967295),
RTM15
Letzte Kalibrierung
Für das Datenelement RTM15 generiert die VU einen Integer-Wert (timeReal gemäß Anlage 1) auf Grundlage des Vorliegens von letzten Kalibrierungsdaten gemäß Anhang IC und Anlage 1.
Die VU setzt den Wert
für RTM15 auf „oldTimeValue” des letzten Kalibrierungsdatensatzes.
Wenn keine Kalibrierung vorliegt, setzt die VU RTM15 auf den Wert „0” .
„oldTimeValue” des letzten Kalibrierungsdatensatzes. tp15638LastCalibrationData
INTEGER(0..4294967295),
RTM16
Vorherige Kalibrierung
Für das Datenelement RTM16 generiert die VU einen Integer-Wert (timeReal gemäß Anlage 1) auf der Grundlage des Kalibrierungsdatensatzes, der der letzten Kalibrierung vorausgeht.
Die VU setzt den Wert
für RTM16 auf „oldTimeValue” des Kalibrierungsdatensatzes vor der letzten Kalibrierung.
Wenn keine vorherige Kalibrierung vorliegt, setzt die VU RTM16 auf den Wert „0” .
„oldTimeValue” des Kalibrierungsdatensatzes, der dem letzten Kalibrierungsdatensatz vorausgeht. tp15638PrevCalibrationData
INTEGER(0..4294967295),
RTM17
Anschlussdatum des
Fahrtenschreibers
Die VU generiert einen Integer-Wert (timeReal gemäß Anlage 1) für das Datenelement RTM17.
Die VU setzt den Wert für RTM17 auf das Datum der ersten Kalibrierung der VU im aktuellen Fahrzeug.
Die VU extrahiert diese Daten aus VuCalibrationData (Anlage 1) aus vuCalibrationRecords, wobei CalibrationPurpose gleich: „03” H ist.
Wenn keine vorherige Kalibrierung vorliegt, setzt die VU RTM17 auf den Wert „0” .
Datum der ersten Kalibrierung der VU im aktuellen Fahrzeug. tp15638DateTachoConnected
INTEGER(0..4294967295),
RTM18
Aktuelle Geschwindigkeit
Die VU generiert einen Integer-
Wert für das Datenelement RTM18.
Die VU setzt den Wert für RTM18 auf die bei der jüngsten Aktualisierung von RtmData zuletzt als aktuell aufgezeichnete Geschwindigkeit.
Zuletzt als aktuell aufgezeichnete Geschwindigkeit tp15638CurrentSpeed INTEGER (0..255), RTM19
Zeitstempel
Die VU generiert einen Integer-Wert für das Datenelement RTM19 (timeReal gemäß Anlage 1).
Die VU setzt den Wert für RTM19 auf den Zeitpunkt der jüngsten Aktualisierung von RtmData.
Zeitstempel des aktuellen Datensatzes
TachographPayload
tp15638Timestamp
INTEGER(0..4294967295),
RTM20
Zeitpunkt der Verfügbarkeit der letzten authentisierten Fahrzeugposition
Die VU generiert einen Integer-Wert (timeReal gemäß Anlage 1) für das Datenelement RTM20.
Die VU setzt den Wert von RTM20 auf den Zeitpunkt, an dem die letzte authentisierte Fahrzeugposition vom GNSS-Empfänger verfügbar war.
Wenn noch nie eine authentisierte Fahrzeugposition vom GNSS-Empfänger verfügbar war, setzt die VU RTM20 auf den Wert „0” .
Zeitstempel der letzten authentisierten Fahrzeugposition tp15638LatestAuthenticatedPosition
INTEGER(0..4294967295),
RTM21
Ununterbrochene Lenkzeit
Die VU generiert einen Integer-Wert für das Datenelement RTM21.
Die VU setzt den Wert für RTM21 auf den Zeitpunkt der laufenden ununterbrochenen Lenkzeit des Fahrers.
Ununterbrochene Lenkzeit des Fahrers, kodiert als Integer-Wert.
Länge: 1 Byte
Auflösung: 2 Minuten/Bit
Kein Offset
Datenbereich: 0 bis 250
Ein Wert von 250 gibt an, dass die ununterbrochene Lenkzeit des Fahrers mindestens 500 Minuten beträgt.
Die Werte 251 bis 254 werden nicht genutzt.
Der Wert 255 gibt an, dass die Informationen nicht verfügbar sind.
tp15638ContinuousDrivingTime INTEGER(0..255), RTM22
Längste tägliche Lenkzeit des Fahrers für die derzeit laufende und die vorherige RTM-Schicht, berechnet gemäß Beiblatt zur Anlage 14
Die VU generiert einen Integer-Wert für das Datenelement RTM22.
Die VU setzt den Wert für RTM22 auf die längere der beiden täglichen Lenkzeiten des Fahrers, d. h. entweder die laufende oder die vorherige RTM-Schicht.
Tägliche Lenkzeit des Fahrers, kodiert als Integer-Wert.
Länge: 1 Byte
Auflösung: 4 Minuten/Bit
Kein Offset
Datenbereich: 0 bis 250
Ein Wert von 250 gibt an, dass die tägliche Lenkzeit des Fahrers mindestens 1000 Minuten beträgt.
Die Werte 251 bis 254 werden nicht genutzt.
Der Wert 255 gibt an, dass die Informationen nicht verfügbar sind.
tp15638DailyDrivingTimeShift INTEGER(0..255), RTM23
Längste tägliche Lenkzeit des Fahrers innerhalb der derzeit laufenden Woche, berechnet gemäß Beiblatt zur Anlage 14
Die VU generiert einen Integer-Wert für das Datenelement RTM23.
Die VU setzt den Wert für RTM23 auf die längste tägliche Lenkzeit des Fahrers; dies ist entweder die laufende RTM-Schicht oder eine abgeschlossene RTM-Schicht, die in der laufenden Woche begonnen oder beendet wurde.
Tägliche Lenkzeit des Fahrers, kodiert als Integer-Wert.
Länge: 1 Byte
Auflösung: 4 Minuten/Bit
Kein Offset
Datenbereich: 0 bis 250
Ein Wert von 250 gibt an, dass die tägliche Lenkzeit des Fahrers mindestens 1000 Minuten beträgt.
Die Werte 251 bis 254 werden nicht genutzt.
Der Wert 255 gibt an, dass die Informationen nicht verfügbar sind.
tp15638DailyDrivingTimeWeek INTEGER(0..255), RTM24
Wöchentliche Lenkzeit des Fahrers, berechnet gemäß Beiblatt zur Anlage 14
Die VU generiert einen Integer-Wert für das Datenelement RTM24.
Die VU setzt den Wert für RTM24 auf die wöchentliche Lenkzeit des Fahrers.
Wöchentliche Lenkzeit des Fahrers, kodiert als Integer-Wert.
Länge: 1 Byte
Auflösung: 20 Minuten/Bit
Kein Offset
Datenbereich: 0 bis 250
Ein Wert von 250 gibt an, dass die wöchentliche Lenkzeit des Fahrers mindestens 5000 Minuten beträgt.
Die Werte 251 bis 254 werden nicht genutzt.
Der Wert 255 gibt an, dass die Informationen nicht verfügbar sind.
tp15638WeeklyDrivingTime INTEGER(0..255), RTM25
Vierzehntägige Lenkzeit des Fahrers, berechnet gemäß Beiblatt zur Anlage 14
Die VU generiert einen Integer-Wert für das Datenelement RTM25.
Die VU setzt den Wert für RTM25 auf die vierzehntägige Lenkzeit des Fahrers.
Vierzehntägige Lenkzeit des Fahrers, kodiert als Integer-Wert.
Länge: 1 Byte
Auflösung: 30 Minuten/Bit
Kein Offset
Datenbereich: 0 bis 250
Ein Wert von 250 gibt an, dass die ununterbrochene Lenkzeit des Fahrers mindestens 7500 Minuten beträgt.
Die Werte 251 bis 254 werden nicht genutzt.
Der Wert 255 gibt an, dass die Informationen nicht verfügbar sind.
tp15638FortnightlyDrivingTime INTEGER(0..255), Hinweis: RTM22, RTM23, RTM24 und RTM25 werden gemäß dem Beiblatt zur dieser Anlage berechnet.
- 5.4.6
- Mechanismus der Datenübertragung
- DSC_42
- Die zuvor definierten Nutzlastdaten werden vom REDCR nach der Initialisierungsphase abgerufen und anschließend von der DSRC-VU im zugewiesenen Fenster übertragen. Zum Abrufen der Daten verwendet das REDCR den Befehl GET.
- DSC_43
- Bei jedem DSRC-Austausch werden die Daten mit PER (Packed Encoding Rules) UNALIGNED verschlüsselt, mit Ausnahme von
und 
, 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
Feld Einstellungen Link Identifier Broadcast-Adresse BeaconId Gemäß EN 12834 Time Gemäß EN 12834 Profile Keine Erweiterung, 0 oder 1 verwenden MandApplications Keine Erweiterung, EID nicht vorhanden, Parameter nicht vorhanden, AID=2 Freight&Fleet NonMandApplications Nicht vorhanden ProfileList Keine Erweiterung, Anzahl Profile in Liste = 0 Fragmentation header Keine Fragmentierung Layer 2 settings Befehls-PDU, UI-Befehl Ein praktisches Beispiel der in Tabelle 14.4 angegebenen Einstellungen samt Angabe der Bit-Verschlüsselungen findet sich in der folgenden Tabelle 14.5.
Tabelle 14.5
Initialisierung — Beispiele für die Inhalte von BST-Frames
Oktett # Attribut/Feld Bits in Oktett Beschreibung 1 FLAG 
Anfangsmerker 2 Broadcast ID 
Broadcast-Adresse 3 MAC Control Field 
PDU-Befehl 4 LLC Control field 
UI-Befehl 5 Fragmentation header 
Keine Fragmentierung 6 BST 
Initialisierungsanfrage SEQUENCE { OPTION indicator
BeaconID
SEQUENCE {
ManufacturerId
INTEGER (0..65535)
NonMand-Anwendungen nicht vorhanden 
Herstellerkennung 7 
8 
IndividualID
INTEGER (0..134217727)
}
27-Bit-ID für Hersteller verfügbar 9 
10 
11 
12 Time
INTEGER (0..4294967295)
32-Bit-UNIX-Realtime 13 
14 
15 
16 Profile
INTEGER (0..127, …)
Keine Erweiterung. Beispielprofil 0 17 MandApplications
SEQUENCE (SIZE(0..127, …)) OF {
Keine Erweiterung, Anzahl mandApplications = 1 18 SEQUENCE { OPTION indicator 
EID nicht vorhanden OPTION indicator 
Parameter nicht vorhanden AID
DSRCApplicationEntityID } }
Keine Erweiterung. AID=2 Freight&Fleet 19 ProfileList
SEQUENCE (0..127, …) OF Profile }
Keine Erweiterung, Anzahl Profile in Liste = 0 20 FCS 
Frame-Überprüfungssequenz 21 
22 Flag 
Endmerker
- 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
Oktett # Attribut/Feld Bits in Oktett Beschreibung 1 FLAG 
Anfangsmerker 2 Private LID 
Link-Adresse der spezifischen DSRC-VU 3 
4 
5 
6 MAC Control Field 
Anforderung eines privaten Fensters 7 FCS 
Frame-Überprüfungssequenz 8 
9 Flag 
Endmerker
- 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
Oktett # Attribut/Feld Bits in Oktett Beschreibung 1 FLAG 
Anfangsmerker 2 Private LID 
Link-Adresse der spezifischen DSRC-VU 3 
4 
5 
6 MAC Control Field 
Zuweisung eines privaten Fensters 7 FCS 
Frame-Überprüfungssequenz 8 
9 Flag 
Endmerker
- DSC_47
- Wenn sie die Zuweisung des privaten Fensters erhält, sendet die DSRC-VU ihre VST (Vehicle Service Table) gemäß EN 12834 und EN 13372, 6.2, 6.3, 6.4 und 7.1 mit den Einstellungen aus Tabelle 14.8, unter Verwendung des zugewiesenen Übertragungsfensters.
Tabelle 14.8
Initialisierung — VST-Frame-Einstellungen
Feld Einstellungen Private LID Gemäß EN 12834 VST-Parameter Fill=0, anschließend für jede unterstützte Anwendung: EID vorhanden, Parameter vorhanden,AID=2, EID wie durch OBU generiert Parameter Keine Erweiterung, enthält die RTM-ContextMark ObeConfiguration Fakultativ kann das Feld „ObeStatus” vorliegen, es soll nicht von REDCR verwendet werden. Fragmentation header Keine Fragmentierung Layer 2 settings Befehls-PDU, UI-Befehl
- 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-ContextMark, zusammengesetzt aus einer OBJEKTKENNUNG für die zugehörige Norm, den entsprechenden Teil (9 für RTM) und möglicherweise die Version sowie einer EID, die von der DSRC-VU generiert wird und dieser Anwendungsinstanz zugeordnet ist.
Ein praktisches Beispiel der in Tabelle 14.8 angegebenen Einstellungen samt Angabe der Bit-Verschlüsselungen findet sich in Tabelle 14.9.
Tabelle 14,9
Initialisierung – Beispiele für die Inhalte von VST-Frames
Oktett # Attribut/Feld Bits in Oktett Beschreibung 1 FLAG 0111 1110 Start-Flag 2 Private LID xxxx xxxx Link-Adresse der spezifischen DSRC-VU 3 xxxx xxxx 4 xxxx xxxx 5 xxxx xxxx 6 MAC Control field 1100 0000 PDU-Befehl 7 LLC Control field 0000 0011 UI-Befehl 8 Fragmentation header 1xxx x001 Keine Fragmentierung 9 VST
SEQUENCE {
Fill BIT STRING (SIZE(4))
1001 Initialisierungsantwort 0000 Nicht verwendet und auf 0 gesetzt 10 Profile INTEGER (0..127,...)
Applications SEQUENCE OF {
0000 0000 Keine Erweiterung. Beispielprofil 0
Keine Erweiterung, 1 Anwendung
11 0000 0001 12 SEQUENCE {
OPTION indicator
OPTION indicator
AID DSRCApplicationEntityID
1 EID vorhanden 1 Parameter vorhanden 00 0010 Keine Erweiterung. AID=2 Freight&Fleet 13 EID Dsrc-EID xxxx xxxx Gemäß OBU definiert, kennzeichnet Anwendungsinstanz. 14 Parameter Container { 0000 0010 Keine Erweiterung, Containerwahl = 02,
Oktett-String
15 0000 0110 Keine Erweiterung, Länge von Rtm-ContextMark = 6 16 Rtm-ContextMark ::= SEQUENCE {
StandardIdentifier
0000 0101 Das erste Oktett ist 05H, die Länge.
Die nachfolgenden 5 Oktette verschlüsseln die Objektkennung des unterstützten Standards, Teil und Version.
{ISO (1) Standard (0) TARV (15638) part9(9) Version2 (2)}
17 standardIdentifier 0010 1000 18 1111 1010 19 0001 0110 20 0000 1001 21 0000 0010 22 ObeConfiguration Sequence {
OPTION indicator
0 ObeStatus nicht vorhanden EquipmentClass INTEGER (0..32767) xxx xxxx Dieses Feld wird für die 23 xxxx xxxx Angaben des Herstellers zur Software-/Hardwareversion der DSRC-Schnittstelle verwendet. 24 ManufacturerId INTEGER (0..65535) xxxx xxxx Herstellerkennung für DSRC-VU gemäß ISO-14816-Register 25 xxxx xxxx 26 FCS xxxx xxxx Frame-Überprüfungssequenz 27 xxxx xxxx 28 Flag 0111 1110 End-Flag
- DCS_49
- Anschließend liest das REDCR die Daten durch die Ausgabe eines GET-Befehls gemäß der Definition in EN 13372, 6.2, 6.3, 6.4 und EN 12834 mit den Einstellungen gemäß Tabelle 14.10.
Tabelle 14.10
Präsentation — Frame-Einstellungen für GET-Anforderungen
Feld Einstellungen Invoker Identifier (IID) Nicht vorhanden Link Identifier (LID) Link-Adresse der spezifischen DSRC-VU Chaining Nein Element Identifier (EID) Gemäß VST. Keine Erweiterung Access Credentials Nein AttributeIdList Keine Erweiterung, 1 Attribut, AttributeID = 1 (RtmData) Fragmentation Nein Layer2 settings PDU-Befehl, Polled ACn-Befehl Tabelle 14.11 zeigt ein Beispiel für das Lesen der RTM-Daten.
Tabelle 14.11
Präsentation — Frame-Beispiel für GET-Anforderungen
Oktett # Attribut/Feld Bits in Oktett Beschreibung 1 FLAG 
Anfangsmerker 2 Private LID 
Link-Adresse der spezifischen DSRC-VU 3 
4 
5 
6 MAC Control Field 
PDU-Befehl 7 LLC Control field 
Polled ACn-Befehl, n Bit 8 Fragmentation header 
Keine Fragmentierung 9 Get.request
SEQUENCE {
GET-Anforderung OPTION indicator 
Zugangsdaten nicht vorhanden OPTION indicator 
IID nicht vorhanden OPTION indicator 
AttributeIdList vorhanden Fill
BIT STRING(SIZE(1))
Auf 0 gesetzt. 10 EID INTEGER(0..127,…) 
EID der RTM-Anwendungsinstanz, Gemäß VST. Keine Erweiterung 11 AttributeIdList SEQUENCE OF {
AttributeId }}
Keine Erweiterung, Anzahl Attribute = 1 12 
AttributeId=1, RtmData. Keine Erweiterung 13 FCS 
Frame-Überprüfungssequenz 14 
15 Flag 
Endmerker
- DSC_50
- Beim Erhalt der GET-Anforderung sendet die DSRC-VU eine GET-Antwort mit den angeforderten Daten gemäß der in EN 13372, 6.2, 6.3, 6.4 und EN 12834 definierten GET-Antwort und den Einstellungen gemäß Tabelle 14.12.
Tabelle 14.12
Präsentation — Frame-Einstellungen für GET-Antwort
Feld Einstellungen Invoker Identifier (IID) Nicht vorhanden Link Identifier (LID) Gemäß EN 12834 Chaining Nein Element Identifier (EID) Gemäß VST. Access Credentials Nein Fragmentation Nein Layer2 settings Antwort-PDU, Antwort verfügbar und Befehl akzeptiert, ACn-Befehl 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
Oktett # Attribut/Feld Bits in Oktett Beschreibung 1 FLAG 
Anfangsmerker 2 Private LID 
Link-Adresse der spezifischen DSRC-VU 3 
4 
5 
6 MAC Control Field 
Antwort-PDU 7 LLC Control field 
Antwort verfügbar, ACn-Befehl, n Bit 8 LLC Status field 
Antwort verfügbar und Befehl akzeptiert 9 Fragmentation header 
Keine Fragmentierung 10 Get.response
SEQUENCE {
Get-Antwort OPTION indicator 
IID nicht vorhanden OPTION indicator 
Attributliste vorhanden OPTION indicator 
Rückgabestatus nicht vorhanden Fill
BIT STRING(SIZE(1))
Nicht verwendet 11 EID
INTEGER(0..127,…)
Antwort aus RTM-Anwendungs-
instanz. Keine Erweiterung
12 AttributeList
SEQUENCE OF {
Keine Erweiterung, Anzahl Attribute = 1 13 Attributes
SEQUENCE {
AttributeId
Keine Erweiterung, AttributeId=1 (RtmData) 14 AttributeValue
CONTAINER {
Keine Erweiterung, Containerwahl = 1010. 15 
RtmData 16 
17 
… … n }}}} 
n+1 FCS 
Frame-Überprüfungssequenz n+2 
n+3 Flag 
Endmerker
- DSC_51
- Anschließend schließt das REDCR die Verbindung durch Ausgabe eines EVENT_REPORT, RELEASE-Befehls gemäß EN 13372, 6.2, 6.3, 6.4 und EN 12834,7.3.8, ohne spezifische RTM-Einstellungen. Tabelle 14.14 zeigt das Beispiel einer Bit-Verschlüsselung des RELEASE-Befehls.
Tabelle 14.14
Beendigung. EVENT_REPORT Inhalte des Release-Frames
Oktett # Attribut/Feld Bits in Oktett Beschreibung 1 FLAG 
Anfangsmerker 2 Private LID 
Link-Adresse der spezifischen DSRC-VU 3 
4 
5 
6 MAC Control Field 
Der Frame enthält eine Befehls-LPDU 7 LLC Control field 
UI-Befehl 8 Fragmentation header 
Keine Fragmentierung 9 EVENT_REPORT.request
SEQUENCE {
EVENT_REPORT (Release) OPTION indicator 
Zugangsdaten nicht vorhanden OPTION indicator 
Ereignisparameter nicht vorhanden OPTION indicator 
IID nicht vorhanden Mode
BOOLEAN
Keine Antwort erwartet 10 EID
INTEGER (0..127,…)
Keine Erweiterung, EID = 0 (System) 11 EventType
INTEGER (0..127,…) }
Ereignisart 0 = Release 12 FCS 
Frame-Überprüfungssequenz 13 
14 Flag 
Endmerker
- DSC_52
- Es wird nicht erwartet, dass die DSRC-VU auf den Release-Befehl antwortet. Die Kommunikation wird dann geschlossen.
- 5.4.8
- Beschreibung der DSRC-Prüftransaktion
- DSC_53
- Vollständige Prüfungen, die eine Sicherung der Daten beinhalten, müssen gemäß Anlage 11 Gemeinsame Sicherheitsmechanismen durch befugtes Personal mit Zugang zu den Sicherheitsverfahren unter Verwendung der normalen, oben definierten GET-Befehle durchgeführt werden.
- DSC_54
- Inbetriebnahme und regelmäßige Inspektionen, bei denen eine Entschlüsselung und ein Verständnis der entschlüsselten Daten erforderlich sind, müssen gemäß Anlage 11 Gemeinsame Sicherheitsmechanismen und Anlage 9 Typgenehmigung — Mindestanforderungen an die durchzuführenden Prüfungen durchgeführt werden.
Die grundlegende DSRC-Kommunikation kann hingegen mit dem Befehl ECHO geprüft werden. Solche Prüfungen können bei der Inbetriebnahme, bei regelmäßigen Inspektionen oder auf Verlangen der zuständigen Kontrollbehörde oder gemäß der Verordnung (EU) Nr. 165/2014 (siehe 6 unten) erforderlich sein.
- DSC_55
- Zur Durchführung dieser Prüfung der grundlegenden Kommunikation wird der Befehl ECHO vom REDCR während einer Sitzung ausgegeben, d. h. nach erfolgreicher Durchführung einer Initialisierungsphase. Die Abfolge der Interaktionen ähnelt deshalb derjenigen einer Abfrage:
- — Schritt 1
Das REDCR sendet eine „Beacon Service Table” (BST) mit den Anwendungskennungen (AID) in der unterstützten Dienstliste. In der RTM-Anwendung ist dies einfach der Dienst mit AID-Wert = 2.
Die DSRC-VU wertet die empfangene BST aus; sofern sie erkennt, dass die BST Freight&Fleet (AID = 2) anfragt, antwortet die DSRC-VU. Wenn das REDCR nicht AID=2 anbietet, beendet die DSRC-VU die Transaktion mit dem REDCR.
- — Schritt 2
- Die DSRC-VU sendet eine Anfrage nach Zuweisung eines privaten Fensters.
- — Schritt 3
- Die REDCR sendet die Zuweisung eines privaten Fensters.
- — Schritt 4
- Die DSRC-VU sendet mithilfe des zugewiesenen privaten Fensters ihre Fahrzeugdiensttabelle (Vehicle Service Table, VST). Diese VST enthält eine Liste aller unterschiedlichen Anwendungsinstanziierungen, die diese DSRC-VU im Rahmen von AID=2 unterstützt. Die verschiedenen Instanziierungen sind durch einzelne EID zu identifizieren, von denen jede mit einem Parameterwert verbunden ist, der die unterstützte Anwendungsinstanz angibt.
- — Schritt 5
- Anschließend analysiert das REDCR die angebotene VST und beendet entweder die Verbindung (RELEASE), weil das Angebot der VST nicht interessant ist (d. h., es erhält von der DSRC-VU eine VST, die keine RTM-VU ist), oder es erhält eine passende VST und startet die Instanziierung der App.
- — Schritt 6
- Das REDCR gibt einen Befehl (ECHO) an die jeweilige DSRC-VU aus und weist ein privates Fenster zu.
- — Schritt 7
- Die DSRC-VU sendet mithilfe des neu zugewiesenen privaten Fensters eine ECHO-Antwort.
- 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
Oktett # Attribut/Feld Bits in Oktett Beschreibung 1 FLAG 
Anfangsmerker 2 Private LID 
Link-Adresse der spezifischen DSRC-VU 3 
4 
5 
6 MAC Control Field 
PDU-Befehl 7 LLC Control field 
Polled ACn-Befehl, n Bit 8 Fragmentation header 
Keine Fragmentierung 9 ACTION.request
SEQUENCE {
Action request (ECHO) OPTION indicator 
Zugangsdaten nicht vorhanden OPTION indicator 
Aktionsparameter vorhanden OPTION indicator 
IID nicht vorhanden Mode
BOOLEAN
Antwort erwartet 10 EID
INTEGER (0..127,…)
Keine Erweiterung, EID = 0 (System) 11 ActionType
INTEGER (0..127,…)
Keine Erweiterung, Aktionstyp ECHO-Anfrage 12 ActionParameter
CONTAINER {
Keine Erweiterung, Containerwahl = 2 13 
Keine Erweiterung. String-Länge = 100 Oktette 14 
Echo-Daten … … 113 }} 
114 FCS 
Frame-Überprüfungssequenz 115 
116 Flag 
Endmerker
- DSC_58
- Beim Erhalt der ECHO-Anforderung sendet die DSRC-VU eine ECHO-Antwort mit 100 Datenoktetten durch Widerspiegelung des erhaltenen Befehls, gemäß ISO 14906, ohne spezifische RTM-Einstellungen. In Tabelle 14.16 ist ein Beispiel für eine Kodierung auf Bit-Ebene dargestellt.
Tabelle 14.16
Beispiel für ACTION-, ECHO-Anfrage-Frame
Oktett # Attribut/Feld Bits in Oktett Beschreibung 1 FLAG 
Anfangsmerker 2 Private LID 
Link-Adresse der spezifischen VU 3 
4 
5 
6 MAC Control Field 
Antwort-PDU 7 LLC Control field 
ACn-Befehl, n Bit 8 LLC status field 
Antwort verfügbar 9 Fragmentation header 
Keine Fragmentierung 10 ACTION.response
SEQUENCE {
ACTION-Antwort (ECHO) OPTION indicator 
IID nicht vorhanden OPTION indicator 
Antwortparameter vorhanden OPTION indicator 
Rückgabestatus nicht vorhanden Fill
BIT STRING (SIZE (1))
Nicht verwendet 11 EID
INTEGER (0..127,…)
Keine Erweiterung, EID = 0 (System) 12 ResponseParameter
CONTAINER {
Keine Erweiterung, Containerwahl = 2 13 
Keine Erweiterung. String-Länge = 100 Oktette 14 
Echo-Daten … … 113 }} 
114 FCS 
Frame-Überprüfungssequenz 115 
116 Flag 
Endmerker
- 5.5
- Reserviert für künftige Verwendung
- 5.5
- Unterstützung für Richtlinie (EU) 2015/719
- 5.5.1
- Überblick
- DSC_59
- Um die Richtlinie (EU) 2015/719 über die maximalen Abmessungen und Gewichte von Nutzfahrzeugen zu unterstützen, entspricht das zum Herunterladen der OWS-Daten über die 5,8-GHz-DSRC-Schnittstellenverbindung derjenigen für die RTM-Daten (siehe 5.4.1); der einzige Unterschied besteht darin, dass die Objektkennung für die TARV-Norm auf die Norm ISO 15638 (TARV) Teil 20 (WOB/OWS) verweist.
- 5.5.2
- Befehle
- DSC_60
- Die für eine OWS-Transaktion verwendeten Befehle entsprechen denjenigen für eine RTM-Transaktion.
- 5.5.3
- Abfragebefehlssequenz
- DSC_61
- Die Abfragebefehlssequenz für OWS-Daten entspricht derjenigen für RTM-Daten.
- 5.5.4
- Datenstrukturen
- DSC_62
- Die Nutzlast (OWS-Daten) besteht aus der Verkettung der
- 1.
- EncryptedOwsPayload-Daten, d. h. der Verschlüsselung von OwsPayload gemäß ASN.1 in Abschnitt 5.5.5. Die Verschlüsselungsmethode entspricht derjenigen für RtmData, die in Anlage 11 angegeben ist.
- 2.
- DSRCSecurityData, berechnet mit demselben Algorithmus wie dem für RtmData angewandten, der in Anlage 11 angegeben ist.
- 5.5.5
- ASN.1-Modul für die OWS-DSRC-Transaktion
- DSC_63.
- Das ASN.1-Modul für die DSRC-Daten innerhalb der RTM-Anwendung ist wie folgt definiert:
- 5.5.6
- Elemente von OswData, durchgeführte Aktionen und Definitionen
Die Elemente von OwsData sind so definiert, dass die Richtlinie Nr. 2015/719/EG über die höchstzulässigen Abmessungen und Gewichte von Nutzfahrzeugen unterstützt wird. Bedeutung:- —
recordedWeight entspricht dem gemessenen Gesamtgewicht des Nutzfahrzeugs mit einer Auflösung von 10 kg gemäß EN ISO 14906. Ein Wert von 2500 beispielsweise entspricht einem Gewicht von 25 Tonnen.
- —
axlesConfiguration entspricht der Nutzfahrzeugkonfiguration hinsichtlich der Achsenzahl. Die Konfiguration wird mit der Bitmaske von 20 Bits definiert (erweitert aus EN ISO 14906).
Eine Bitmaske von 2 Bit entspricht der Konfiguration einer Achse gemäß folgendem Format:
- —
Bei Wert 00B liegt kein Wert vor, da das Fahrzeug über keine zur Erfassung der Achslast notwendige Ausrüstung verfügt.
- —
Bei Wert 01B liegt die Achse nicht vor.
- —
Bei Wert 10B liegt die Achse vor, die Achslast wurde berechnet und erfasst und wird im Feld axlesRecordedWeight ausgegeben.
- —
Wert 11B ist für zukünftige Zwecke reserviert.
Die letzten vier Bits sind für zukünftige Zwecke reserviert.
Achsenzahl Achsenzahl Zugmaschine Achsenzahl Anhänger 00/01/10/11 00/01/10/11 00/01/10/11 00/01/10/11 00/01/10/11 00/01/10/11 00/01/10/11 00/01/10/11 00/01/10/11 00/01/10/11 RFU
(4 Bits)
- —
axlesRecordedWeight stellt das spezifische Gewicht pro Achse mit einer Auflösung von 10 kg dar. Pro Achse werden zwei Oktette verwendet. Ein Wert von 150 beispielsweise entspricht einem Gewicht von 1500 kg.
- 5.5.7
- Mechanismen der Datenübertragung
- DSC_64
- Der Mechanismus für die Übermittlung der OWS-Daten zwischen Abfrageeinrichtung und DSRC-Einrichtung im Fahrzeug entspricht demjenigen für die eRTM-Daten (siehe 5.4.6).
- DSC_65
- Die Datenübermittelung zwischen der Plattform zur Erfassung der Daten über das höchstzulässige Gewicht und der DSRC-Einrichtung im Fahrzeug basiert auf der physischen Verbindung und den in Abschnitt 5.6 definierten Schnittstellen und Protokollen.
- 5.6
- Datenübermittelung zwischen DSRC-VU und VU
- 5.6.1
- Physische Verbindung und Schnittstellen
- DSC_66
- Die Verbindung zwischen VU und DSRC-VU kann entweder über eine Kabelverbindung oder eine Kurzbereich-Drahtloskommunikation basierend auf Bluetooth v4.0 BLE erfolgen.
- DSC_67
- Unabhängig von der Wahl von Verbindung und Schnittstelle müssen die folgenden Anforderungen erfüllt sein:
- DSC_68
- a)
- Damit unterschiedliche Hersteller für die Lieferung der VU und DSRC-VU und auch unterschiedlicher Lose der DSRC-VU gewählt werden können, muss die Verbindung zwischen VU und nicht VU-interner DSRC-VU nach einem offenen Standard erfolgen. Die VU wird auf eine der folgenden Arten mit der DSRC-VU verbunden:
- i)
- über ein mindestens 2 m langes Festkabel mit geradem H11-Stecker (11-polig) nach DIN 41612 von der DSRC-VU auf eine passende Buchse mit DIN/ISO-Zulassung vom VU-Gerät
- ii)
- über Bluetooth Low Energy (BLE)
- iii)
- über eine standardmäßige ISO-11898- oder SAE-J1939-Verbindung
- DSC_69
- b)
- Die Definition der Schnittstellen und Verbindung zwischen VU und DSRC-VU muss die in 5.6.2. definierten Befehle des Anwendungsprotokolls erfüllen, und
- DSC_70
- c)
- VU und DSRC-VU müssen die Datenübermittlung über die Verbindung im Hinblick auf Leistung und 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:
- —
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).
- —
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.
- —
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 DataTransactionId kennzeichnet die jeweilige Datenübertragung. Außerdem wird durch LinkIdentifier sichergestellt, dass der entsprechende Link korrekt ist.- —
wird von der DSRC-VU gesendet, um der VU Rückmeldung über den Erhalt der Daten infolge eines Befehls 
zu geben, gekennzeichnet durch den Parameter DataTransactionId. Der Antwortparameter lautet 1 (Erfolg) oder = 0 (Fehler). Wenn eine VU mehr als drei Antworten gleich 0 erhält oder wenn die VU kein RCDT Data Acknowledgment für einen bestimmten zuvor gesendeten RCDT-Send Data mit spezifischer DataTransactionId erhält, muss die VU ein Ereignis generieren und aufzeichnen.- —
request wird von der VU an die DSRC-VU gesendet, um einen Link für einen spezifischen LinkIdentifier zu beenden.
- DSC_76
- Beim Neustart der DSRC-VU oder einer VU müssen alle bestehenden Kommunikationslinks gelöscht werden, da aufgrund eines abrupten Herunterfahrens einer VU „bezuglose” Links vorhanden sein könnten.
- —
wird von der DSRC-VU an die VU gesendet, um die Aufforderung zur Beendigung des Links durch die VU für den spezifischen LinkIdentifier zu bestätigen.
- 5.7
- Fehlerbehandlung
- 5.7.1
- Aufzeichnung und Kommunikation der Daten in der DSRC-VU
- DSC_77
- Die Daten sind, stets gesichert, von der VUSM-Funktion der DSRC-VU bereitzustellen. Die VUSM verifiziert, dass in der DSRC-VU aufgezeichnete Daten erfolgreich an die DSRC-VU übermittelt wurden. Die Aufzeichnung und Protokollierung von Fehlern bei der Datenübermittlung von der VU in den Speicher der DSRC-VU muss mit dem Typ EventFaultType und dem Enum-Wert „0C” H für das Ereignis „Kommunikationsfehler mit der Fernkommunikationsausrüstung” zusammen mit dem Zeitstempel erfolgen. Die VUSM verifiziert, dass die Daten erfolgreich an die DSRC-VU übermittelt wurden.
- DSC_78
- Reserviert für künftige Verwendung.
- DSC_79
- Wenn die VUPM vergebens versucht, VU-Daten vom Sicherheitsmodul abzurufen (um diese an die VU-DSRC weiterzuleiten), muss sie diesen Fehler mit dem Typ EventFaultType 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
für die zugehörigen (d. h. mit der gleichen DataTransactionId 
-Nachrichten versehenen) 
eingeht.
- 5.7.2
- Fehler in der Drahtloskommunikation
- DSC_80
- Die Behandlung von Kommunikationsfehlern muss mit derjenigen gemäß zugehörigen DSRC-Normen, nämlich EN 300 674-1, EN 12253, EN 12795, EN 12834 und den entsprechenden Parametern von EN 13372, übereinstimmen.
- 5.7.2.1
- Verschlüsselungs- und Signaturfehler
- DSC_81
- Verschlüsselungs- und Signaturfehler sind gemäß Anlage 11 Gemeinsame Sicherheitsmechanismen zu behandeln und sind in den Fehlernachrichten zur DSRC-Datenübermittlung nicht vorhanden.
- 5.7.2.2
- Aufzeichnung von Fehlern
Das DSRC-Medium ist eine dynamische Drahtloskommunikation in einer Umgebung mit unsicheren atmosphärischen und Interferenzbedingungen, insbesondere in den an dieser Anwendung beteiligten Kombinationen „tragbares REDCR” und „Fahrzeug in Bewegung” . Deshalb muss zwischen den Bedingungen „Lesefehler” und „Fehler” ein Unterschied bestehen. Bei einer Transaktion über eine Drahtlosschnittstelle sind Lesefehler gängig; anschließend wird in der Regel ein neuer Versuch gestartet, d. h. die BST erneut gesendet und die Sequenz wiederholt. Meist verläuft dieser erneute Kommunikationsversuch dann erfolgreich und die Daten werden übertragen, sofern das Fahrzeug sich nicht in der zur Wiederübertragung erforderlichen Zeit aus dem Empfangsbereich bewegt. (Eine „erfolgreiche” Instanz eines Lesevorgangs umfasst mitunter mehrere Versuche und Wiederholungen). Ein Lesefehler kann auftreten, weil die Antennen nicht richtig gekoppelt sind (Fehler beim „Ausrichten” ), weil eine der Antennen abgeschirmt ist (dies kann gewollt sein, aber auch durch die Nähe eines anderen Fahrzeugs verursacht sein), durch Funkstörung (insbesondere durch Wifi- oder andere öffentliche Drahtloskommunikation im Bereich von ca. 5,8 GHz), Radarinterferenz oder schwierige atmosphärische Bedingungen (z. B. während eines Unwetters) oder einfach dadurch, dass das Fahrzeug den Bereich der DSRC-Kommunikation verlässt. Die einzelnen Instanzen der Lesefehler lassen sich nicht aufzeichnen, da die Kommunikation schlichtweg nicht stattgefunden hat. Wenn aber der Mitarbeiter der zuständigen Kontrollbehörde ein Fahrzeug anvisiert und versucht, dessen DSRC-VU abzufragen, die Daten jedoch nicht erfolgreich übermittelt werden, kann dieser Fehler auf eine gewollte Manipulation zurückzuführen sein. Deshalb muss der Mitarbeiter der zuständigen Kontrollbehörde den Fehler protokollieren und die an der Maßnahme beteiligten Kollegen über einen möglichen Verstoß informieren. Die Kollegen können dann das Fahrzeug anhalten und physisch überprüfen. Da aber keine erfolgreiche Kommunikation stattgefunden hat, kann die DSRC-VU keine Daten über den Fehler liefern. Eine solche Protokollierung ist deshalb abhängig vom Design des REDCR-Geräts. Ein „Lesefehler” ist technisch gesehen etwas anderes als ein „Fehler” In diesem Kontext bedeutet „Fehler” , dass ein falscher Wert erfasst wurde. Die an die DSRC-VU gelieferten Daten sind bereits gesichert und müssen deshalb durch den Lieferanten der Daten verifiziert werden (siehe 5.4). Anschließend über die Luftschnittstelle übermittelte Daten werden durch zyklische Redundanzprüfungen (CRC) auf der Kommunikationsebene geprüft. Wenn diese Prüfung erfolgreich verläuft, sind die Daten korrekt. Andernfalls werden die Daten erneut übertragen. Die Wahrscheinlichkeit, dass Daten eine CRC-Prüfung fälschlicherweise erfolgreich bestehen, ist statistisch so verschwindend gering, dass sie unberücksichtigt bleiben kann. Wenn die CRC-Prüfung fehlschlägt und keine Zeit für ein erneutes Senden und Empfangen der korrekten Daten mehr bleibt, führt dies nicht zu einem Fehler, sondern zu einer Instanziierung einer bestimmten Art von Lesefehler. Die einzige aussagekräftige „Fehlerinformation” , die sich aufzeichnen lässt, ist die Anzahl erfolgreicher Initiierungen von Transaktionen, die nicht zu einer erfolgreichen Datenübermittlung an das REDCR geführt haben.- DSC_82
- Das REDCR hat deshalb die Anzahl der Fälle mit Zeitstempel aufzuzeichnen, in denen die „Initialisierungsphase” einer DSRC-Abfrage erfolgreich verläuft, die Transaktion aber abbricht, bevor das REDCR die Daten erfolgreich abrufen konnte. Diese Daten sind dem Mitarbeiter der zuständigen Kontrollbehörde zur Verfügung zu stellen und im Speicher des REDCR-Geräts abzulegen. Wie dies geschieht, ist eine Frage des Produktdesigns oder der Festlegung durch die zuständige Kontrollbehörde.
Die einzige aussagekräftige „Fehlerinformation” , die sich aufzeichnen lässt, ist die Anzahl der Fälle, in der das REDCR die empfangenen Daten nicht entschlüsseln konnte. Dies bezieht sich allerdings nur auf die Effizienz der REDCR-Software. Unter Umständen werden Daten technisch entschlüsselt, ergeben aber keinen semantischen Sinn.
- DSC_83
- Deshalb muss das REDCR mit einem Zeitstempel die Anzahl der Fälle mit Zeitstempel aufzeichnen, in denen das Gerät vergeblich versucht hat, die über die DSRC-Schnittstelle empfangenen Daten zu entschlüsseln.
- 6
- INBETRIEBNAHME- UND REGELMÄSSIGE INSPEKTIONSPRÜFUNGEN DER FERNKOMMUNIKATIONSFUNKTION
- 6.1
- Allgemein
- DSC_84
- Für die Fernkommunikationsfunktion sind zwei Arten von Prüfungen vorgesehen:
- 1)
- ECHO-Prüfung, um den Drahtloskommunikationskanal DSRC-REDCR >>-:-<DSRC-VU wireless zu überprüfen.
- 2)
- Ende-zu-Ende-Sicherheitsprüfung, um zu gewährleisten, dass eine Werkstattkarte auf die von der VU erzeugten verschlüsselten und signierten und über den Drahtloskommunikationskanal übermittelten Dateninhalte zugreifen kann.
- 6.2
- ECHO
Die Spezifikationen dieses Abschnitts geben an, wie geprüft wird, dass die Verbindung DSRC-REDCR >>-:-<DSRC-VU in funktioneller Hinsicht aktiv ist. Ziel des ECHO-Befehls ist es, Werkstätten oder Prüfeinrichtungen zur Typgenehmigung in die Lage zu versetzen, zu prüfen, ob der DSRC-Link funktioniert, ohne auf die Sicherheitsangaben zugreifen zu müssen. Die Ausrüstung des Prüfers muss deshalb nur in der Lage sein, eine DSRC-Kommunikation (durch Senden einer BST mit AID=2) einzuleiten, anschließend den Befehl ECHO zu senden und, bei funktionierender DSRC, die ECHO-Antwort zu empfangen. Zu Einzelheiten siehe 5.4.8. Wenn diese Antwort korrekt empfangen wird, kann bestätigt werden, dass die DSRC-Verbindung (DSRC-REDCR >>-:-<DSRC-VU) korrekt funktioniert.- 6.3
- Prüfungen zur Validierung sicherer Dateninhalte
- DSC_85
- Mit dieser Prüfung wird der sichere Ende-zu-Ende-Datenfluss überprüft. Für diese Prüfung wird ein DSRC-Prüflesegerät benötigt. Dieses DSRC-Prüflesegerät bietet die gleiche Funktionalität und wird mit denselben Spezifikationen wie das Lesegerät der Kontrollbehörden eingerichtet. Der einzige Unterschied besteht darin, dass anstelle einer Kontrollkarte eine Werkstattkarte benutzt wird, um den Benutzer des DSRC-Prüflesegeräts zu authentisieren. Die Prüfung kann im Anschluss an die Erstaktivierung eines intelligenten Fahrtenschreibers oder am Ende des Kalibrierungsverfahrens durchgeführt werden. Nach der Aktivierung generiert die Fahrzeugeinheit die gesicherten Früherkennungsdaten und übermittelt diese an die DSRC-VU.
- DSC_86
- Das Werkstattpersonal positioniert das DSRC-Prüflesegerät in einem Abstand von 2–10 Metern vor dem Fahrzeug.
- DSC_87
- Anschließend steckt das Werkstattpersonal eine Werkstattkarte in das DSRC-Prüflesegerät ein und fragt von der Fahrzeugeinheit die Früherkennungsdaten ab. Nach erfolgreicher Abfrage greift das Werkstattpersonal auf die empfangenen Daten zu, um zu überprüfen, ob deren Integrität erfolgreich validiert und die Daten entschlüsselt wurden.
Fußnote(n):
- (*)
— Downlink-Parameter unterliegen Konformitätsprüfung gemäß relevanter Parameterprüfung aus EN 300 674-1
- (**)
— Uplink-Parameter unterliegen Konformitätsprüfung gemäß relevanter Parameterprüfung aus EN 300 674-1
© Europäische Union 1998-2021
Tipp: Verwenden Sie die Pfeiltasten der Tastatur zur Navigation zwischen Normen.