Legalize
Legalize / Deutschland / Bundesgesetz

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

Typ Bundesgesetz
Veröffentlichung 2018-03-20
Letzte Aktualisierung 2026-04-04
Status In Kraft
Ministerium BMJ (Bundesministerium der Justiz)
Quelle gesetze-im-internet.de
Artikel 58
Änderungshistorie JSON API

Der EETS-Anbieter übermittelt dem Mauterheber eine Liste der am Pilotbetrieb teilnehmenden Fahrzeuge bzw. Bordgeräte. In der Liste kennzeichnet der EETS-Anbieter für welche Bordgeräte eine Einwilligung zur temporären Aufbewahrung und Verarbeitung der Fahrspuren zum Zwecke der Qualitätssicherung während des Pilotbetriebs vorliegt.

Mauterheber und EETS-Anbieter sorgen dafür, dass die jeweils genannten Verantwortlichen für den gesamten Pilotbetrieb zur Verfügung stehen. Im Pilotbetrieb werden die Wirkbetriebsumgebungen des EETS-Anbieters und des Mauterhebers verwendet.

Dabei gelten insbesondere die folgenden Randbedingungen des Wirkbetriebs:

1.

Alle Schnittstellen des EETS-Anbieters zu Dritten sind in Betrieb (zum Beispiel Banken, Kreditkartengesellschaften, Erfüllungsstellen, Verrechnungsstellen, Kundenbetreuung).

2.

Das Teilsystem des EETS-Anbieters befindet sich im regulären Systembetrieb inklusive aller Betriebsprozesse, wie zum Beispiel Betrieb und Wartung zentraler und dezentraler Komponenten sowie Release- und Changemanagement.

3.

Es gelten die Regelungen der zwischen Mauterheber und EETS-Anbieter getroffenen EETS-Prüfvereinbarung.

4.

Die vertraglich vereinbarten SLAs zwischen EETS-Anbieter und Mauterheber sowie Dritten sind wirksam (zum Beispiel Durchlaufzeiten des Mauterhebungsdienstes).

5.

Es gelten die für den Wirkbetrieb vereinbarten Bestimmungen bzgl. Datenschutz und Datensicherheit.

6.

Es gelten die vereinbarten Fristen, wie zum Beispiel Wertstellungs- und Archivierungsfristen.

7.

Die Prüfungen werden durch Fahrten im gesamten mautpflichtigen Streckennetz durchgeführt.

8.

Der EETS-Anbieter ist für die Bereitstellung von technischen und personellen Ressourcen für die Durchführung des Pilotbetriebs verantwortlich, insbesondere für die Bereitstellung und Ausstattung der Nutzerreferenzgruppe sowie für die Wartung der Bordgeräte.

9.

Der EETS-Anbieter muss sicherstellen, dass produktive Bordgeräte, die nicht Teil seiner Nutzerreferenzgruppe sind, vor und während des Pilotbetriebs entweder keine DSRC-Kommunikation mit den Kontrolleinrichtungen des Mauterhebers durchführen, oder den Erhebungsstatus „nicht erhebungsbereit“ über DSRC übermitteln.

Vorgaben für die Nutzerreferenzgruppe:

1.

Anzahl der aktiven Fahrzeuge: mindestens 100 (im Durchschnitt über die Dauer des Pilotbetriebs)

2.

Fahrzeuge auf der Nutzerliste: maximal 2000 Fahrzeuge

3.

Verteilung der Bordgerätetypen: minimal 15 Fahrzeuge pro Gerätetyp

4.

In einem Fahrzeug der Nutzerreferenzgruppe darf jeweils nur ein Bordgerät des EETS-Anbieters installiert und erhebungsbereit sein

5.

Für die Bordgeräte der Nutzerreferenzgruppe sollte der EETS-Anbieter eine Einwilligung des Transportunternehmens einholen, die eine Aufbewahrung und Verarbeitung der Fahrspuren zum Zwecke der Qualitätssicherung durch den nationalen Mautbetreiber während des Pilotbetriebs ermöglicht

Vorgaben in Bezug auf die zu erreichenden Mengen:

1.

Anzahl der zu erreichenden DSRC-Kontakte mit Kontrolleinrichtungen des Mauterhebers: 6 000

2.

Umfang der Befahrung des mautpflichtigen Streckennetzes: 500 000 mautpflichtige Kilometer, davon mindestens 10% auf Bundesstraßen

3.

Die Zeitdauer des Pilotbetriebs beträgt mindestens drei Monate.

4.

Für den Fall, dass Bordgeräte eingesetzt werden, die auch über eine Smartphone-Applikation gesteuert werden können, müssen mindestens 500 Bordgeräte oder die Hälfte der auf der Nutzerliste aufgeführten Bordgeräte zumindest einmal im Pilotzeitraum über die Smartphone-Applikation bedient worden sein.

Sollten sich Änderungen an den mautbezogenen Rahmenbedingungen (mautpflichtiges Streckennetz, mautpflichtige Fahrzeuge) ergeben, behält sich der Mauterheber eine Anpassung des Mengengerüsts vor.

Der Pilotbetrieb ist ein laufender Betrieb mit Quotenermittlung. Er darf als Gesamtphase vom EETS-Anbieter nicht unterbrochen werden.

Der Mauterheber darf die Prüfung stoppen, falls begründete Zweifel an der Qualität der Prüfdaten und Prozesse bestehen.

Sollten im Rahmen des Pilotbetriebs eine negative Beeinflussung des Wirkbetriebs des Mauterhebers und/oder EETS-Teilsysteme anderer EETS-Anbieter oder eine Gefährdung der Mauteinnahmen festgestellt werden, kann der Mauterheber den Pilotbetrieb mit sofortiger Wirkung abbrechen.

Wird während der Prüfungen festgestellt, dass die Qualität oder Fahrleistung der Nutzerreferenzgruppe nicht ausreichend ist, ist der EETS-Anbieter verpflichtet, Maßnahmen zur Erhöhung der Qualität oder Fahrleistung zu ergreifen. Sollte dies nicht erfolgen, so kann der Mauterheber den Pilotbetrieb abbrechen.

6.3 Übersicht Prüfszenarien

Die in der folgenden Tabelle dargestellten Szenarien bilden die Grundlage für die Prüfungen, die im Rahmen des Programms zur Validierung durch Betriebsbewährung des Teilsystems des EETS-Anbieters abgedeckt und durchgeführt werden müssen.

PrüfszenarioBeschreibung

P3-001korrekte Mauterhebung

P3-002korrekte Abrechnung und Auskehr

P3-003Überwachung des EETS-Anbieters

P3-004Szenario ist entfallen

P3-005korrekte Kontrollprozesse

Tabelle 6: Liste der Prüfszenarien für Phase 3 – Pilotbetrieb

In den folgenden Abschnitten werden die einzelnen Prüfszenarien beschrieben.

6.3.1 P3-001 – korrekte Mauterhebung

ZielIn diesem Szenario wird geprüft, ob der Ende-zu-Ende Prozess der Mauterhebung bis zum Empfang der Mautbuchungsnachweise unter Wirkbetriebsbedingungen technisch funktioniert und fachlich korrekt erfolgt. Die Nutzerreferenzgruppe repräsentiert im Pilotbetrieb die Gruppe der späteren EETS-Nutzer und verhält sich wirkbetriebskonform. Insofern handelt es sich um ein vom Prüfvorgang unbeeinflusstes Fahr- und Nutzerverhalten.Wenn nach Ablauf der Mindestdauer des Pilotbetriebs das unbeeinflusste Fahrverhalten der Nutzerreferenzgruppe nicht ausgereicht hat die Vorgaben des Szenarios abzudecken, so kann in Abstimmung mit dem Mauterheber darüber entschieden werden, ob spezielle Prüffahrten durchzuführen sind, oder ob auf den Nachweis der Erfüllung der Vorgabe verzichtet werden kann.

VorbereitungVorbereitung des EETS-Anbieters1.Die Nutzerreferenzgruppe wird bereitgestellt2.Bereitstellung einer Liste mit den Fahrzeugen der Nutzerreferenzgruppe, die für die Teilnahme am automatischen Verfahren beim nationalen Mautbetreiber registriert sind3.Parallele Ausstattung einiger Fahrzeuge der Nutzerreferenzgruppe mit vom Mauterheber bereitgestellten Geräten für Referenzmessungen (nach Aufforderung durch den Mauterheber).4.Alle internen Prozesse des EETS-Anbieters sowie die Schnittstellen zum Mauterheber sind technisch und prozessual implementiert und wirkbetriebsbereit.5.Einrichtung eines Servicedesks zur Meldung von Incidents und Information des Mauterhebers und des nationalen Mautbetreibers über die Kommunikationswege und -prozesseVorbereitung des Mauterhebers1.Optional: Aufforderung zur Ausstattung einiger Fahrzeuge der Nutzerreferenzgruppe mit Geräten für Referenzmessungen inklusive Bereitstellung der Geräte.2.Alle internen Prozesse des Mauterhebers sowie die Schnittstellen zum EETS-Anbieter und zum nationalen Mautbetreiber sind technisch und prozessual implementiert und im Wirkbetrieb.Vorbereitung des nationalen Mautbetreibers1.Sperrung der Bordgeräte der Fahrzeuge der Nutzerreferenzgruppe, die beim nationalen Mautbetreiber registriert sind, um Doppelbemautung zu vermeiden2.Alle internen Prozesse des nationalen Mautbetreibers sowie die Schnittstellen zum EETS-Anbieter und zum Mauterheber sind technisch und prozessual implementiert und im Wirkbetrieb.3.Der EETS-Servicedesk wurde für den EETS-Anbieter eingerichtet und der EETS-Anbieter wurde über die Kommunikationswege und -prozesse informiert

DurchführungDie Nutzerreferenzgruppe fährt mit mautpflichtigen Fahrzeugen und Bordgeräten unter den Regeln für die Teilnahme am Wirkbetrieb (zum Beispiel Mitwirkungspflicht und korrekte Selbstdeklaration). Der EETS-Anbieter trägt dafür Sorge, dass die Nutzerreferenzgruppe bezüglich der Teilnahme am Pilotbetrieb ausreichend informiert ist.Der EETS-Anbieter überwacht die Nutzerreferenzgruppe hinsichtlich der Erfüllung der Prüfkriterien. Können die Kriterien nicht vollständig von der Nutzerreferenzgruppe abgedeckt werden, so können vom EETS-Anbieter zur Abdeckung dieser Prüfkriterien in Abstimmung mit dem Mauterheber besondere Nutzer eingesetzt werden.

BewertungDie Bewertung erfolgt auf Basis der Auswertung der erhobenen Daten. Die Prüfergebnisse werden vom EETS-Anbieter hinsichtlich der Erfüllung der Vorgaben des Prüfszenarios sowie der Prüfkriterien bewertet.Die Gesamtbewertung erfolgt abschließend durch den Mauterheber. Dabei umfasst die Prüfung mindestens, dass die vom EETS-Anbieter vorgelegten Prüfergebnisse hinsichtlich der Prüfkriterien abgeglichen, bewertet sowie dokumentiert werden.Einhaltung der folgenden Vorgaben für das Prüfszenario:1.Es sind alle Gewichts- und Achsklassen sowie mindestens zwei verschiedene Schadstoffklassen und zwei verschiedene CO2-Emissionsklassen abzudecken.2.Jedes Fahrzeug darf nur ein Bordgerät des EETS-Anbieters enthalten.3.Änderung der Achszahl durch Anhängen und Abkoppeln von Anhängern bzw. Wechsel eines Aufliegers bei einer Fahrtunterbrechung auf einem Rastplatz4.Übermittlung einer vollständigen Nutzerliste durch den EETS-Anbieter5.Übermittlung technisch korrekter und fachlich richtiger Fahrspuren an den MED über die Schnittstelle 0056.Vollständiger Empfang der Mautbuchungsnachweise über die SST007R durch den EETS-Anbieter7.eineindeutige Zuordnung von Kennzeichen (inklusive Nationalität) und Fahrzeug8.eineindeutige Zuordnung von Bordgerät zu Fahrzeug9.Erreichung der gemäß Zulassungsvertrag geforderten Quoten für:9.1.Erfassungsquote9.2.Sperrlistenquote9.3.Nutzerlistenquote9.4.Fahrspurquote

6.3.2 P3-002 – korrekte Abrechnung und Auskehr

ZielIn diesem Prüfszenario wird die korrekte Auskehr der Mautbeträge an den Mauterheber auf Einzeldatenbasis mit realen Fahrdaten geprüft.

VorbereitungVorbereitung des EETS-Anbieters1.Einrichten und Einbinden eines Abwicklungskontos2.Anbindung an den wirkbetrieblichen Zahlverkehr sowie an alle relevanten internen und externen SchnittstellenVorbereitung des Mauterhebers1.Alle internen Prozesse des Mauterhebers sowie die Schnittstellen zum EETS-Anbieter und zum nationalen Mautbetreiber sind technisch und prozessual implementiert und im Wirkbetrieb.

DurchführungDer EETS-Anbieter übermittelt regelmäßig die E-Mail (Ist-Auskehrbetrag) an den Mauterheber und erstellt und übermittelt regelmäßig die Tagesberichte und überweist den auszukehrenden Betrag auf das Abwicklungskonto. Die Zahlungseingänge müssen wirkbetriebskonform ablaufen und die reale Wertstellungsfrist berücksichtigen. Wenn eine Auskehr nach Ablauf der Wertstellungsfrist erfolgt, werden auch die anfallenden Zinsen korrekt berechnet, im Tagesbericht ausgewiesen und vollständig ausgekehrt.Das Prüfszenario wird mit realem Geldverkehr durchgeführt.

BewertungDie Bewertung erfolgt auf Basis der Auswertung der erhobenen Daten. Die Prüfergebnisse werden vom EETS-Anbieter hinsichtlich der Erfüllung der Vorgaben des Prüfszenarios sowie der Prüfkriterien bewertet. Die Gesamtbewertung erfolgt abschließend durch den Mauterheber. Dabei umfasst die Prüfung mindestens, dass die vom EETS-Anbieter vorgelegten Prüfergebnisse hinsichtlich der Prüfkriterien abgeglichen, bewertet sowie dokumentiert werden.Einhaltung der folgenden Vorgaben für das Prüfszenario:1.fachlich korrekte und vollständige Auskehr des Gesamtbetrags (Prüfung der Auskehr der Mauteinnahmen an den Mauterheber in voller Höhe über die gesamte Laufzeit im Pilotbetrieb durch einen Ordnungsmäßigkeits- und einen Vollständigkeitsnachweis: Prüfung der Tagesberichte gegen Mautbuchungsnachweise)2.korrekte Berücksichtigung der Wertstellungsfrist und Fälligkeit bei den Überweisungen auf das Abwicklungskonto3.korrekte Anwendung der Zinsberechnungsmethodik4.regelmäßige Erstellung und fristgerechte Übermittlung der E-Mail, mit dem Ist-Auskehrbetrag (jeweils am Stichtag der Auskehr bis 15:00 Uhr)5.regelmäßige Erstellung und fristgerechte Übermittlung des Tagesberichts (spätestens 15:00 Uhr am auf den Stichtag der Auskehr folgenden Werktag)

6.3.3 P3-003 – Überwachung des EETS-Anbieters

ZielZiel dieses Prüfszenarios ist es, einerseits die technisch und fachlich korrekte Durchführung der Überwachung des EETS-Anbieters und die Übermittlung der Informationen gemäß SST 013 zu prüfen, andererseits die Auswirkungen von möglichen Störungen im System des EETS-Anbieters auf den Mauterheber zu prüfen. Dazu werden folgende Bereiche überwacht:1.Prüfung des Monitorings und der Implementierung der Überwachungsprozeduren beim EETS-Anbieter in einem dauerhaften Regelbetrieb2.Prüfung der Anwendung der SST 013Es darf nicht simuliert werden. Es darf keine Datenbearbeitung und -extraktion erfolgen, wenn diese nicht in definierten, nachvollziehbaren Betriebsprozessen vorgesehen sind

VorbereitungVorbereitung des EETS-Anbieters1.Die Prozesse des EETS-Anbieters zur Überwachung und Bereitstellung von Überwachungsdaten (SST 013 Reports) sind definiert und übergreifend implementiert.

DurchführungWährend der gesamten Laufzeit des Pilotbetriebs führt der EETS-Anbieter unter Wirkbetriebsbedingungen ein Monitoring und eine Überwachung seines Systems durch. Der EETS-Anbieter erzeugt entsprechende Überwachungsreports und übermittelt diese über SST 013 an den Mauterheber.

BewertungDie Bewertung erfolgt auf Basis der Auswertung der erhobenen Daten. Die Prüfergebnisse werden vom EETS-Anbieter hinsichtlich der Erfüllung der Vorgaben des Prüfszenarios sowie der Prüfkriterien bewertet. Die Gesamtbewertung erfolgt abschließend durch den Mauterheber. Dabei umfasst die Prüfung mindestens, dass die vom EETS-Anbieter vorgelegten Prüfergebnisse hinsichtlich der Prüfkriterien abgeglichen, bewertet sowie dokumentiert werden.Einhaltung der folgenden Vorgaben für das Prüfszenario:1.Der EETS-Anbieter muss die Überwachungsdaten (Überwachungsreports) dem Mauterheber regelmäßig in korrekter und vollständiger Form über die SST 013 bereitstellen.2.Regulär auftretende Störungen im Pilotbetrieb wurden durch den EETS-Anbieter mit den definierten Mitteln überwacht, erfasst und ausgewertet.3.Die Überwachungsreports spiegeln mindestens die durch den Mauterheber wahrgenommenen Entwicklungen und Vorkommnisse (z.B. Störungen) im Teilsystem des EETS-Anbieters in korrekter Form wider.

6.3.4 P3-005 – korrekte Kontrollprozesse

ZielDie Korrektheit der Kontrollprozesse wird im Rahmen von Fahrten der Nutzerreferenzgruppe mit Kontrollen im realen Verkehr geprüft.Das Prüfszenario umfasst die Sachverhaltsermittlung (DSRC-Kommunikation des Bordgerätes mit den Kontrolleinrichtungen) und geht über die Sachverhaltsfeststellung bis zur Nacherhebung und Ahndung. Dies deckt einerseits den Prozess der Datenerhebung vom Bordgerät des EETS-Anbieters bis zum zentralseitigen Eingang beim Mauterheber ab. Weiterhin ist auch die notwendige Datenbereitstellung für die Zwecke der Ahndung und Nacherhebung (Fahrzeug-/Adressdaten, Bereitstellung Informationen zu weiteren Bordgeräten des EETS-Nutzers) davon umfasst. Berücksichtigt werden alle Einrichtungen der automatischen und der manuellen Kontrolle. Einrichtungen der Betriebskontrolle werden nicht berücksichtigt

VorbereitungVorbereitung des EETS-Anbieters1.Die Nutzerreferenzgruppe wird bereitgestellt.2.Alle internen Prozesse des EETS-Anbieters sowie die Schnittstellen zum Mauterheber sind technisch und prozessual implementiert und wirkbetriebsbereit.Vorbereitung des Mauterhebers1.Alle internen Prozesse des Mauterhebers sowie die Schnittstellen zum EETS-Anbieter und zum nationalen Mautbetreiber sind technisch und prozessual implementiert und im Wirkbetrieb.Vorbereitung des nationalen Mautbetreibers1.Alle internen Prozesse des nationalen Mautbetreibers sowie die Schnittstellen zum EETS-Anbieter und zum Mauterheber sind technisch und prozessual implementiert und im Wirkbetrieb.

DurchführungDie Nutzerreferenzgruppe des EETS-Anbieters befährt das mautpflichtige Streckennetz. Der EETS-Anbieter stellt über Schnittstelle 001 Sperrlisten bereit.Der Mauterheber führt alle relevanten Kontrollarten durch und ermittelt die dabei entstehenden Sachverhalte im Rahmen der übergreifenden Kontrollprozesse.Die Kontrolleure des Mauterhebers erfassen und dokumentieren dabei besondere Vorkommnisse und Auffälligkeiten in Bezug auf den Pilot-EETS-Anbieter (z.B. fortwährende Verbindungsabbrüche in der Kontrollkommunikation).Aufgenommene Kontrollfälle der EETS-Nutzer werden im Rahmen der Prozesse Nacherhebung und Ahndung beim Mauterheber verarbeitet. Für seine EETS-Nutzer stellt der EETS-Anbieter dem Mauterheber die Beteiligtendaten (Fahrzeug-/Adressdaten, Informationen zu weiteren Bordgeräten des EETS-Nutzers) über die Schnittstellen 002b und 002c bereit.

BewertungDie Bewertung erfolgt auf Basis der Auswertung der erhobenen Daten. Die Prüfergebnisse werden vom EETS-Anbieter hinsichtlich der Erfüllung der Vorgaben des Prüfszenarios sowie der Prüfkriterien bewertet.Die Gesamtbewertung erfolgt abschließend durch den Mauterheber. Dabei umfasst die Prüfung mindestens, dass die vom EETS-Anbieter vorgelegten Prüfergebnisse hinsichtlich der Prüfkriterien abgeglichen, bewertet sowie dokumentiert werden.Einhaltung der folgenden Vorgaben für das Prüfszenario:1.Technisch korrekte Kommunikation zwischen den Bordgeräten des EETS-Anbieters und den Kontrolleinrichtungen über die Schnittstelle 3012.Übermittlung fachlich korrekter Werte im Rahmen der DSRC-Kommunikation3.Technisch korrekte Kommunikation über die Schnittstelen 002b und 002c sowie Übermittlung korrekter Beteiligtendaten zur Unterstützung der Prozesse Nacherhebung und Ahndung des Mauterhebers4.Erreichung der gemäß Zulassungsvertrag geforderten DSRC-Quote

6.4 Quality Gate – QG4

Das Quality Gate 4 schreibt die Kriterien für die Ausgangsqualität des Teilsystems des EETS-Anbieters nach dem Pilotbetrieb vor.

Für das Bestehen des Pilotbetriebs gelten die in Abschnitt 2.8 genannten Kriterien. Im Pilotbetrieb werden die im Wirkbetrieb vorgesehenen Quoten und Qualitätsparameter ermittelt und bei der Feststellung des Prüfergebnisses berücksichtigt.

Anhang A - Vorgaben für Prüfprotokolle und -berichte

Dieser Anhang enthält die detaillierten Anforderungen an die Inhalte aller Protokolle und Berichte, die im Rahmen der Gebrauchstauglichkeitsprüfung zu erstellen sind.

Anhang A.1: Prüfprotokoll für den einzelnen Prüffall (Phase 1 und Phase 2)

Für jeden vom EETS-Anbieter durchgeführten Prüffall ist von ihm ein separates Prüfprotokoll zu erstellen, welches das abschließende Prüfergebnis dieses Prüffalls dokumentiert. Alle Detailinformationen zu den Prüfbedingungen und Ereignissen während der Prüfdurchführung müssen in das Prüfprotokoll aufgenommen werden.

Das Prüfprotokoll muss mindestens die folgenden Inhalte umfassen:

1.

eindeutige Referenznummer für das Prüfprotokoll

2.

Diese sollte sich zusammensetzen aus der Nummer des Prüffalls gemäß des entsprechenden Prüfkatalogs, einem eindeutigen Bezeichner des EETS-Anbieters und einem eindeutigen Suffix (zum Beispiel Zeitstempel).

3.

Datum der Fertigstellung des Prüfprotokolls

4.

Prüfzeitraum (Datum und Uhrzeit von Beginn und Ende der Prüfungen)

5.

Angabe des Prüfszenarios

6.

Angaben zum EETS-Anbieter inklusive Firmenname und Anschrift

7.

Angaben zum Verantwortlichen für die Durchführung der Prüfung und Erstellung des Prüfprotokolls

8.

Angaben zu den Teilnehmern an der Prüfung (vom EETS-Anbieter und vom Mauterheber)

9.

eindeutige Konfigurations- und Versionsbezeichnung aller beteiligten Teilsysteme des EETS-Anbieters (Zentralsystem und verwendete Bordgeräte)

10.

aktuelle Prüfbedingungen (Informationen zu eingesetzten Fahrzeugen, Bordgeräten und Systemen sowie zu Teststrecken und weiteren Umgebungsbedingungen)

11.

besondere Beobachtungen, die für Analyse und Auswertung sowie für die Bestimmung des Prüfergebnisses relevant sein könnten

12.

Ergebnis für die durchgeführten Prüffälle mit:

• festgestellten Übereinstimmungen mit den erwarteten Ergebnissen

• festgestellten Abweichungen von den erwarteten Ergebnissen inklusive Bewertung der festgestellten Abweichungen

• festgestellte Auffälligkeiten bei der Durchführung der Prüffälle inklusive Bewertung der festgestellten Auffälligkeiten

• Bewertungsvorschlag des EETS-Anbieters („bestanden", „bestanden mit Abweichungen/Auffälligkeiten“ oder „nicht bestanden“)

13.

abschließender Zusammenfassung des Prüfergebnisses

14.

Falls der Prüffall trotz festgestellter Abweichungen oder Auffälligkeiten als „bestanden“ eingestuft wird, müssen die Abweichungen oder Auffälligkeiten nach Aufforderung des Mauterhebers in Form einer Risikoanalyse bewertet und das Ergebnis begründet werden.

15.

digitale Unterschrift des Verantwortlichen für die Erstellung des Prüfprotokolls

Zusätzlich sollte das Prüfprotokoll ausreichend Platz vorsehen für:

1.

Kommentare des Mauterhebers, insbesondere zu der Bewertung der Prüfabdeckung und eventuell festgestellter Abweichungen sowie dem Prüfergebnis, inklusive Name des Kommentierenden

2.

Bewertung des Mauterhebers für einzelner Prüffälle

3.

digitale Unterschrift des Mauterhebers

Anhang A.2: Szenariobericht (nur Phase 3)

Für jedes Prüfszenario ist ein separater Szenariobericht zu erstellen, der das abschließende Prüfergebnis dieses Szenarios in Form einer Übersicht dokumentiert und mindestens die folgenden Inhalte umfasst:

1.

eindeutige Referenznummer für den Szenariobericht

2.

Diese sollte sich zusammensetzen aus der Nummer des Prüfszenarios, einem eindeutigen Bezeichner des EETS-Anbieters und einem eindeutigen Suffix (zum Beispiel Zeitstempel).

3.

Datum der Fertigstellung des Berichts

4.

Angabe des Prüfszenarios

5.

Angaben zum EETS-Anbieter inklusive Firmenname und Anschrift

6.

Angaben zum Verantwortlichen für die Erstellung des Prüfberichts

7.

eindeutige Konfigurations- und Versionsbezeichnung aller beteiligten Teilsysteme des EETS-Anbieters (Zentralsystem und verwendete Bordgeräte)

8.

Falls während der Prüfung mehr als eine Konfiguration oder Version der Teilsysteme des EETS-Anbieters zum Einsatz kam, sind hier alle Konfigurations- und Versionsbezeichnungen aufzuführen.

9.

eindeutige Konfigurations- oder Versionsbezeichnung des Mauterhebers

10.

Der Prüfbericht eine Übersicht aller Vorgaben des Prüfszenarios enthalten (vergleiche jeweils Zeilen „Bewertung“ in Kapitel 6.3). Für jede Vorgabe muss nachvollziehbar erläutert werden, in welcher Form und zu welchem Zeitpunkt sie durch das Fahrverhalten der Nutzerreferenzgruppe, durch die Prozesse im Teilsystem des EETS-Anbieters oder durch die Prozesse des Mauterhebers (z.B. im Kontrollbereich) erfüllt wurde. Für jede Vorgabe muss die Liste folgende Informationen enthalten:

• Beschreibung der Vorgabe

• Beschreibung der Art und Weise der Erfüllung

• Zeitpunkt der Erfüllung

• Beschreibung eventuell festgestellter Abweichungen

11.

abschließende Zusammenfassung des Prüfergebnisses für das Prüfszenario

12.

Falls das Prüfszenario trotz festgestellter Abweichungen in einzelnen Prüffällen oder trotz unvollständiger Abdeckung als „Bestanden“ eingestuft wird, müssen die Abweichungen in Form einer Risikoanalyse bewertet und das Ergebnis ausführlich begründet werden.

13.

gegebenenfalls Beschreibungen der Maßnahmen, mit denen die Abweichungen behoben werden sollen

14.

digitale Unterschrift des Verantwortlichen für die Erstellung des Szenarioberichts

Zusätzlich sollte der Szenariobericht ausreichend Platz vorsehen für:

1.

Kommentare des Mauterhebers, insbesondere zu der Bewertung der Prüfabdeckung und eventuell festgestellter Abweichungen sowie dem Prüfergebnis

2.

digitale Unterschrift des Mauterhebers

Anhang A.3: Abschlussbericht für jede Prüfphase

Für jede Prüfphase ist ein separater Abschlussbericht zu erstellen, der das abschließende Prüfergebnis dieser Phase dokumentiert. Der Abschlussbericht enthält eine Übersicht über alle in der Phase durchgeführten Prüfungen und Inspektionen und umfasst mindestens die folgenden Inhalte:

Generelle Inhalte für jede der Phasen 1 bis 3:

1.

eindeutige Referenznummer für den Abschlussbericht

2.

Diese sollte sich zusammensetzen aus der Bezeichnung der Prüfphase, einem eindeutigen Bezeichner des EETS-Anbieters und einem eindeutigen Suffix (zum Beispiel Zeitstempel).

3.

Datum der Fertigstellung des Berichts

4.

Angabe der Prüfphase

5.

Angaben zum EETS-Anbieter inklusive Firmenname und Anschrift

6.

Angaben zum Verantwortlichen für die Erstellung des Abschlussberichts

7.

sofern Inspektionen durchgeführt wurden:

8.

• erfolgreich abgeschlossen (Ja/Nein),

• eindeutige Referenznummer des zugeordneten Inspektionsberichtes

9.

abschließende Zusammenfassung des Prüfergebnisses für die Prüfphase

10.

Falls die Prüfphase trotz festgestellter Abweichungen, Auffälligkeiten oder unvollständiger Abdeckung in einzelnen Prüfszenarien als „Bestanden“ eingestuft wird, müssen die Abweichungen, Auffälligkeiten und der Abdeckungsgrad nach Aufforderung des Mauterhebers in Form einer Risikoanalyse bewertet und das Ergebnis ausführlich begründet werden.

11.

digitale Unterschrift des Verantwortlichen für die Erstellung des Abschlussberichts

Inhalte des Abschlussberichts für Phase 1:

1.

Übersicht über die Durchführung aller Prüffälle der Schnittstellenprüfung inklusive Ergebnis, für jeden Prüffall muss die Liste folgende Informationen enthalten

2.

Nummer des Prüffalls gemäß der abgestimmten Prüfplanung

3.

Prüfergebnis („Bestanden“, „Bestanden mit Abweichungen/Auffälligkeiten“,“ Nicht bestanden“)

4.

Abweichungen festgestellt (Ja / Nein)

5.

eindeutige Referenznummer für das entsprechende Prüfprotokoll

6.

Ergebnis der Durchführung der Kompatibilitätstests (DSRC-Kompatibilitätstests und MED-Kompatibilitätstests) inklusive Referenz auf den Ergebnisbericht der Kompatibilitätstests

Inhalte des Abschlussberichts für Phase 2:

1.

Übersicht mit allen im Rahmen der Prüfphase durchgeführten Prüffällen (gegliedert nach den Prüfszenarien); für jeden Prüffall muss die Liste folgende Informationen enthalten:

2.

Nummer des Prüffalls gemäß der abgestimmten Prüfplanung

3.

Prüfergebnis („Bestanden“, „Bestanden mit Abweichungen/Auffälligkeiten“,“ Nicht bestanden“)

4.

Abweichungen festgestellt (Ja / Nein)

5.

eindeutige Referenznummer für das entsprechende Prüfprotokoll

Inhalte des Abschlussberichts für Phase 3:

1.

Übersicht mit allen im Rahmen der Prüfphase durchgeführten Prüfszenarien; für jedes Prüfszenario muss die Liste folgende Informationen enthalten:

2.

Nummer des Prüfszenarios

3.

Prüfergebnis,

4.

eindeutige Referenznummer für die entsprechenden Szenarioberichte

Nachdem der EETS-Anbieter den Abschlussbericht zur Verfügung gestellt hat, erstellt der Mauterheber einen eigenen Abschlussbericht.

Anhang B: Prüfkataloge

Siehe separate Dokumente als Anlagen:

(1) Prüfkatalog Schnittstellenprüfung

(2) Prüfkatalog DSRC-Kompatibilitätstests

(3) Prüfkatalog MED-Kompatibilitätstests

(4) Prüfkatalog Probebetrieb

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

Europäischer elektronischer Mautdienst (EETS)

Verfahren zur Feststellung der Gebrauchstauglichkeit

Anlage 1 zum Dokument B- Prüfkonzept

Prüfkatalog „Schnittstellenprüfung“

Dokumentenhistorie

VersionDatumBearbeiterBearbeitung/Änderung

0.117.09.2020RT, BAGErstellung erster unvollständiger Entwurf

1.004.12.2020RT, BAGÜberarbeitung nach Review Prüfspezifikation SSP, QS und Finalisierung

1.107.09.2021RT, BAGRedaktionelle Überarbeitung und Ergänzung fehlende Beschreibung bei P1-SSP-006.1

1.201.03.2024RT, BALMÜberarbeitung entsprechend der Änderungen im BFStrMG

1 Einleitung

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

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

2 Prüffälle

2.1 P1- SSP-001: Austausch von sicherheitsrelevanten Objekten (SST 004)

IDNameBeschreibungZiel

P1-SSP-001.1Übertragung von Transportschlüsseln vom BALM zum EADer Mauterheber überträgt die folgenden Transportschlüssel via SST004 (organisatorische Schnittstelle) jeweils einzeln an den EETS-Anbieter:•KPUB_BAG_ENC•KPUB_BAG_SIGDer EA implementiert die Transportschlüssel in seinem Zentralsystem und quittiert die erfolgreiche Implementierung .Korrekte und vollständige Übertragung der Transportschlüssel an den EA und erfolgreiche Quittierung durch den EA

P1-SSP-001.2Übertragung von Transportschlüsseln vom EA zum BALMDer EA überträgt den folgenden Transportschlüssel via SST004 (organisatorische Schnittstelle) an das BALM:•KPUB_EP_SIGDas BALM implementiert den Transportschlüssel in seinem Zentralsystem und quittiert die erfolgreiche Implementierung.Korrekte und vollständige Übertragung der Transportschlüssel an das BALM und erfolgreiche Quittierung durch das BALM

P1-SSP-001.3Übertragung von Zertifikaten vom BALM zum EADer Mauterheber überträgt die folgenden Zertifikate via SST004 (organisatorische Schnittstelle) jeweils einzeln an den EETS-Anbieter:•CERT_BAG_HTTPS•CERT_BAG_HTTPS_AUTH•CERT_BAG_MAIL•CERT_BAG_NSIG•CERT_TA_BAG•CERT_ROOT_BAGDer EA implementiert die Zertifikate in seinem Zentralsystem und quittiert die erfolgreiche Implementierung.Korrekte und vollständige Übertragung der Zertifikate an den EA und erfolgreiche Quittierung durch den EA

P1-SSP-001.4Übertragung von Zertifikaten vom EA zum BALM•Der EA überträgt die folgenden Zertifikate via SST004 (organisatorische Schnittstelle) an das BALM:•CERT_EP_HTTPS•CERT_EP_HTTPS_AUTH•CERT_EP_MAIL•CERT_EP_NSIG•CERT_TA_EP•CERT_ROOT_EPDas BALM implementiert die Zertifikate in seinem Zentralsystem und quittiert die erfolgreiche Implementierung.Korrekte und vollständige Übertragung der Zertifikate an das BALM und erfolgreiche Quittierung durch das BALM

P1-SSP-001.5Übertragung von Masterkeys vom EA zum BALMDer EA überträgt die folgenden Masterkeys via SST004 (organisatorische Schnittstelle) an das BALM:•KM_CONTROL_MAC1•KM_CONTROL_ACDas BALM implementiert die Masterkeys in seinem Zentralsystem und Kontrollstellen und quittiert die erfolgreiche Implementierung.Prüfung der DSRC-Kommunikation zwischen EETS-OBU und Kontrollstelle.Korrekte und vollständige Übertragung der Masterkeys an das BALM sowie erfolgreiche Quittierung durch das BALM und erfolgreiche DSRC-Kommunikation zwischen EETS-OBU und Kontrollstelle.

2.2 P1- SSP-002: technische Schnittstellenprüfung (SST 001, SST 002, , SST 008, SST 099)

IDNameBeschreibungZiel

P1-SSP-002.1Übertragung einer leeren Nutzerliste (SST002a)Der EA übermittelt dem Mauterheber via SST002a eine leere Nutzerliste. Der Mauterheber bestätigt im selben WebService-Aufruf den erfolgreichen Empfang mit einer sendApduResponse ohne Apdu-Element.Nach der Verarbeitung der empfangenen (leeren) Nutzerliste führt der Mauterheber einen WebService-Aufruf via SST099 durch und sendet dem EA eine AckADU mit dem ApduReasonCode „apduOKNachweis der erfolgreichen Übertragung einer Nutzerliste inklusive synchrone und asynchrone Bestätigung

P1-SSP-002.2Übertragung einer leeren Sperrliste (SST001)Der EA übermittelt dem Mauterheber via SST001 eine leere Sperrliste. Der Mauterheber bestätigt im selben WebService-Aufruf den erfolgreichen Empfang mit einer sendApduResponse ohne Apdu-Element.Nach der Verarbeitung der empfangenen (leeren) Sperrliste führt der Mauterheber einen WebService-Aufruf via SST099 durch und sendet dem EA eine AckADU mit dem ApduReasonCode „apduOKNachweis der erfolgreichen Übertragung einer Sperrliste inklusive synchrone und asynchrone Bestätigung

P1-SSP-002.3Übertragung eines leeren Tagesberichts (SST008)Der EA übermittelt dem Mauterheber via SST008 in jeweils einzelnen Nachrichten die verschiedenen Anteile des Tagesberichts. Diese werden vom Mauterheber synchron und asynchron quittiert. Zum Abschluss überträgt der EA den Überblick Tagesbericht, der ebenfalls vom Mauterheber synchron und asynchron quittiert wird.Nachweis der erfolgreichen Übertragung eines Tagesberichts Sperrliste inklusive synchrone und asynchrone Bestätigungen sowie korrekte Übermittlung des Überblick Tagesberichts am Ende der Übertragung

2.3 P1- SSP-003: Verwalten der Nutzerliste (SST 002a)

IDNameBeschreibungZiel

P1-SSP-003.1Neuanlage mehrerer Nutzer mit FahrzeugenDer EA legt im Rahmen einer Erstvertragsanlage mehrere neue EETS-Nutzer mit jeweils mehreren Fahrzeugen an und aktiviert für diese den Service für das deutsche Mautgebiet BFStrMG. Der EA aktualisiert die Nutzerliste, in dem er die neuen UserIds der EETS-Nutzer in die Nutzerliste einträgt, und übermittelt diese spezifikationskonform via SST002a an den MauterheberNachweis, dass der EA UserIds von EETS-Nutzern vollständig und korrekt anlegt und diese via SST002a vollständig und spezifikationskonform innerhalb der Nutzerliste an den Mauerheber übermittelt.

P1-SSP-003.2Abmelden eines FahrzeugsDer EA meldet der bereits angelegten und an den Mauterheber via SST002a gemeldeten UserId ab und aktualisiert die Nutzerliste.Anschließend übermittelt der EA die Nutzerliste spezifikationskonform via SST002a an den Mauterheber. Die abgemeldete UserID ist nicht mehr Bestandteil der Nutzerliste.Nachweis, dass der EA UserIds von EETS-Nutzern vollständig und korrekt anlegt und diese via SST002a vollständig und spezifikationskonform innerhalb der Nutzerliste an den Mauerheber übermittelt. Nachweis, dass der EA UserId, die nicht mehr für den Dienst Deutschland bei ihm registriert sind von der Nutzerliste entfernt.

P1-SSP-003.3Neues Bordgerät für bestehendes FahrzeugDas EETS-Bordgerät eines angelegten EETS-Fahrzeugs wird deinstalliert und ein neues Bordgerät wird in das Fahrzeug installiert. Dies führt dazu, dass die „alte“ UserId nicht mehr Bestandteil der Nutzerliste ist. Stattdessen wird die Nutzerliste um die „neue“ UserId ergänzt.Die aktualisierte Nutzerliste wird sodann an den Mauterheber via SST002a spezifikationskonform übermittelt.Nachweis, dass der EA Änderungen in den Daten einer UserId korrekt verarbeitet und in seinem Zentralsystem korrekt anlegt und dass der EA die Änderungen bei der Aktualisierung der Nutzerliste korrekt berücksichtigt und sie via SST002a vollständig und spezifikationskonform an den Mauerheber übermittelt.

2.4 P1- SSP-004: Verwalten der Liste der Sperrliste (SST 001)

IDNameBeschreibungZiel

P1-SSP-004.1Sperrung mehrerer Bordgeräte (SST001)Der EA sperrt mehrere UserIds und aktualisiert die Sperrliste. Anschließend übermittelt der EA die aktualisierte Sperrliste spezifikationskonform via SST001 an den Mauterheber.Nachweis, dass der EA Sperrungen von bei ihm registrierten UserIds, die einen aktiven Vertrag BFStrMG haben, durchführen kann und die gesperrten UserIds via SST001 vollständig und spezifikationskonform auf der Sperrliste an den Mauerheber übermittelt.

P1-SSP-004.2Entsperrung mehrerer Bordgeräte (SST001)Der EA entsperrt die im Rahmen des vorherigen Testfalls gesperrten UserIds und aktualisiert die Sperrliste. Anschließend übermittelt der EA die aktualisierte Sperrliste spezifikationskonform via SST001 an den Mauterheber.Nachweis, dass der EA gesperrte, bei ihm registrierte UserIds wieder entsperren kann und die entsperrten UserIds nicht mehr auf der Sperrliste an den Mauterheber übermittelt.

2.5 P1- SSP-005: Verwalten von Nutzeradress- und Fahrzeugdaten (SST 002b)

IDNameBeschreibungZiel

P1-SSP-005.1Verschiedene Abfragen zu mehreren User-IdsDer Mauterheber führt Anfragen zu Fahrzeug- und Adressdaten von unterschiedlichen, beim EA registrierten UserIds via SST002b durch. Nach der Verarbeitung der Anfragen stellt der EA via SST002b dem Mauterheber die geforderten Nutzerinformationen bereit.Der Mauterheber führt Anfragen zu Fahrzeug- und Adressdaten von unterschiedlichen, beim EA registrierten UserIds via SST002b durch. Nach der Verarbeitung der Anfragen stellt der EA via SST002b dem Mauterheber die geforderten Nutzerinformationen bereit.

P1-SSP-005.2Abfrage von Fahrzeugdaten nach Änderung von NutzerinformationenDie Fahrzeugdaten einer UserId werden geändert. Der Mauterheber führt anschließend eine Anfrage zu den (geänderten) Fahrzeugdaten via SST002b durch.Nach der Verarbeitung der Anfrage stellt der EA dem Mauterheber via SST002b die geforderten Nutzerinformationen bereit.Nachweis, dass der EA Änderungen an den Fahrzeugdaten in seinem Zentralsystem korrekt umsetzt sowie die SST002b-Anfragen des Mauterhebers entgegennimmt und verarbeitet und dem Mauterheber die angeforderten Daten via SST002b vollständig und spezifikationskonform bereitstellt

2.6 P1- SSP-006: Verwalten der Fahrzeugliste von EETS-Nutzern (SST 002c)

IDNameBeschreibungZiel

P1-SSP-006.1Abfrage des mautpflichtigen Fahrzeugbestands zu mehreren User-IdsDer Mauterheber führt Anfragen nach den Fahrzeuglisten mehrerer EETS-Nutzer durch. Nach der Verarbeitung der Anfragen zu den Fahrzeuglisten der EETS-Nutzer stellt der EETS-Anbieter dem Mauterheber die geforderten Flotteninformationen über die SST 002c bereit.Nachweis, dass der EA Anfragen des Mauterhebers zur Fahrzeugliste mehrerer EETS-Nutzer via SST002c entgegennimmt und verarbeitet und dem Mauterheber die geforderten 002c-Daten vollständig und spezifikationskonform bereitstellt

2.7 P1- SSP-007: Erzeugung von Tagesberichten (SST 008)

IDNameBeschreibungZiel

P1-SSP-007.1Erzeugung von Tagesberichten (SST008)Der EA erstellt die Tagesberichts-Anteile für ausgeglichene und neue überfällige Mautfahrten sowie den Überblick Tagesbericht für die im Rahmen der MED-Kompatibilitätstests erhaltenen Mautbuchungsnachweise (SST007R-Daten). Die SST008-Daten werden spezifikationskonform vom EA an den Mauterheber via SST008 übertragen.Der Mauterheber prüft im Rahmen der EETS-Einnahmeprüfung die Korrektheit der im Tagesbericht kommunizierten Mautbeträge und führt eine Plausibilisierung zwischen den im Tagesbericht referenzierten und den erhaltenen Mautbuchungsnachweisen durch.Nachweis, dass der EA für die im MED-Kompatibilitätstests erhaltenen Mautbuchungsnachweise Tagesberichte gemäß SST008 erzeugt und diese an spezifikationskonform an den Mauterheber übermittelt.

2.8 P1-SSP-008 (optional): Übertragung der Mautbasisdaten (SST003) an den EETS-Anbieter

Hinweis: Bei diesem Szenario handelt es sich um ein optionales Prüfszenario. Es muss nur dann absolviert werden, wenn der EETS-Anbieter die SST003 implementiert.

IDNameBeschreibungZiel

P1-SSP-008.1Übertragung der Mautbasisdaten (SST003) an den EETS-AnbieterDer Mauterheber hat in seinem System eine Aktualisierung der Mautbasisdaten durchgeführt. Um die aktualisierten Mautbasisdaten an den EA zu kommunizieren, führt der Mauterheber einen WebService-Aufruf via SST003 in Richtung des EA durch und übermittelt die aktuellen Mautbasisdaten an den EA. Der EA quittiert den erfolgreichen Empfang der Mautbasisdaten im selben WebService-Aufruf anhand einer AckADU mit dem apduReasonCode „apduOk (2)“.Nachweis, dass der Mauterheber die Schnittstelle 003 beim EA aufrufen und die Mautbasisdaten spezifikationskonform an den EA übertragen kann inklusive der erfolgreichen synchronen Rückmeldung.

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

Europäischer elektronischer Mautdienst (EETS)

Verfahren zur Feststellung der Gebrauchstauglichkeit

Anlage 2 zum Dokument B- Prüfkonzept

Prüfkatalog „DSRC-Kompatibilitätstests“

Dokumentenhistorie

VersionDatumBearbeiterBearbeitung/Änderung

0.117.09.2020RT, BAGErstellung erster unvollständiger Entwurf

0.230.10.2020RT, BAGEinarbeitung Review TC

1.004.12.2020RT, BAGQS und Finalisierung

2.007.07.2021RT, BAGErgänzung Prüffälle für Version 3.0 der SST 301

2.101.03.2024RT, BALMWegfall der Testfälle für SST 301 v2.1 Ergänzung betrieblicher Testfälle für SST 301 v3.1 Überarbeitung entsprechend der Änderungen des BFStrMG

1 Einleitung

Der vorliegende Prüfkatalog enthält die Prüffalle, deren Erfüllung im Rahmen der Feststellung der Gebrauchstauglichkeit in Prüfblock 2, Phase 1 Kompatibilitätstests nachzuweisen ist. Er beschränkt sich auf die Prüffälle zum Nachweis der Kompatibilität zwischen dem Bordgerät des EETS-Anbieters zu den Kontrollstellen des nationalen Mautbetreibers.

Die DSRC-Kompatibilitätstests umfassen dabei sowohl funktionale als auch betriebliche Aspekte und werden durch den nationalen Mautbetreiber geplant und durchgeführt.

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

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

Name/IDBeschreibungZiel

DSRC_A0BA_BI01_0010Die 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_0010Die 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_0011Die 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_0010Die 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_0010Die 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_0010Die 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_0010Die 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_0010Die 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_0010Die 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_0011Die 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_0011Die 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_0011Die 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_0011Die 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_5010Die 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_5010Die 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_0011Die 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_0011Die 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_5010Die 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_0011Die 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_0011Die 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_5010Die 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_0011Die 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_0011Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein GET.rq fürAttribut 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_0011Die 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_0011Die 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_5010Die 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_5010Die 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_0011Die 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_5010Die 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_0011Die 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_0010Die 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_0010Die 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_0010Die 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_0010Die 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_0011Die 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_0010Die 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_0010Die 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_0010Die 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_0010Die 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_0010Die 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_0010Die 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_0010Die 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_0010Die 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_0011Die 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_0011Die 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_0010Die 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 einSET_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_0010Die 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_0010Fü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_0010Fü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_0010Fü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_0010Fü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_0010Fü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_0010Fü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_0010Fü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_0010Fü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_0010Die 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_0010Die 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_0011Die 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_0010Die 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_0010Die 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_0010Die 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_0010Die 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_0010Die 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_0010Die 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_0011Die 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_0011Die 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_0011Die 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_0011Die 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_5010Die 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_5010Die 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_0011Die 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_0011Die 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_5010Die 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_0011Die 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_0011Die 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_5010Die 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_0011Die 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_0011Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein GET.rq fürAttribut 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_0011Die 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_0011Die 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_5010Die 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_5010Die 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_0011Die 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_5010Die 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_0011Die 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_0010Die 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_0010Die 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_0010Die 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_0010Die 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_0011Die 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_0010Die 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_0010Die 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_0010Die 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_0010Die 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_0010Die 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_0010Die 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_0010Die 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_0010Die 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_0011Die 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_0011Die 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_0010Die 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_0010Die 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_0010Zunä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_0010Zunä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_0010Zunä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_0010Zunä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_0010Zunä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_0010Zunä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_0010Zunä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_0010Zunä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_0010Zunä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 imLLC-Kontrollfeld erkennt und ignoriert.

DSRC_LLC__BI02_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Anschließend sendet sie 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_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Anschließend sendet sie 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_0010Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Anschließend sendet sie ein ECHO.rq mit 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_0010Zunä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.

Dieses Dokument ersetzt nicht die offizielle Publikation im Bundesgesetzblatt. Für eventuelle Ungenauigkeiten bei der Übertragung in dieses Format wird keine Haftung übernommen.

Dieser Text wird zu den eigenen Weiterverwendungsbedingungen von gesetze-im-internet.de veröffentlicht, nicht unter einer Legalize-Lizenz oder einer Public-Domain-Lizenz. gesetze-im-internet.de
gemeinfrei (amtliche Werke nach § 5 UrhG; freie Nutzung und Weiterverwendung)