Title: **3 Prüffälle für SST 301 Version 3.1**

Description:
Vereinbarung über die Durchführung des Prüfverfahrens zur Erbringung mautdienstbezogener Leistungen (EEMD-ZVAnl I)
**Prüfkatalog „DSRC-Kompatibilitätstests“**
**3 Prüffälle für SST 301 Version 3.1**

Paragraph: 29

Content:
Vereinbarung über die Durchführung des Prüfverfahrens zur Erbringung mautdienstbezogener Leistungen (EEMD-ZVAnl I)
**Prüfkatalog „DSRC-Kompatibilitätstests“**
**3 Prüffälle für SST 301 Version 3.1**

**3.1 P1-KTD-001: Betriebliche DSRC-Kompatibilitätstests der SST 301 –
DSRC-Kommunikation**

*    *   Name/ID

    *   Beschreibung

    *   Ziel

*    *   DSRC\_A0BA\_BI01\_0010

    *   Die Bake sendet BSTs für AIDs 1, 20 und 21 mit einem profile, das von
        der OBU nicht unterstützt wird. Die OBU soll nicht antworten. Das wird
        wiederholt mit einem weiteren von der OBU nicht unterstützten profile
        wiederholt.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul das Profil
        korrekt handhabt.

*    *   DSRC\_A0BA\_BI02\_0010

    *   Die Bake sendet BSTs für eine von der OBU nicht unterstütze Anwendung
        in der mandApplicationList und leerer nonmandApplicationList. Die OBU
        soll nicht antworten. Das wird wiederholt mit einer weiteren von der
        OBU nicht unterstützten Anwendung in der mandApplicationList und der
        vorigen Anwendung in der nonmandApplicationList.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul
        applicationIds korrekt handhabt.

*    *   DSRC\_A0BA\_BI03\_0011

    *   Die Bake sendet BSTs für eine von der OBU nicht unterstütze Anwendung
        mit EID in der mandApplicationList und AID=20 in der
        nonmandApplicationList. Die OBU soll nicht antworten.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul
        applicationIds korrekt handhabt.

*    *   DSRC\_A0BA\_BV01\_0010

    *   Die Bake führt eine reguläre Initialisierungsphase für AIDs 1, 20 und
        21 durch. Anschließend sendet sie ein ECHO.rq, das die OBU beantworten
        soll. Dann schickt sie eine BST, die die OBU nicht beantworten soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul die
        Initialisierung korrekt durchführt.

*    *   DSRC\_A0BA\_BV02\_0010

    *   Die Bake führt eine reguläre Initialisierungsphase für AIDs 1, 20 und
        21 durch. Anschließend sendet sie ein ECHO.rq, das die OBU beantworten
        soll, und zwei RELEASEs. Dann schickt sie ein weiteres ECHO, das die
        OBU nicht beantworten soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul die
        Initialisierung korrekt durchführt.

*    *   DSRC\_A0BA\_BV03\_0010

    *   Die Bake führt eine reguläre Initialisierungsphase für AIDs 1, 20 und
        21 durch. Anschließend sendet sie ein ECHO.rq, das die OBU beantworten
        soll. Der ganze Vorgang wird wiederholt, wobei erst die manufacturerID
        und dann die individualId der BST verändert wird.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul die
        Initialisierung korrekt durchführt.

*    *   DSRC\_A0BA\_BV04\_0010

    *   Die Bake führt eine reguläre Initialisierungsphase für AIDs 1, 20 und
        21 durch. Anschließend sendet sie ein ECHO.rq, das die OBU beantworten
        soll. Der ganze Vorgang wird wiederholt, wobei die beacon time der BST
        um 256 Sekunden erhöht wird.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul die
        Initialisierung korrekt durchführt.

*    *   DSRC\_A0BA\_BV09\_0010

    *   Die Bake führt eine reguläre Initialisierungsphase für AIDs 1, 20 und
        21 mit profile=0 und leerer profileList durch. In der VST soll der
        Wert von profile auf 0 gesetzt sein. Der Vorgang wird wiederholt mit
        einer BST mit neuer BeaconID, profile=0 und profileList=1,U, wobei in
        der VST profile wieder den Wert 0 haben soll. Der Vorgang wird
        wiederholt mit einer BST mit neuer BeaconID, profile=1 und leerer
        profileList, wobei in der VST profile wieder den Wert 1 haben soll.
        Der Vorgang wird wiederholt mit einer BST mit neuer BeaconID,
        profile=1 und profileList=0,U, wobei in der VST profile wieder den
        Wert 1 haben soll. U hat den Wert eines Profils, das die OBU nicht
        unterstützt.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul das Profil
        korrekt handhabt.

*    *   DSRC\_A0BA\_BV10\_0010

    *   Die Bake führt eine reguläre Initialisierungsphase für AIDs 1, 20 und
        21 durch. Die VST wird auf ein korrektes Format hin überprüft.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul die BST mit
        einer korrekten VST beantwortet.

*    *   DSRC\_A0DA\_BI01\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie jeweils ein SET.rq für Attribute 16, 17, 18,
        19, 20, 22, 46, 48, 55, 60, 62 und 63, das jeweils mit Fehlercode
        (einem Wert ungleich 0) beantwortet werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul
        schreibgeschützte Attribute nicht ändert, auch wenn sie mittels SET
        dazu aufgefordert wird.

*    *   DSRC\_A0DA\_BI02\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie ein SET.rq für Attribute 16, 17, 18, 19, 20,
        22, 46, 48, 55, 60, 62 und 63, das mit Fehlercode (einem Wert ungleich
        0) beantwortet werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul
        schreibgeschützte Attribute nicht ändert, auch wenn sie mittels SET
        dazu aufgefordert wird.

*    *   DSRC\_A0DA\_BI03\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie ein SET.rq für Attribute 0, 24 und 32, das mit
        Fehlercode (einem Wert ungleich 0) beantwortet werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul
        schreibgeschützte Attribute nicht ändert, auch wenn sie mittels SET
        dazu aufgefordert wird.

*    *   DSRC\_A0DA\_BI04\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie jeweils ein SET.rq für Attribute 0, 24 und 32,
        das jeweils mit Fehlercode (einem Wert ungleich 0) beantwortet werden
        soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul
        schreibgeschützte Attribute nicht ändert, auch wenn sie mittels SET
        dazu aufgefordert wird.

*    *   DSRC\_A0DA\_BI05\_5010

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie ein gemeinsames SET.rq für Attribute 49, 50,
        51, 52, 53, 61, 64, und ein weiteres gemeinsames SET.rq für die
        Attribute 99, 100 und 101, die mit Fehlercode beantwortet werden
        sollen.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul
        schreibgeschützte Attribute nicht ändert, auch wenn sie mittels SET
        dazu aufgefordert wird.

*    *   DSRC\_A0DA\_BI06\_5010

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie jeweils ein SET.rq für Attribute 49, 50, 51,
        52, 53, 61, 64, 99, 100 und 101, das mit Fehlercode beantwortet werden
        soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul
        schreibgeschützte Attribute nicht ändert, auch wenn sie mittels SET
        dazu aufgefordert wird.

*    *   DSRC\_A0DA\_BI07\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie ein GET.rq mit ungültigen accessCredentials
        für Attribute 24 und 32, das mit Fehlercode (einem Wert ungleich 0)
        beantwortet werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul
        lesegeschützte Attribute nicht zurückgibt, wenn sie mittels GET dazu
        aufgefordert wird.

*    *   DSRC\_A0DA\_BI08\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie ein GET.rq mit ungültigen accessCredentials
        für Attribute 16, 17, 18, 19, 20, 22, 46, 48, 55, 60, 62 und 63, das
        mit Fehlercode (einem Wert ungleich 0) beantwortet werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul
        lesegeschützte Attribute nicht zurückgibt, wenn sie mittels GET dazu
        aufgefordert wird.

*    *   DSRC\_A0DA\_BI09\_5010

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie ein gemeinsames GET.rq mit ungültigen
        accessCredentials für Attribute 49, 50, 51, 52, 53, 61, 64, und ein
        weiteres gemeinsames GET.rq mit ungültigen accessCredentials für die
        Attribute 99, 100 und 101, die mit Fehlercode beantwortet werden
        sollen.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul keine
        Attributwerte zurückgibt, wenn die AccessCredentials nicht korrekt
        sind.

*    *   DSRC\_A0DA\_BI10\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie ein
        GET\_STAMPED.rq mit ungültigen accessCredentials für Attribute 24 und
        32,
        das mit Fehlercode (einem Wert ungleich 0) beantwortet werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul
        lesegeschützte Attribute nicht zurückgibt, wenn sie mittels
        GET\_STAMPED dazu aufgefordert wird.

*    *   DSRC\_A0DA\_BI11\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie ein
        GET\_STAMPED.rq mit ungültigen accessCredentials für Attribute 16, 17,
        18, 19, 20, 22, 46, 48, 55, 60, 62 und 63, das mit Fehlercode (einem
        Wert ungleich 0) beantwortet werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul
        lesegeschützte Attribute nicht zurückgibt, wenn sie mittels
        GET\_STAMPED dazu aufgefordert wird.

*    *   DSRC\_A0DA\_BI12\_5010

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie ein gemeinsames GET-STAMPED.rq mit ungültigen
        accessCredentials für Attribute 49, 50, 51, 52, 53, 61, 64, und ein
        weiteres gemeinsames GET-STAMPED.rq mit ungültigen accessCredentials
        für die Attribute 99, 100 und 101, die mit Fehlercode beantwortet
        werden sollen.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul keine
        Attributwerte zurückgibt, wenn die AccessCredentials nicht korrekt
        sind.

*    *   DSRC\_A0DA\_BV01\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie ein GET.rq für Attribute 24 und 32, das
        ordnungsgemäß beantwortet werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET-
        Befehl korrekt handhabt.

*    *   DSRC\_A0DA\_BV02\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie ein GET.rq für
        Attribut 24, das ordnungsgemäß beantwortet werden soll. Dann sendet
        sie ein GET.rq für Attribut 32, das ordnungsgemäß beantwortet werden
        soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET-
        Befehl korrekt handhabt.

*    *   DSRC\_A0DA\_BV03\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie ein GET.rq für Attribute 16, 17, 18, 19, 20,
        22, 46, 48, 55, 60, 62 und 63, das ordnungsgemäß beantwortet werden
        soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET-
        Befehl korrekt handhabt.

*    *   DSRC\_A0DA\_BV04\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie jeweils ein GET.rq für Attribute 16, 17, 18,
        19, 20, 22, 46, 48, 55, 60, 62 und 63, das ordnungsgemäß beantwortet
        werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET-
        Befehl korrekt handhabt.

*    *   DSRC\_A0DA\_BV05\_5010

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie ein gemeinsames GET.rq für Attribute 49, 50,
        51, 52, 53, 61, 64, und ein weiteres gemeinsames GET.rq für die
        Attribute 99, 100 und 101, die mit Fehlercode beantwortet werden
        sollen.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET-
        Befehl korrekt handhabt.

*    *   DSRC\_A0DA\_BV06\_5010

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie jeweils ein GET.rq für Attribute 49, 50, 51,
        52, 53, 61, 64, 99, 100 und 101, das ordnungsgemäß beantwortet werden
        soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET-
        Befehl korrekt handhabt.

*    *   DSRC\_A0DA\_BV07\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie ein
        GET\_STAMPED.rq für Attribute 24 und 32,
        das ordnungsgemäß beantwortet werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den
        GET\_STAMPED-Befehl korrekt handhabt.

*    *   DSRC\_A0DA\_BV09\_5010

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie ein gemeinsames GET-STAMPED.rq für Attribute
        49, 50, 51, 52, 53, 61, 64, und ein weiteres gemeinsames GET-
        STAMPED.rq für die Attribute 99, 100 und 101, die mit Fehlercode
        beantwortet werden sollen.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den
        GET\_STAMPED-Befehl korrekt handhabt.

*    *   DSRC\_A0DA\_BV10\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie ein
        GET\_STAMPED.rq für Attribute 16, 17, 18, 19, 20, 22, 46, 48, 55, 60,
        62 und 63, das ordnungsgemäß beantwortet werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den
        GET\_STAMPED-Befehl korrekt handhabt.

*    *   DSRC\_A0FU\_BI02\_0010

    *   Die Bake führt vorab eine reguläre Initialisierungsphase durch, um die
        Bereitschaft der OBU zur Kommunikation zu überprüfen. Anschließend
        sendet sie je eine BST mit PDU-Nummern 0 und 1, die von der OBU nicht
        beantwortet werden sollen.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul PDU-Nummern
        korrekt erkennt.

*    *   DSRC\_A0FU\_BI03\_0010

    *   Die Bake führt eine reguläre Initialisierungsphase durch. Dann sendet
        sie je eine PDU mit mode=1 und flow control=7 und allen ungültigen
        Werten des Fragmentzählers, die von der OBU nicht beantwortet werden
        sollen. Abschließend sendet sie eine PDU mit mode=1 und flow control=7
        und dem gültigen Wert des Fragmentzählers (0), die von der OBU
        beantwortet werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul PDU-
        Fragmente korrekt erkennt.

*    *   DSRC\_A0FU\_BI04\_0010

    *   Die Bake sendet je eine BST mit allen ungültigen Werten des
        Fragmentzählers, die von der OBU nicht beantwortet werden sollen.
        Abschließend führt sie eine reguläre Initialisierung durch, um zu
        überprüfen, dass die OBU noch korrekt reagiert.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul PDU-
        Fragmente korrekt erkennt.

*    *   DSRC\_A0FU\_BI06\_0010

    *   Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend
        sendet sie "chained" PDUs in einem Rahmen, von denen die erste einen
        Fehler erzeugen und die zweite mit "chaining error" beantwortet werden
        soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul PDU-Nummern
        korrekt erkennt.

*    *   DSRC\_A0FU\_BV01\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend
        sendet sie ein GET.rq für ein geeignetes Attribut, das ordnungsgemäß
        beantwortet werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET-
        Befehl korrekt handhabt.

*    *   DSRC\_A0FU\_BV08\_0010

    *   Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend
        sendet sie ein ACTION.rq mit mode=1 und FlowControl=7 (zum Beispiel
        ECHO), das ordnungsgemäß beantwortet werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den ACTION-
        Befehl korrekt handhabt.

*    *   DSRC\_A0FU\_BV09\_0010

    *   Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend
        sendet sie ein SET\_MMI.rq mit mode=0 und FlowControl=4. Der Tester
        überprüft, ob die OBU das SET\_MMI ausführt.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den ACTION-
        Befehl korrekt handhabt.

*    *   DSRC\_A0FU\_BV10\_0010

    *   Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend
        sendet sie ein SET\_MMI.rq mit mode=0 und FlowControl=1. Der Tester
        überprüft, ob die OBU das SET\_MMI ausführt.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den ACTION-
        Befehl korrekt handhabt.

*    *   DSRC\_A0FU\_BV11\_0010

    *   Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend
        sendet sie ein SET\_MM.rq mit mode=0 und FlowControl=1 an die
        Broadcast-LID. Der Tester überprüft, ob die OBU das SET\_MMI ausführt.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den ACTION-
        Befehl korrekt handhabt.

*    *   DSRC\_A0FU\_BV12\_0010

    *   Die Bake sendet ein SET\_MMI.rq mit mode=0 und FlowControl=1 an die
        Broadcast-LID. Der Tester überprüft, ob die OBU das SET\_MMI ausführt.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den ACTION-
        Befehl korrekt handhabt.

*    *   DSRC\_A0FU\_BV13\_0010

    *   Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend
        sendet sie je ein ECHO.rq mit PDU number 2 bis 31, das jeweils
        ordnungsgemäß beantwortet werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul PDU-
        Fragmente korrekt erkennt.

*    *   DSRC\_A0FU\_BV14\_0010

    *   Die Bake führt eine reguläre Initialisierungsphase durch, wobei die
        OBU Anwendungen für zwei ElementIDs !=0
        (EID1, EID2) anmelden soll. Dann sendet sie
        ECHO.rq mit jeweils neuen Daten für EID1, EID2, EID1 und EID2, die
        jeweils ordnungsgemäß beantwortet werden sollen.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul in einer
        Transaktion PDUs für mehrere Elemente empfangen kann.

*    *   DSRC\_A0FU\_BV16\_0010

    *   Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend
        sendet sie "concatenated" (nicht "chained") PDUs in einem Rahmen, die
        jeweils ordnungsgemäß in einem Rahmen beantwortet werden sollen.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul PDU-
        Fragmente korrekt erkennt.

*    *   DSRC\_A0FU\_BV17\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend
        sendet sie ein GET.rq für ein geeignetes Attribut, das ordnungsgemäß
        beantwortet werden soll. Dann sendet sie ein GET.rq mit falschen
        AccessCredentials, das mit Fehlermeldung (ReturnStatus 1) beantwortet
        werden soll. Dann sendet sie jeweils ein
        GET.rq mit AttributeIdList mit nicht existierendem Attribut 31 und
        falscher EID, die jeweils mit Fehlermeldung (ReturnStatus !=0)
        beantwortet werden sollen.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET-
        Befehl korrekt handhabt.

*    *   DSRC\_A0FU\_BV19\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend
        sendet sie ein GET\_STAMPED.rq für ein geeignetes Attribut, das
        ordnungsgemäß beantwortet werden soll. Dann sendet sie jeweils ein
        GET\_STAMPED.rq mit falschen AccessCredentials, das mit Fehlermeldung
        (ReturnStatus 1) beantwortet werden soll. Dann sendet sie jeweils ein
        GET\_STAMPED.rq mit AttributeIdList mit nicht existierendem Attribut
        31, falscher EID und ungültigem Wert für den keyRef-Parameter 19, die
        jeweils mit Fehlermeldung
        (ReturnStatus !=0) beantwortet werden sollen.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den
        GET\_STAMPED-Befehl korrekt handhabt.

*    *   DSRC\_A0FU\_BV20\_0010

    *   Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend
        sendet sie ein SET\_MMI.rq mit mode=0 und flowControl=1, dessen
        Ausführung der Tester bestätigen soll. Dann sendet sie ein
        SET\_MMI.rq mit mode=0 und flowControl=4, dessen Ausführung der Tester
        bestätigen soll und das von der OBU korrekt beantwortet werden soll.
        Zuletzt sendet sie ein
        SET\_MMI.rq mit ungültigem ActionParameter, das mit Fehlermeldung
        (ReturnStatus !=0) beantwortet werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den
        SET\_MMI-Befehl korrekt handhabt.

*    *   DSRC\_A0FU\_BV21\_0010

    *   Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend
        sendet sie ein ECHO.rq mit mode=0. Dann sendet sie ein ECHO.rq mit
        mode=1 und flowControl=7, das von der OBU korrekt beantwortet werden
        soll. Zuletzt sendet sie ein ECHO.rq mit ungültigem
        ActionParameter(hex. 11 01 20 04 12 34 56 78 70), das mit
        Fehlermeldung (ReturnStatus !=0) beantwortet werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den ECHO-
        Befehl korrekt handhabt.

*    *   DSRC\_A0SE\_BV01\_0010

    *   Für diesen Testfall wird der keyRef-Wert 1 benutzt. Die Bake führt
        eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein
        GET\_STAMPED.rq für das Attribut 32, das regulär beantwortet werden
        soll. Dann sendet sie jeweils ein GET\_STAMPED.rq mit ungültigen
        accesssCredentials, für ein ungültiges Attribut 31, für eine ungültige
        EID und mit ungültigem keyRef 19, die jeweils mit Fehlercode
        beantwortet werden sollen. Die Verwendung korrekter Authenticators ist
        Bestandteil der Testprüfung.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den
        GET\_STAMPED-Befehl korrekt handhabt.

*    *   DSRC\_A0SE\_BV02\_0010

    *   Für diesen Testfall wird der keyRef-Wert 2 benutzt. Die Bake führt
        eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein
        GET\_STAMPED.rq für ein geeignetes Attribut 32, das regulär
        beantwortet werden soll. Dann sendet sie jeweils ein GET\_STAMPED.rq
        mit ungültigen accesssCredentials, für ein ungültiges Attribut 31, für
        eine ungültige EID und mit ungültigem keyRef 19, die jeweils mit
        Fehlercode beantwortet werden sollen. Die Verwendung korrekter
        Authenticators ist Bestandteil der Testprüfung.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den
        GET\_STAMPED-Befehl korrekt handhabt.

*    *   DSRC\_A0SE\_BV03\_0010

    *   Für diesen Testfall wird der keyRef-Wert 3 benutzt. Die Bake führt
        eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein
        GET\_STAMPED.rq für ein geeignetes Attribut 32, das regulär
        beantwortet werden soll. Dann sendet sie jeweils ein GET\_STAMPED.rq
        mit ungültigen accesssCredentials, für ein ungültiges Attribut 31, für
        eine ungültige EID und mit ungültigem keyRef 19, die jeweils mit
        Fehlercode beantwortet werden sollen. Die Verwendung korrekter
        Authenticators ist Bestandteil der Testprüfung.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den
        GET\_STAMPED-Befehl korrekt handhabt.

*    *   DSRC\_A0SE\_BV04\_0010

    *   Für diesen Testfall wird der keyRef-Wert 4 benutzt. Die Bake führt
        eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein
        GET\_STAMPED.rq für ein geeignetes Attribut 32, das regulär
        beantwortet werden soll. Dann sendet sie jeweils ein GET\_STAMPED.rq
        mit ungültigen accesssCredentials, für ein ungültiges Attribut 31, für
        eine ungültige EID und mit ungültigem keyRef 19, die jeweils mit
        Fehlercode beantwortet werden sollen. Die Verwendung korrekter
        Authenticators ist Bestandteil der Testprüfung.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den
        GET\_STAMPED-Befehl korrekt handhabt.

*    *   DSRC\_A0SE\_BV05\_0010

    *   Für diesen Testfall wird der keyRef-Wert 5 benutzt. Die Bake führt
        eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein
        GET\_STAMPED.rq für ein geeignetes Attribut 32, das regulär
        beantwortet werden soll. Dann sendet sie jeweils ein GET\_STAMPED.rq
        mit ungültigen accesssCredentials, für ein ungültiges Attribut 31, für
        eine ungültige EID und mit ungültigem keyRef 19, die jeweils mit
        Fehlercode beantwortet werden sollen. Die Verwendung korrekter
        Authenticators ist Bestandteil der Testprüfung.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den
        GET\_STAMPED-Befehl korrekt handhabt.

*    *   DSRC\_A0SE\_BV06\_0010

    *   Für diesen Testfall wird der keyRef-Wert 6 benutzt. Die Bake führt
        eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein
        GET\_STAMPED.rq für ein geeignetes Attribut 32, das regulär
        beantwortet werden soll. Dann sendet sie jeweils ein GET\_STAMPED.rq
        mit ungültigen accesssCredentials, für ein ungültiges Attribut 31, für
        eine ungültige EID und mit ungültigem keyRef 19, die jeweils mit
        Fehlercode beantwortet werden sollen. Die Verwendung korrekter
        Authenticators ist Bestandteil der Testprüfung.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den
        GET\_STAMPED-Befehl korrekt handhabt.

*    *   DSRC\_A0SE\_BV07\_0010

    *   Für diesen Testfall wird der keyRef-Wert 7 benutzt. Die Bake führt
        eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein
        GET\_STAMPED.rq für ein geeignetes Attribut 32, das regulär
        beantwortet werden soll. Dann sendet sie jeweils ein GET\_STAMPED.rq
        mit ungültigen accesssCredentials, für ein ungültiges Attribut 31, für
        eine ungültige EID und mit ungültigem keyRef 19, die jeweils mit
        Fehlercode beantwortet werden sollen. Die Verwendung korrekter
        Authenticators ist Bestandteil der Testprüfung.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den
        GET\_STAMPED-Befehl korrekt handhabt.

*    *   DSRC\_A0SE\_BV08\_0010

    *   Für diesen Testfall wird der keyRef-Wert 8 benutzt. Die Bake führt
        eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein
        GET\_STAMPED.rq für ein geeignetes Attribut 32, das regulär
        beantwortet werden soll. Dann sendet sie jeweils ein GET\_STAMPED.rq
        mit ungültigen accesssCredentials, für ein ungültiges Attribut 31, für
        eine ungültige EID und mit ungültigem keyRef 19, die jeweils mit
        Fehlercode beantwortet werden sollen. Die Verwendung korrekter
        Authenticators ist Bestandteil der Testprüfung.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den
        GET\_STAMPED-Befehl korrekt handhabt.

*    *   DSRC\_A1BA\_BI01\_0010

    *   Die Bake sendet eine BST mit einem profile 13 (hex D), das von der
        OBU/dem DSRC-Modul nicht unterstützt wird. Die OBU/das DSRC-Modul soll
        nicht antworten. Das wird wiederholt mit einem weiteren von der OBU
        nicht unterstützten profile 17 (hex 11) wiederholt.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul das Profil
        korrekt handhabt.

*    *   DSRC\_A1BA\_BI02\_0010

    *   Die Bake sendet BSTs für die von der OBU nicht unterstütze Anwendung
        19 (hex 13) in der mandApplicationList und leerer
        nonmandApplicationList. Die OBU soll nicht antworten. Das wird
        wiederholt mit einer weiteren von der OBU nicht unterstützten
        Anwendung 31 (hex 1F) in der mandApplicationList und 19 in der
        nonmandApplicationList.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul
        applicationIds korrekt handhabt.

*    *   DSRC\_A1BA\_BI03\_0011

    *   Die Bake sendet BSTs für eine von der OBU/dem DSRC-Modul nicht
        unterstütze Anwendung 19 (hex 13) mit EID in der mandApplicationList
        und AID=20 in der nonmandApplicationList. Die OBU/das DSRC-modul soll
        nicht antworten.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul
        applicationIds korrekt handhabt.

*    *   DSRC\_A1BA\_BV01\_0010

    *   Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend
        sendet sie ein ECHO.rq, das die OBU/das DSRC-Modul beantworten soll.
        Dann wiederholt sie ihre BST (evtl. mit neuer BeaconTime, wenn diese
        sich mittlerweile verändert hat), die die OBU nicht beantworten soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul die
        Initialisierung korrekt durchführt.

*    *   DSRC\_A1BA\_BV02\_0010

    *   Die Bake führt eine reguläre Initialisierungsphase für AIDs 1, 20 und
        21 durch. Anschließend sendet sie ein ECHO.rq, das die OBU beantworten
        soll, und zwei RELEASEs. Dann schickt sie ein weiteres ECHO, das die
        OBU nicht beantworten soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul die
        Initialisierung korrekt durchführt.

*    *   DSRC\_A1BA\_BV03\_0010

    *   Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend
        sendet sie ein ECHO.rq, das die OBU beantworten soll. Der ganze
        Vorgang wird einmal wiederholt mit um 1 erhöhter manufacturerID in der
        BST und dann nochmals wiederholt mit der vorigen, erhöhten
        manufacturerID und um 1 erhöhter individualId der BST.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul die
        Initialisierung korrekt durchführt.

*    *   DSRC\_A1BA\_BV04\_0010

    *   Die Bake führt eine reguläre Initialisierungsphase für AIDs 1, 20 und
        21 durch. Anschließend sendet sie ein ECHO.rq, das die OBU beantworten
        soll. Der ganze Vorgang wird wiederholt, wobei die Beacon Time der BST
        um 256 Sekunden erhöht wird.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul die
        Initialisierung korrekt durchführt.

*    *   DSRC\_A1BA\_BV09\_0010

    *   Die Bake sendet eine BST mit einem profile 13 (hex D), das von der OBU
        nicht unterstützt wird. Die OBU soll nicht antworten. Das wird mit
        einem weiteren von der OBU nicht unterstützten profile 17 (hex 11)
        wiederholt.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul das Profil
        korrekt handhabt.

*    *   DSRC\_A1BA\_BV10\_0010

    *   Die Bake führt eine reguläre Initialisierungsphase für AIDs 1, 20 und
        21 durch. Die VST wird auf ein korrektes Format hin überprüft.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul die BST mit
        einer korrekten VST beantwortet.

*    *   DSRC\_A1DA\_BI01\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie jeweils ein SET.rq für Attribute 16, 17, 18,
        19, 20, 22, 46, 48, 55, 60, 62 und 63, das jeweils mit Fehlercode
        beantwortet werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul
        schreibgeschützte Attribute nicht ändert, auch wenn sie mittels SET
        dazu aufgefordert wird.

*    *   DSRC\_A1DA\_BI02\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie ein SET.rq für Attribute 16, 17, 18, 19, 20,
        22, 46, 48, 55, 60, 62 und 63, das mit Fehlercode beantwortet werden
        soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul
        schreibgeschützte Attribute nicht ändert, auch wenn sie mittels SET
        dazu aufgefordert wird.

*    *   DSRC\_A1DA\_BI03\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie ein SET.rq für Attribute 0, 24 und 32, das mit
        Fehlercode beantwortet werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul
        schreibgeschützte Attribute nicht ändert, auch wenn sie mittels SET
        dazu aufgefordert wird.

*    *   DSRC\_A1DA\_BI04\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie jeweils ein SET.rq für Attribute 0, 24 und 32,
        das jeweils mit Fehlercode beantwortet werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul
        schreibgeschützte Attribute nicht ändert, auch wenn sie mittels SET
        dazu aufgefordert wird.

*    *   DSRC\_A1DA\_BI05\_5010

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie ein gemeinsames SET.rq für Attribute 49, 50,
        51, 52, 53, 61, 64, und ein weiteres gemeinsames SET.rq für die
        Attribute 99, 100 und 101, die mit Fehlercode beantwortet werden
        sollen.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul
        schreibgeschützte Attribute nicht ändert, auch wenn sie mittels SET
        dazu aufgefordert wird.

*    *   DSRC\_A1DA\_BI06\_5010

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie jeweils ein SET.rq für Attribute 49, 50, 51,
        52, 53, 61, 64, 99, 100 und 101, das mit Fehlercode beantwortet werden
        soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul
        schreibgeschützte Attribute nicht ändert, auch wenn sie mittels SET
        dazu aufgefordert wird.

*    *   DSRC\_A1DA\_BI07\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie ein GET.rq mit ungültigen accessCredentials
        für Attribute 24 und 32, das mit Fehlercode beantwortet werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul
        lesegeschützte Attribute nicht zurückgibt, wenn sie mittels GET dazu
        aufgefordert wird.

*    *   DSRC\_A1DA\_BI08\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie ein GET.rq mit ungültigen accessCredentials
        für Attribute 16, 17, 18, 19, 20, 22, 46, 48, 55, 60, 62 und 63, das
        mit Fehlercode beantwortet werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul
        lesegeschützte Attribute nicht zurückgibt, wenn sie mittels GET dazu
        aufgefordert wird.

*    *   DSRC\_A1DA\_BI09\_5010

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie ein gemeinsames GET.rq mit ungültigen
        accessCredentials für Attribute 49, 50, 51, 52, 53, 61, 64, und ein
        weiteres gemeinsames GET.rq mit ungültigen accessCredentials für die
        Attribute 99, 100 und 101, die mit Fehlercode beantwortet werden
        sollen.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul keine
        Attributwerte zurückgibt, wenn die AccessCredentials nicht korrekt
        sind.

*    *   DSRC\_A1DA\_BI10\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie ein
        GET\_STAMPED.rq mit ungültigen accessCredentials für Attribute 24 und
        32,
        das mit Fehlercode beantwortet werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul
        lesegeschützte Attribute nicht zurückgibt, wenn sie mittels
        GET\_STAMPED dazu aufgefordert wird.

*    *   DSRC\_A1DA\_BI11\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie ein
        GET\_STAMPED.rq mit ungültigen accessCredentials für Attribute 16, 17,
        18, 19, 20, 22, 46, 48, 55, 60, 62 und 63, das mit Fehlercode
        beantwortet werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul
        lesegeschützte Attribute nicht zurückgibt, wenn sie mittels
        GET\_STAMPED dazu aufgefordert wird.

*    *   DSRC\_A1DA\_BI12\_5010

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie ein gemeinsames GET-STAMPED.rq mit ungültigen
        accessCredentials für Attribute 49, 50, 51, 52, 53, 61, 64, und ein
        weiteres gemeinsames GET-STAMPED.rq mit ungültigen accessCredentials
        für die Attribute 99, 100 und 101, die mit Fehlercode beantwortet
        werden sollen.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul keine
        Attributwerte zurückgibt, wenn die AccessCredentials nicht korrekt
        sind.

*    *   DSRC\_A1DA\_BV01\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie ein GET.rq für Attribute 24 und 32, das
        ordnungsgemäß beantwortet werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET-
        Befehl korrekt handhabt.

*    *   DSRC\_A1DA\_BV02\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie ein GET.rq für
        Attribut 24, das ordnungsgemäß beantwortet werden soll. Dann sendet
        sie ein GET.rq für Attribut 32, das ordnungsgemäß beantwortet werden
        soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET-
        Befehl korrekt handhabt.

*    *   DSRC\_A1DA\_BV03\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie ein GET.rq für Attribute 16, 17, 18, 19, 20,
        22, 46, 48, 55, 60, 62 und 63, das ordnungsgemäß beantwortet werden
        soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET-
        Befehl korrekt handhabt.

*    *   DSRC\_A1DA\_BV04\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie jeweils ein GET.rq für Attribute 16, 17, 18,
        19, 20, 22, 46, 48, 55, 60, 62 und 63, das ordnungsgemäß beantwortet
        werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET-
        Befehl korrekt handhabt.

*    *   DSRC\_A1DA\_BV05\_5010

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie ein gemeinsames GET.rq für Attribute 49, 50,
        51, 52, 53, 61, 64, und ein weiteres gemeinsames GET.rq für die
        Attribute 99, 100 und 101, das ordnungsgemäß beantwortet werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET-
        Befehl korrekt handhabt.

*    *   DSRC\_A1DA\_BV06\_5010

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie jeweils ein GET.rq für Attribute 49, 50, 51,
        52, 53, 61, 64, 99, 100 und 101, das ordnungsgemäß beantwortet werden
        soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET-
        Befehl korrekt handhabt.

*    *   DSRC\_A1DA\_BV07\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie ein
        GET\_STAMPED.rq für Attribute 24 und 32, das ordnungsgemäß beantwortet
        werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den
        GET\_STAMPED-Befehl korrekt handhabt.

*    *   DSRC\_A1DA\_BV09\_5010

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie ein gemeinsames GET-STAMPED.rq für Attribute
        49, 50, 51, 52, 53, 61, 64, und ein weiteres gemeinsames GET-
        STAMPED.rq für die Attribute 99, 100 und 101, das ordnungsgemäß
        beantwortet werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den
        GET\_STAMPED-Befehl korrekt handhabt.

*    *   DSRC\_A1DA\_BV10\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch.
        Anschließend sendet sie ein
        GET\_STAMPED.rq für Attribute 16, 17, 18, 19, 20, 22, 46, 48, 55, 60,
        62 und 63, das ordnungsgemäß beantwortet werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den
        GET\_STAMPED-Befehl korrekt handhabt.

*    *   DSRC\_A1FU\_BI02\_0010

    *   Die Bake führt vorab eine reguläre Initialisierungsphase durch, um die
        Bereitschaft der OBU zur Kommunikation zu überprüfen. Anschließend
        sendet sie je eine BST mit PDU-Nummern 0 und 1, die von der OBU nicht
        beantwortet werden sollen.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul PDU-Nummern
        korrekt erkennt.

*    *   DSRC\_A1FU\_BI03\_0010

    *   Die Bake führt eine reguläre Initialisierungsphase durch. Dann sendet
        sie je eine PDU mit mode=1 und flow control=7 und allen ungültigen
        Werten des Fragmentzählers, die von der OBU nicht beantwortet werden
        sollen. Abschließend sendet sie eine PDU mit mode=1 und flow control=7
        und dem gültigen Wert des Fragmentzählers (0), die von der OBU
        beantwortet werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul PDU-
        Fragmente korrekt erkennt.

*    *   DSRC\_A1FU\_BI04\_0010

    *   Die Bake sendet je eine BST mit allen ungültigen Werten des
        Fragmentzählers, die von der OBU nicht beantwortet werden sollen.
        Abschließend führt sie eine reguläre Initialisierung durch, um zu
        überprüfen, dass die OBU noch korrekt reagiert.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul PDU-
        Fragmente korrekt erkennt.

*    *   DSRC\_A1FU\_BI06\_0010

    *   Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend
        sendet sie "chained" PDUs in einem Rahmen, von denen die erste einen
        Fehler erzeugen und die zweite mit "chaining error" beantwortet werden
        soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul PDU-Nummern
        korrekt erkennt.

*    *   DSRC\_A1FU\_BV01\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend
        sendet sie ein GET.rq für ein geeignetes Attribut, das ordnungsgemäß
        beantwortet werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET-
        Befehl korrekt handhabt.

*    *   DSRC\_A1FU\_BV08\_0010

    *   Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend
        sendet sie ein ACTION.rq mit mode=1 und FlowControl=7 (zum Beispiel
        ECHO), das ordnungsgemäß beantwortet werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den ACTION-
        Befehl korrekt handhabt.

*    *   DSRC\_A1FU\_BV09\_0010

    *   Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend
        sendet sie ein ACTION.rq mit mode=0 und FlowControl=4 (zum Beispiel
        SET\_MMI). Der Tester überprüft, ob die OBU das SET\_MMI ausführt.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den ACTION-
        Befehl korrekt handhabt.

*    *   DSRC\_A1FU\_BV10\_0010

    *   Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend
        sendet sie ein ACTION.rq mit mode=0 und FlowControl=1 (zum Beispiel
        SET\_MMI). Der Tester überprüft, ob die OBU das SET\_MMI ausführt.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den ACTION-
        Befehl korrekt handhabt.

*    *   DSRC\_A1FU\_BV11\_0010

    *   Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend
        sendet sie ein ACTION.rq mit mode=0 und FlowControl=1 (zum Beispiel
        SET\_MMI) an die Broadcast-LID. Der Tester überprüft, ob die OBU das
        SET\_MMI ausführt.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den ACTION-
        Befehl korrekt handhabt.

*    *   DSRC\_A1FU\_BV12\_0010

    *   Die Bake sendet ein ACTION.rq mit mode=0 und FlowControl=1 (zum
        Beispiel SET\_MMI) an die Broadcast-LID. Der Tester überprüft, ob die
        OBU das SET\_MMI ausführt.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den ACTION-
        Befehl korrekt handhabt.

*    *   DSRC\_A1FU\_BV13\_0010

    *   Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend
        sendet sie je ein ECHO.rq mit PDU number 2 bis 31, das jeweils
        ordnungsgemäß beantwortet werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul PDU-
        Fragmente korrekt erkennt.

*    *   DSRC\_A1FU\_BV14\_0010

    *   Die Bake führt eine reguläre Initialisierungsphase durch, wobei die
        OBU Anwendungen für zwei ElementIDs !=0 (EID1, EID2) anmelden soll.
        Dann sendet sie ECHO.rq mit jeweils neuen Daten für EID1, EID2, EID1
        und EID2, die jeweils ordnungsgemäß beantwortet werden sollen.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul in einer
        Transaktion PDUs für mehrere Elemente empfangen kann.

*    *   DSRC\_A1FU\_BV16\_0010

    *   Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend
        sendet sie "concatenated" (nicht "chained") PDUs in einem Rahmen, die
        jeweils ordnungsgemäß in einem Rahmen beantwortet werden sollen.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul PDU-
        Fragmente korrekt erkennt.

*    *   DSRC\_A1FU\_BV17\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend
        sendet sie ein GET.rq für ein geeignetes Attribut, das ordnungsgemäß
        beantwortet werden soll. Dann sendet sie ein GET.rq mit falschen
        AccessCredentials, das mit Fehlermeldung (ReturnStatus 1) beantwortet
        werden soll. Dann sendet sie jeweils ein
        GET.rq mit AttributeIdList mit nicht existierendem Attribut 31 und
        falscher EID, die jeweils mit Fehlermeldung (ReturnStatus !=0)
        beantwortet werden sollen.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET-
        Befehl korrekt handhabt.

*    *   DSRC\_A1FU\_BV19\_0011

    *   Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend
        sendet sie ein GET\_STAMPED.rq für ein geeignetes Attribut, das
        ordnungsgemäß beantwortet werden soll. Dann sendet sie jeweils ein
        GET\_STAMPED.rq mit falschen AccessCredentials, das mit Fehlermeldung
        (ReturnStatus 1) beantwortet werden soll. Dann sendet sie jeweils ein
        GET\_STAMPED.rq mit AttributeIdList mit nicht existierendem Attribut
        31, falscher EID und ungültigem Wert für den keyRef-Parameter 19, die
        jeweils mit Fehlermeldung
        (ReturnStatus !=0) beantwortet werden sollen.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den
        GET\_STAMPED-Befehl korrekt handhabt.

*    *   DSRC\_A1FU\_BV20\_0010

    *   Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend
        sendet sie ein SET\_MMI.rq mit mode=0 und flowControl=1, dessen
        Ausführung der Tester bestätigen soll. Dann sendet sie ein
        SET\_MMI.rq mit mode=0 und flowControl=4, dessen Ausführung der Tester
        bestätigen soll und das von der OBU korrekt beantwortet werden soll.
        Zuletzt sendet sie ein
        SET\_MMI.rq mit ungültigem ActionParameter, das mit Fehlermeldung
        (ReturnStatus !=0) beantwortet werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den
        SET\_MMI-Befehl korrekt handhabt.

*    *   DSRC\_A1FU\_BV21\_0010

    *   Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend
        sendet sie ein ECHO.rq mit mode=0. Dann sendet sie ein ECHO.rq mit
        mode=1 und flowControl=7, das von der OBU korrekt beantwortet werden
        soll. Zuletzt sendet sie ein ECHO.rq mit ungültigem ActionParameter,
        das mit Fehlermeldung (ReturnStatus !=0) beantwortet werden soll.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den ECHO-
        Befehl korrekt handhabt.

*    *   DSRC\_A1SE\_BV01\_0010

    *   Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen,
        dass die OBU kommunikationsbereit ist. Dann führt die Bake eine
        reguläre Initialisierungsphase durch. Anschließend sendet sie ein
        GET\_STAMPED.rq für ein geeignetes Attribut 32, das regulär
        beantwortet werden soll. Danach sendet sie jeweils ein GET\_STAMPED.rq
        mit ungültigen accesssCredentials, für ein ungültiges Attribut 31, für
        eine ungültige EID und mit ungültigem keyRef 19, die jeweils mit
        Fehlercode beantwortet werden sollen. Für diesen Testfall wird der
        keyRef-Wert 1 benutzt.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den
        GET\_STAMPED-Befehl korrekt handhabt.

*    *   DSRC\_A1SE\_BV02\_0010

    *   Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen,
        dass die OBU kommunikationsbereit ist. Dann führt die Bake eine
        reguläre Initialisierungsphase durch. Anschließend sendet sie ein
        GET\_STAMPED.rq für ein geeignetes Attribut 32, das regulär
        beantwortet werden soll. Danach sendet sie jeweils ein GET\_STAMPED.rq
        mit ungültigen accesssCredentials, für ein ungültiges Attribut 31, für
        eine ungültige EID und mit ungültigem keyRef 19, die jeweils mit
        Fehlercode beantwortet werden sollen. Für diesen Testfall wird der
        keyRef-Wert 1 benutzt.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den
        GET\_STAMPED-Befehl korrekt handhabt.

*    *   DSRC\_A1SE\_BV03\_0010

    *   Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen,
        dass die OBU kommunikationsbereit ist. Dann führt die Bake eine
        reguläre Initialisierungsphase durch. Anschließend sendet sie ein
        GET\_STAMPED.rq für ein geeignetes Attribut 32, das regulär
        beantwortet werden soll. Danach sendet sie jeweils ein GET\_STAMPED.rq
        mit ungültigen accesssCredentials, für ein ungültiges Attribut 31, für
        eine ungültige EID und mit ungültigem keyRef 19, die jeweils mit
        Fehlercode beantwortet werden sollen. Für diesen Testfall wird der
        keyRef-Wert 3 benutzt.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den
        GET\_STAMPED-Befehl korrekt handhabt.

*    *   DSRC\_A1SE\_BV04\_0010

    *   Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen,
        dass die OBU kommunikationsbereit ist. Dann führt die Bake eine
        reguläre Initialisierungsphase durch. Anschließend sendet sie ein
        GET\_STAMPED.rq für ein geeignetes Attribut 32, das regulär
        beantwortet werden soll. Danach sendet sie jeweils ein GET\_STAMPED.rq
        mit ungültigen accesssCredentials, für ein ungültiges Attribut 31, für
        eine ungültige EID und mit ungültigem keyRef 19, die jeweils mit
        Fehlercode beantwortet werden sollen. Für diesen Testfall wird der
        keyRef-Wert 4 benutzt.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den
        GET\_STAMPED-Befehl korrekt handhabt.

*    *   DSRC\_A1SE\_BV05\_0010

    *   Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen,
        dass die OBU kommunikationsbereit ist. Dann führt die Bake eine
        reguläre Initialisierungsphase durch. Anschließend sendet sie ein
        GET\_STAMPED.rq für ein geeignetes Attribut 32, das regulär
        beantwortet werden soll. Danach sendet sie jeweils ein GET\_STAMPED.rq
        mit ungültigen accesssCredentials, für ein ungültiges Attribut 31, für
        eine ungültige EID und mit ungültigem keyRef 19, die jeweils mit
        Fehlercode beantwortet werden sollen. Für diesen Testfall wird der
        keyRef-Wert 5 benutzt.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den
        GET\_STAMPED-Befehl korrekt handhabt.

*    *   DSRC\_A1SE\_BV06\_0010

    *   Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen,
        dass die OBU kommunikationsbereit ist. Dann führt die Bake eine
        reguläre Initialisierungsphase durch. Anschließend sendet sie ein
        GET\_STAMPED.rq für ein geeignetes Attribut 32, das regulär
        beantwortet werden soll. Danach sendet sie jeweils ein GET\_STAMPED.rq
        mit ungültigen accesssCredentials, für ein ungültiges Attribut 31, für
        eine ungültige EID und mit ungültigem keyRef 19, die jeweils mit
        Fehlercode beantwortet werden sollen. Für diesen Testfall wird der
        keyRef-Wert 6 benutzt.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den
        GET\_STAMPED-Befehl korrekt handhabt.

*    *   DSRC\_A1SE\_BV07\_0010

    *   Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen,
        dass die OBU kommunikationsbereit ist. Dann führt die Bake eine
        reguläre Initialisierungsphase durch. Anschließend sendet sie ein
        GET\_STAMPED.rq für ein geeignetes Attribut 32, das regulär
        beantwortet werden soll. Danach sendet sie jeweils ein GET\_STAMPED.rq
        mit ungültigen accesssCredentials, für ein ungültiges Attribut 31, für
        eine ungültige EID und mit ungültigem keyRef 19, die jeweils mit
        Fehlercode beantwortet werden sollen. Für diesen Testfall wird der
        keyRef-Wert 7 benutzt.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den
        GET\_STAMPED-Befehl korrekt handhabt.

*    *   DSRC\_A1SE\_BV08\_0010

    *   Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen,
        dass die OBU kommunikationsbereit ist. Dann führt die Bake eine
        reguläre Initialisierungsphase durch. Anschließend sendet sie ein
        GET\_STAMPED.rq für ein geeignetes Attribut 32, das regulär
        beantwortet werden soll. Danach sendet sie jeweils ein GET\_STAMPED.rq
        mit ungültigen accesssCredentials, für ein ungültiges Attribut 31, für
        eine ungültige EID und mit ungültigem keyRef 19, die jeweils mit
        Fehlercode beantwortet werden sollen. Für diesen Testfall wird der
        keyRef-Wert 8 benutzt.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den
        GET\_STAMPED-Befehl korrekt handhabt.

*    *   DSRC\_LLC\_\_BI01\_0010

    *   Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen,
        dass die OBU kommunikationsbereit ist. Dann sendet die Bake BSTs für
        AIDs 1, 20 und 21, bei der die beiden Füllbits im LLC-Kontrollfeld auf
        die ungültigen Werte 00, 01 und 10 gesetzt sind. 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 gesetzten Füllbits im
        LLC-Kontrollfeld erkennt und ignoriert.

*    *   DSRC\_LLC\_\_BI02\_0010

    *   Zunä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 einen ECHO-Befehl, bei dem ein halbes Byte
        entfernt wird. Die OBU soll nicht reagieren. Anschließend wird mit
        einem korrekten ECHO-Befehl überprüft, ob die OBU noch korrekt
        reagiert.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen
        Rahmen mit nicht ganzzahliger Anzahl von Bytes erkennt und ignoriert.

*    *   DSRC\_LLC\_\_BI03\_0010

    *   Zunä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 ECHO-Befehle mit P-Bit=1, aber allen
        ungültigen Werten der modifier-Bits. Die OBU soll nicht reagieren.
        Dann sendet sie ECHO-Befehle mit P-Bit=1, aber allen ungültigen Werten
        der reserved-Bits. Die OBU soll nicht reagieren. Abschließend wird mit
        einem korrekten ECHO-Befehl überprüft, ob die OBU noch korrekt
        reagiert.

    *   Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen
        Rahmen mit ungültigen modifier- und reserved-Bits im LLC-Kontrollfeld
        erkennt und ignoriert.

*    *   DSRC\_LLC\_\_BI04\_0010

    *   Zunä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 der LID 0xFF, das die OBU
        nicht beantworten soll. Danach sendet sie ECHO.rq an alle Multicast-
        LIDs, die die OBU ebenfalls nicht beantworten soll. Nach jedem
        ungültigen Rahmen 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-Rahmen
        mit Broadcast- oder Multicast-LID ignoriert.

*    *   DSRC\_LLC\_\_BI05\_0010

    *   Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen,
        dass die OBU kommunikationsbereit ist. Dann sendet die Bake BSTs für
        AIDs 1, 20 und 21, bei der in der Nachricht ein halbes Byte fehlt. 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 nicht ganzzahliger Anzahl von Bytes erkennt und ignoriert.

*    *   DSRC\_LLC\_\_BI06\_0010

    *   Zunä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\_0010

    *   Zunä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\_0010

    *   Zunä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-Modul
        UI-Befehle austauschen kann.

*    *   DSRC\_LLC\_\_BV02\_0010

    *   Zunä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\_0010

    *   Zunä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\_0010

    *   Zunä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\_0010

    *   Zunä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\_0010

    *   Zunä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\_0010

    *   Zunä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\_0010

    *   Zunä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\_0010

    *   Zunä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\_0010

    *   Zunä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\_0010

    *   Zunä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\_0010

    *   Zunä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\_0010

    *   Zunä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 das
        A-Bit im MAC-Kontrollfeld beachtet.

*    *   DSRC\_MAC\_\_BI10\_0010

    *   Zunä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\_0010

    *   Zunä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\_0010

    *   Zunä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\_0010

    *   Zunä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\_0010

    *   Zunä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\_0010

    *   Zunä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\_0010

    *   Zunä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\_0010

    *   Zunä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\_0010

    *   Zunä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\_0010

    *   Zunä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\_0010

    *   Zunä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\_0010

    *   Zunä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 das
        A-Bit im MAC-Kontrollfeld beachtet.

*    *   DSRC\_MAC\_\_BI22\_0010

    *   Zunä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 das
        A-Bit im MAC-Kontrollfeld beachtet.

*    *   DSRC\_MAC\_\_BI23\_0010

    *   Zunä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\_0010

    *   Zunä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\_0010

    *   Zunä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\_0010

    *   Zunä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\_0010

    *   Zunä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\_0010

    *   Zunä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\_0010

    *   Zunä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\_0010

    *   Zunä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\_0010

    *   Zunä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 des
        s-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\_0010

    *   Zunä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\_0010

    *   Zunä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\_5010

    *   Die 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\_0010

    *   Eine 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\_5010

    *   Eine 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\_5011

    *   Eine 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\_0010

    *   Zunä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 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 durchgeführt, ein
            ECHO.rq (Poll Bit=1) gesendet, das beantwortet werden soll, und
            anschließend mit einem
            EVENT-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\_0010

    *   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 mit mode=1 und FlowControl=2 konfiguriert und
            aktiviert.

        •   Danach sendet die Bake ein ECHO.rq
            Befehl, 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\_0010

    *   Zunä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\_0010

    *   Eine 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-Transaktion
            durch. 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-Transaktion
            durch. Aus dem Transaktionslog werden die Attribute 53, 61, 99 und 100
            zur Auswertung ausgelesen. Es wird erwartet, dass der Zustand in
            noGoUserSwitchOff-3 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 noGoUserSwitchOff-3 ist.

        –   Der Benutzer wird aufgefordert die Stromversorgung einzuschliessen.

        –   Die Bake führt eine CCC-Transaktion
            durch. 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\_0010

    *   Eine 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\_0010

    *   Eine 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\_0010

    *   Eine 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\_0010

    *   Eine 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\_0010

    *   Zunä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\_0010

    *   Zunä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\_5010

    *   Eine 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(SST301
            v3.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\_5010

    *   Zunä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\_5015

    *   Zunä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\_5020

    *   Zunä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 einer
            neuen 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 15s

            2.  CCC:2019(SST301 v3.1)-Transaktionen für Max 15s

            3.  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\_5010

    *   Zunä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\_5020

    *   Zunä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\_5030

    *   Zunä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 15s

            2.  CCC:2019(SST301 v3.1)-Transaktionen für Max 15s

            3.  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 15s

            2.  CCC:2019(SST301 v3.1)-Transaktionen für Max 15s

            3.  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\_5010

    *   Eine 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\_5010

    *   Das 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\_5010

    *   Das 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\_5010

    *   Das 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\_5010

    *   Zunä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 der
        2\. 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.

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

*    *   Name/ID

    *   Beschreibung

    *   Ziel

*    *   AutoKST\_SVF\_FG06AV

    *   Fahrzeuggeräte von neuen EETS-Providern 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.
        Für die Kommunikation mit den EETS-Fahrzeuggeräten müssen die
        Kontrollstellen neben der Gebietsvorgaben V2.1/2.2 auch die Vorgaben
        der Version 3.0/3.1 unterstützen. Anhand der ContextMark kann die
        Kontrollstelle entscheiden, ob die weitere Kommunikation nach den
        neuen Gebietsvorgaben 3.0/3.1 zu erfolgen hat oder nicht.

    *   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
        Version 3.0/3.1).

*    *   AutoKST\_SVF\_ FG06AV\_2xFzG

    *   Der 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).
        Für die Kommunikation mit den EETS-Fahrzeuggeräten müssen die
        Kontrollstellen neben der Gebietsvorgaben V2.1/2.2 auch die Vorgaben
        der Version 3.0/3.1 unterstützen.
        Anhand der ContextMark kann die Kontrollstelle entscheiden, ob die
        weitere Kommunikation nach den neuen Gebietsvorgaben 3.0/3.1 zu
        erfolgen hat oder nicht.

    *   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 (Version 3.0/3.1).

*    *   AutoKST\_SVF\_FG07\_
        mautfreier\_Modus

    *   Fahrzeuggeräte von neuen EETS-Providern 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 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.
        Für die Kommunikation mit den EETS-Fahrzeuggeräten müssen die
        Kontrollstellen neben der Gebietsvorgaben V2.1/2.2 auch die Vorgaben
        der Version 3.0 unterstützen.
        Anhand der ContextMark kann die Kontrollstelle entscheiden, ob die
        weitere Kommunikation nach den neuen Gebietsvorgaben
        3\.0/3.1 zu erfolgen hat oder nicht.

    *   Ein Test-LKW mit Test-FzG, welches sich im mautfreien Modus befindet,
        erzeugt eine Fallgruppe 7.

        •   Auswertung nach SST 301 v.3.0/3.1 durch
            Attribut ExtendedOBUStatusHistoryPart1.

        •   Korrekte und vollständige DSRC-Daten (gemäß SST-Spezifikation 301
            Version 3.0/3.1).

*    *   AutoKST\_SVF\_FG12

    *   Fahrzeuggeräte von neuen EETS-Providern 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 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.
        Für die Kommunikation mit den EETS-Fahrzeuggeräten müssen die
        Kontrollstellen neben der Gebietsvorgaben V2.1/2.2 auch die Vorgaben
        der Version 3.0/3.1 unterstützen.
        Anhand der ContextMark kann die Kontrollstelle entscheiden, ob die
        weitere Kommunikation nach den neuen Gebietsvorgaben
        3\.0/3.1 zu erfolgen hat oder nicht.

    *   Ein LKW mit einem eingebauten FzG, welches gesperrt ist, erzeugt eine
        FG 12
        Auswertung nach SST 301 v.3.0/3.1 durch Attribut
        ExtendedOBUStatusHistoryPart1: FzG-Status
        "noGoContractual" oder "noGoPaymentMeans" (Parameter entsprechen der
        jeweiligen Testkonfiguration)".

        •   Korrekte und vollständige DSRC-Daten
            (gemäß SST-Spezifikation 301 Version 3.0/3.1).

*    *   AutoKST\_SVF\_FG16

    *   Fahrzeuggeräte von neuen EETS-Providern 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.
        Der 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ändige DSRC-Daten (gemäß SST-Spezifikation 301
        Version 3.0/3.1).
        Die Falldaten werden nicht an die KonZ\_2.0 verschickt und in der
        Test-Kontrollstelle gelöscht.

*    *   AutoKST\_
        Verifikation\_EETS\_
        Masterkey

    *   Fahrzeuggeräte von neuen EETS-Providern durchlaufen eine
        Gebrauchstauglichkeitsprüfung (GTP). Im Rahmen des
        Kompatibilitätstests wird die Umsetzung der funktionalen Anforderungen
        an die EETS-Fahrzeuggeräte in einem E2E-Szenario überprüft.
        In 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 Version 3.0/3.1).

*    *   KonB\_DezKst\_SVF\_FG

    *   Fahrzeuggeräte von neuen EETS-Providern 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.
        Ein Test-LKW passiert eine Kontrollstelle und ein Verdachtsfall wird
        angelegt. Dieser Verdachtsfall wird in der KonZ2.0 mit der passenden
        Fallgruppe gespeichert.

    *   Sicherstellung, dass der Kontrollfall aus der KonZ\_2.0 korrekt in der
        KonB ankommt.
        Gewährleistung Interoperabilität Kontrollstelle zu weiterführenden
        Systemen.

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

    *

*    *   KonMa\_auswinken\_VKB

    *   Das Fahrzeug wird ausgewunken. Ein verkürzter Kontrollbericht (VKB,
        FG19) wird ohne weitere Kontrolle erstellt.

    *   Erfolgreiches Erstellen eines VKB (FG19).

*    *   KonMa\_KonZ\_2.0\_
        Berichte\_weiterverarbeiten\_
        in\_KonB

    *   Dieser 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\_Kontrolle

    *   Fahrzeuggeräte von neuen EETS-Providern 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.
        Aufgrund einer Erweiterung der DSRC-Schnittstelle muss die KonMa mit
        den DSRC-Formaten Gebietsvorgaben 2.1/2.2 und Gebietsvorgaben 3.0/3.1
        umgehen können.
        In diesem Testfall wird die Auslesung eines EETS-FzGs im Test-LKW mit
        einer KonMa im Modus mobile Kontrolle durchgeführt.
        Durchführung einer Mobile-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 Version 3.0/3.1).
        Die Fallgruppe wird durch die KonMa korrekt angezeigt.

*    *   KonMa\_Standkontrolle\_
        Start\_KB

    *   Fahrzeuggeräte von neuen EETS-Providern 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.
        Aufgrund einer Erweiterung der DSRC-Schnittstelle muss die KonMa mit
        den DSRC-Formaten Gebietsvorgaben 2.1/2.2 und Gebietsvorgaben 3.0/3.1
        umgehen können.
        In 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 Version 3.0/3.1).
        Es wird die Kontrollberichterstellung durchgeführt.

*    *   KonZ\_2.0\_DezKst\_SVF

    *   Fahrzeuggeräte von neuen EETS-Providern durchlaufen eine
        Gebrauchstauglichkeitsprüfung (GTP).
        Im Rahmen der Kompatibilitätstests wird die Umsetzung der funktionalen
        Anforderung an die EETS-Fahrzeuggeräte überprüft.
        Die 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.
        Aufgrund einer Erweiterung der DSRC-Schnittstelle muss die KonZ mit
        den DSRC-Formaten Gebietsvorgaben 2.1/2.2 und Gebietsvorgaben 3.0/3.1
        umgehen können.

    *   Ü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 Version 3.0/3.1).

Bundesrepublik Deutschland
vertreten durch das
Bundesministerium für Digitales und Verkehr (BMDV)
dieses vertreten durch das

Source: https://www.gesetze-im-internet.de/eemd-zvanl_i/__29.html
Directory: eemd-zvanl_i
Level: 3.0