(37)
|
Anlage 12 wird wie folgt geändert:
(a)
|
Das Inhaltsverzeichnis wird wie folgt geändert:
(i)
|
Nach Nummer 1.1 wird folgende Nummer 1.1.1 eingefügt:
„1.1.1.
|
Referenzdokumente“;
|
|
(ii)
|
Nummer 2 erhält folgende Fassung:
„2.
|
GRUNDLEGENDE MERKMALE DES GNSS-EMPFÄNGERS“;
|
|
(iii)
|
Nummer 3 erhält folgende Fassung:
„3.
|
VOM GNSS-EMPFÄNGER GELIEFERTE DATENSÄTZE“;
|
|
(iv)
|
Die folgenden Nummern 4.2.4 und 4.2.5 werden eingefügt:
„4.2.4.
|
Struktur des Befehls WriteRecord
|
|
(v)
|
Nummer 5.2 erhält folgende Fassung:
„5.2.
|
Übermittlung von Daten vom GNSS-Empfänger an die Fahrzeugeinheit“;
|
|
(vi)
|
Nummer 5.2.1 wird gestrichen.
|
(vii)
|
Die folgenden Nummern 5.3, 5.4 und 5.4.1 werden eingefügt:
„5.3.
|
Übermittlung von Daten von der Fahrzeugeinheit an den GNSS-Empfänger
|
5.4.
|
Fehlerbehandlung
5.4.1
|
Fehlende Positionsdaten des GNSS-Empfängers“;
|
|
|
(viii)
|
Die Nummern 6 und 7 erhalten folgende Fassung:
„6.
|
POSITIONSDATENVERARBEITUNG UND -AUFZEICHNUNG DURCH DIE FAHRZEUGEINHEIT
|
|
(ix)
|
Folgende Nummer 8 wird angefügt:
„8.
|
DATENKONFLIKT FAHRZEUGBEWEGUNG“;
|
|
|
(b)
|
Nummer 1 wird wie folgt geändert:
(i)
|
Der Text vor Abbildung 1 erhält folgende Fassung:
„1. EINLEITUNG
Diese Anlage enthält die technischen Anforderungen für den GNSS-Empfänger und die GNSS-Daten, die von der Fahrzeugeinheit verwendet werden, einschließlich der Protokolle, die implementiert werden müssen, um die sichere und korrekte Übertragung der Positionsbestimmungsinformationen zu gewährleisten.
1.1. Anwendungsbereich
GNS_1
|
Die Fahrzeugeinheit muss Standortdaten von mindestens einem globalen GNSS-Satellitennetz erfassen.
Die Fahrzeugeinheit kann gegebenenfalls über eine externe GNSS-Ausrüstung verfügen (siehe Abbildung 1):“;
|
|
(ii)
|
Nach Nummer 1.1 wird folgende Nummer 1.1.1 eingefügt:
„1.1.1.
|
Referenzdokumente
Referenzdokumente zu dieser Anlage:
NMEA
|
NMEA (National Marine Electronics Association – Nationale Vereinigung für Marineelektronik) 0183 Interface Standard, V4.11“;
|
|
|
(iii)
|
In Nummer 1.2 werden folgende Akronyme eingefügt:
„OSNMA
|
Galileo Open Service Navigation Message Authentication (Authentisierung von Navigationsnachrichten im Offenen Dienst von Galileo)
|
RTC
|
Real Time Clock (Echtzeituhr)
|
“;
|
|
(c)
|
Nummer 2 wird wie folgt geändert:
(i)
|
Die Überschrift erhält folgende Fassung:
„2.
|
GRUNDLEGENDE MERKMALE DES GNSS-EMPFÄNGERS“;
|
|
(ii)
|
Absatz GNS_3 erhält folgende Fassung:
„GNS_3
|
Der GNSS-Empfänger muss fähig sein, die Authentisierung von Navigationsnachrichten im Offenen Dienst von Galileo (OSNMA) zu unterstützen.“;
|
|
(iii)
|
Die folgenden Absätze GNS_3a bis GNS_3g werden eingefügt:
„GNS_3a
|
Der GNSS-Empfänger führt eine Reihe von Konsistenzprüfungen durch, um zu verifizieren, ob die vom GNSS-Empfänger auf der Grundlage der OSNMA-Daten berechneten Messungen zu den korrekten Informationen zu Position, Geschwindigkeit und Daten des Fahrzeugs geführt haben und somit nicht durch externe Angriffe wie dem Wiederabstrahlen von empfangenen Signalen mit einem Repeater (Meaconing) beeinflusst wurden. Diese Konsistenzprüfungen umfassen beispielsweise Folgendes:
—
|
Feststellung anormaler Leistungsemissionen durch kombinierte Überwachung von automatischer Verstärkungsregelung (Automatic Gain Control, AGC) und Träger-Rauschdichte-Verhältnis (C/N0)
|
—
|
Konsistenz der Pseudostreckenmessung und der Doppler-Messung im Zeitverlauf, einschließlich Erkennung abrupter Messsprünge
|
—
|
Techniken der autonomen empfängerseitigen Integritätsprüfung (Receiver Autonomous Integrity Monitoring, RAIM), einschließlich Erkennung von Inkonsistenzen zwischen Messung und geschätzter Position
|
—
|
Positions- und Geschwindigkeitsprüfungen, einschließlich anormaler Positions- und Geschwindigkeitslösungen, plötzlicher Sprünge und eines Verhaltens, das nicht mit der Fahrzeugdynamik vereinbar ist
|
—
|
Konsistenz von Zeit und Frequenz, einschließlich Uhrzeitsprünge und -abweichungen, die nicht im Einklang mit den Eigenschaften der Empfängeruhr stehen
|
|
GNS_3b
|
Die Europäische Kommission erarbeitet und genehmigt die folgenden Dokumente:
—
|
Ein Schnittstellenkontrolldokument für das Signal im Raum (Signal In Space Interface Control Document, SIS-ICD), in dem Einzelheiten zu den im Galileo-Signal übermittelten OSNMA-Informationen festgelegt werden.
|
—
|
Leitlinien für OSNMA-Empfänger, in denen die Anforderungen und Verfahren in den Empfängern aufgeführt sind, um eine sichere Implementierung von OSNMA zu gewährleisten, und die Empfehlungen zur Verbesserung der OSNMA-Leistung enthalten.
|
Die in Fahrtenschreiber integrierten GNSS-Empfänger, ob intern oder extern, müssen gemäß dem SIS-ICD und den Leitlinien für OSNMA-Empfänger gebaut sein.
|
GNS_3c
|
Der GNSS-Empfänger liefert Positionsnachrichten (in diesem Anhang und seinen Anlagen als authentisierte Positionsnachrichten bezeichnet), die ausschließlich unter Verwendung von Satelliten erstellt werden, für die die Authentizität der Navigationsnachrichten erfolgreich verifiziert wurde.
|
GNS_3d
|
Der GNSS-Empfänger liefert auch Standardpositionsnachrichten, die unter Verwendung der sichtbaren Satelliten erstellt werden, unabhängig davon, ob diese authentisiert sind.
|
GNS_3e
|
Der GNSS-Empfänger verwendet die Echtzeituhr (RTC) der Fahrzeugeinheit als Zeitreferenz für die für OSNMA erforderliche Synchronisierung der Zeit.
|
GNS_3f
|
Die RTC-Zeit der Fahrzeugeinheit wird dem GNSS-Empfänger von der Fahrzeugeinheit übermittelt.
|
GNS_3g
|
Die maximale Zeitabweichung gemäß Anhang IC Randnummer 41 wird dem GNSS-Empfänger zusammen mit der RTC-Zeit der Fahrzeugeinheit übermittelt.“;
|
|
|
(d)
|
Nummer 3 erhält folgende Fassung:
„3.
|
VOM GNSS-EMPFÄNGER GELIEFERTE DATENSÄTZE
In diesem Abschnitt werden die Datensätze beschrieben, die für das Funktionieren des intelligenten Fahrtenschreibers bei der Übermittlung von Standard- und authentifizierten Positionsnachrichten verwendet werden. Dieser Abschnitt gilt für die Konfiguration des intelligenten Fahrtenschreibers sowohl mit als auch ohne externe GNSS-Ausrüstung.
GNS_4
|
Die Standardpositionsdaten basieren auf dem von der NMEA empfohlenen minimalen spezifischen Datensatz (Recommended Minimum Specific, RMC) für das GNSS, der die Positionsinformation (Breite, Länge), die Zeit im UTC-Format (hhmmss.ss), die Geschwindigkeit in Knoten über Grund sowie zusätzliche Werte umfasst.
Der RMC-Datensatz weist folgendes Format auf (gemäß Norm NMEA V4.11):
$--RMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,xxxx,x.x,a,a,a*hh
2)
|
Status, A= Gültige Position, V= Warnmeldung
|
7)
|
Geschwindigkeit in Knoten über Grund
|
10)
|
Magnetische Deklination, Grad
|
12)
|
FAA Betriebsartanzeiger
|
Der Navigationsstatus ist optional und möglicherweise nicht im RMC-Datensatz enthalten.
Der Status zeigt an, ob das GNSS-Signal verfügbar ist. Solange der Statuswert nicht auf ‚A‘ gesetzt ist, können die empfangenen Daten (z. B. Uhrzeit oder Breite/Länge) nicht verwendet werden, um die Position des Fahrzeugs in der Fahrzeugeinheit aufzuzeichnen.
Die Auflösung der Position basiert auf dem oben beschriebenen RMC-Datensatzformat. Der erste Teil der Felder 3 und 5 wird verwendet, um die Gradwerte darzustellen. Der Rest dient dazu, die Minuten mit drei Dezimalzahlen darzustellen. Die Auflösung ist also 1/1 000 Minute oder 1/60 000 Grad (da eine Minute 1/60 Grad ist).
|
GNS_4a
|
Die authentisierten Positionsdaten basieren auf einem NMEA-artigen Datensatz, dem authentisierten minimalen spezifischen Datensatz (Authenticated Minimum Specific, AMC), der die Positionsinformation (Breite, Länge), die Zeit im UTC-Format (hhmmss.ss), die Geschwindigkeit in Knoten über Grund sowie zusätzliche Werte umfasst.
Der AMC-Datensatz weist folgendes Format auf (gemäß Norm NMEA V4.11, außer für Wert 2):
$--AMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,xxxx,x.x,a,a,a*hh
2)
|
Status, A = authentisierte Position (ermittelt anhand von mindestens 4 Satelliten, von denen die Authentizität der Navigationsnachrichten erfolgreich verifiziert wurde), J = Jamming oder O = anderer GNSS-Angriff bei fehlgeschlagener Authentisierung von Navigationsnachrichten (anhand von implementierten Konsistenzprüfungen gemäß GNS_3a), F = fehlgeschlagene Authentisierung von Navigationsnachrichten (gemäß Feststellung mittels OSNMA-Überprüfungen, die in den in GNS_3b angeführten Referenzdokumenten festgelegt sind), V = ungültig (authentisierte Position aus anderem Grund nicht verfügbar)
|
7)
|
Geschwindigkeit in Knoten über Grund
|
10)
|
Magnetische Deklination, Grad
|
12)
|
FAA Betriebsartanzeiger
|
Der Navigationsstatus ist optional und möglicherweise nicht im AMC-Datensatz enthalten.
Der Status zeigt an, ob eine authentisierte GNSS-Position verfügbar ist, ob ein Angriff auf die GNSS-Signale erkannt wurde, ob die Authentisierung der Navigationsnachrichten fehlgeschlagen ist oder ob die GNSS-Position ungültig ist. Wenn der Statuswert nicht auf ‚A‘ gesetzt ist, werden die empfangenen Daten (z. B. Uhrzeit oder Breite/Länge) als nicht gültig betrachtet und können daher nicht verwendet werden, um die Position des Fahrzeugs in der Fahrzeugeinheit aufzuzeichnen. Wenn der Statuswert auf ‚J‘ (Jamming), ‚O‘ (anderer GNSS-Angriff) oder ‚F‘ (fehlgeschlagene Authentisierung von Navigationsnachrichten) gesetzt ist, wird in der Fahrzeugeinheit eine GNSS-Anomalie gemäß Anhang IC und Anlage 1 (EventFaultCode) aufgezeichnet.
|
GNS_5
|
Die Fahrzeugeinheit muss die Positionsinformation zur Breite und Länge mit einer Auflösung von 1/10 Minute oder 1/600 Grad in der VU-Datenbank speichern, wie in Anlage 1 für GeoCoordinates beschrieben.
Der Befehl GPS DOP und aktive Satelliten (GSA) (gemäß Norm NMEA V4.11) kann von der Fahrzeugeinheit verwendet werden, um die Signalverfügbarkeit und -genauigkeit von Standardpositionen zu bestimmen und aufzuzeichnen. Die HDOP dient insbesondere dazu, die Genauigkeit der aufgezeichneten Standortdaten anzugeben (siehe 4.2.2). Die Fahrzeugeinheit speichert den Wert der Horizontalgenauigkeit (HDOP), der als niedrigster der in den verfügbaren GNSS-Systemen erfassten HDOP-Werte berechnet wird.
Die ID des GNSS gibt für jede GNSS-Konstellation und satellitengestützte Ergänzungssysteme (Satellite-Based Augmentation System, SBAS) die entsprechende NMEA-ID an.
$--GSA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*hh
3)
|
ID des 1. für die Ortung verwendeten Satelliten
|
4)
|
ID des 2. für die Ortung verwendeten Satelliten
|
…
14)
|
ID des 12. für die Ortung verwendeten Satelliten
|
Die System-ID ist optional und möglicherweise nicht im GSA-Datensatz enthalten.
In entsprechender Weise kann der NMEA-ähnliche Datensatz für authentisierte aktive Satelliten (Authenticated Active Satellites, ASA) von der Fahrzeugeinheit verwendet werden, um die Signalverfügbarkeit und Genauigkeit von authentisierten Positionen zu bestimmen und aufzuzeichnen. Die Werte 1 bis 18 sind in der Norm NMEA-V4.11 definiert.
$--ASA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*hh
3)
|
ID des 1. für die Ortung verwendeten Satelliten
|
4)
|
ID des 2. für die Ortung verwendeten Satelliten
|
…
14)
|
ID des 12. für die Ortung verwendeten Satelliten
|
Die System-ID ist optional und möglicherweise nicht im ASA-Datensatz enthalten.
|
GNS_6
|
Bei Verwendung einer externen GNSS-Ausrüstung wird der GSA-Datensatz im GNSS Secure Transceiver mit der Datensatznummer ‚02‘ bis ‚06‘ gespeichert, und der ASA-Datensatznummer wird unter der Datensatznummer ‚12‘ bis ‚16‘ gespeichert.
|
GNS_7
|
Die maximale Größe der NMEA-Datensätze (z. B. RMC, AMC, GSA, ASA oder sonstige) für den Befehl Read Record beträgt 85 Bytes (siehe Tabelle 1).“;
|
|
|
(e)
|
Nummer 4 wird wie folgt geändert:
(i)
|
Nummer 4.1.1 Absatz GNS_9 wird wie folgt geändert:
1)
|
Der Text vor Unterabsatz b erhält folgende Fassung:
„GNS_9
|
Die externe GNSS-Ausrüstung muss folgende Komponenten umfassen (siehe Abbildung 6):
a)
|
Einen handelsüblichen GNSS-Empfänger, um die Positionsdaten über die GNSS-Datenschnittstelle bereitzustellen. Die GNSS-Datenschnittstelle kann beispielsweise der Norm NMEA V4.11 entsprechen; der GNSS-Empfänger dient dann als Sender und überträgt NMEA-Datensätze an den GNSS Secure Transceiver mit einer Frequenz von 1 Hz für die zuvor festgelegten NMEA- und NMEA-ähnlichen Datensätze, die mindestens die RMC, AMC, RMC- und ASA-Datensätze umfassen müssen. Die Implementierung der GNSS-Datenschnittstelle wählt der Hersteller der externen GNSS-Ausrüstung.“;
|
|
|
2)
|
Unterabsatz c erhält folgende Fassung:
„c)
|
Ein Gehäusesystem mit Funktion zur Manipulationserkennung, in dem der GNSS-Empfänger und der GNSS Secure Transceiver untergebracht sind. Die Funktion zur Manipulationserkennung muss den Sicherheitsmaßnahmen gemäß dem Schutzprofil des intelligenten Fahrtenschreibers entsprechen.“;
|
|
|
(ii)
|
Nummer 4.2.1 wird wie folgt geändert:
1)
|
Absatz GNS_14 erhält folgende Fassung:
„GNS_14
|
Das Protokoll der Kommunikation zwischen der externen GNSS-Ausrüstung und der Fahrzeugeinheit muss die folgenden Funktionen unterstützen:
1.
|
das Erfassen und Verteilen von GNSS-Daten (z. B. Standort, Zeit, Geschwindigkeit),
|
2.
|
das Erfassen der Konfigurationsdaten der externen GNSS-Ausrüstung,
|
3.
|
das Verwaltungsprotokoll zur Unterstützung der Kopplung, gegenseitigen Authentisierung und Sitzungsschlüsselvereinbarung zwischen der externen GNSS-Ausrüstung und der Fahrzeugeinheit,
|
4.
|
die Übermittlung der RTC-Zeit der Fahrzeugeinheit und der maximalen Differenz zwischen der tatsächlichen Zeit und der RTC-Zeit der Fahrzeugeinheit an die externe GNSS-Ausrüstung.“;
|
|
|
2)
|
Folgender Absatz wird nach Absatz GNS_18 eingefügt:
„GNS_18a
|
Im Hinblick auf die Funktion 4) Übermittlung der RTC-Zeit der Fahrzeugeinheit und der maximalen Differenz zwischen der tatsächlichen Zeit und der RTC-Zeit der Fahrzeugeinheit an die externe GNSS-Ausrüstung muss der GNSS-Secure Transceiver eine EF (EF VU) in derselben DF mit Dateikennung ‚2F30‘ gemäß Beschreibung in Tabelle 1 verwenden.“;
|
|
3)
|
Folgender Absatz wird nach Absatz GNS_19 eingefügt:
„GNS_19a
|
Der GNSS Secure Transceiver muss die von der Fahrzeugeinheit kommenden Daten in der Elementardatei EF VU speichern. Es handelt sich hierbei um einen linearen Datensatz von fester Länge mit der Kennung ‚2F30‘ im Hexadezimalformat.“;
|
|
4)
|
Absatz GNS_20 Unterabsatz 1 erhält folgende Fassung:
„GNS_20
|
Der GNSS Secure Transceiver muss für die Speicherung der Daten einen Speicher verwenden und mindestens die Anzahl von Schreib/Lese-Zyklen durchführen können, die während einer Lebensdauer von mindestens 15 Jahren notwendig sind. Von diesem Aspekt abgesehen bleiben das Innendesign und die Implementierung des GNSS Secure Transceivers dem Hersteller überlassen.“;
|
|
5)
|
GNS_21, Tabelle 1 erhält folgende Fassung:
„
Tabelle 1
Dateistruktur
|
|
Zugriffsbedingungen
|
Datei
|
Dateikennung
|
Lesen
|
Aktualisieren
|
Verschlüsselt
|
MF
|
3F00
|
|
|
|
EF.ICC
|
0002
|
ALW
|
NEV
(durch VU)
|
Nein
|
DF GNSS Facility
|
0501
|
ALW
|
NEV
|
Nein
|
EF EGF_MACertificate
|
C100
|
ALW
|
NEV
|
Nein
|
EF CA_Certificate
|
C108
|
ALW
|
NEV
|
Nein
|
EF Link_Certificate
|
C109
|
ALW
|
NEV
|
Nein
|
EF EGF
|
2F2F
|
SM-MAC
|
NEV
(durch VU)
|
Nein
|
EF VU
|
2F30
|
SM-MAC
|
SM-MAC
|
Nein
|
Datei/Datenelement
|
Datensatz Nr.
|
Größe (Bytes)
|
Standardwerte
|
|
|
Min.
|
Max.
|
|
MF
|
|
552
|
1031
|
|
EF.ICC
|
|
|
|
|
sensorGNSSSerialNumber
|
|
8
|
8
|
|
|
|
|
|
|
DF GNSS Facility
|
|
612
|
1023
|
|
EF EGF_MACertificate
|
|
204
|
341
|
|
EGFCertificate
|
|
204
|
341
|
{00..00}
|
EF CA_Certificate
|
|
204
|
341
|
|
MemberStateCertificate
|
|
204
|
341
|
{00..00}
|
EF Link_Certificate
|
|
204
|
341
|
|
LinkCertificate
|
|
204
|
341
|
{00..00}
|
|
|
|
|
|
EF EGF
|
|
|
|
|
RMC NMEA-Datensatz
|
'01'
|
85
|
85
|
|
1. GSA NMEA-Datensatz
|
'02'
|
85
|
85
|
|
2. GSA NMEA-Datensatz
|
'03'
|
85
|
85
|
|
3. GSA NMEA-Datensatz
|
'04'
|
85
|
85
|
|
4. GSA NMEA-Datensatz
|
'05'
|
85
|
85
|
|
5. GSA NMEA-Datensatz
|
'06'
|
85
|
85
|
|
Erweiterte Seriennummer der externen GNSS-Ausrüstung gemäß Anlage 1 als SensorGNSSSerialNumber.
|
'07'
|
8
|
8
|
|
Kennung des Betriebssystems des GNSS Secure Transceiver gemäß Anlage 1 als SensorOSIdentifier.
|
'08'
|
2
|
2
|
|
Typgenehmigungsnummer der externen GNSS-Ausrüstung gemäß Anlage 1 als SensorExternalGNSSApprovalNumber.
|
'09'
|
16
|
16
|
|
Kennung der Sicherheitskomponente der externen GNSS-Ausrüstung gemäß Anlage 1 als SensorExternalGNSSSCIdentifier.
|
'10'
|
8
|
8
|
|
AMC-Datensatz
|
'11'
|
85
|
85
|
|
1. ASA-Datensatz
|
'12'
|
85
|
85
|
|
2. ASA-Datensatz
|
'13'
|
85
|
85
|
|
3. ASA-Datensatz
|
'14'
|
85
|
85
|
|
4. ASA-Datensatz
|
'15'
|
85
|
85
|
|
5. ASA-Datensatz
|
'16'
|
85
|
85
|
|
RFU Für künftige Anwendungen reserviert
|
von ‚17‘ bis ‚FD‘
|
|
|
|
EF VU
|
|
|
|
|
VuRtcTime (siehe Anlage 1)
|
'01'
|
4
|
4
|
{00..00}
|
VuGnssMaximalTimeDifference (siehe Anlage 1)
|
'02'
|
2
|
2
|
{00..00}
|
“;
|
|
(iii)
|
Nummer 4.2.2 wird wie folgt geändert:
1)
|
Absatz GNS_22 Unterabsatz 1 erhält folgende Fassung:
„GNS_22
|
Die sichere Übertragung von GNSS-Positionsdaten, RTC-Zeit der Fahrzeugeinheit und maximaler Differenz zwischen der tatsächlichen Zeit und der RTC-Zeit der Fahrzeugeinheit ist nur unter den folgenden Bedingungen zulässig:“;
|
|
2)
|
Absatz GNS_23 erhält folgende Fassung:
„GNS_23
|
Alle T Sekunden (wobei T kleiner/gleich 20 ist), sofern nicht eine Koppelung oder gegenseitige Authentisierung und Sitzungsschlüsselvereinbarung erfolgen, fordert die VU von der externen GNSS-Ausrüstung die Positionsdaten auf Grundlage des folgenden Datenflusses an:
1.
|
Die Fahrzeugeinheit fordert von der externen GNSS-Ausrüstung die Positionsdaten samt DOP-Daten an (aus dem GSA- und dem ASA-Datensatz). Der Secure Transceiver der Fahrzeugeinheit verwendet die Befehle SELECT (Auswählen) und READ RECORD(S) (Datensatz/Datensätze lesen) gemäß ISO/IEC 7816-4:2013 im Secure Messaging (reiner Authentisierungsmodus), wie in Anlage 11 Abschnitt 11.5 beschrieben, mit der Dateikennung ‚2F2F‘ und der Datensatznummer ‚01‘ für den RMC NMEA-Datensatz, den Datensatznummern ‚02‘, ‚03‘, ‚04‘, ‚05‘ und ‚06‘ für den GSA NMEA-Datensatz, der Datensatznummer ‚11‘ für den AMC-Datensatz und den Datensatznummern ‚12‘, ‚13‘, ‚14‘, ‚15‘, ‚16‘ für den ASA-Datensatz.
|
2.
|
Die zuletzt empfangenen Positionsdaten werden in der EF mit der Kennung ‚2F2F‘ gespeichert und die in Tabelle 1 beschriebenen Datensätze im GNSS Secure Transceiver, wenn der GNSS Secure Transceiver vom GNSS-Empfänger NMEA-Daten mit einer Frequenz von mindestens 1 Hz über die GNSS-Datenschnittstelle erhält.
|
3.
|
Der GNSS Secure Transceiver sendet die Antwort an den Secure Transceiver der Fahrzeugeinheit, indem er die APDU-Antwortnachricht im Secure Messaging (reiner Authentisierungsmodus) verwendet, wie in Anlage 11 Abschnitt 11.5 beschrieben.
|
4.
|
Der Secure Transceiver der Fahrzeugeinheit prüft die Authentizität und Integrität der erhaltenen Antwort. Im Falle eines positiven Ergebnisses werden die Positionsdaten über die GNSS-Datenschnittstelle an den Prozessor der Fahrzeugeinheit übermittelt.
|
5.
|
Der Prozessor der Fahrzeugeinheit prüft die empfangenen Daten, indem er die Informationen (z. B. Breite, Länge, Zeit) aus dem RMC NMEA-Datensatz extrahiert. Der RMC NMEA-Datensatz gibt Auskunft darüber, ob die nicht authentisierte Position gültig ist. Wenn die nicht authentisierte Position gültig ist, extrahiert der Prozessor der Fahrzeugeinheit auch die HDOP-Werte aus den GSA NMEA-Datensätzen und berechnet den Mindestwert für das verfügbare Satellitensystem (z. B. wenn die Ortung verfügbar ist).
|
6.
|
Der Prozessor der Fahrzeugeinheit extrahiert auch die Informationen (z. B. Breite, Länge, Zeit) aus dem AMC-Datensatz. Der AMC-Datensatz gibt Auskunft darüber, ob die authentisierte Position nicht gültig ist oder ob das GNSS-Signal angegriffen wurde. Wenn die Position gültig ist, extrahiert der Prozessor der Fahrzeugeinheit auch die HDOP-Werte aus den ASA-Datensätzen und berechnet den Mindestwert für das verfügbare Satellitensystem (d. h. wenn die Ortung verfügbar ist).
|
|
GNS_23a
|
Die Fahrzeugeinheit schreibt auch die RTC-Zeit der Fahrzeugeinheit und die maximale Differenz zwischen der tatsächlichen Zeit und der RTC-Zeit der Fahrzeugeinheit nach Bedarf unter Verwendung der Befehle SELECT (Auswählen) und WRITE RECORD(S) (Datensatz/Datensätze schreiben) gemäß ISO/IEC 7816-4:2013 im Secure Messaging (reiner Authentisierungsmodus), wie in Anlage 11 Abschnitt 11.5 beschrieben, mit der Dateikennung ‚2F30‘ und den Datensatznummern ‚01‘ für VuRtcTime und ‚02‘ für MaximalTimeDifference.“;
|
|
|
(iv)
|
Nummer 4.2.3 wird wie folgt geändert:
1)
|
In Absatz GNS_26 erhalten der vierte und der fünfte Gedankenstrich folgende Fassung:
„–
|
Wird der Datensatz nicht gefunden, sendet der GNSS Secure Transceiver ‚6A83‘ zurück.
|
–
|
Wenn die externe GNSS-Ausrüstung eine Manipulation erkannt hat, muss sie die Statusbytes ‚6690‘ zurücksenden.“;
|
|
2)
|
Absatz GNS_27 wird gestrichen;
|
|
(v)
|
Die folgenden Nummern 4.2.4 und 4.2.5 werden eingefügt:
„4.2.4.
|
Struktur des Befehls WriteRecord
Dieser Abschnitt beschreibt die Struktur des Befehls Write Record (Datensatz schreiben) im Einzelnen. Secure Messaging (reiner Authentisierungsmodus) wird gemäß der Beschreibung in Anlage 11 (Gemeinsame Sicherheitsmechanismen) hinzugefügt.
GNS_26a
|
Der Befehl muss das Secure Messaging (reiner Authentisierungsmodus) unterstützen, siehe Anlage 11.
|
GNS_26b
|
Befehlsnachricht
Byte
|
Länge
|
Wert
|
Beschreibung
|
CLA
|
1
|
‚0Ch‘
|
Secure Messaging angefordert.
|
INS
|
1
|
‚D2h‘
|
Datensatz schreiben
|
P1
|
1
|
‚XXh‘
|
Datensatznummer ('00' verweist auf den aktuellen Datensatz)
|
P2
|
1
|
‚04h‘
|
Schreiben des Datensatzes mit der in P1 angegebenen Datensatznummer
|
Daten
|
X
|
‚XXh‘
|
Daten
|
|
GNS_26c
|
Der in P1 angegebene Datensatz wird zum aktuellen Datensatz.
Byte
|
Länge
|
Wert
|
Beschreibung
|
SW
|
2
|
‚XXXXh‘
|
Statusbytes (SW1, SW2)
|
—
|
Ist der Befehl erfolgreich, sendet der GNSS Secure Transceiver ‚9000‘ zurück.
|
—
|
Wenn die aktuelle Datei nicht datensatzorientiert ist, sendet der GNSS Secure Transceiver ‚6981‘ zurück.
|
—
|
Wenn der Befehl mit P1 = '00' verwendet wird, aber keine aktuelle EF vorliegt, sendet der GNSS Secure Transceiver ‚6986‘ (Befehl nicht zulässig) zurück.
|
—
|
Wird der Datensatz nicht gefunden, sendet der GNSS Secure Transceiver ‚6A83‘ zurück.
|
—
|
Wenn die externe GNSS-Ausrüstung eine Manipulation erkannt hat, muss sie die Statusbytes ‚6690‘ zurücksenden.
|
|
|
4.2.5
|
Sonstige Befehle
GNS_27
|
Der GNSS Secure Transceiver muss die folgenden, in Anlage 2 spezifizierten Befehle für Fahrtenschreiber der 2. Generation unterstützen:
Befehl
|
Referenz
|
Select (Auswählen)
|
Anlage 2 Kapitel 3.5.1
|
Read Binary (Binär lesen)
|
Anlage 2 Kapitel 3.5.2
|
Get Challenge (Zufallszahl abrufen)
|
Anlage 2 Kapitel 3.5.4
|
PSO: Verify Certificate (Zertifikat verifizieren)
|
Anlage 2 Kapitel 3.5.7
|
External Authenticate (Externe Authentisierung)
|
Anlage 2 Kapitel 3.5.9
|
General Authenticate (Allgemeine Authentisierung)
|
Anlage 2 Kapitel 3.5.10
|
MSE:SET
|
Anlage 2 Kapitel 3.5.11
|
|
|
“;
|
(vi)
|
Nummer 4.4.1 Absatz GNS_28 erhält folgende Fassung:
„GNS_28
|
Ein Ereignis ‚Kommunikationsfehler mit der externen GNSS-Ausrüstung‘ muss in der Fahrzeugeinheit aufgezeichnet werden, wie in Anhang IC Randnummer 82 und Anlage 1 (EventFaultType) definiert. In diesem Kontext wird ein Kommunikationsfehler ausgelöst, wenn der Secure Transceiver der Fahrzeugeinheit im Anschluss an eine Anforderungsnachricht gemäß 4.2 keine Antwortnachricht erhält.“;
|
|
(vii)
|
Nummer 4.4.2 Absatz GNS_29 erhält folgende Fassung:
„GNS_29
|
Wenn bei der externen GNSS-Ausrüstung eine Sicherheitsverletzung stattgefunden hat, muss der GNSS Secure Transceiver sicherstellen, dass das kryptografische Material nicht verfügbar ist. Gemäß GNS_25 und GNS_26 muss die VU einen Eingriff erkennen, wenn die Antwort den Status ‚6690‘ aufweist. Die VU generiert dann ein Ereignis des Typs ‚Versuch Sicherheitsverletzung‘ wie in Anhang IC Randnummer 85 und Anlage 1 (EventFaultType für Manipulationserkennung beim GNSS) definiert. Alternativ kann die externe GNSS-Ausrüstung auf Anforderungen der VU ohne Secure Messaging und mit dem Status ‚6A88‘ antworten.“;
|
|
(viii)
|
Nummer 4.4.3 Absatz GNS_30 erhält folgende Fassung:
„GNS_30
|
Wenn der GNSS Secure Transceiver keine Daten vom GNSS-Empfänger erhält, generiert der GNSS Secure Transceiver auf den Befehl READ RECORD (Datensatz lesen) eine Antwortnachricht mit der Datensatznummer ‚01‘ und einem Datenfeld von 12 Bytes, die alle auf 0xFF gesetzt sind. Bei Erhalt der Antwortnachricht mit diesem Wert im Datenfeld muss die Fahrzeugeinheit ein Ereignis des Typs ‚Fehlende Positionsdaten des GNSS-Empfängers‘ generieren und aufzeichnen, wie in Anhang IC Randnummer 81 und Anlage 1 (EventFaultType) definiert.“;
|
|
(ix)
|
Nummer 4.4.4 wird wie folgt geändert:
1)
|
Absatz GNS_31 erhält folgende Fassung:
„GNS_31
|
Wenn die Fahrzeugeinheit erkennt, dass das EGF-Zertifikat zur gegenseitigen Authentisierung nicht mehr gültig ist, muss die Fahrzeugeinheit ein Ereignis des Typs ‚Versuch Sicherheitsverletzung‘ gemäß Anhang IC Randnummer 85 und Anlage 1 (EventFaultType für abgelaufenes Zertifikat der externen GNSS-Ausrüstung) generieren und aufzeichnen. Die Fahrzeugeinheit verwendet weiterhin die erhaltenen GNSS-Positionsdaten.“;
|
|
2)
|
Die Überschrift von Abbildung 4 erhält folgende Fassung:
„Abbildung 6
Schema der externen GNSS-Ausrüstung“;
|
|
|
(f)
|
Nummer 5 wird wie folgt geändert:
(i)
|
Nummer 5,1 Absatz GNS_32 erhält folgende Fassung:
„GNS_32
|
Bei der Übermittlung von Positions-, DOP- und Satellitendaten dient der GNSS-Empfänger als Sender und überträgt NMEA- oder NMEA-artige Datensätze an den als Empfänger dienenden Prozessor der Fahrzeugeinheit mit einer Frequenz von mindestens 1/10 Hz für die zuvor festgelegten Datensätze, die mindestens die RMC-, GSA-, AMC- und ASA-Datensätze umfassen müssen. Alternativ können der Prozessor der Fahrzeugeinheit und die interne GNSS-Ausrüstung andere Datenformate verwenden, um die Daten auszutauschen, die in den in GNS_4, GNS_4a und GNS_5 spezifizierten NMEA- oder NMEA-ähnlichen Datensätzen enthalten sind.“;
|
|
(ii)
|
Nummer 5.2 erhält folgende Fassung:
„5.2.
|
Übermittlung von Daten vom GNSS-Empfänger an die Fahrzeugeinheit
GNS_34
|
Der Prozessor der Fahrzeugeinheit prüft die empfangenen Daten, indem er die Informationen (z. B. Breite, Länge, Zeit) aus dem RMC NMEA-Datensatz und dem AMC-Datensatz extrahiert.
|
GNS_35
|
Der RMC NMEA-Datensatz gibt Auskunft darüber, ob die nicht authentisierte Position gültig ist. Wenn die nicht authentisierte Position nicht gültig ist, sind die Positionsdaten nicht verfügbar und können nicht verwendet werden, um die Position des Fahrzeugs aufzuzeichnen. Wenn die nicht authentisierte Position gültig ist, extrahiert der Prozessor der Fahrzeugeinheit auch die HDOP-Werte aus den GSA NMEA-Datensätzen.
|
GNS_36
|
Der Prozessor der Fahrzeugeinheit extrahiert auch die Informationen (z. B. Breite, Länge, Zeit) aus dem AMC-Datensatz. Der AMC-Datensatz gibt Auskunft darüber, ob die nicht authentisierte Position gemäß GNS_4a gültig ist. Wenn die nicht authentisierte Position gültig ist, extrahiert der Prozessor der Fahrzeugeinheit auch die HDOP-Werte aus den ASA-Datensätzen.
|
|
5.3.
|
Übermittlung von Daten von der Fahrzeugeinheit an den GNSS-Empfänger
GNS_37
|
Der Prozessor der Fahrzeugeinheit stellt dem GNSS-Empfänger die RTC-Zeit der Fahrzeugeinheit und die maximale Differenz zwischen der tatsächlichen Zeit und der RTC-Zeit der Fahrzeugeinheit gemäß GNS_3f und GNS_3g zur Verfügung.
|
|
5.4.
|
Fehlerbehandlung
5.4.1
|
Fehlende Positionsdaten des GNSS-Empfängers
GNS_38
|
Die Fahrzeugeinheit muss ein Ereignis des Typs ‚Fehlende Positionsdaten des GNSS-Empfängers‘ generieren und aufzeichnen, wie in Anhang IC Randnummer 81 und Anlage 1 (EventFaultType) definiert.‘
|
|
|
|
|
(g)
|
Die Nummern 6 und 7 erhalten folgende Fassung:
„6.
|
POSITIONSDATENVERARBEITUNG UND -AUFZEICHNUNG DURCH DIE FAHRZEUGEINHEIT
Dieser Abschnitt gilt für die Konfiguration des intelligenten Fahrtenschreibers sowohl mit als auch ohne externe GNSS-Ausrüstung.
GNS_39
|
Die Positionsdaten müssen in der Fahrzeugeinheit gespeichert werden, zusammen mit einem Merker, der angibt, ob die Position authentisiert wurde. Wenn Positionsdaten in der Fahrzeugeinheit aufgezeichnet werden müssen, gelten folgende Regeln:
a)
|
Wenn sowohl die authentisierte Position als auch die Standardposition gültig und konsistent sind, werden die Standardposition und deren Genauigkeit in der Fahrzeugeinheit aufgezeichnet und der Merker wird auf ‚authentisiert‘ gesetzt.
|
b)
|
Wenn sowohl die authentisierte Position als auch die Standardposition gültig sind, aber diese nicht konsistent sind, werden die authentisierte Position und deren Genauigkeit in der Fahrzeugeinheit gespeichert und der Merker wird auf ‚authentisiert‘ gesetzt.
|
c)
|
Wenn die authentisierte Position gültig und die Standardposition nicht gültig ist, werden die authentisierte Position und deren Genauigkeit in der Fahrzeugeinheit aufgezeichnet und der Merker wird auf ‚authentisiert‘ gesetzt.
|
d)
|
Wenn die Standardposition gültig und die authentisierte Position nicht gültig ist, werden die Standardposition und deren Genauigkeit in der Fahrzeugeinheit aufgezeichnet und der Merker wird auf ‚nicht authentisiert‘ gesetzt.
|
Authentisierte Positionen und Standardpositionen gelten als konsistent, wie in Abbildung 7 dargestellt, wenn die horizontale authentisierte Position in einem Kreis liegt, dessen Mittelpunkt die horizontale Standardposition ist und dessen Radius der nach folgender Formel berechnete Wert R_H, aufgerundet auf die nächste ganze Zahl, ist:
R_H = 1,74 • σUERE • HDOP
|
Wobei Folgendes gilt:
—
|
R_H ist der relative Radius eines Kreises rund um die geschätzte horizontale Position, in Metern. Es handelt sich dabei um einen Indikator, der verwendet wird, um die Konsistenz zwischen der Standard- und der authentisierten Position zu prüfen.
|
—
|
σUERE ist die Standardabweichung des benutzeräquivalenten Bereichsfehlers (User Equivalent Range Error, UERE), der alle Messfehler für die Zielanwendung modelliert, einschließlich städtische Umgebungen. Ein konstanter Wert von σUERE = 10 Meter wird verwendet.
|
—
|
HDOP (Horizontal Dilution of Precision) ist die Horizontalgenauigkeit, die vom GNSS-Empfänger berechnet wird.
|
—
|
σUERE . HDOP ist die geschätzte mittlere quadratische Abweichung im horizontalen Bereich.
|
|
GNS_40
|
Wenn der Wert des Status in einem empfangenen AMC-Datensatz gemäß Randnummer GNS_4a auf ‚J‘ oder ‚O‘ oder ‚F‘ gesetzt wird, muss die Fahrzeugeinheit ein Ereignis des Typs ‚GNSS-Anomalie‘ generieren und aufzeichnen, wie in Anhang IC Randnummer 88a und Anlage 1 (EventFaultType) definiert. Die Fahrzeugeinheit kann zusätzliche Prüfungen durchführen, bevor sie eine GNSS-Anomalie im Anschluss an den Empfang einer Einstellung ‚J‘ oder ‚O‘ speichert.
|
|
7.
|
GNSS-ZEITKONFLIKT
GNS_41
|
Stellt die Fahrzeugeinheit eine Abweichung zwischen der Zeitmessfunktion der Fahrzeugeinheit und der aus den GNSS-Signalen stammenden Zeit fest, muss die Fahrzeugeinheit ein Ereignis des Typs ‚Zeitkonflikt‘ gemäß Anhang IC Randnummer 86 und Anlage 1 (EventFaultType) generieren und aufzeichnen.“
|
|
|
(h)
|
Folgende Nummer 8 wird angefügt:
„8.
|
DATENKONFLIKT FAHRZEUGBEWEGUNG
GNS_42
|
Die Fahrzeugeinheit muss ein Ereignis des Typs ‚Datenkonflikt Fahrzeugbewegung‘ gemäß Anhang IC Randnummer 84 auslösen und aufzeichnen, wenn die vom Bewegungssensor berechneten Bewegungsangaben in Widerspruch zu den vom internen GNSS-Empfänger oder von der externen GNSS-Ausrüstung berechneten Bewegungsangaben oder zu den Bewegungsangaben aus einer oder mehreren unabhängigen Quelle(n) gemäß Anhang IC Randnummer 26 stehen.
Das Ereignis ‚Datenkonflikt Fahrzeugbewegung‘ muss bei Eintritt einer der folgenden Auslösebedingungen ausgelöst werden:
|
Auslösebedingung 1:
Der getrimmte Mittelwert der Geschwindigkeitsdifferenzen zwischen den Quellen wird gemäß folgender Erläuterung verwendet, wenn die Positionsdaten des GNSS-Empfängers verfügbar sind und die Zündung des Fahrzeugs eingeschaltet ist:
—
|
Höchstens alle 10 Sekunden wird der Absolutwert der Differenz zwischen der vom GNSS und der vom Bewegungssensor kalkulierten Fahrzeuggeschwindigkeit berechnet.
|
—
|
Alle in einem die letzten 5 Minuten, in denen Fahrzeugbewegung stattgefunden hat, umfassenden Zeitfenster berechneten Werte werden herangezogen, um den getrimmten Mittelwert zu errechnen.
|
—
|
Der getrimmte Mittelwert wird als Durchschnitt von 80 % der übrigen Werte berechnet, nachdem die höchsten Absolutwerte ausgeschlossen wurden.
|
Das Ereignis ‚Datenkonflikt Fahrzeugbewegung‘ wird ausgelöst, wenn der getrimmte Mittelwert ununterbrochen für fünf Minuten, in denen Bewegung stattfindet, über 10 km/h liegt. (Hinweis: Durch die Verwendung des getrimmten Mittels in den letzten 5 Minuten soll das Risiko von Messausreißern und transienten Werten gemindert werden.)
Für die Berechnung des getrimmten Mittelwerts gilt das Fahrzeug als in Bewegung, wenn mindestens ein geschätzter Wert für die Fahrzeuggeschwindigkeit entweder vom Bewegungssensor oder vom GNSS-Empfänger nicht gleich Null ist.
|
|
Auslösebedingung 2:
Das Ereignis ‚Datenkonflikt Fahrzeugbewegung‘ muss auch ausgelöst werden, wenn die folgende Bedingung erfüllt ist:
GnssDistance > [OdometerDifference × OdometerToleranceFactor + Minimum(SlipDistanceUpperlimit; (OdometerDifference × SlipFactor)) + GnssTolerance + FerryTrainDistance]
Wobei Folgendes gilt:
—
|
GnssDistance ist die Entfernung zwischen der aktuellen und der vorherigen Position des Fahrzeugs, mit beiden Positionen aus gültigen authentisierten Positionsnachrichten, ohne Berücksichtigung der Höhe
|
—
|
OdometerDifference ist die Differenz zwischen dem aktuellen Kilometerstand und dem Kilometerstand, der der vorherigen gültigen authentisierten Positionsnachricht entspricht
|
—
|
OdometerToleranceFactor ist gleich 1,1 (ungünstigster Toleranzfaktor für alle Messtoleranzen des Kilometerzählers)
|
—
|
GnssTolerance ist gleich 1 km ist (GNSS-Toleranz im ungünstigsten Fall)
|
—
|
Minimum (SlipDistanceUpperLimit;
(OdometerDifference * SlipFactor)) ist der Mindestwert zwischen:
—
|
SlipDistanceUpperLimit ist gleich 10 km (oberer Grenzwert der Schlupfdistanz, die durch Schlupfwirkungen beim Bremsen verursacht wird)
|
—
|
und OdometerDifference * SlipFactor, wobei SlipFactor ist gleich 0,2 (maximaler Einfluss von Schlupfwirkungen beim Bremsen)
|
|
—
|
FerryTrainDistance wird berechnet als: FerryTrainDistance = 200 km/h * tFerryTrain, wobei tFerryTrain die Summe der Dauer in Stunden der Fährüberfahrten/Zugfahrten im betrachteten Zeitintervall ist. Die Dauer der Fährüberfahrten/Zugfahrten ist definiert als die Zeitdifferenz zwischen dem Merker ‚Ende‘ und dem Merker ‚Anfang‘ der Fährüberfahrt/Zugfahrt.
|
Die oben genannten Prüfungen müssen alle 15 Minuten durchgeführt werden, wenn die erforderlichen Positionsdaten vorhanden sind, und andernfalls, sobald die Positionsdaten vorhanden sind.
Für diese Auslösebedingung gilt:
—
|
Datum und Uhrzeit des Beginns des Ereignisses entsprechen dem Datum und der Uhrzeit des Empfangs der vorherigen Positionsnachricht,
|
—
|
Datum und Uhrzeit des Endes des Ereignisses entsprechen dem Datum und der Uhrzeit, wenn die geprüfte Bedingung wieder falsch wird.
|
|
|
Auslösebedingung 3:
Die Fahrzeugeinheit stellt eine Abweichung fest, die darin besteht, dass in einem bestimmten Zeitraum der Bewegungssensor keine Bewegung erkennt und die unabhängige Bewegungsquelle eine Bewegung erkennt. Die Bedingungen für die Aufzeichnung einer Abweichung sowie des Zeitraums der Feststellung der Abweichung werden vom Hersteller der Fahrzeugeinheit festgelegt, wobei die Abweichung jedoch innerhalb von höchstens drei Stunden erkannt werden muss.“;
|
|
|
|
|