Vereinbarung über die Durchführung des Prüfverfahrens zur Erbringung mautdienstbezogener Leistungen

DSRC_LLC__BI06_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Anschließend sendet sie ein ECHO.rq mit P-Bit im LLC-Kontrollfeld=1, aber ohne LSDU, der von der OBU ignoriert werden soll. Abschließend wird mit einem gültigen ECHO.rq an die OBU überprüft, ob sie noch auf valide ACn-Befehle reagiert.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul ACn-Befehle mit p-Bit=1, aber ohne LSDU ignoriert.

DSRC_LLC__BI07_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Anschließend sendet sie ein ECHO.rq, das von der OBU beantwortet werden soll. Die Bake wiederholt das ECHO.rq unverändert und erwartet die gleiche Antwort wie vorher. Danach sendet die Bake einen ECHO.rq mit invertiertem n-Bit und anderen ECHO-Daten und erwartet eine korrekte Antwort auf den neuen Befehl.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul doppelt ACn-Befehle korrekt verarbeitet.

DSRC_LLC__BV01_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Das P-Bit im LLC-Kontrollfeld der VST soll den Wert 0 haben.Es soll sichergestellt werden, dass die OBU/das DSRC-ModulUI-Befehle austauschen kann.

DSRC_LLC__BV02_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Danach sendet sie ein SET_MMI.rq als AC0-Befehl; als Antwort wird eine AC1-Antwort mit Final-Bit=0 und status subfield=NR_OK erwartet. Dann sendet die Bake ein SET_MMI.rq als AC1-Befehl; als Antwort wird eine AC0-Antwort mit Final-Bit=0 und status subfield=NR_OK erwartet.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul ACn-Befehle empfangen kann.

DSRC_LLC__BV03_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Danach sendet sie ein ECHO.rq als AC0-Befehl; als Antwort wird eine AC1-Antwort mit Final-Bit=1 und status subfield=OK_OK erwartet. Dann sendet die Bake ein ECHO.rq als AC1-Befehl; als Antwort wird eine AC0-Antwort mit Final-Bit=1 und status subfield=OK_OK erwartet.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul ACn-Befehle austauschen kann.

DSRC_LLC__BV05_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Dann sendet sie einen ACn-Befehl, der dazu führt, dass die OBU die late response-Prozedur ausführt. Als Antwort wird ein Rahmen mit LLC status subfield=NE_OK erwartet. Die Bake wiederholt BSTs, bis die angenommene Verarbeitungsdauer der OBU abgelaufen ist, und erwartet dann ein private window request. Die Bake sendet ein private window response und erwartet die Antwort auf den ACn-Befehl in einem UI-Rahmen.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul die late response-prozedur I korrekt durchführt.

DSRC_MAC__BI01_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21, bei der in der Nachricht zwei Bitfehler auftreten. Die OBU soll nicht antworten. Anschließend wird mit einer ungestörten BST überprüft, ob die OBU korrekt reagiert.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen mit zweifachem Bitfehler in der Nachricht ignoriert.

DSRC_MAC__BI02_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21, bei der in der FCS zwei Bitfehler auftreten. Die OBU soll nicht antworten. Anschließend wird mit einer ungestörten BST überprüft, ob die OBU korrekt reagiert.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen mit zweifachem Bitfehler in der FCS ignoriert.

DSRC_MAC__BI03_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21, bei der in der Nachricht 15 aufeinanderfolgende Bit invertiert werden. Die OBU soll nicht antworten. Anschließend wird mit einer ungestörten BST überprüft, ob die OBU korrekt reagiert.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen mit 15 konsekutiven Bitfehlern in der Nachricht ignoriert.

DSRC_MAC__BI04_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21, bei der das Einfügen der 0-Bits unterbleibt. Die OBU soll nicht antworten. Anschließend wird mit einer ungestörten BST überprüft, ob die OBU korrekt reagiert.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen ohne 0-Bit insertion in der LID ignoriert.

DSRC_MAC__BI05_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21, bei der das end flag durch ein Abort-Byte ersetzt wird. Die OBU soll nicht antworten. Anschließend wird mit einer ungestörten BST überprüft, ob die OBU korrekt reagiert.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen mit einem Abort-Byte anstelle der end flag ignoriert.

DSRC_MAC__BI06_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21, bei der die ProfileList so lang ist, dass die maximal erlaubte Rahmenlänge (128 Bytes incl. Flags und FCS) überschritten wird. Die OBU soll nicht antworten.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul Rahmen erkennt und ignoriert, die länger als die vom Standard erlaubten 128 Byte (incl. Flags und FCS) sind.

DSRC_MAC__BI07_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Anschließend sendet sie privateWindowRequests, bei der die LID 5 statt der vorgesehenen 4 Byte lang ist und bei der die ersten 4 der 5 Byte der LID der OBU entsprechen. Zuletzt wird überprüft, ob die OBU noch auf valide window allocations reagiert.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul eine falsche LID erkennt und ignoriert.

DSRC_MAC__BI08_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Anschließend sendet sie privateWindowRequests ohne MAC-Kontrollfeld. Zuletzt wird überprüft, ob die OBU noch auf valide window allocations reagiert.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen ohne MAC-Kontrollfeld erkennt und ignoriert.

DSRC_MAC__BI09_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21, bei der das A-Bit im MAC-Kontrollfeld auf 0 gesetzt ist. Die OBU soll nicht antworten. Anschließend wird mit einer normalen BST überprüft, ob die OBU korrekt reagiert.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul dasA-Bit im MAC-Kontrollfeld beachtet.

DSRC_MAC__BI10_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21, bei der das D-Bit im MAC-Kontrollfeld auf 1 gesetzt ist. Die OBU soll nicht antworten. Anschließend wird mit einer normalen BST überprüft, ob die OBU korrekt reagiert.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul in der BST das D-Bit im MAC-Kontrollfeld beachtet.

DSRC_MAC__BI11_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21 und erwartet ein private window request. Danach sendet sie ein private window allocation, bei dem das D-Bit im MAC-Kontrollfeld auf 1 gesetzt ist. Die OBU soll nicht antworten. Anschließend wird mit einem korrekten private window allocation überprüft, ob die OBU korrekt reagiert.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul in privaten Rahmen das D-Bit im MAC-Kontrollfeld beachtet.

DSRC_MAC__BI12_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21, bei der das L-Bit im MAC-Kontrollfeld auf 0 gesetzt ist. Die OBU soll nicht antworten. Anschließend wird mit einer normalen BST überprüft, ob die OBU korrekt reagiert.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen mit falsch gesetztem L-Bit im MAC-Kontrollfeld erkennt und ignoriert.

DSRC_MAC__BI13_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21 und erwartet ein private window request. Danach sendet sie ein private window allocation, bei dem das L-Bit im MAC-Kontrollfeld auf 1 gesetzt ist. Die OBU soll nicht antworten. Anschließend wird mit einem korrekten private window allocation überprüft, ob die OBU korrekt reagiert.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen mit falsch gesetztem L-Bit im MAC-Kontrollfeld erkennt und ignoriert.

DSRC_MAC__BI14_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21 und erwartet ein private window request. Danach sendet sie ein private window allocation, bei dem das C/R-Bit im MAC-Kontrollfeld auf 1 gesetzt ist. Die OBU soll nicht antworten. Anschließend wird mit einem korrekten private window allocation überprüft, ob die OBU korrekt reagiert.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen mit falsch gesetztem C/R-Bit im MAC-Kontrollfeld erkennt und ignoriert.

DSRC_MAC__BI15_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21 und erwartet ein private window request. Danach sendet sie ein private window allocation, bei dem die Füllbits im MAC-Kontrollfeld auf 1 gesetzt sind. Die OBU soll nicht antworten. Anschließend wird mit einem korrekten private window allocation überprüft, ob die OBU korrekt reagiert.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen mit falsch gesetzten Füllbits im MAC-Kontrollfeld erkennt und ignoriert.

DSRC_MAC__BI16_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21, bei der das Radiosignal über 15 zusammenhängende Bit unterdrückt wird. Die OBU soll nicht antworten. Anschließend wird mit einer ungestörten BST überprüft, ob die OBU korrekt reagiert.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen mit einer Funkstörung über 15 zusammenhängende Bit ignoriert.

DSRC_MAC__BI17_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21, bei der das Radiosignal während der start flag unterdrückt wird. Die OBU soll nicht antworten. Anschließend wird mit einer ungestörten BST überprüft, ob die OBU korrekt reagiert.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen mit einer Funkstörung während der start flag ignoriert.

DSRC_MAC__BI18_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21, bei der das Radiosignal während der end flag unterdrückt wird. Die OBU soll nicht antworten. Anschließend wird mit einer ungestörten BST überprüft, ob die OBU korrekt reagiert.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen mit einer Funkstörung während der end flag ignoriert.

DSRC_MAC__BI19_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21 und erwartet ein private window request. Danach sendet sie ein private window allocation mit der LID 0xFF. Die OBU soll nicht antworten. Anschließend wird mit einem korrekten private window allocation überprüft, ob die OBU korrekt reagiert.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen mit der Broadcast-LID anstelle der privaten ignoriert.

DSRC_MAC__BI20_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21 und erwartet ein private window request. Dann sendet sie ein private window allocation mit einer Multicast-LID. Die OBU soll nicht antworten. Anschließend wird mit einem korrekten private window allocation überprüft, ob die OBU korrekt reagiert.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen mit einer Multicast-LID anstelle der privaten ignoriert.

DSRC_MAC__BI21_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21 und erwartet ein private window request. Danach sendet sie ein private window allocation, bei dem das A-Bit im MAC-Kontrollfeld auf 0 gesetzt ist. Die OBU soll nicht antworten. Anschließend wird mit einem korrekten private window allocation überprüft, ob die OBU korrekt reagiert.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul in privaten Rahmen dasA-Bit im MAC-Kontrollfeld beachtet.

DSRC_MAC__BI22_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und FIXME LA durch. Anschließend sendet sie einen ACn-Befehl, wobei das A-Bit des Rahmens auf 0 gesetzt wird. Zuletzt wird mit einem ACn-Befehl mit korrektem A-Bit überprüft, ob die OBU noch korrekt reagiert.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul in privaten Rahmen dasA-Bit im MAC-Kontrollfeld beachtet.

DSRC_MAC__BI23_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21 und erwartet ein private window request. Dann sendet sie ein private window allocation mit gültiger, aber von der LID des private windows request abweichender LID. Die OBU soll nicht antworten. Anschließend wird mit einem korrekten private window allocation überprüft, ob die OBU korrekt reagiert.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul in privaten Rahmen die LID beachtet.

DSRC_MAC__BI24_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21 und erwartet ein private window request. Die Bake ignoriert das window request und wiederholt die BST. Die OBU soll ihr private window request wiederholen.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul private window requests korrekt wiederholt.

DSRC_MAC__BV01_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21, bei der die ProfileList so lang ist, dass die maximal erlaubte Rahmenlänge (128 Bytes incl. Flags und FCS) erreicht wird. Die OBU soll mit einem private window request antworten.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul auch DSRC-Rahmen der durch den Standard festgelegten Maximallänge korrekt verarbeiten kann.

DSRC_MAC__BV02_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Anschließend sendet sie T1 nach dem Ende der VST ein ECHO.rq. Eine Antwort der OBU wird erwartet.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul auch DSRC-Rahmen verarbeiten kann, die im vom Standard erlaubten zeitlichen Mindestabstand versendet wurden.

DSRC_MAC__BV03_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21 und erwartet ein private window request. Das wird X male wiederholt und dann ausgewetet, ob die window requests zeitlich im erlaubten Bereich lagen.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul jedes der drei public uplink windows benutzt.

DSRC_MAC__BV04_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Anschließend sendet sie ein SET_MMI.rq ohne window allocation und dann unmittelbar im zeitlichen Abstand von T2 eine neue BST. Eine Antwort der OBU wird erwartet.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul auch DSRC-Rahmen verarbeiten kann, die im vom Standard erlaubten zeitlichen Mindestabstand versendet wurden.

DSRC_MAC__BV05_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Dabei wird die Zeit zwischen dem Ende des end flag des private window allocation und dem ersten Bit der Präambel der VST sowie dem Ende des letzten Bit der end flag der VST gemessen. Beide Werte sollen die Vorgaben aus dem Standard einhalten.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul bei privaten Rahmen das vom Standard vorgegebene Timing einhält.

DSRC_MAC__BV06_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Die Bake ignoriert die VST und sendet ein private window allocation mit dem gleichen S-Bit wie beim vorigen window allocation. Es wird erwartet, dass die OBU mit einer VST antwortet.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul das S-Bit und das L-Bit des MAC-Kontrollfeldes korrekt verarbeitet und Wiederholungen der VST korrekt verarbeiten kann.

DSRC_MAC__BV07_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Anschließend sendet die Bake ein ECHO mit ECHO_DATA1 und erwartet ein ECHO.rs mit ECHO_DATA1. Dann sendet die Bake ein ECHO mit ECHO_DATA2 und dem gleichen Wert dess-Bits wie zuvor und erwartet ein ECHO.rs mit ECHO_DATA2. Dann sendet die Bake ein private window allocation mit dem gleichen Wert des S-Bit und erwartet ein ECHO.rs mit ECHO_DATA2.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul das S-Bit und das L-Bit des MAC-Kontrollfeldes bei Rahmen mit LPDU korrekt verarbeitet.

DSRC_MAC__BV08_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21 und erwartet ein private window request. Das wird X male wiederholt und dann ausgewertet, ob die private window requests gleichmäßig benutzt wurden.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul jedes der drei public uplink windows benutzt.

DSRC_MAC__BV09_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch, wobei das C/R-Bit des private window allocation auf 1 gesetzt wird. Anschließend sendet die Bake ein private window request mit C/R=0 und gleichem S-Bit wie vorher. Die OBU soll eine VST schicken.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul beide gültigen Werte des C/R-Bit des MAC-Kontrollfeldes eines private window requests korrekt verarbeitet.

DSRC_SFXX_2CCC_5010Die Bake wird für CCC:2019 (SST301 v3.1) konfiguriert. Wenn sich die OBU anmeldet, muss diese in der VST alle ContextMarks anzeigen, die sie für CCC unterstützt. Die Bake führt die Transaktion dann mit der EID der gültigen CCC:2019 (SST301 v3.1) ContextMark durch. In einem zweiten Durchlauf wird die Bake für CCC:2015 (SST301 v2.2) konfiguriert. Wenn sich die OBU anmeldet, muss diese in der VST alle ContextMarks anzeigen, die sie für CCC unterstützt. Die Bake führt die Transaktion dann mit der EID der gültigen CCC:2015 (SST301v2.2) ContextMark durch.Dieser Testfall soll sicherstellen, dass EETS-OBUs, die in der VST CCC:2015 und CCC:2019 anbieten, in beiden Versionen eine CCC-Transaktion erfolgreich durchführen können. In Anlehnung an die Bitfehlerraten-Tests der EN300674-2-2 werden in diesem Labortest die Übertragungssicherheit im stabilen Laboraufbau überprüft.

DSRC_SFXX_ABAA_5010–Die Bake wird so konfiguriert, dass ausschließlich die Contextmark für CCC:2019 (SST301 v3.1) für die Transaktion benutzt wird.–Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob die OBU/das DSRC-Modul kommunikationsbereit ist.–Die folgenden Schritte werden 10x wiederholt:–Der Tester wird aufgefordert, den Wert der Achszahl auf einen neuen Wert einzustellen und bestätigt die Einstellung.–Zwei CCC:2019(SST301 v3.1)-Transaktionen werden durchgeführt mit einem zeitlichen Abstand von mehr als 15 Sekunden.–Die Transaktionsdaten werden aus der Bake ausgelesen.–Das Log wird am Ende der 10 Testwiederholungen bezüglich der achszahlbezogenen Attribute (19, 17, 46, 48, 62) ausgewertet, wobei jede zweite Transaktion berücksichtigt wird.Es soll nachgewiesen werden, dass das DUT alle von der eingestellten Achszahl (Attribut 19) abhängigen Attribute(17, 46, 48, 62) gleichzeitig ändert und so die Datenkonsistenz gewährleistet ist, wenn der Nutzer eine andere Achszahl einstellt. Somit wird erwartet, dass sich eine Achszahländerung im Bereich der Kommunikationszone der Bake sich auf alle betroffenen Attribute gleichzeitig ausgewirkt hat. Dieser Test wurde im Review CEN-TC278-WG1_N2610_2_ ISO_DIS_13143-1_ Commenting_Form- Response als sinnvoll angesehen, konnte jedoch noch nicht in den normativen Testfallkatalog aufgenommen werden, weil hierfür noch keine direkte Anforderung in der 12813 besteht. Für das BALM ist dieser Test jedoch notwendig, da inkonsistente Daten eine Beweissicherung erschweren wurden.

DSRC_SFXX_ALAT_5010–Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit ist.–Die Bake wird für eine CCC:2019(SST301 v3.1)-Transaktion in der Form konfiguriert, dass jedes Attribut einzeln durch ein Get.rq abgefragt wird.–Nach der Attribute Abfrage wird die Bakenübertragung angehalten.–Die Transaktionsdaten werden aus der Bake ausgelesen.–Das Log wird bezüglich der Attribute entsprechend den Attributsformaten im Standard, der Wert gemäß den Vorgaben vom Einzeldokument 4.3.1 V3.1 und bzgl. der Identifkationsdaten der VST ausgewertet.Es soll geprüft werden, dass das DUT alle der für CCC (ISO 12813:2019 und Anlage 2 Einzeldokument 4.3.1 V3.1, Stand: 09.06.2022) erforderlichen Attribute(0, 16, 17, 18, 19, 20, 22, 24, 32, 46, 48, 49, 50, 51, 52, 53, 55, 60, 61, 62, 63, 64, 99, 100, 101) unterstützt. Weiterhin sollen die Identifikationsdaten des Moduls aus der VST ermittelt werden, die aus den Parametern CCC-ContextMark, ManufacturerID und EquipmentClass bestehen. Dieses ist ein modifizierter Normtestfall (TP/AP-BAS/OBU/BV/10 und TP/AP-DAT/OBU/BV/04 der Norm CCC ISO_TS_13143-1:2020) zur Dokumentation der DUT-Identifikations- und Attributedaten.

DSRC_SFXX_AWKT_0010Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit sind.•Die Bake sendet danach eine neue BST mit der neuen Beacon-ID (1) und erwartet ein private Windows.req vom DUT.•Danach pausiert die Bake für 95 ms.•Dann sendet die Bake eine zweite BST mit einer neuen Beacon-ID (2) und erwartet wieder ein private Windows.req vom DUT.•Die Dauer ab der BST mit Beacon-ID (1) bis zum private window request nach der BST mit Beacon-ID (2) wird gemessen.Es soll nachgewiesen werden, dass die Dauer vor dem Umschalten in den Energiesparmodus und damit die AwakeT-Dauer des DUTs >100ms beträgt. Dieser Test erfolgt als Labortest zur Verifizierung der Anforderungen im Kapitel Interlayer Management nach Einzeldokument 4.3.1 Version 3.1 (Stand: 09.06.2022).

DSRC_SFXX_BCKT_5010Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit ist. Danach wird eine vollständige CCC:2019(SST301 v3.1)-Transaktion mit dem DUT mit einer neuen Beacon-ID (1) und einem abschließenden Release (1) der Bake durchgeführt. Dann sendet Bake BSTs im Abstand von 50 ms mit einer neuen Beacon-ID (2). Es wird die Zeit zwischen dem Release (1) und dem ersten darauffolgenden private window request ermittelt.Es soll nachgewiesen werden, dass die Dauer des BlockingTimer des DUT nicht größer als 3 Sekunden ist. Dieser Test erfolgt als Labortest zur Verifizierung der Anforderungen im Kapitel Interlayer Management nach Einzeldokument 4.3.1 Version 3.1(Stand: 09.06.2022).

DSRC_SFXX_BCKT_5011Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit ist. Danach wird eine vollständige CCC-Transaktion mit dem DUT mit einer neuen Beacon-ID (1) und einem abschließenden Release (1) der Bake durchgeführt. Dann sendet Bake BSTs im Abstand von 50 ms mit einer neuen Beacon-ID (2). Es wird die Zeit zwischen dem Release (1) und dem privaten Windows.req auf die BST mit der Beacon-ID (2) ermittelt.Es soll nachgewiesen werden, dass die Dauer des BlockingTimer des DUT nicht größer als 5 Sekunden ist.

DSRC_SFXX_BLIM_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake 200 Mal eine BST und registriert, ob die OBU bis zuletzt mit einem private window request antwortet.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul alle empfangenen BSTs richtig auswertet.

DSRC_SFXX_BV02_0001•Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit ist.•Für den eigentlichen Testfall wird eine Initialisierung (BST-VST) mit einer neuen BeaconID und einem anschließenden EVENT-REPORT.request(RELEASE) mit Mode=0 und FlowControl=1 konfiguriert und aktiviert.•Danach wird mit der gleichen LID ein ECHO.rq Command mit Poll Bit = 0 und ohne Nutzdaten gesendet und überprüft, ob die OBU/das DSRC Modul wider Erwarten noch reagiert.Es soll nachgewiesen werden, dass das DUT den RELEASE-Befehl mit einem ECHO.rq korrekt verarbeitet. Der Testfall ist abgeleitet aus dem CCC ISO_TS_13143-1:2020-11 Normtestfall TP/AP-BAS/OBU/BV/02 (ECHO.rq mit Poll Bit=0, siehe ISO TS-13143-1).

DSRC_SFXX_BV02_0002•Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit ist.•Für den eigentlichen Testfall wird eine Initialisierung (BST-VST) mit einer neuen Beacon-ID und einem anschließenden EVENT-REPORT.request(RELEASE) mit Mode=0 und FlowControl=1 konfiguriert und aktiviert.•Danach wird mit der gleichen BST gesendet und überprüft, ob das DUT wider Erwarten reagiert.•Anschließend wird nach 5s erneut die gleiche BST wiederholt und überprüft, ob das DUT wider Erwarten reagiert.Es soll nachgewiesen werden, dass das DUT den RELEASE-Befehl mit derselben BST korrekt verarbeitet. Der Testfall ist abgeleitet aus dem CCC ISO_TS_13143-1:2020-11 Normtestfall TP/AP-BAS/OBU/BV/02 (ECHO.rq mit Poll Bit=0, siehe ISO TS-13143-1). (Sofortiges RELEASE).

DSRC_SFXX_BV02_0003•Eine Initialisierung (BST-VST) mit einerneuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit ist.•Für den eigentlichen Testfall wird eine Initialisierung (BST-VST) mit einer neuen Beacon-ID durchgeführt, ein ECHO.rq (Poll Bit=1) gesendet, das beantwortet werden soll, und anschließend mit einemEVENT-REPORT.request(RELEASE) mit Mode=0 und FlowControl=1 die Transaktion abgeschlossen.•Danach wird die gleiche BST wiederholt und überprüft, ob das DUT wider Erwarten reagiert.•Anschließend wird nach 5s erneut die gleiche BST wiederholt und überprüft, ob das DUT wider Erwarten reagiert.•Die Transaktionsdaten werden aus der Bake ausgelesen und ausgewertet.Es soll nachgewiesen werden, dass das DUT den RELEASE-Befehl mit ECHO.rq (Poll Bit=1) korrekt verarbeitet. Der Testfall ist abgeleitet aus dem CCC ISO_TS_13143-1:2020-11 Normtestfall TP/AP-BAS/OBU/BV/02 (ECHO.rq mit Poll Bit=1: Initialisation, private ACn, RELEASE, Initialisationsversuch).

DSRC_SFXX_BV04_0010Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit ist.•Für den eigentlichen Testfall wird eine Initialisierung (BST-VST) mit einer neuen Beacon-ID mit mode=1 und FlowControl=2 konfiguriert und aktiviert.•Danach sendet die Bake ein ECHO.rqBefehl, welcher von der OBU beantwortet werden soll.•Nach 256 Sekunden sendet die Bake erneut eine BST mit gleicher Beacon-ID mit mode=1 und FlowControl=2, die von der OBU mit einer neuen LID (und in der Folge VST) wieder beantwortet werden soll.Es soll geprüft werden, dass das DUT den Parameter beaconTime der BST nach 256s korrekt handhabt. Der Testfall ist abgeleitet aus dem CCC ISO_TS_13143-1:2020-11 Normtestfall TP/AP-BAS/OBU/BV/04.

DSRC_SFXX_D003_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake Transaktionen mit zeitlichen Unterbrechungen und Übertragungswiederholungen durch.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul korrekte Kontrollfeldkombinationen benutzt.

DSRC_SFXX_DLAY_0010Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit ist.•Dann führt die Bake eine Initialisierung (BST-VST) mit einer neuen Beacon-ID durch.•Danach sendet die Bake ein ECHO.rq, für das eine Antwort erwartet wird. Dieser ECHO.rq wird mit einer um 0.1 ms wachsenden Pause wiederholt bis eine Pause von 1s erreicht wird.•Wenn die OBU alle ECHO.rq beantwortet hat, ist der Testfall bestanden.Es soll nachgewiesen werden, dass das DUT auch bei unterschiedlich langen Pausen, wie sie bei schwachen Funkbedingungen üblich sind, kommunikationsbereit bleibt. Dieser Test erfolgt als Labortest in Anlehnung an die Testspezifikation ISO/TS 14907-1:2015 Table B7-Traffic Conditions-Shadowing.

DSRC_SFXX_HISX_5010–Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit ist.–Der Benutzer wird aufgefordert den Zustand des DUTs (Go-1) einzustellen (an Stromversorgung angeschlossen, GNSS und Mobilfunk verfügbar, MMI zeigt Betriebsbereitschaft an).–Die Bake führt eine CCC-Transaktion durch. Aus dem Transaktionslog werden die Attribute 53, 61, 99 und 100 zur Auswertung ausgelesen.–Der Benutzer wird aufgefordert für 5 Minuten das DUT in eine abgeschirmte Kammer mit angeschlossener Stromversorgung abzulegen. (Kein GNSS und Mobilfunk verfügbar).–Der Benutzer wird aufgefordert das DUT aus der abgeschirmten Kammer rauszunehmen und 5 Minuten zu warten (bis es GNSS bereit ist).–Die Bake führt eine CCC-Transaktiondurch. Aus dem Transaktionslog werden die Attribute 53, 61, 99 und 100 zur Auswertung ausgelesen. Es wird erwartet, dass der Zustand in Go-1 erreicht ist.Akzeptanzkriterium ist, dass –die zuvor aktuellsten zwei Einträge zwei Positionen weitergerückt sind,–der aktuellste Eintrag einen Zeitstempel hat, der weniger als 6 Minuten alt und der Zustand Go-1 ist.–der zweite aktuellste Eintrag einen Zeitstempel hat, der weniger als 11 Minuten alt und der Zustand noGo-0 ist.–Der Benutzer wird aufgefordert für 5 Minuten die Stromversorgung abzuziehen.–Die Bake führt eine CCC-Transaktiondurch. Aus dem Transaktionslog werden die Attribute 53, 61, 99 und 100 zur Auswertung ausgelesen. Es wird erwartet, dass der Zustand innoGoUserSwitchOff-3 erreicht ist. Akzeptanzkriterium ist, dass–die zuvor aktuellsten drei Einträge einePosition weitergerückt sind.–der aktuellste Eintrag einen Zeitstempel hat, der weniger als 6 Minuten alt und der Zustand noGoUserSwitchOff-3 ist.–Der Benutzer wird aufgefordert die Stromversorgung anzuschließen.–Die Bake führt eine CCC-Transaktiondurch. Aus dem Transaktionslog werden die Attribute 53, 61, 99 und 100 zur Auswertung ausgelesen. Es wird erwartet, dass der Zustand Go-1 erreicht ist.Akzeptanzkriterium ist, dass –die zuvor aktuellsten drei Einträge eine Position weitergerückt sind.–der aktuellste Eintrag einen Zeitstempel hat, der weniger als 6 Minuten alt und der Zustand Go-1 ist.Benutzer Hinweis: Gemäß Bedienungsanleitung des DUTs können Abweichungen zum Erzwingen eines anderen Status-Zustand beschrieben sein.In der Version 2019-11 hat der ISO 12813 u.a. die Attribute 99 (ExtendedOBUStatusHistoryPart1) und 100 (ExtendedOBUStatusHistoryPart2) neu eingeführt. Dieser Testfall soll sicherstellen, dass das DUT gemäß Einzeldokument 4.3.1 Version 3.1 (Stand: 09.06.2022) Kap. 2.2 diese Attribute korrekt setzt.

DSRC_SFXX_HNG1_0010Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit ist.•Dann führt die Bake erneut eine Initialisierung (BST-VST) mit einer neuen Beacon-ID mit dem DUT durch.•Die Bake sendet ein GET_STAMPED.rq mit einer anderen LID für das Attribut 32, das mit einem GET_STAMPED.rq für die Attribute 24, 16, 19, 55, 22, 17, 61, 62 verkettet ist, das DUT darf nicht darauf reagieren.•Die Bake sendet ein GET_STAMPED.rq mit einer anderen LID für die Attribute 32, 60, 50, 52, 49, das DUT darf nicht darauf reagieren.•Die Bake sendet ein RELEASE mit einem anderen LID, das DUT das darf nicht darauf reagieren.•Die Bake sendet ein GET_STAMPED.rq mit der LID für das oben registrierte DUT für das Attribut 32, das mit einem GET_STAMPED.rq für die Attribute 24, 16, 19, 55, 22, 17, 61, 62 verkettet wurde.•Die Bake sendet ein GET_STAMPED.rq mit der LID für das oben registrierte DUT für die Attribute 32, 60, 50, 52, 49.•Die Bake sendet ein RELEASE mit der LID für das oben registrierte DUT.Es soll geprüft werden, dass das DUT auch dann sauber kommuniziert, wenn die Bake nach der Initialisierung weitere Transaktionsphasen mit einer anderen LID durchführt (Was vom DUT nicht beantworten werden darf). Dieser Test erfolgt als Labortest in Anlehnung an die Testspezifikation ISO/TS 14907-1:2015 Table B1-B3-Traffic Conditions-lateral and longitudinal distance between OBUs.

DSRC_SFXX_HNG2_0010Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit ist.•Dann führt die Bake erneut eine Initialisierung (BST-VST) mit einer neuen Beacon-ID mit dem DUT durch.•Die Bake wartet für die Dauer von zwei Datenaustauschphasen einer CCC-Transaktion (20 ms)•Die Bake sendet ein RELEASE mit einer anderen LID, das DUT darf nicht darauf reagieren.•Die Bake sendet ein GET_STAMPED.rq mit der LID für das oben registrierte DUT für das Attribut 32, welches mit einem GET_STAMPED.rq für die Attribute 24, 16, 19, 55, 22, 17, 61, 62 verkettet wurde.•Die Bake sendet ein GET_STAMPED.rq mit der LID für das oben registrierte DUT für die Attribute 32, 60, 50, 52, 49.•Die Bake sendet ein RELEASE mit der LID für das oben registrierte DUT.Es soll nachgewiesen werden, dass das DUT auch dann sauber kommuniziert, wenn die Bake die Kommunikation nach der Initialisierung unterbricht und später wieder aufnimmt. Dieser Test erfolgt als Labortest in Anlehnung an die Testspezifikation ISO/TS 14907-1:2015 Table B7-Traffic Conditions-Shadowing.

DSRC_SFXX_HNG3_0010Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob die OBU/DSRC-Modul kommunikationsbereit ist.•Dann führt die Bake erneut eine Initialisierung (BST-VST) mit einer neuen Beacon-ID mit der OBU/DSRC Modul durch.•Die Bake wartet für die Dauer einer gesamten CCC-Transaktion (30 ms). Anschliessend führt die Bake erneut eine neue Initialisierung (BST-VST) mit einer neuen Beacon-ID mit dem DUT durch.•Die Bake sendet ein GET_STAMPED.rq mit der LID für das oben registrierte DUT für das Attribut 32, welche mit einem GET_STAMPED.rq für die Attribute 24, 16, 19, 55, 22, 17, 61, 62 verkettet wurde.•Die Bake sendet ein GET_STAMPED.rq mit der LID für das oben registrierte DUT für die Attribute 32, 60, 50, 52, 49.•Die Bake sendet ein RELEASE mit der LID für das oben registrierte DUT.Es soll geprüft werden, dass das DUT auch dann sauber kommuniziert, wenn die Bake nach der Initialisierung die Kommunikation unterbricht und wieder neu initialisiert. Mit diesem Testfall soll in einem Labortest die BALM-Anforderung für die Mobile Kontrolle nach Einzeldokument 4.3.1 Version 3.1 (Stand:09.06.2022) überprüft werden, mit der nach einer fehlgeschlagenen Transaktion die CCC-Transaktion mit einer neuen Beacon-ID neu aufgesetzt werden kann.

DSRC_SFXX_HNG4_0010Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit ist. Dann führt die Bake erneut eine Initialisierung (BST-VST) mit einer neuen Beacon-ID mit dem DUT durch.•Die Bake sendet während der gesamten Dauer (30 ms) einer CCC-Transaktion Zufallsdaten (Fehlerhafte DSRC-Rahmen).•Anschliessend führt die Bake erneut eine neue Initialisierung (BST-VST) mit einer neuen Beacon-ID mit dem DUT durch.•Die Bake sendet ein GET_STAMPED.rq mit der LID für die oben registrierte OBU/das DSRC Modul für das Attribut 32, die mit einem GET_STAMPED.rq für die Attribute 24, 16, 19, 55, 22, 17, 61, 62 verkettet wurde.•Die Bake sendet ein GET_STAMPED.rq mit der LID für das oben registrierte DUT für die Attribute 32, 60, 50, 52, 49.•Die Bake sendet ein RELEASE mit der LID für das oben registrierte DUT.Es soll geprüft werden, dass das DUT auch dann sauber kommuniziert, wenn die Bake nach der Initialisierung fehlerhafte Frames versendet und dann eine neue Transaktion durchführt. Mit diesem Testfall soll in einem Labortest geprüft werden, dass die BALM-Anforderung für die Mobile Kontrolle nach Einzeldokument 4.3.1 Version 3.1 (Stand:09.06.2022), mit der nach einer fehlgeschlagenen Transaktion die CCC-Transaktion mit einer neuen Beacon-ID neu aufgesetzt werden kann, mit dem DUT erfüllt werden kann.

DSRC_SFXX_LID_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird nach einer regulären Initialisierungsphase das erste GET der CCC-Transaktion gesendet, das ordnungsgemäß beantwortet werden soll. Dann wird der GET-Befehl mit zwei verschiedenen, verfälschten LIDs wiederholt, die beide nicht beantwortet werden sollen. Dann sendet die Bake jeweils ein RELEASE an zwei verfälschte LIDs. Anschließend sendet die Bake den zweiten GET-Befehl der Transaktion an die OBU, der beantwortet werden soll. Dann sendet die Bake den gleichen GET-Befehl an zwei verfälschte LIDs, wobei die OBU nicht antworten soll.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul die LID korrekt handhabt.

DSRC_SFXX_MV02_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird die OBU initialisiert. Anschließend werden jeweils zwei ECHO.rq so gesendet, dass ein bestimmter Zeitabstand zwischen dem Ende des ersten ECHO.rs und dem Anfang des zweiten ECHO.rq liegt. Dieser Zeitabstand wird schrittweise auf dem minimalen erlaubten Abstand (T1) reduziert.Es soll nachgewiesen werden, dass die OBU/das DSRC-Modul auf Befehle der Bake reagiert, die mit der kleinsten erlaubten Verzögerung von T1 zwischen Ende der Antwort auf den vorigen Befehl und Anfang des neuen Befehls gesendet werden.

DSRC_SFXX_SETA_5010Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit ist. Die nächsten Schritte werden für alle Einstellmöglichkeiten der Achszahl wiederholt. Der Tester stellt im DUT die Achszahl (initial auf den kleinstmöglichen Wert) ein und bestätigt die Einstellung. Der Tester gibt die am DUT eingestellte Achszahl am Testplatz ein. Die Bake führt eine CCC:2019(SST301 v3.1)-Transaktion (incl. Auslesung des Attributs 19) durch. Die Transaktionsdaten werden darauf untersucht, ob die über DSRC ausgelesene Achszahl dem eingegebenen Wert entspricht.Es soll nachgewiesen werden, dass vom Nutzer alle Einstellmöglichkeiten der Achszahl korrekt im entsprechenden Attribut 19 gespeichert und bei einer CCC:2019(SST301 v3.1)-Transaktion an die Bake übertragen werden.

DSRC_SFXX_SETG_5010–Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit ist.–Der Tester stellt in dem DUT (je nach Typ des DUTs) das Gewicht oder die Gewichtsklasse auf den kleinstmöglichen Wert ein und bestätigt die Einstellung.–Die nächsten Schritte werden so wiederholt, dass nach Möglichkeit die Gewichte unterhalb und oberhalb der Gewichtsklassegrenzen eingestellt werden.–Der Tester stellt im DUT das Gewicht bzw. die Gewichtsklasse (initial auf den kleinstmöglichen Wert) ein und bestätigt die Einstellung.–Der Tester gibt das am DUT eingestellte Gewicht am Testplatz ein.–Die Bake führt eine CCC:2019(SST301v3.1)-Transaktion (incl. Auslesung des Attributs 55) durch.–Die Transaktionsdaten werden darauf untersucht, ob das über DSRC ausgelesene Gewicht dem eingegebenen Wert entspricht.Es soll nachgewiesen werden, dass das vom Nutzer eingestellte Gewicht korrekt im entsprechenden Attribut (55) gespeichert und bei einer CCC:2019(SST301 v3.1)-Transaktion an die Bake übertragen wird. Mit diesem Testfall wird überprüft, in welchem Einstellbereich die Gewichtseinstellung des DUTs veränderbar ist.

DSRC_SFXX_STPW_5010Zunächst wird die Sendeleistung der Bake auf den gewünschten Wert eingestellt und testweise eine Transaktion ausgelöst. Falls keine Kommunikation mit der OBU erfolgt, wird der Testlauf abgebrochen. Dann werden bei laufend wechselnder Beacon-ID im Dauertest CCC:2019(SST301 v3.1)-Transaktionen durchgeführt. Nach Ablauf der Testdauer wird die Bake angehalten und das Log auf die zeitliche Lage der public windows requests untersucht. Für eine tiefergehende Analyse wird aus den Sendezeitpunkten zusätzlich ein PDF und ein CSV erzeugt.Es soll nachgewiesen werden, dass eine OBU/ein DSRC-Modul alle drei public Anmeldefenster gleichmäßig nutzt. Darüberhinaus werden Statistiken zur zeitlichen Lage der private windows requests erhoben.

DSRC_SFXX_STPW_5015Zunächst wird die Sendeleistung der Bake auf den gewünschten Wert eingestellt und testweise eine Transaktion ausgelöst. Falls keine Kommunikation mit der OBU erfolgt, wird der Testlauf abgebrochen. Dann werden bei laufend wechselnder Beacon-ID im Dauertest CCC:2019(SST301 v3.1)-Transaktionen durchgeführt. Nach Ablauf der Testdauer wird die Bake angehalten und das Log auf die zeitliche Lage der private windows requests untersucht. Für eine tiefergehende Analyse wird aus den Sendezeitpunkten zusätzlich ein PDF und ein CSV erzeugt.Es soll nachgewiesen werden, dass die OBU/das DSRC-Modul das erlaubte Zeitfenster für Übertragungen in private uplink windows einhält. Darüberhinaus werden Statistiken zur zeitlichen Lage der Übertragungen erhoben.

DSRC_SFXX_STPW_5020Zunächst wird die Sendeleistung der Bake auf den gewünschten Wert eingestellt und testweise eine Transaktion ausgelöst. Falls keine Kommunikation mit den OBUs erfolgt, wird der Testlauf abgebrochen. Dann werden bei laufend wechselnder Beacon-ID im Dauertest CCC:2019(SST301 v3.1)-Transaktionen durchgeführt. Nach Ablauf der Testdauer wird die Bake angehalten und das Log auf die zeitliche Lage der private windows requests untersucht. Für eine tiefergehende Analyse wird aus den Sendezeitpunkten zusätzlich ein PDF und ein CSV erzeugt.Es soll nachgewiesen werden, dass mehrere DUT des gleichen Herstellers jeweils alle drei public Anmeldefenster gleichmäßig nutzt. Darüberhinaus werden Statistiken zur zeitlichen Lage der private windows requests erhoben.

DSRC_SFXX_STPW_5030–Eine Initialisierung (BST-VST) mit einerneuen Beacon-ID wird durchgeführt, um festzustellen, ob alle OBUs/DSRC-Module (DUT und drei weitere DSRC-Module) kommunikationsbereit sind.–Die Bake wird für einen Dauertest konfiguriert, der über eine Zeit von 5 Stunden mit folgenden Einstellungen durchgeführt wird: 1.Beacon Change Intervall 15s2.CCC:2019(SST301 v3.1)-Transaktionen für Max 15s3.Nach der Transaktion wird die Bake für 15s angehalten (Simulation des Verlassens der Kommunikationszone)–Nach Ablauf der Testdauer wird das Bakelog auf die zeitliche Lage der public windows requests untersucht. Darüberhinaus werden Statistiken zur zeitlichen Lage der public windows requests erhoben(PublicWindows Zeit-Überlappung und -Verletzungen).Es soll nachgewiesen werden, dass das DUT im Zusammenspiel mit drei weiteren OBUs (Module verschiedener Typen und Hersteller) alle drei public Anmeldefenster gleichmäßig nutzt und die Module sich nicht gegenseitig stören. (Erfahrungsgemäß halten nicht alle Lieferanten von DSRC Modulen die in der Norm vorgegebenen Zeiteinheiten für die Public Windows ein).

DSRC_SFXX_STTD_5010Zunächst wird testweise eine Transaktion ausgelöst. Falls keine Kommunikation mit der OBU erfolgt, wird der Testlauf abgebrochen. Dann werden bei laufend wechselnder Beacon-ID im Dauertest CCC:2019(SST301 v3.1)-Transaktionen durchgeführt. Nach Ablauf der Testdauer wird die Bake angehalten und aus dem Log die Verteilung der Transaktionsdauern ermittelt.Es soll nachgewiesen werden, dass die OBU/das DSRC-Modul Transaktionen innerhalb der vorgesehenen Dauer durchführen kann. Gemäß Kap. 4.2.1 der Gebietsvorgaben (Einzeldokument 4.3.1 Version 3.1 (Stand: 09.06.2022)) wird gefordert, dass eine ungestörte Transaktion in einer maximalen Transaktionszeit von 70 ms erfolgen soll.

DSRC_SFXX_STTD_5020Zunächst wird der Sende Pegel der Bake auf einem mittleren Wert eingestellt (zum Beispiel 30 dbm). Dann werden bei laufend wechselnder Beacon-ID im Dauertest CCC:2019(SST301 v3.1)-Transaktionen durchgeführt. Nach Ablauf der Testdauer wird die Bake angehalten und aus dem Log die Verteilung der Transaktionsdauern ermittelt.Es soll nachgewiesen werden, dass die OBU/das DSRC-Modul auch bei mäßigen Kommunikationsbedingungen Transaktionen innerhalb der vorgesehenen Dauer durchführen kann. Gemäß Kap. 4.3.1 der Gebietsvorgaben (Einzeldokument 4.3.1 Version 3.1 (Stand: 09.06.2022)) wird gefordert, dass eine ungestörte Transaktion in einer maximalen Transaktionszeit von 70 ms erfolgen soll.

DSRC_SFXX_STTD_5030Zunächst wird der Sende Pegel der Bake auf einem niedrigen Wert eingestellt (zum Beispiel 27 dbm). Dann werden bei laufend wechselnder Beacon-ID im Dauertest CCC:2019(SST301 v3.1) -Transaktionen durchgeführt. Nach Ablauf der Testdauer wird die Bake angehalten und aus dem Log die Verteilung der Transaktionsdauern ermittelt.Es soll nachgewiesen werden, dass die OBU/das DSRC-Modul auch bei schwachen Kommunikationsbedingungen Transaktionen innerhalb der vorgesehenen Dauer durchführen kann. Gemäß Kap. 4.3.1 der Gebietsvorgaben (Einzeldokument 4.3.1 Version 3.1 (Stand: 09.06.2022)) wird gefordert, dass eine ungestörte Transaktion in einer maximalen Transaktionszeit von 70 ms erfolgen soll.

DSRC_SFXX_STTD_5040–Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob alle OBUs/DSRC-Module kommunikationsbereit sind.–Die Bake wird für einen Dauertest konfiguriert, der über einen Zeitraum von 5 Stunden mit folgenden Einstellungen durchgeführt wird: 1.Beacon Change Intervall 15s2.CCC:2019(SST301 v3.1)-Transaktionen für Max 15s3.Nach der Transaktion wird die Bake für 15s angehalten (Simulation des Verlassens der Kommunikationszone)–Nach Ablauf der Testdauer wird aus den Bake-Logs die Verteilung pro OBU/DSRC Modul Transaktionszeiten ermittelt.Es soll nachgewiesen werden, dass das DUT Transaktionen innerhalb der vorgesehenen Transaktionzeiten (<70 ms) mit der DSRC Bake durchführen kann, wenn mehrere DSRC-Module (max 3 weitere Module verschiedener Typen und Hersteller) gleichzeitig kommunizieren. Dieser Test erfolgt als Labortest in Anlehnung an die Testspezifikation ETSI TS 102 486-1-2 TP/MAC/OBU/BV/01 und in Anlehnung an die Testspezifikation ISO/TS 14907-1:2015 Table B3-Traffic Conditions-Lateral distance between OBEs unter Berücksichtigung der Allgemeinen Vorgaben nach Einzeldokument 4.3.1 Version 3.1 (Stand: 09.06.2022).

DSRC_SFXX_TRPT_5040–Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit ist.–Die Bake wird für einen Dauertest konfiguriert, der über einen Zeitraum von 5 Stunden mit folgenden Einstellungen durchgeführt wird: 1.Beacon Change Intervall 15s2.CCC:2019(SST301 v3.1)-Transaktionen für Max 15s3.Nach der Transaktion wird die Bake für 15s angehalten (Simulation des Verlassens der Kommunikationszone)–Nach Ablauf der Testdauer wird aus dem Backlog die Anzahl der durchgeführten Transaktionen mit den zu erwartenden Transaktionen verglichen.Es soll nachgewiesen werden, dass in einem Dauerlauf das DUT alle CCC:2019(SST301 v3.1)-Transaktionen erfolgreich durchführt. In Anlehnung an die Bitfehlerraten-Tests der EN300674-2-2 wird in diesem Labortest die Übertragungssicherheit im stabilen Laboraufbau überprüft.

DSRC_SFXX_UCON_5010Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit ist.–Ein Fehler wird provoziert (zum Beispiel kein GNSS Empfang).–Der Benutzer wird aufgefordert die Fehlermeldung zu bestätigen.–Die Bake führt eine CCC-Transaktion durch. Aus dem Transaktionslog wird der Zeitstempel der UserConfirmation ausgelesen, der den Zeitpunkt der Bestätigung entspricht.In der Version 2019-11 hat der ISO 12813 u.a. das Attribut 101 (UserConfirmation) neu eingeführt. Dieser Testfall soll sicherstellen, dass das DUT dieses Attribut korrekt setzt.

DSRC_SFXX_WKUP_0010–Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob die OBU/DSRC-Module kommunikationsbereit sind.–Die Bake pausiert für 10 Sekunden.–Dann sendet die Bake BSTs, bis sie ein private window request empfängt. Die Dauer ab der ersten BST bis zum private window request wird gemessen.Es soll sichergestellt werden, dass die Wakeup-Dauer des DUTs unter 20 ms liegt.

DSRC_SFXX_FUL1_5010Das Dämpfungsglied wird für den gewünschten Pegelverlauf eingestellt, die Bake führt eine CCC:2019(SST301 v3.1)-Transaktion durch und das Log wird auf korrekte LID, Kontrollfelder und Vollständigkeit der Transaktion überprüft. Der Testfall wird als Dauertest über einen einstellbaren Zeitraum wiederholt. Abschließend wird die Transaktionserfolgsrate ausgegeben, wobei für jeden Initialisierungsversuch der Bake mindestens ein private request der Bake erwartet wird.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul unter Funkbedingungen [FootPrint (KonSL)], die dem Wirkbetrieb möglichst nahe kommen, ordnungsgemäß Transaktionen durchführen kann. Hinweis: FootPrint (KonSL): DSRC_SFXX_FUL1_5010-KonSL-LKW-3.5mSeitl-plusLöcher.txt Der Pegelverlauf basiert auf der Messung einer LKW-Passage an einer KonSL, wobei die Messdaten durch manuell eingefügte Pegeleinbrüche künstlich verschlechtert werden.

DSRC_SFXX_FUL2_5010Das Dämpfungsglied wird für den gewünschten Pegelverlauf eingestellt, die Bake führt eine CCC:2019(SST301 v3.1)-Transaktion durch und das Log wird auf korrekte LID, Kontrollfelder und Vollständigkeit der Transaktion überprüft. Der Testfall wird als Dauertest über einen einstellbaren Zeitraum wiederholt. Abschließend wird die Transaktionserfolgsrate ausgegeben, wobei für jeden Initialisierungsversuch der Bake mindestens ein private request der Bake erwartet wird.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul unter Funkbedingungen [Footprint (KonMA)], die dem Wirkbetrieb möglichst nahekommen, ordnungsgemäß Transaktionen durchführen kann. Hinweis: Footprint (KonMA): DSRC_SFXX_FUL2_5010-KonMa1-plusLöcher.txt Der Pegelverlauf basiert auf der Messung einer KonMA-Passage an einem LKW, wobei die Messdaten durch manuell eingefügte Pegeleinbrüche künstlich verschlechtert werden.

SRC_SFXX_FUL3_5010Das Dämpfungsglied wird für den gewünschten Pegelverlauf eingestellt, die Bake führt eine CCC:2019(SST301 v3.1)-Transaktion durch und das Log wird auf korrekte LID, Kontrollfelder und Vollständigkeit der Transaktion überprüft. Der Testfall wird als Dauertest über einen einstellbaren Zeitraum wiederholt. Abschließend wird die Transaktionserfolgsrate ausgegeben, wobei für jeden Initialisierungsversuch der Bake mindestens ein private request der Bake erwartet wird.Es soll sichergestellt werden, dass die OBU/das DSRC-Modul unter Funkbedingungen [Footprint (Sägezahn)], die dem Wirkbetrieb möglichst nahekommen, ordnungsgemäß Transaktionen durchführen kann. Hinweis: Footprint (Sägezahn): DSRC_SFXX_FUL3_5010-Saegezahn.txt Der Pegel wird jeweils um 2,8dB besser und verschlechtert sich dann wieder langsam um 1,8 dB. Das wird so lange wiederholt, bis ein ungedämpfter Kanal erreicht ist.

DSRC_SFXX_2BKN_5010Zunächst wird testweise eine Transaktion separat mit jeder der beteiligten Baken ausgelöst. Falls keine Kommunikation mit der OBU erfolgt, wird der Testlauf abgebrochen. Dann werden bei gleichbleibender Beacon-ID an beiden Baken im Parallelbetrieb CCC:2019 (SST301 v3.1)-Transaktionen durchgeführt. Es wird erwartet, dass das DSRC Modul beim Empfang einer BST die laufende Transaktion unterbricht und zur anderen RSU wechselt, und dass das Modul nach dem Ablauf der2. Bake-Testphase noch Transaktionen mit einer einzelnen Bake durchführen kann. Nach Ablauf der Testdauer wird ermittelt, ob die OBUs die Bakenbefehle immer mit der korrekten LID und gemäß des Protokollablaufs beantwortet haben.Es soll nachgewiesen werden, dass das DSRC-Modul sich in einer worst case-Situation, die aber bei einer Vorbeifahrt einer KonMA unter der KonAU auftritt, korrekt verhält.

DSRC_SFXX_CO2C_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird mit der Bake eine CCC-2019-Transaktion durchgeführt. Abschließend wird das Bakenlog ausgelesen und überprüft, ob die genannten Bits des Teilattributs VehicleSpecificCharacteristics.FutureCharacteristics korrekt gesetzt sind. Erwartetes Ergebnis: Die Bit-Struktur im Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics ist korrekt gesetzt: SS = 01'B OOO = 000'BDas Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics hat die Bit-Struktur FSSOOOPP und muss für die Bit-Struktur SSOOO wie folgt belegt werden mit: SS – cO2Scheme, muss mit 01'B belegt werden, um die CO2-Schemadefinition gemäß EU-Verordnung 2022/362 Artikel 1 (11), der Artikel 7ga in Richtlinie 1999/62 einfügt, zu referenzieren. OOO – cO2Class, muss mit 000'B belegt werden, wenn keine CO2-Emissionsklasse zugeordnet werden kann, ansonsten mit den Werten 001'B, 010'B, 011'B, 100'B, 101'B für die CO2-Emissionsklassen 1 bis 5.

DSRC_SFXX_CO2C_0011Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird mit der Bake eine CCC-2019-Transaktion durchgeführt. Abschließend wird das Bakenlog ausgelesen und überprüft, ob die genannten Bits des Teilattributs VehicleSpecificCharacteristics.FutureCharacteristics korrekt gesetzt sind. Erwartetes Ergebnis: Die Bit-Struktur im Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics ist korrekt gesetzt: SS = 01'B OOO = 001'BDas Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics hat die Bit-Struktur FSSOOOPP und muss für die Bit-Struktur SSOOO wie folgt belegt werden mit: SS – cO2Scheme, muss mit 01'B belegt werden, um die CO2-Schemadefinition gemäß EU-Verordnung 2022/362 Artikel 1 (11), der Artikel 7ga in Richtlinie 1999/62 einfügt, zu referenzieren. OOO – cO2Class, muss mit 000'B belegt werden, wenn keine CO2-Emissionsklasse zugeordnet werden kann, ansonsten mit den Werten 001'B, 010'B, 011'B, 100'B, 101'B für die CO2-Emissionsklassen 1 bis 5.

DSRC_SFXX_CO2C_0012Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird mit der Bake eine CCC-2019-Transaktion durchgeführt. Abschließend wird das Bakenlog ausgelesen und überprüft, ob die genannten Bits des Teilattributs VehicleSpecificCharacteristics.FutureCharacteristics korrekt gesetzt sind. Erwartetes Ergebnis: Die Bit-Struktur im Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics ist korrekt gesetzt: SS = 01'B OOO = 010'BDas Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics hat die Bit-Struktur FSSOOOPP und muss für die Bit-Struktur SSOOO wie folgt belegt werden mit: SS – cO2Scheme, muss mit 01'B belegt werden, um die CO2-Schemadefinition gemäß EU-Verordnung 2022/362 Artikel 1 (11), der Artikel 7ga in Richtlinie 1999/62 einfügt, zu referenzieren. OOO – cO2Class, muss mit 000'B belegt werden, wenn keineCO2-Emissionsklasse zugeordnet werden kann, ansonsten mit den Werten 001'B, 010'B, 011'B, 100'B, 101'B für die CO2-Emissionsklassen 1 bis 5.

DSRC_SFXX_CO2C_0013Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird mit der Bake eine CCC-2019-Transaktion durchgeführt. Abschließend wird das Bakenlog ausgelesen und überprüft, ob die genannten Bits des Teilattributs VehicleSpecificCharacteristics.FutureCharacteristics korrekt gesetzt sind. Erwartetes Ergebnis: Die Bit-Struktur im Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics ist korrekt gesetzt: SS = 01'B OOO = 011'BDas Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics hat die Bit-Struktur FSSOOOPP und muss für die Bit-Struktur SSOOO wie folgt belegt werden mit: SS – cO2Scheme, muss mit 01'B belegt werden, um die CO2-Schemadefinition gemäß EU-Verordnung 2022/362 Artikel 1 (11), der Artikel 7ga in Richtlinie 1999/62 einfügt, zu referenzieren. OOO – cO2Class, muss mit 000'B belegt werden, wenn keine CO2-Emissionsklasse zugeordnet werden kann, ansonsten mit den Werten 001'B, 010'B, 011'B, 100'B, 101'B für die CO2-Emissionsklassen 1 bis 5.

DSRC_SFXX_CO2C_0014Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird mit der Bake eine CCC-2019-Transaktion durchgeführt. Abschließend wird das Bakenlog ausgelesen und überprüft, ob die genannten Bits des Teilattributs VehicleSpecificCharacteristics.FutureCharacteristics korrekt gesetzt sind. Erwartetes Ergebnis: Die Bit-Struktur im Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics ist korrekt gesetzt: SS = 01'B OOO = 100'BDas Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics hat die Bit-Struktur FSSOOOPP und muss für die Bit-Struktur SSOOO wie folgt belegt werden mit: SS – cO2Scheme, muss mit 01'B belegt werden, um die CO2-Schemadefinition gemäß EU-Verordnung 2022/362 Artikel 1 (11), der Artikel 7ga in Richtlinie 1999/62 einfügt, zu referenzieren. OOO – cO2Class, muss mit 000'B belegt werden, wenn keine CO2-Emissionsklasse zugeordnet werden kann, ansonsten mit den Werten 001'B, 010'B, 011'B, 100'B, 101'B für die CO2-Emissionsklassen 1 bis 5.

DSRC_SFXX_CO2C_0015Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird mit der Bake eine CCC-2019-Transaktion durchgeführt. Abschließend wird das Bakenlog ausgelesen und überprüft, ob die genannten Bits des Teilattributs VehicleSpecificCharacteristics.FutureCharacteristics korrekt gesetzt sind. Erwartetes Ergebnis: Die Bit-Struktur im Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics ist korrekt gesetzt: SS = 01'B OOO = 101'BDas Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics hat die Bit-Struktur FSSOOOPP und muss für die Bit-Struktur SSOOO wie folgt belegt werden mit: SS – cO2Scheme, muss mit 01'B belegt werden, um die CO2-Schemadefinition gemäß EU-Verordnung 2022/362 Artikel 1 (11), der Artikel 7ga in Richtlinie 1999/62 einfügt, zu referenzieren. OOO – cO2Class, muss mit 000'B belegt werden, wenn keine CO2-Emissionsklasse zugeordnet werden kann, ansonsten mit den Werten 001'B, 010'B, 011'B, 100'B, 101'B für die CO2-Emissionsklassen 1 bis 5.

DSRC_SFXX_CO2S_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird mit der Bake eine CCC-2019-Transaktion durchgeführt. Abschließend wird das Bakenlog ausgelesen und überprüft, ob die genannten Bits des Teilattributs VehicleSpecificCharacteristics.FutureCharacteristics korrekt gesetzt sind. Erwartetes Ergebnis: Die Bits im Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics sind korrekt gesetzt: PP = 00'BOptionaler Testfall: Das Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics hat die Bit-Struktur FSSOOOPP und die Teilstruktur PP kann wie folgt belegt werden mit: –PP – suspensionType – Die Komponente sollte korrekt nach folgenden Vorgaben belegt werden, wird durch den Mauterheber jedoch derzeit nicht ausgewertet:–00'B – means information is not available,–01'B – means the vehicle uses air suspensions,–10'B – means the vehicle uses hydraulic suspensions,–11'B – means the vehicle uses electric suspensions.Dieser Testfall soll nachweisen, dass die Komponente PP nach geeigneter Personalisierung des DUT den Wert 00'B hat.

DSRC_SFXX_CO2S_0011Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird mit der Bake eine CCC-2019-Transaktion durchgeführt. Abschließend wird das Bakenlog ausgelesen und überprüft, ob die genannten Bits des Teilattributs VehicleSpecificCharacteristics.FutureCharacteristics korrekt gesetzt sind. Erwartetes Ergebnis: Die Bits im Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics sind korrekt gesetzt: PP = 01'BOptionaler Testfall: Das Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics hat die Bit-Struktur FSSOOOPP und die Teilstruktur PP kann wie folgt belegt werden mit: –PP – suspensionType – Die Komponente sollte korrekt nach folgenden Vorgaben belegt werden, wird durch den Mauterheber jedoch derzeit nicht ausgewertet:–00'B – means information is not available;–01'B – means the vehicle uses air suspensions–10'B – means the vehicle uses hydraulic suspensions–11'B – means the vehicle uses electric suspensions.Dieser Testfall soll nachweisen, dass die Komponente PP nach geeigneter Personalisierung des DUT den Wert 01'B hat.

DSRC_SFXX_CO2S_0012Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird mit der Bake eine CCC-2019-Transaktion durchgeführt. Abschließend wird das Bakenlog ausgelesen und überprüft, ob die genannten Bits des Teilattributs VehicleSpecificCharacteristics.FutureCharacteristics korrekt gesetzt sind. Erwartetes Ergebnis: Die Bits im Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics sind korrekt gesetzt: PP = 10'BOptionaler Testfall: Das Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics hat die Bit-Struktur FSSOOOPP und die Teilstruktur PP kann wie folgt belegt werden mit: –PP – suspensionType – Die Komponente sollte korrekt nach folgenden Vorgaben belegt werden, wird durch den Mauterheber jedoch derzeit nicht ausgewertet:–00'B – means information is not available;–01'B – means the vehicle uses air suspensions–10'B – means the vehicle uses hydraulic suspensions–11'B – means the vehicle uses electric suspensions.Dieser Testfall soll nachweisen, dass die Komponente PP nach geeigneter Personalisierung des DUT den Wert 10'B hat.

DSRC_SFXX_CO2S_0013Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird mit der Bake eine CCC-2019-Transaktion durchgeführt. Abschließend wird das Bakenlog ausgelesen und überprüft, ob die genannten Bits des Teilattributs VehicleSpecificCharacteristics.FutureCharacteristics korrekt gesetzt sind. Erwartetes Ergebnis: Die Bits im Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics sind korrekt gesetzt: PP = 11'BOptionaler Testfall: Das Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics hat die Bit-Struktur FSSOOOPP und die Teilstruktur PP kann wie folgt belegt werden mit: –PP – suspensionType – Die Komponente sollte korrekt nach folgenden Vorgaben belegt werden, wird durch den Mauterheber jedoch derzeit nicht ausgewertet:–00'B – means information is not available;–01'B – means the vehicle uses air suspensions–10'B – means the vehicle uses hydraulic suspensions–11'B – means the vehicle uses electric suspensions.Dieser Testfall soll nachweisen, dass die Komponente PP nach geeigneter Personalisierung des DUT den Wert 11'B hat.

DSRC_SFXX_FXXX_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird mit der Bake eine CCC-2019-Transaktion durchgeführt. Abschließend wird das Bakenlog ausgelesen und überprüft, ob die genannten Bits des Teilattributs VehicleSpecificCharacteristics.FutureCharacteristics korrekt gesetzt sind. Erwartetes Ergebnis: Die Bits im Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics sind korrekt gesetzt: –F = 0'B oder 1'BOptionaler Testfall: Das Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics hat die Bit-Struktur FSSOOOPP und kann wie folgt belegt werden mit: –F – futureElement, kann mit 0'B oder 1'B belegt werdenDer Testfall soll nachweisen, dass die Komponente F korrekt belegt ist, sofern der EETS-Anbieter die Belegung dieses Datenelements unterstützt.

DSRC_SFXX_TSPS_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird mit der Bake eine CCC-2019-Transaktion durchgeführt. Danach wird das Bakenlog ausgelesen und die tspStatus-Werte extrahiert. Abschließend wird überprüft, ob die tspStatus-Werte und ihre Bedeutung inhaltlich zum jeweiligen Statuswechsel passen. Erwartetes Ergebnis: Alle gefundenen tspStatus haben in Bezug auf den jeweiligen Statuswechsel einen plausiblen Wert gemäß EETS-Anbieterspezifikation.Optionaler Testfall: Die Attribute UserConfirmation, ExtendedOBUStatusHistoryPart1 und ExtendedOBUStatusHistoryPart2 haben jeweils tspStatus-Teilattribute, die bei Statuswechsel einen EETS-Anbieterspezifischen Statuscode enthalten können. Die Bedeutung der tspStatus-Werte kann von jedem EETS-Anbieter frei festgelegt werden und laut Gebietsvorgaben kann der Mauterheber den Mautdienstanbieter ersuchen, die Bedeutung einer speziellen Belegung des Datenelements zu erläutern. Der Testfall soll den tspStatus-Wert auslesen und dieser soll in Bezug auf den durchgeführten Statuswechsel einen plausiblen Grund gemäß EETS-Anbieterspezifikation aufzeigen.

DSRC_SFXX_VSDE_0000Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird mit der Bake eine CCC-2019-Transaktion durchgeführt das Bakenlog ausgelesen und überprüft, ob der Wert des Teilattributs VehicleSpecificCharacteristics.descriptiveCharacteristics den vorgegebenen Wert hat. Erwartetes Ergebnis: Das Teilattribut VehicleSpecificCharacteristics.descriptiveCharacteristics hat jeweils den vorgegebenen Wert. Optional: Falls ein Dienstanbieter das Teilattribut fachlich nutzt, so wird eine manuelle Prüfung auf korrekte Belegung durchgeführt und dies im Testreport dokumentiert.Optionaler Testfall: Das Teilattribut VehicleSpecificCharacteristics.descriptiveCharacteristics kann optional durch den Dienstanbieter belegt werden. Dieser Testfall soll nachweisen, dass die Komponente descriptiveCharacteristics nach geeigneter Personalisierung des DUT den Wert 0 hat. Dieser Testfall soll prüfen, ob der Parameter descriptiveCharacteristics dem in der Konfigurationsmatrix der OBU vorgegebenen Wert entspricht.

DSRC_SFXX_VSEE_0000Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Für die Werte 0 (Minimalwert), 2 (Zwischenwert), 7 (Maximalwert) und 15 (Zusatzwert) wird jeweils –der Tester aufgefordert, eine geeignete personalisierte OBU vor der Testbake zu positionieren–mit der Bake eine CCC-2019-Transaktion durchgeführt–das Bakenlog ausgelesen und überprüft, ob der Wert des Teilattributs VehicleSpecificCharacteristics.environmentalCharacteristics.euroValue den vorgegebenen Wert hat.Erwartetes Ergebnis: Das Teilattribut VehicleSpecificCharacteristics.environmentalCharacteristics.euroValue hat jeweils den vorgegebenen Wert.Das Teilattribut VehicleSpecificCharacteristics.environmentalCharacteristics.euroValue kann mit Werten von 0 bis 7 einschließlich, sowie 15 belegt werden. Dieser Testfall soll exemplarisch anhand einiger Werte nachweisen, dass die OBU den gültigen Wertebereich unterstützt.

DSRC_SFXX_VSEN_0000Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Für die Werte 0 (Minimalwert), 28 (Zwischenwert), 52 (Maximalwert) und 255 (Zusatzwert) wird jeweils –der Tester aufgefordert, eine geeignete personalisierte OBU vor der Testbake zu positionieren–mit der Bake eine CCC-2019-Transaktion durchgeführt–das Bakenlog ausgelesen und überprüft, ob der Wert des Teilattributs VehicleSpecificCharacteristics.engineCharacteristics den vorgegebenen Wert hat.Erwartetes Ergebnis: Das Teilattribut VehicleSpecificCharacteristics.engineCharacteristics hat jeweils den vorgegebenen Wert.Optionaler Testfall: Das Teilattribut VehicleSpecificCharacteristics.engineCharacteristics kann durch den Dienstanbieter optional mit Werten von 0 bis einschließlich 52 und 255 belegt werden. Dieser Testfall soll exemplarisch anhand einiger Werte nachweisen, dass die OBU den gültigen Wertebereich unterstützt.

DSRC_SFXX_GNSS_0000Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird mit der Bake eine CCC-2019-Transaktion durchgeführt. Abschließend wird das Bakenlog ausgelesen und überprüft, ob das Attribut korrekt geparst werden kann, ob die GPS-Position der tatsächlichen OBU-Position entspricht und die letzte Aktualisierung höchstens 60 Sekunden vor der Transaktion erfolgt ist. Erwartetes Ergebnis: Das Attribut hat die richtige Länge und kann geparst werden, die GPS-Position laut Attribut entspricht den GPS-Koordinaten des Testlabors und die letzte Aktualisierung liegt höchstens 60 Sekunden zurück.Die Attributdefinition hat sich in den letzten Versionen der Norm (ISO FDIS 12813) mehrfach geändert. Es ist möglich, dass es dadurch bei der Implementierung des Attributs bei den OBU-Lieferanten zu Fehlern gekommen ist. Die gültige Version basiert auf ISO FDIS 12813:2023. Der Testfall soll nachweisen, dass –die Kodierung des Attributs gemäß PER (packed encoding rules) korrekt umgesetzt wurde, andernfalls ob die akzeptierte Umsetzung gemäß dem legacy encoding korrekt implementiert ist–die OBU die GPS-Position korrekt setzt–die OBU das Attribut im vorgesehenen Zeitrahmen aktualisiert

DSRC_SFXX_HISN_0012Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird der Tester aufgefordert, die OBU in den Zustand 2-„noGoContractual“ zu versetzen. Dazu muss evtl. Unterstützung vom Dienstanbieter angefordert werden. Mit der Bake wird eine CCC-2019-Transaktion durchgeführt. Abschließend wird das Bakenlog ausgelesen und überprüft, ob im Attribut ExtendedOBUStatusHistoryPart1 bzw. ExtendedOBUStatusHistoryPart2 der StatusIndicator korrekt gesetzt ist. Erwartetes Ergebnis: Der Status 2-„noGoContractual“ wurde erreicht.Der StatusIndicator im Attribut ExtendedOBUStatusHistoryPart1 und ExtendedOBUStatusHistoryPart2 zeigt an, ob die OBU erhebungsbereit ist bzw. welche Art von Störung vorliegt. Dieser Testfall soll zeigen, dass der Wert des StatusIndicators unter den passenden Umständen den Wert 2-„noGoContractual“ annimmt.

3 P1-KTD-002: Fachliche DSRC-Kompatibilitätstests der SST 301 – DSRC-Kommunikation

Name/IDBeschreibungZiel

AutoKST_SVF_FG06AVFahrzeuggeräte von neuen EETS-Anbietern durchlaufen eine Gebrauchstauglichkeitsprüfung (GTP). Im Rahmen der Kompatibilitätstests wird die Umsetzung der funktionalen Anforderungen an die EETS-Fahrzeuggeräte in einem E2E-Szenario überprüft. In diesem Testfall wird die Erzeugung der Fallgruppe 6 (Falschdeklarierer) mit einem Test-FzG überprüft. Ein Test-FzG wird im Test-LKW (mit Anhänger) benutzt und auf eine geringere Achszahl bzw. Gewichtsklasse personalisiert, als der Test-LKW inklusive Anhänger tatsächlich besitzt. Bei einer Durchfahrt unter der Test-Kontrollstelle wird überprüft, ob die Test-Kontrollstelle gemäß aktuellem Tarifparametermodell einen Falschdeklarier erkennt.Ein Test-LKW mit Test-FzG, aber unzureichend deklarierter Achsklasse und/oder Gewichtsklasse erzeugt eine Fallgruppe 6 (Falschdeklarierer). Korrekte und vollständige DSRC-Daten (gemäß SST-Spezifikation 301).

AutoKST_SVF_ FG06AV_2xFzGDer Testfall prüft ein häufig im Pilotbetrieb auftretendes Szenario: Ein mautpflichtiges Fahrzeug ist mit einem Fahrzeuggerät (FzG_1) des EETS-Anbieters sowie einem zweiten deaktivierten/gesperrten Fahrzeuggerät (FzG_2) eines weiteren Anbieters ausgestattet. Um einen Kontrollfall inklusive DSRC-Daten zu erzeugen, wird das Szenario in Form eines Falschdeklarierers durchgeführt. FzG_1 und FzG_2 werden im Test- LKW (mit Anhänger) positioniert. FzG_1 wird auf eine geringere Achszahl bzw. Gewichtsklasse deklariert, als der Test-LKW inklusive Anhänger tatsächlich besitzt. FzG_2 befindet sich im Status NOK (gesperrt/deaktiviert).Ein Test-LKW mit falsch deklariertem Test-FzG (FzG_1) und einem weiteren FzG (FzG_2) im Status NOK erzeugt einen Verdachtsfall der Fallgruppe 6 (Falschdeklarierer). Die DSRC-Daten beider Fahrzeuggeräte werden korrekt und vollständig übertragen, wobei ausschließlich eine Auffälligkeit des im Rahmen der Gebrauchstauglichkeitsprüfung zu testenden EETS-Fahrzeuggeräts (FzG_1) zum Fehlschlagen des Testfalls führen kann. Kommunikation gemäß SST-Spezifikation 301.

AutoKST_SVF_FG07_ mautfreier_ModusIn diesem Testfall wird die Erzeugung der Fallgruppe 7 mit einem Test-FzG überprüft. Ein Test-FzG wird im Test-LKW (mit Anhänger) angeschlossen. Anschließend wird das Test-FzG so eingestellt, dass das Fahrzeug damit im Gebiet BFStrMG nicht mautpflichtig ist. Bei der Durchfahrt an der Kontrollstelle wird überprüft, ob die Kontrollstelle eine FG7 erkennt.Ein Test-LKW mit Test-FzG, welches sich im mautfreien Modus befindet, erzeugt eine Fallgruppe 7.–Auswertung nach SST 301 durch Attribut ExtendedOBUStatusHistoryPart1.Korrekte und vollständige DSRC-Daten (gemäß SST-Spezifikation 301).

AutoKST_SVF_FG12In diesem Testfall wird die Erzeugung der Fallgruppe 12 mit einem Test-FzG überprüft. Der Test-LKW, dessen Test-FzG mit dem Status „gesperrt“ eingesetzt ist, passiert die Kontrollstelle. Die DSRC-Daten aus dem Test-FzG werden von der Test-Kontrollstelle ausgelesen. Der Status „gesperrt“ wird festgestellt und die Test-Kontrollstelle erzeugt einen Verdachtsfall der Fallgruppe 12. Dieser wird anschließend an die Test-KonZ_2.0 gesendet.Ein LKW mit einem eingebauten FzG, welches gesperrt ist, erzeugt eine FG-12-Auswertung nach SST 301 durch Attribut ExtendedOBUStatusHistoryPart1: FzG-Status „noGoContractual“ oder „noGoPaymentMeans“ (Parameter entsprechen der jeweiligen Testkonfiguration).Korrekte und vollständigeDSRC-Daten(gemäß SST-Spezifikation 301).

AutoKST_SVF_FG16Der Test-LKW befindet sich im automatischen Verfahren. Das Test-FzG wurde den Klassifikationsdaten entsprechend des Test-LKWs oder höher (Überzahler) konfiguriert. Der Test-LKW passiert die Test-Kontrollstelle, der DSRC-Datensatz aus dem Test-FzG wird ausgelesen. Die Test-Kontrollstelle entscheidet aufgrund der deklarierten Parameter und der Sensorikdaten auf FG16. Der Fall wird nicht an die KonZ_2.0 verschickt und in der Test-Kontrollstelle gelöscht.Ein Test-LKW mit korrekt eingestelltem Test-FzG erzeugt die FG16 (Gutzahler AV).Korrekte und vollständigeDSRC-Daten (gemäß SST-Spezifikation 301). Die Falldaten werden nicht an die KonZ_2.0 verschickt und in der Test-Kontrollstelle gelöscht.

AutoKST_ Verifikation_EETS_ MasterkeyIn diesem Testfall wird der neu aufgespielte EETS-Masterkey auf der dezentralen Komponente (KonAu/KonSL) verifiziert.Ein Test-LKW mit einem Test-FzG des EETS-Anbieters passiert als Gutzahler die Kontrollstelle. DSRC-Daten werden vollständig erfasst und entschlüsselt (gemäß SST-Spezifikation 301).

FzG_Parameter_EingabeVariable Fahrzeugparameter dürfen während der Fahrt (am Fahrzeuggerät selbst oder über eine App auf einem mit dem Fahrzeuggerät verbundenen Mobilgerät) nicht geändert werden. In diesem Testfall wird geprüft, ob das Test-Fahrzeuggerät eine Anpassung der variablen Fahrzeugparameter während der Fahrt unterbindet.Anpassung der variablen Fahrzeugparameter während der Fahrt nicht mehr möglich.

KonB_DezKst_SVF_FGEin Test-LKW passiert eine Kontrollstelle und ein Verdachtsfall wird angelegt. Dieser Verdachtsfall wird in der KonZ_2.0 mit der passenden Fallgruppe gespeichert. Kontrollfall- und Nacherhebungsdaten werden aus der KonZ_2.0 in die KonB (zunächst aKA) übertragen. Anschließend werden die Daten in die VB übernommen und aufbereitet. Übertragung bis ins SC-OWI sowie die Rückantwort an die KonZ_2.0 werden überprüft.Sicherstellung, dass der Kontrollfall aus der KonZ_2.0 korrekt in der KonB ankommt. Gewährleistung Interoperabilität Kontrollstelle zu weiterführenden Systemen.

KonMa_auswinken_VKBDas Fahrzeug wird ausgewunken. Ein verkürzter Kontrollbericht (VKB, FG19) wird ohne weitere Kontrolle erstellt.Erfolgreiches Erstellen eines VKB (FG19).

KonMa_KonZ_ Berichte_weiterverarbeiten_ in_KonBDieser Testfall prüft die Weiterverarbeitung von Kontrollfällen mit einem Kontrollbericht über die KonZ_2.0 bis in die KonB. Die Überprüfung erfolgt für den Kontrollfall, Kontrollfalldaten bzw. die erfassten Beweismittel. Es wird die e-Akte in SC-OWI überprüft. Optional: Die Anreichung der e-Akte mit den zugehörigen DSRC-Daten prüfen.Absicherung der Übermittlung von Fahrzeugkontrollfällen nach SC-OWI. Optional: Absicherung der DSRC-Daten-Anreicherung. Vollständigkeit und inhaltliche Richtigkeit der e-Akte in SC-OWI für Fahrzeugkontrollfälle prüfen.

KonMa_Mobile_KontrolleIn diesem Testfall wird die Auslesung eines EETS-FzGs im Test-LKW mit einer KonMa im Modus mobile Kontrolle durchgeführt. Durchführung einer Mobilen Kontrolle. Die entsprechenden Daten des Kontrollfalls bei einer DSRC-/OBE-Auslesung werden vollständig und korrekt angezeigt.Mit der KonMa wird eine Mobile Kontrolle gemäß den Testparametern erfolgreich durchgeführt. Die entsprechenden DSRC-Daten des Kontrollfalls werden vollständig und korrekt angezeigt (gemäß SST-Spezifikation 301). Die Fallgruppe wird durch die KonMa korrekt angezeigt.

KonMa_Standkontrolle_ Start_KBIn diesem Testfall wird die Auslesung eines EETS-FzGs im Test-LKW mit einer KonMa im Modus Standkontrolle mit dem Handheld durchgeführt. Das Test-FzG ist so eingestellt, dass das Fahrzeug damit im Gebiet BFStrMG nicht mautpflichtig ist. Bei der Kontrolle wird festgestellt, dass es sich bei dem Fahrzeug um ein mautpflichtiges Fahrzeug handelt und sich demnach eine FG7 (Nichtzahler) ergibt. Beginnen und Durchführung der Standkontrolle zum Erstellen eines Kontrollberichts. Auslesung der DSRC-Daten mit Handheld. Abschluss des Kontrollberichts.Mit der KonMa wird eine Standkontrolle gemäß den genannten Testparametern im Szenario erfolgreich gestartet. Die entsprechenden Daten des Kontrollfalls werden vollständig und korrekt angezeigt (gemäß SST-Spezifikation 301). Es wird die Kontrollberichterstellung durchgeführt.

KonZ_2.0_DezKst_SVFDie Test-Kontrollstelle erstellt einen Verdachtsfall und sendet diesen mit den Beweismitteln an die Test-KonZ_2.0. In der WebGUI wird nach dem KFZ-Kennzeichen selektiert und anhand des von der Test-Kontrollstelle gelesenen Kennzeichens überprüft. In diesem Testfall wird die Verarbeitung eines Verdachtsfalls in der Test-KonZ_2.0 einer durch die Test-Kontrollstelle durchgeführten Fahrt überprüft. Nach der Sachverhaltsfeststellung wird der Verdachtsfall in der Kontrollfallverwaltung verarbeitet, bis der fertige Kontrollfall an das SC-OWI (KonB) exportiert wird.Überprüfung der korrekten Weiterleitung des Verdachtsfalls von der Kontrollstelle an die KonZ_2.0. Überprüfung aller relevanten DSRC-Parameter in der Kontrollzentrale (gemäß SST-Spezifikation 301).

Bundesrepublik Deutschland vertreten durch das Bundesministerium für Digitales und Verkehr (BMDV) dieses vertreten durch das Bundesamt für Logistik und Mobilität (BALM)

Europäischer elektronischer Mautdienst (EETS)

Verfahren zur Feststellung der Gebrauchstauglichkeit

Anlage 3 zum Dokument B- Prüfkonzept

Prüfkatalog „MED-Kompatibilitätstests“

Dokumentenhistorie

VersionDatumBearbeiterBearbeitung/Änderung

0.117.09.2020RT, BAGErstellung erster unvollständiger Entwurf

0.230.10.2020RT, BAGÜberarbeitung nach Vorlage Prüfspezifikation KT MED

1.004.12.2020RT, BAGÜberarbeitung nach Vorlage Prüfspezifikation KT MED v1.0, QS und Finalisierung

1.118.06.2021RT, BAGErgänzung Fahrmanöver MF_09 und MF_10 in P1-KTM-001

1.201.03.2024RT, BALMRedaktionelle Überarbeitung entsprechend der Änderungen im BFStrMG und Umbenennung BAG in BALM

1 Einleitung

Der vorliegende Prüfkatalog enthält die Prüffalle, deren Erfüllung im Rahmen der Feststellung der Gebrauchstauglichkeit in Prüfblock 2, Phase 1 Kompatiblitätests nachzuweisen ist.

Er beschränkt sich auf die Prüffälle zum Nachweis der Kompatibilität zum Mauterhebungs-dienst (MED) in Bezug auf die Schnittstellen zwischen dem Teilsystem des EETS-Anbieters und dem MED sowie in Bezug auf die Erfüllung der Anforderungen an die Ortung durch die Bordgeräte des EETS-Anbieters (MED-Kompatibilitätstests)

Die Kompatibilitätstests werden durch den nationalen Mautbetreiber im Auftrag des Mauterhebers geplant und durchgeführt.

Die in diesem Prüfkatalog aufgeführten Prüffalle werden durch die Prüfspezifikation „Kompatibilitätstests MED“ detailliert und konkretisiert.

2 Prüffälle

2.1 P1-KTM-001: Ortungstests der Bordgeräte

IDNameBeschreibungZiel

FS_01OrtungstestEs werden die in den folgenden Zeilen beschriebenen Messfahrten mit unterschiedlichen Fahrszenarien durchgeführt. Die durch die EETS-Fahrzeuggeräte aufgezeichneten Fahrspuren werden nach Abschluss aller Messfahrten ausgewertet.Alle im Rahmen der Messfahrten eingesetzten EETS-Fahrzeuggeräte erfüllen die Qualitätsanforderungen hinsichtlich der Ortung.

MF_01: Geradeausfahrt unter normalen BedingungenMit diesem Test wird das normale am häufigsten auftretende Fahrverhalten der Nutzer getestet. Es werden alle Fahrten auf der Autobahn ohne besondere Einstellungen durchgeführt.Das Verhalten der initialen Sensorfunktion der EETS-OBUs wird unter Normalbedingungen überprüft.

MF_02: Autobahnfahrt/Landstraße – normales Fahren mit wechselnden BedingungenFahrszenario zur Simulation von Fahrverhalten bei wechselnden Bedingungen. Es ist eine Testzeit von minimal 7,5 Stunden angesetzt, um Daten für typische reale GNSS-Empfangsbedingungen zu erhalten.Das Langzeitverhalten und die Stabilität in einem typischen Produktivszenario werden getestet.

MF_03: GebirgeFahrszenario zur Simulation von Fahrverhalten bei starken GNSS-Abschattungen und abwechslungsreichem Gelände.Es wird das Verhalten der EETS-FzG bei Satellitenabschattung (Bäume, Berge) und gleichzeitig kurvenreicher Strecke getestet. Unter Umständen kann auch ein GNSS-Ausfall provoziert werden um das Aufsetzverhalten (Reakquisition) zu testen

MF_04: StadtfahrtFahrszenario zur Fahrt im eng bebauten Gebiet (Stadtfahrt). Eine Besonderheit bei den Stadtfahrten stellen Reflexionen des GPS-Signals dar. Dieser Test soll insbesondere die Fähigkeiten der Sensorfusion in solchen Fällen und die Handhabung von Multipath-Effekten in der GNSS-Hardware überprüfenEs wird das Verhalten der EETS-FzG bei eng bebauten Straßen und hohen Gebäuden getestet

MF_05: Achterfahrt unter normalen BedingungenDer Test prüft, ob die GNSS-Sensorik, -Algorithmik oder die Sensorfusion die Messergebnisse verzerren, verzögern oder verfälschen (z.B. die Kurven verziehen, überschwinden, stark abrunden, etc.).Ziel dieser Tests ist es eine Abhängigkeit aus der ohne GNSS zurückgelegten Strecke, dem Streckenverlauf und der Abweichung über die Strecke zu ermitteln.

MF_06: Rückwärtsfahrt/WendemanöverFahrszenario zur Simulation von Fahrverhalten bei Park- und Wendemanövern.Der Test prüft, ob bei Umkehrung der Fahrtrichtung die Sensorik die korrekte Bewegung vollzieht (oder ob z.B. stattdessen eine Vorwärtsfahrt erzeugt wird).

MF_07: Langsamfahrt Autobahn (Stau)Fahrszenario zur Simulation von Fahrverhalten bei geringen Geschwindigkeiten.Das Verhalten bei langsamer Fahrt oder Beinahe-Stillstand unterscheidet sich erheblich vom Normalbetrieb. Dies wird mit diesem Test geprüft.

MF_08: Wiederholte AutobahnfahrtBei diesem Testfall wird die wiederholte Auf- und Abfahrt auf Autobahnen simuliert. Dabei wird dazwischen jeweils ein gerades Stück Autobahn befahren. Dieser Test dient der Erkennung von möglicherweise auftretenden Drifts, also dem seitlichen „Abwandern“ der PositionenEs wird das Verhalten der Geräte bei wiederholtem Wechsel von geradeaus befahrbaren Straßenabschnitten und Kurvensegmenten getestet.

MF_09: TunnelfahrtDurchführung mehrere Tunnelbefahrungen zur Bewertung der Reakquisitionszeit nach Ausfahrt aus dem Tunnel.Der Test bewertet die Reakquisitionszeit nach einer Tunnelbefahrung

MF_10: Statischer Test (Stillstand)Dieses Szenario dient der Simulation von Fahrverhalten bei Stillstand des Fahrzeugs.Der Test bewertet die Einhaltung der Ortungsanforderungen beim Stillstand des Fahrzeugs.

2.2 P1-KTM-002: Erhebungstest unter Alltagsbedingungen

IDNameBeschreibungZiel

FT-001-SST005Übertragung und Verarbeitung von Fahrspuren (SST 005)Die mit den OBUs des EETS-Anbieter ausgestattete Speditionsflotte fährt innerhalb des Streckennetzes des Mautgebiets BFStrMG. Die Fahrspuren werden von den OBUs des EETS-Anbieters erhoben und vom Testsystem der EETS-Anbieter über die SST 005 an das Testsystem der TC übermittelt und in diesem verarbeitet.Der EETS-Anbieter überträgt korrekte und vollständige Fahrspuren über die SST005

FT-002-SST005Die Bewertung der Ortungsqualität der EETS-Geräte im Speditionsumfeld.Die vom EETS-Anbieter übertragenen Fahrspuren werden bezüglich Ortungsqualität unter Alltagsbedingungen bewertet.Die Bewertung der Ortungsqualität der EETS-Geräte im Speditionsumfeld.

FT-003-SST007RErzeugung und Übertragung von Mautbuchungsnachweisen (SST 007R)Aus den übertragenen Fahrspuren der EETS-Anbieter werden Mautbu-chungsnachweise erzeugt und diese vom Testsystem der TC an das Testsystem des EETS-Anbieter über die SST 007R übermittelt.Die Mautbuchungsnachweise werden aus dem MED über die SST007R an den EETS-Anbieter übertragen.

FT-004-SST009Übermittlung Report „Information zu Auffälligkeiten bei Bordgeräten“ (SST009)Aus den übertragenen Fahrspuren der EETS-Anbieter werden Informationen zu auffälligen Bordgeräten der EETS-Anbieter generiert und vom Testsystem der TC an das Testsystem der EETS-Anbieter über die SST 009 übermittelt.Übermittlung des Reports zu auffälligen Bordgeräten über die SST009.

Bundesrepublik Deutschland vertreten durch das Bundesministerium für Digitales und Verkehr (BMDV) dieses vertreten durch das Bundesamt für Logistik und Mobilität (BALM)

Europäischer elektronischer Mautdienst (EETS)

Verfahren zur Feststellung der Gebrauchstauglichkeit

Anlage 4 zum Dokument B - Prüfkonzept

Prüfkatalog „Probebetrieb“

Dokumentenhistorie

VersionDatumBearbeiterBearbeitung/Änderung

0.117.09.2020RT, BAGErstellung erster unvollständiger Entwurf

0.230.10.2020RT, BAGÜberarbeitung nach Review und Abstimmung mit BAG und TC

1.004.12.2020RT, BAGQS und Finalisierung

1.101.03.2024RT, BALMÜberarbeitung entsprechend der Änderungen des BFStrMG

1 Einleitung

Der vorliegende Prüfkatalog enthält die Prüffalle, deren Erfüllung im Rahmen der Feststellung der Gebrauchstauglichkeit in Prüfblock 2, Phase 2 Probebetrieb nachzuweisen ist.

Die in diesem Prüfkatalog aufgeführten Prüffalle werden durch die Prüfspezifikation „Probebetrieb“ detailliert und konkretisiert.

2 Prüffälle

2.1 P2-001: korrekte Mauterhebung

IDNameBeschreibungZiel

P2.001.1Befahrung des mautpflichtigen StreckennetzesMehrtägige Befahrung des deutschen mautpflichtigen StreckennetzesNachweis der Übermittlung korrekter Fahrspurdaten und Verarbeitung zu Mautbuchungsnachweisen

P2.001.2Sonderfahrten - Änderung Achs- und GewichtsklasseDurchführung von Änderungen in den tarifrelevanten Fahrzeugparametern (Achs- und Gewichtsklasse) durch An- und Abhängen eines Anhängers innerhalb des deutschen Mautnetzes (BFStrMG), wobei das mautpflichtige Netz während der Testfalldurchführung nicht verlassen wird.Nachweis der Übermittlung korrekter Fahrspurdaten inklusive veränderter tarifrelevanten Fahrzeugparametern und Verarbeitung zu Mautbuchungsnachweisen basierend auf den geänderten Fahrzeugparametern

P2.001.3Sonderfahrten - Tausch des Bordgeräts in einem FahrzeugDas Bordgerät eines bereits beim EA registrierten Nutzers wird ausgetauscht und ein neues Bordgerät in das Fahrzeug installiert. Vor dem Tausch erfolgt eine Befahrung des mautpflichtigen Streckennetzes.Nachweis der korrekten Aktualisierung und Übermittlung der Nutzerlisten an den Mauterheber im Falle des Tauschs eines Bordgeräts

P2.001.4Sonderfahrten - Weitergabe des Bordgeräts an ein anderes FahrzeugDas Bordgerät eines bereits beim EA registrierten Nutzers wird aus dem Fahrzeug ausgebaut und in ein anderes Fahrzeug installiert. Vor dem Ausbau erfolgt eine Befahrung des mautpflichtigen Streckennetzes.Nachweis der korrekten Aktualisierung und Übermittlung der Nutzerlisten an den Mauterheber im Falle der Weitergabe des Bordgeräts

P2.001.5ZwangsbeendigungDurchführung einer Befahrung des mautpflichtigen Netzes mit einer längeren Fahrtunterbrechung auf dem mautpflichtigen NetzNachweis der Übermittlung korrekter Fahrspurdaten und Verarbeitung zu Mautbuchungsnachweisen auch im Falle von längeren Fahrtunterbrechungen auf dem mautpflichtigen Netz

P2.001.6Fahrt mit Fahrzeug unterhalb der Mautpflichtgrenze (≤ 3,5 t)Durchführung einer Befahrung des mautpflichtigen Streckennetzes mit einem unterhalb der Mautpflichtgrenze deklarierten BordgerätNachweis, dass keine Fahrspurdaten für nicht-mautpflichtige Fahrzeuge übermittelt werden

P2.001.7Fahrt mit Fahrzeug ohne aktiven Vertrag für das Mautgebiet BFStrMGDurchführung einer Befahrung des mautpflichtigen Streckennetzes mit einem Bordgerät ohne aktiven Vertrag für das Mautgebiet BFStrMGNachweis, dass keine Fahrspurdaten für Fahrzeuge ohne aktiven Vertrag für das Mautgebiet BFStrMG übermittelt werden

2.2 P2-002: korrekte Abrechnung und Auskehr

IDNameBeschreibungZiel

P2.002.1Abrechnung und Auskehr der Fahrten aus P2.001Simulation der Auskehr und Durchführung des Auskehrreportings für die in P2.001 durchgeführten FahrtenNachweis, dass das Auskehrreporting korrekt und vollständig erfolgt

P2.002.2Vergutschriftung (Fall A) – manuelle Korrektur für bereits ausgekehrte MautfahrtenDurchführung des Prozesses der Vergutschriftung aufgrund einer Fehlvergebührung des MED unter der Annahme, dass der fehlerhafte Mautbetrag bereits ausgekehrt wurdeSicherstellung korrekter Abrechnung und Auskehr auch im Falle von Fehlvergebührungen des MED

P2.002.3Vergutschriftung (Fall B) – manuelle Korrektur vor Auskehr der MautfahrtenDurchführung des Prozesses der Vergutschriftung aufgrund einer Fehlvergebührung des MED unter der Annahme, dass der fehlerhafte Mautbetrag noch nicht ausgekehrt wurdeSicherstellung korrekter Abrechnung und Auskehr auch im Falle von Fehlvergebührungen des MED

2.3 P2-003: Überwachung des EETS-Anbieters

IDNameBeschreibungZiel

P2.003.1Bereitstellung der Überwachungsreports über die SST 013Erstellung und Übermittlung des Überwachungsreports "1. IT Sicherheit & Betrieb"Nachweis eines funktionsfähigen Überwachungsprozesses beim EA und korrekte Übermittlung des Überwachungsreports

P2.003.2Störung Schnittstelle – SST002b User-DetailsDer EA erzeugt eine Störung der SST002b so dass keine Fahrzeug- und Halterdaten Anfrage erfolgen kann. Nach Beseitigung der Störung ist die Anfrage möglich. Die Störung wird im Überwachungsreport "1. IT Sicherheit & Betrieb" aufgenommen und übermitteltNachweis eines funktionsfähigen Überwachungsprozesses beim EA und korrekte Übermittlung des Überwachungsreports

P2.003.3Störung BordgerätDer EA verhindert während einer Fahrt auf dem mautpflichtigen Streckennetz die Übermittlung von Fahrspuren eines Bordgerätes. Die Störung wird > 72h nach Abschluss der Fahrt beseitigt und die aufgezeichneten Fahrspurdaten werden übermittelt. Die technische Auffälligkeit wird erkannt und an den EA übermittelt.Nachweis der Funktionsfähigkeit des Prozesses der Erkennung von Auffälligkeiten von Bordgeräten und der korrekten Interaktion zwischen Mauterheber und EA in diesem Fall.

P2.003.4Bereitstellung Informationen zu technischem Zustand EETS-Bordgerät über die SST 016Der Mauterheber stellt über die organisatorische Schnittstelle 016 eine Anfrage zum technischen Zustand eines Bordgeräts an den EA, welche vom EA beantwortet wird.Nachweis der spezifikationskonformen Bereitstellung von Informationen zum technischen Zustand eines Bordgeräts über die SST 016 durch den EA

2.4 P2-005: korrekte Kontrollprozesse

IDNameBeschreibungZiel

P2.005.1Kontrolle von Bordgeräten vor und nach SperrlisteneintragEs werden zwei Befahrungen des mautpflichtigen Streckennetzes durchgeführt, auf welchen jeweils eine automatische Kontrolle erfolgt. Zwischen den beiden Befahrungen wird das Bordgerät gesperrt. Im Rahmen des bei der zweiten Kontrolle entstehenden Verdachtsfalls werden auf Anfrage des Mauterhebers die Fahrzeug- und Halterdaten über die SST002b vom EA übermittelt.Nachweis der Funktionsfähigkeit des Sperrprozesses der Bordgeräte inklusive der korrekten Aktualisierung der Sperrliste und Übermittlung plausibler Werte über die DSRC-Schnittstelle. Nachweis der Funktionsfähigkeit der Abfrage von Fahrzeug- und Halterdaten über die SST002b im Rahmen des Ahndungsprozesses des Mauterhebers.

Anlage 4 zur Prüfvereinbarung

(Fundstelle: BAnz AT 29.10.2021 V 2)

Zeit- und Projektplan

(Nach Abschluss der Prüfvereinbarung beizufügen.)

Anlage 5 zur Prüfvereinbarung

(Fundstelle: BAnz AT 29.10.2021 V 2)

Entgeltordnung

1. Vorbemerkung

Im Rahmen der Durchführung des Zulassungsverfahrens zur Erbringung mautdienstbezogener Leistungen auf dem EETS-Gebiet BFStrMG sind vom BALM Gebühren für die Geltendmachung individuell zurechenbarer öffentlicher Leistungen zu erheben. Das Zulassungsverfahren gliedert sich in folgende Phasen:

2. Gebühren

Von einem EETS-Anbieter, der das Zulassungsverfahren durchläuft, sind die nachfolgend genannten Pauschalbeträge zu entrichten:

VerfahrensphasePauschalentgelta)vor Beginn der Prüfung der Voraussetzungen und Dokumentation (GTP Prüfblock 1, Nummer 1, 2, 3 und 4)22 500 Eurob)vor Beginn der Prüfung der wirtschaftlichen Vorgaben25 500 Euroc)vor Beginn der GTP Phase 1 (GTP Prüfblock 2, Nummer 5)143 500 Eurod)vor Beginn des Probebetriebs (GTP Prüfblock, Nummer 6)48 500 Euroe)vor Beginn des Pilotbetriebs (GTP Prüfblock, Nummer 7)62 000 EuroGesamtbetrag:302 000 Euro

3. Fälligkeit

Diese Pauschalbeträge sind jeweils vor Beginn der zugehörigen Verfahrensphase fällig. Das BALM fordert einen EETS-Anbieter vor jeder Verfahrensphase schriftlich zur Zahlung des Betrags auf. Die Verfahrensphase wird vom BALM erst nach Eingang der entsprechenden Zahlung eingeleitet.

4. Erneute Durchführung des Verfahrens

Es ist möglich, dass eine erneute Prüfung eines Teils oder des gesamten Teilsystems eines EETS-Anbieters notwendig wird. Dies ist der Fall, wenn