Gesetze / Gesetzblätter
Bundesgesetzblatt, Teil I, Jahrgang 2023, Nr. 329
BGBl. 2023 I Nr. 329 · 320.677 Zeichen · Textauszug aus unserem Bestand.
Textauszug (durchsuchbar)
Teil I
2023 Ausgegeben zu Bonn am 30. November 2023 Nr. 329
Zweite Verordnung
zur Änderung der EEMD-Gebietsvorgabenverordnung und der
EEMD-Zulassungsverordnung
Vom 27. November 2023
Auf Grund des § 4h Satz 1 und des § 4i Satz 1 des Bundesfernstraßenmautgesetzes vom 12. Juli 2011 (BGBl. I
S. 1378), die durch Artikel 2 Nummer 3 des Gesetzes vom 5. Dezember 2014 (BGBl. I S. 1980) eingefügt worden
sind, in Verbindung mit § 1 Nummer 2 und 3 der BALM-Übertragungsverordnung vom 14. Januar 2016 (BAnz AT
26.01.2016 V1), der zuletzt durch Artikel 32 des Gesetzes vom 2. März 2023 (BGBl. 2023 I Nr. 56) geändert worden
ist, verordnet das Bundesamt für Logistik und Mobilität:
Artikel 1
Änderung der EEMD-Gebietsvorgabenverordnung
Die EEMD-Gebietsvorgabenverordnung vom 20. März 2018 (BAnz AT 27.03.2018 V1), die zuletzt durch Artikel 1
der Verordnung vom 25. Oktober 2021 (BAnz AT 29.10.2021 V2) geändert worden ist, wird wie folgt geändert:
1. Die Anlage 1 der EEMD-Gebietsvorgabenverordnung wird wie folgt geändert:
a) Die Überschrift der Anlage 1 wird wie folgt geändert:
aa) Die Wörter „Verkehr und digitale Infrastruktur (BMVI)“ werden durch die Wörter „Digitales und Verkehr
(BMDV)“ ersetzt.
bb) Die Wörter „Güterverkehr (BAG)“ werden durch die Wörter „Logistik und Mobilität (BALM)“ ersetzt.
b) Die Tabelle wird wie folgt geändert:
aa) In der Nummer 1 Spalte 3 Absatz 3 werden in Satz 4 die Wörter „Güterverkehr (BAG)“ durch die Wörter
„Logistik und Mobilität (BALM)“ ersetzt.
bb) In der Nummer 2 Spalte 3 wird in Satz 1 nach dem Wort „Mauterheber“ das Wort „wird“ durch das Wort
„hat“ ersetzt und nach dem Wort „EETS-Zulassungsvertrags“ das Wort „zu“ eingefügt.
cc) Die Nummer 18_EET Spalte 3 wird wie folgt geändert:
aaa) Nummer 1 wird wie folgt gefasst „1. Sperrliste (SST 001)“.
bbb) In Nummer 2 wird nach dem Wort „Nutzerlisten“ das Wort „(Userlist)“ gestrichen.
dd) Die Nummer 18_MED Spalte 3 wird wie folgt geändert:
aaa) Nummer 1 wird wie folgt neu gefasst „1. Sperrliste (SST 001)“.
bbb) In Nummer 2 wird nach dem Wort „Nutzerlisten“ das Wort „(Userlist)“ gestrichen.
ccc) In Nummer 11 wird das Wort „und“ durch ein Komma ersetzt.
ddd) In Nummer 12 wird nach der Angabe „(SST 301)“ der Punkt durch ein Komma ersetzt.
eee) Nach Nummer 12 werden folgende Nummern eingefügt:
„13. Gutzuschreibende EETS-Fahrten (SST 017),
14. Bewertete Gutschriften (SST 018) und
15. EETS-Anbieter Gutschriften (SST 019).“
ee) Die Nummer 19 wird wie folgt geändert:
aaa) In der Spalte „Technisch-organisatorische Vorgaben“ werden die Wörter „Blocklist (Sperrliste)“ durch
das Wort „Sperrliste“ ersetzt.
bbb) In der 3. Spalte werden in Satz 1 die Wörter „Blocklist (Sperrliste)“ durch das Wort „Sperrliste“
ersetzt.
ff) In der Nummer 46 Spalte 3 wird in Absatz 3 Satz 2 das Wort „BMVI“ durch das Wort „BMDV“ ersetzt.
gg) Die Nummer 54_EET wird wie folgt gefasst:
„54_EET Qualitätsparameter Der EETS-Anbieter muss beim Betrieb seines EETS-Teilsystems
folgende Qualitätsparameter erfüllen:
1. Erfassungsquote EQ_nonMED von mindestens 99,500 %
Die Erfassungsquote EQ_nonMED dient der Bestimmung der
Qualität der korrekten Erkennung befahrener Abschnitte des
mautpflichtigen Straßennetzes. Es wird geprüft, ob für im
Rahmen der Kontrollaktivitäten des Mauterhebers identifizierte
mautpflichtige Fahrzeuge abschnittsbezogene Erhebungsdaten
durch den EETS-Anbieter an das BALM geliefert werden.
2. DSRC-Quote von mindestens 98,500 %
Die DSRC-Quote dient der Messung der korrekten DSRC-Kom
munikation zwischen den EETS-Fahrzeuggeräten und den
Kontrolleinrichtungen. Es wird geprüft, ob für alle abschnitts
bezogenen Erhebungsdaten des EETS-Anbieters auch eine
entsprechende DSRC-Kommunikation vorliegt, sofern auf dem
jeweiligen Abschnitt eine Kontrolleinrichtung des Mauterhebers
aktiv war.
3. Sperrlistenquote von mindestens 99,900 %
Über die Sperrlistenquote wird bestimmt, ob Fahrzeuggeräte
durch den EETS-Anbieter technisch gesperrt wurden, bevor
diese auf die Sperrliste gesetzt werden. Es wird geprüft, ob
erhebungsbereite Fahrzeuggeräte dennoch auf der Sperrliste
aufgeführt sind.
4. Nutzerlistenquote von mindestens 99,900 %
Ziel der Quote ist die Messung der Qualität der Erstellung und
Übermittlung der Nutzerliste vom EETS-Anbieter an den Maut
erheber. Es wird geprüft, ob erhebungsbereite Fahrzeuggeräte,
die durch die Kontrolleinrichtungen des Mauterhebers erfasst
sind, auch in der Nutzerliste eingetragen sind.
5. Quote für abschnittsbezogene Erhebungsdaten von mindestens
99,000 %
Die Quote misst die Korrektheit und Rechtzeitigkeit der Über
mittlung von abschnittsbezogenen Erhebungsdaten (ABED).
Es wird geprüft, ob die abschnittsbezogenen Erhebungsdaten
innerhalb der im EETS-Zulassungsvertrag festgelegten Fristen
übermittelt wurden und keine Fehler aufweisen.
Die Einzelheiten zur Messung und Bewertung der Qualitätspara
meter sind in der Anlage 5 zum EETS-Zulassungsvertrag „Quali
tätsparameter für EETS-Anbieter“ geregelt.“
hh) In der Nummer 54_MED wird in Nummer 1 in Satz 2 das Wort „BAG“ durch das Wort „BALM“ ersetzt.
2. Die Anlage 2 der EEMD-Gebietsvorgabenverordnung wird wie folgt gefasst:
„Anlage 2
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)
Vorgaben für das EETS-Gebiet nach dem Bundesfernstraßenmautgesetz (EETS-Gebiet BFStrMG)
Hinweise zum Vergütungsmodell
I. Einleitung
Die Richtlinie (EU) 2019/520 des Europäischen Parlaments und des Rates vom 19. März 2019 über die
Interoperabilität elektronischer Mautsysteme und die Erleichterung des grenzüberschreitenden
Informationsaustauschs über die Nichtzahlung von Straßenbenutzungsgebühren in der Union (ABl. L 91
vom 29.03.2019, S. 45) und die Durchführungsverordnung (EU) 2020/204 der Kommission vom 28. November
2019 über detaillierte Pflichten der Anbieter des europäischen elektronischen Mautdienstes, den Mindestinhalt
der Vorgabe für das EETS-Gebiet, elektronische Schnittstellen und Anforderungen
an Interoperabilitätskomponenten sowie zur Aufhebung der Entscheidung 2009/750/EG (ABl. L 43
vom 17.02.2020, S. 49), deren Umsetzung oder Durchführung in Deutschland durch das
Bundesfernstraßenmautgesetz (BFStrMG) und das Mautsystemgesetz (MautSysG) erfolgt, legen einen
Vergütungsanspruch des EETS-Anbieters sowie Grundsätze der Ermittlung dieser Vergütung fest.
Gemäß Anhang II 1.2 der Durchführungsverordnung (EU) 2020/204 müssen die Geschäftsbedingungen des
Mauterhebers eine Beschreibung der Elemente, die zur Festlegung der vom Mauterheber an den EETS-
Anbieter zu zahlenden festen und/oder variablen Vergütung herangezogen werden, umfassen. Dies erfolgt im
Rahmen der Beschreibung des Vergütungsmodells und der konkreten Beträge der Vergütung in Anlage 9 zum
EETS-Zulassungsvertrag.
Gemäß Artikel 7 der Richtlinie (EU) 2019/520 muss die Methode zur Festlegung der Vergütung der EETS-
Anbieter als Teil der geschäftlichen Rahmenbedingungen veröffentlicht werden. Gemäß Anhang II 1.3 der
Durchführungsverordnung (EU) 2020/204 müssen die Gebietsvorgaben eine Beschreibung der besonderen
Anforderungen und Pflichten des Hauptdiensteanbieters enthalten, die sich von denen der EETS-Anbieter
unterscheiden und etwaige Unterschiede bei der Vergütung des Hauptdiensteanbieters gegenüber den EETS-
Anbietern rechtfertigen. Dementsprechend beschreibt diese Anlage:
1. die Methode der Festlegung der Vergütung des EETS-Anbieters,
2. die Struktur der Vergütung vergleichbarer Leistungen des Hauptdiensteanbieters und
3. die Unterschiede in der Vergütung des Hauptdiensteanbieters aufgrund unterschiedlicher
Leistungsanforderungen.
Im EETS-Gebiet des BFStrMG ist ein Hauptdiensteanbieter im Sinne der Richtlinie (EU) 2019/520 tätig. Es
handelt sich um die Toll Collect GmbH, die einen langfristigen Betreibervertrag mit dem Bundesamt für Logistik
und Mobilität (BALM, ehemals Bundesamt für Güterverkehr, BAG) erfüllt und seit dem 01.09.2018 zu 100 % im
Eigentum der Bundesrepublik Deutschland ist.
II. Prinzipien des Vergütungsmodells
Das Vergütungsmodell für das EETS-Gebiet BFStrMG steht im Einklang mit den Anforderungen des Artikels 7
der Richtlinie (EU) 2019/520.
Sowohl das Vergütungsmodell als auch die Beschreibung der Elemente des Vergütungsmodells werden im
Rahmen der EETS-Gebietsvorgaben und des EETS-Zulassungsvertrags veröffentlicht.
Die Vergütung erfolgt dabei für alle EETS-Anbieter nach derselben transparenten und diskriminierungsfreien
Methode. Eine Unterscheidung wird lediglich in Bezug auf die Nutzung des Mauterhebungsdienstes (MED)
vorgenommen. Bei diesem erfolgt die Berechnung der Maut für die Nutzer von EETS-Anbietern, einschließlich
des Erkennungsprozesses zur Unterscheidung mautpflichtiger von nicht mautpflichtigen Streckenabschnitten
und der Ermittlung der abschnittsbezogenen Erhebungsdaten und der Erstellung der Mautbuchungsnachweise,
durch das BALM. Da der zu erbringende Leistungsumfang von EETS-Anbietern, die den MED nutzen, geringer
ist, erfolgt hier eine entsprechend geringere Vergütung.
Das Verfahren für die Berechnung der Vergütung der EETS-Anbieter folgt dabei derselben Struktur wie die
Vergütung vergleichbarer Dienste, die von dem Hauptdiensteanbieter angeboten werden (siehe Abschnitt III).
Sofern sich Leistungen des Hauptdiensteanbieters von den Leistungen der EETS-Anbieter unterscheiden, wurde
dies bei der Herleitung des Vergütungsmodells entsprechend berücksichtigt.
III. Struktur der Vergütung Die Vergütung des Hauptdiensteanbieters besteht aus vier Bestandteilen: 1. Vergütung der Aufwände für die Leistungserbringung Diese Position umfasst alle Aufwände des Hauptdiensteanbieters, die zur Erbringung der Leistungen notwendig sind, die im Grundsatz mit Leistungen des EETS-Anbieters vergleichbar sind. Dies betrifft insbesondere die automatische Mauterhebung. Der Hauptdiensteanbieter erbringt gemäß Betreibervertrag weitere Leistungen im Bereich des manuellen Verfahrens und der Kontrolle. Diese wurden im Vergütungsmodell nicht berücksichtigt. Sofern die Leistungen grundsätzlich vergleichbar sind, sich im Umfang jedoch unterscheiden, werden diese Unterschiede bei der Festsetzung der Vergütung begründet. 2. Vergütung für die Erreichung von Unternehmenszielen Der Hauptdienstanbieter erhält eine variable Vergütung, die an die Erreichung von bestimmten Unternehmenszielen geknüpft ist. Diese werden je Geschäftsjahr durch die Eigentümerin festgelegt und sind nur sehr eingeschränkt mit den vertraglichen Anforderungen an EETS-Anbieter vergleichbar. 3. Vergütung für Änderungsverlangen des Auftraggebers Änderungen am Mautsystem, die sich durch Projekte des Auftraggebers ergeben, zum Beispiel auch die Umsetzung von Änderungen aufgrund gesetzlicher Vorgaben, werden durch den Auftraggeber separat vergütet. 4. Gewinn- und Wagniszuschlag Auf die unter Nummer 1 und 3 genannten Vergütungselemente erhält der Hauptdiensteanbieter einen Gewinn- und Wagnisaufschlag, um die mit der Erbringung der entsprechenden Leistungen verbundenen Risiken zu adressieren. Die Struktur der Vergütung des EETS-Anbieters besteht aus denselben vier Bestandteilen: 1. Vergütung der Aufwände für die Leistungserbringung Der EETS-Anbieter erhält eine Vergütung für die Leistungen, die er gemäß EETS-Zulassungsvertrag und den sonstigen mitgeltenden Verordnungen gegenüber dem BALM zu erbringen hat. Dafür wurden die einzelnen Leistungen identifiziert und auf ihre Vergleichbarkeit mit ähnlichen Leistungen des Hauptdiensteanbieters geprüft. Basierend darauf wurde die dem EETS-Anbieter für seine Leistungserbringung zu gewährende Vergütung auf Basis der Kosten des Hauptdiensteanbieters abgeleitet. 2. Vergütung für die Erreichung von Unternehmenszielen Für EETS-Anbieter gibt das BALM keine direkten Unternehmensziele vor. Eine überdurchschnittliche Leistungserbringung in Bezug auf die Qualität der korrekten Mauterhebung für Befahrungen des mautpflichtigen Straßennetzes wird jedoch im Vergütungsmodell über eine Bonusregelung für eine Überschreitung der geforderten Zielgröße der Erfassungsquote gemäß EETS-Zulassungsvertrag honoriert. 3. Vergütung für Änderungsverlangen des Mauterhebers Wie der Hauptdiensteanbieter, erhalten auch die EETS-Anbieter eine Vergütung für Änderungsverlangen, die durch den Mauterheber initiiert werden. Dies können konfigurative und betriebliche Anpassungen an Systemen und Schnittstellen, aber auch Umsetzungsprojekte sein, zum Beispiel die Einführung eines neuen technischen Standards. 4. Gewinn- und Wagniszuschlag Analog zum Hauptdiensteanbieter erhalten auch die EETS-Anbieter auf die unter Nummer 1 und 3 genannten Vergütungselemente einen Gewinn- und Wagniszuschlag, um die mit der Erbringung der entsprechenden Leistungen verbundenen Risiken zu adressieren. IV. Vergütungselemente und Vergütungsmodell Bei der Herleitung der Elemente des Vergütungsmodells wurde grundsätzlich in vier Schritten vorgegangen: 1. Ermittlung der Leistungen der EETS-Anbieter: Die Leistungen der EETS-Anbieter wurden auf Basis der einschlägigen rechtlichen Vorschriften, insbesondere aufgrund des EETS-Zulassungsvertrages und der Gebietsvorgaben, ermittelt. Anschließend wurde geprüft, welche dieser Leistungen im Grundsatz vergleichbar zu Leistungen des Hauptdiensteanbieters sind und welche Unterschiede in der Leistungserbringung zwischen EETS-Anbietern und Hauptdiensteanbieter bestehen. 2. Bestimmung der Art der Leistung: Für die spätere Festlegung der tatsächlichen Vergütung einer Leistung im Vergütungsmodell ist es wesentlich, bestimmte Eigenschaften der Leistung zu ermitteln. Dabei wurde geprüft, ob die Leistung einen fixen oder variablen Aufwand verursacht. Sofern es sich um variablen Aufwand handelt, wurde ermittelt, mit welchem Parameter der Aufwand skaliert. Auch wurde ermittelt, inwiefern die Nutzung des MED Einfluss auf die Leistungserbringung hat. 3. Bestimmung von Vergütungselementen: Zur effizienten Entwicklung des Vergütungsmodells wurden gleichartige Leistungen zu Vergütungselementen zusammengefasst. Dies erfolgte, wenn Leistungen inhaltliche Zusammenhänge aufwiesen und mit denselben Parametern (siehe Abschnitt IV, Nummer 2) skalieren.
4. Bestimmung der Vergütung für die Vergütungselemente: Im letzten Schritt wurde die Höhe der Vergütung für die Vergütungselemente ermittelt. Hierbei wurden die entsprechenden Aufwände des Hauptdiensteanbieters berücksichtigt. Unterschieden in der Leistungserbringung wurde über entsprechende Zu- und Abschläge Rechnung getragen. Des Weiteren wurden Synergieeffekte des EETS-Anbieters berücksichtigt, die bei der Erbringung der gleichen Leistung auch für andere EETS-Gebiete realisiert werden können. Im Ergebnis dieser Analyse wurde festgelegt, dass die Vergütung der EETS-Anbieter unter Berücksichtigung der Struktur in Abschnitt III nach den folgenden Elementen erfolgt: 1. Betriebsentgelt Feste Vergütung für Leistungen, die nicht mit variablen Parametern skalieren. Das Betriebsentgelt enthält eine so genannte Änderungspauschale, die pauschal sowohl betriebliche und organisatorische Anpassungen an Prozessen und Systemen, die während des laufenden Betriebs auftreten, abdeckt als auch größere Entwicklungsprojekte umfasst, die der Mauterheber für die kommende Vergütungsperiode plant. 2. Entgelt Automatisches Verfahren (AV-Entgelt) Variable Vergütung für Leistungen des EETS-Anbieters, die mit der Anzahl der aktiven Fahrzeuggeräte in Zusammenhang stehen. Das Vergütungselement wird gezahlt in Abhängigkeit von der Anzahl der im Betrachtungszeitraum aktiven Fahrzeuggeräte, d. h. Fahrzeuggeräten, für die mindestens eine mautpflichtige Befahrung des Streckennetzes an den Mauterheber übermittelt wurde. 3. Nutzungs- und Zahlungsprovisionsentgelt Variable Vergütung für Leistungen, die mit der Höhe des abgerechneten Mautvolumens bzw. der abgerechneten Fahrleistung skalieren. Das Vergütungselement wird gezahlt in Abhängigkeit von der Höhe der im Betrachtungszeitraum wertgestellten Mautzahlungen abzüglich positiv beschiedener Erstattungsverlangen und Verzugszinsen. 4. Bonus für Erfassungsquote Variable Vergütung für die Überschreitung der vertraglich festgelegten, mindestens zu erreichenden Erfassungsquote. Gemäß Anlage 5 des EETS-Zulassungsvertrags muss der EETS-Anbieter eine Erfassungsquote von mindestens 99,500 % erreichen. Sofern der EETS-Anbieter im Betrachtungszeitraum diese Quote überschreitet, erhält er einen Bonus von 12,5 % der fiktiven Mauteinnahmen, die sich durch die höhere Erfassungsquote ergeben. Alle Leistungen der EETS-Anbieter wurden einem dieser Vergütungselemente zugeordnet (siehe Abschnitt V). Die Vergütung wird jeweils für eine Vergütungsperiode festgelegt. Die Vergütungsperiode gemäß Anlage 9 zum EETS-Zulassungsvertrag umfasst den Zeitraum vom 01.03.2023 bis 31.12.2025. Der Mauterheber wird eine Überprüfung und Festlegung der Vergütung für folgende Vergütungsperioden gemäß den Regelungen in Nummer 2 der Anlage 9 zum EETS-Zulassungsvertrag vornehmen. V. Herleitung der Höhe der Vergütung Die folgenden Kapitel beschreiben detailliert die Herleitung der Vergütung aufgrund der Analyse der Leistungen des EETS-Anbieters gemäß Abschnitt IV. Für die identifizierten vergleichbaren Leistungen wurde die durchschnittliche Vergütung des Hauptdiensteanbieters in Bezug auf Implementierungs- und Betriebskosten herangezogen. Dabei wurde die Vergütung des Hauptdiensteanbieters auch dann berücksichtigt, wenn die für die Erbringung der Leistung notwendigen Systeme und Prozesse bereits in der Vergangenheit implementiert wurden. Sofern bei der Vergütung Personalkosten, beispielsweise für die Betreuung der Geschäftsprozesse, relevant sind, enthalten die vom Hauptdiensteanbieter herangezogenen Kosten, neben den Gehaltskosten einschließlich der Arbeitgeberkosten, auch die direkt dem Personal zuordenbaren Gemeinkosten, wie zum Beispiel IT- und Geschäftsausstattung oder Personalmanagement. Nicht direkt zuordenbare Gemeinkosten wie die Kosten für Geschäftsführung, externe Kommunikation oder Rechtsabteilung wurden durch einen Verwaltungsaufschlag in Ansatz gebracht, der auf die Vergütungselemente Betriebsentgelt und Entgelt automatisches Verfahren aufgeschlagen wurde. Kosten für die Implementierung von IT-Systemen enthalten auch einen Anteil der notwendigen Testkosten. Des Weiteren wird kenntlich gemacht, sofern gemäß der Leistungsanalyse eine Leistung nicht nur im EETS- Gebiet BFStrMG erbracht wird, sondern sich Synergieeffekte mit anderen EETS-Gebieten ergeben. Dabei wird individuell je Leistung ermittelt, wie hoch der Synergieeffekt ausfällt. Sofern die Leistung grundsätzlich in allen EETS-Gebieten genutzt werden kann, wird die Vergütung des Hauptdiensteanbieters mit 25 % für die Vergütung des EETS-Anbieters berücksichtigt, da dieser seine Leistungen gemäß Artikel 5 Absatz 1 der Richtlinie (EU) 2019/520 in mindestens vier Mitgliedsstaaten erbringen muss. Sofern nur Teile der Leistung auch in den anderen EETS-Gebieten genutzt werden können oder die Leistung in satellitenbasierten Mautsystemen angewendet werden kann, wird die Vergütung des Hauptdiensteanbieters mit 50 % für die Vergütung des EETS-Anbieters
berücksichtigt. In diesem Fall gibt es keine direkte Abhängigkeit zur Anzahl der EETS-Gebiete, in denen der EETS-Anbieter zugelassen ist. Der Mauterheber behält sich vor, diesen Synergieeffekt im Rahmen der regelmäßigen Überprüfung des Vergütungsmodells an die aktuelle Entwicklung im EETS-Markt anzupassen. Unterschieden in der Leistungserbringung wird durch entsprechende Auf- oder Abschläge bei der Vergütung Rechnung getragen (Komplexitätsfaktor). Hierbei kann im Einzelfall der Leistungsumfang des Hauptdiensteanbieters oder des EETS-Anbieters höher sein. Auch wird der Komplexitätsfaktor genutzt, um im Vergleich zu anderen EETS-Gebieten erhöhte Anforderungen des Mauterhebers trotz grundsätzlicher Anwendung des Synergieeffekts zu berücksichtigen. Für die Herleitung der Vergütung wurden gemäß den Vorgaben der Richtlinie (EU) 2019/520 die Struktur und die Kosten für vergleichbare Leistungen des Hauptdiensteanbieters herangezogen. In den folgenden Kapiteln erfolgt eine qualitative Beschreibung der Überleitung der einzelnen Vergütungsbestandteile in die Vergütungselemente, die Angabe von konkreten Kosten unterbleibt zum Schutz der Betriebs- und Geschäftsgeheimnisse des Hauptdiensteanbieters und dessen Unterauftragnehmern. V.1. Vergütung der Aufwände für die Leistungserbringung V.1.1. Leistungen mit Zuordnung zum Betriebsentgelt 1. Betriebshaftpflicht Die EETS-Anbieter haben die vertragliche Verpflichtung eine Betriebshaftpflichtversicherung abzuschließen. Eine vergleichbare Verpflichtung hat auch der Hauptdiensteanbieter. Die Höhe der Vergütung der EETS- Anbieter wurde auf Basis der Vergütung der Basis-Haftpflichtversicherung des Hauptdiensteanbieters unter Anpassung auf die gemäß EETS-Zulassungsvertrag geforderte Versicherungssumme ermittelt. Sowohl Hauptdiensteanbieter als auch EETS-Anbieter haben die vertragliche Verpflichtung, eventuelle Erlöse aus der Versicherung an den Mauterheber abzutreten. 2. Anforderungen an gebietsfremde EETS-Anbieter Gebietsfremde EETS-Anbieter treffen bestimmte Anforderungen des EETS-Zulassungsvertrags, die auf den Hauptdiensteanbieter nicht zutreffen und die bei gebietsansässigen EETS-Anbietern implizit erbracht werden. Dies betrifft zum Beispiel die Anforderungen an die Kommunikation in deutscher Sprache oder die Unterhaltung einer deutschen Zustelladresse. Eine entsprechende Vergütung erfolgt nicht für den Hauptdiensteanbieter. Die Höhe der Vergütung wurde deshalb auf Basis der abgeschätzten Aufwände für diese Leistungen ermittelt. Eine differenzierte Vergütung von gebietsfremden und gebietsansässigen EETS-Anbietern in Bezug auf diese Anforderung findet aus Vereinfachungsgründen und des relativ geringen Anteils an der Gesamtvergütung nicht statt. 3. Weitere organisatorische Anforderungen EETS-Anbieter haben einige sonstige organisatorische Anforderungen des EETS-Zulassungsvertrags zu erfüllen, die auf den Hauptdiensteanbieter nicht zutreffen. Dies betrifft zum Beispiel Anforderungen zur Trennung der Maut von sonstigen Einnahmen sowie Informationspflichten gegenüber dem Mitgliedstaat, in dem die Registrierung erfolgt. Eine entsprechende Vergütung erfolgt nicht für den Hauptdiensteanbieter. Die Höhe der Vergütung wurde deshalb auf Basis der abgeschätzten Aufwände für diese Leistungen ermittelt. 4. Änderungspauschale Das Betriebsentgelt enthält gemäß Struktur der Vergütung auch eine Pauschale für die Vergütung von Änderungen, die durch den Mauterheber initiiert wurden. Details zur Ermittlung der Änderungspauschale sind in Nummer 2.3 der Anlage 9 zum EETS-Zulassungsvertrag enthalten. Die Änderungspauschale wurde aufgrund von Abschätzungen der Höhe der Kosten für die Umsetzung der Änderungen beim Hauptdiensteanbieter ermittelt. Die tatsächlichen Umsetzungskosten können je nach EETS- Anbieter aufgrund unterschiedlicher Ausgangsbedingungen und interner Kostenstrukturen variieren. Es ist dem Mauterheber jedoch unzumutbar und aus Gründen der Gleichbehandlung der EETS-Anbieter auch nicht zulässig, individuell auf jegliche solcher Voraussetzungen mit einer unterschiedlichen Vergütung zu reagieren. V.1.2. Leistungen mit Zuordnung zum Entgelt automatisches Verfahren Alle in diesem Abschnitt aufgeführten Leistungen mit Zuordnung zum Entgelt automatisches Verfahren werden für den Betrachtungszeitraum eines Kalendermonats auf die Anzahl der aktiven Fahrzeuggeräte umgelegt. Manche der Leistungen skalieren nicht direkt mit der Anzahl der Fahrzeuggeräte, sondern zum Beispiel mit der Anzahl der Nutzer. Aus Gründen der Reduzierung der Komplexität des Vergütungsmodells sowie der eindeutigen Bestimmbarkeit der dem Vergütungsmodell zugrunde liegenden Parameter durch den Mauterheber, wird einheitlich die Skalierung über die Zahl der aktiven Fahrzeuggeräte verwendet. Bei der Ermittlung der Höhe des Entgelts automatisches Verfahren wird die Zahl der durchschnittlich pro Monat aktiven Fahrzeuggeräte des Hauptdiensteanbieters herangezogen, da auch dessen Kosten für die Herleitung verwendet wurden. Das Entgelt automatisches Verfahren für die Vergütungsperiode ab dem 01.03.2023 wird gemäß dem Verfahren in Nummer 2.1 der Anlage 9 zum EETS-Zulassungsvertrag indexiert.
1. Leistungen der Nutzeranmeldung/ -abmeldung/ -betreuung Die Leistungen umfassen alle Aspekte der Nutzerbetreuung und insbesondere der An- und Abmeldung von Nutzern und Fahrzeugen. Die Erbringung der Leistungen erfordert dabei die Unterstützung durch IT-Systeme (zum Beispiel CRM-System). Personalkosten für die Nutzerbetreuung (zum Beispiel Customer Care Center) sind dem Nutzungs- und Zahlungsprovisionsentgelt zugeordnet. Die Höhe der Vergütung wurde auf Basis der Implementierungs- und Betriebskosten des Hauptdiensteanbieters abgeschätzt. Die für die Vergütung herangezogenen Kosten des Hauptdiensteanbieters beinhalten auch die notwendigen Testkosten für die IT- Systeme vor ihrer Produktivsetzung. Die Implementierungskosten wurden über die angenommene Nutzungsdauer abgeschrieben. In den Implementierungs- und Betriebskosten sind auch Kosten für die in den IT-Systemen notwendigen Funktionen zur Ermittlung der CO2-Emissionsklasse eines Fahrzeugs und die Speicherung der für die Ermittlung herangezogenen Dokumente des Fahrzeugs enthalten. Da die Leistungen auch mautdomänenübergreifend genutzt werden können, erfolgt die Anwendung des Synergieeffekts, das heißt die abgeschätzten Kosten werden mit 25 % nur anteilig vergütet. Die EETS-Anbieter erhalten einen Aufschlag auf die Vergütung gegenüber den Kosten des Hauptdiensteanbieters, da sie umfangreichere Verpflichtungen treffen, zum Beispiel für den Abgleich der registrierten Fahrzeugparameter mit den Zulassungspapieren, der Verwaltung von Sperrlisten oder der Generierung von Nutzerlisten. 2. Leistungen der Fahrzeuggeräte-Ausgabe/Bereitstellung/Rückgabe Die Leistungen umfassen sowohl die Beschaffungskosten der Fahrzeuggeräte-Hardware und ihre Distribution an die Nutzer, die Implementation und Betrieb der dafür notwendigen IT-Systeme als auch das Personal für den Betrieb der Fahrzeuggeräte-Logistik. Die für die Vergütung herangezogenen Kosten des Hauptdiensteanbieters beinhalten auch die notwendigen Testkosten für die Fahrzeuggeräte-Hardware und die IT-Systeme der Fahrzeuggeräte-Logistik vor ihrer Produktivsetzung. Die Implementierungskosten wurden über die angenommene Nutzungsdauer abgeschrieben. Für die Beschaffungskosten der Fahrzeuggeräte-Hardware wurde ein in der Vergütungsperiode durchschnittlich realisierbarer Marktpreis für ein Windshield-Gerät angesetzt, der über eine angenommene Nutzungsdauer abgeschrieben wird. Für die Herleitung der Höhe der Vergütung für die Fahrzeuggeräte-Logistik wurden die Kosten des Servicepartnernetzes und die Kosten der dafür notwendigen IT-Systeme und Personalkosten herangezogen. Die Implementierungskosten wurden über die angenommene Nutzungsdauer abgeschrieben. Da die Leistungen auch mautdomänenübergreifend genutzt werden können, erfolgt die Anwendung des Synergieeffekts in Höhe von 25 % der Kosten des Hauptdiensteanbieters. Die EETS-Anbieter erhalten einen geringfügigen Abschlag auf die Vergütung des Hauptdiensteanbieters, da sie vertraglich nicht verpflichtet sind, ein flächendeckendes Netz von Servicepartnern für Ein- und Ausbau sowie Überprüfung von Fahrzeuggeräten zu betreiben. 3. Fahrzeuggeräte/Erkennungsverfahren Die Leistungen umfassen alle Aufwände für die Software der Fahrzeuggeräte einschließlich der notwendigen zentralseitigen Systeme für das Management der Fahrzeuggeräte einschließlich der dafür notwendigen Personalkosten. Weiterhin werden die Kosten der Mobilkommunikation der Fahrzeuggeräte erfasst. Auch gehen die Kosten für die IT-Systeme und die notwendigen Personalkosten für die Betreuung des Prozesses der Erkennung von mautpflichtigen Abschnitten auf Basis der erhobenen Positionsdaten sowie deren Tarifierung ein, wobei diese nur für EETS-Anbieter berücksichtigt werden, die den MED nicht nutzen. Die Höhe der Vergütung für die Software der Fahrzeuggeräte und zugehörigen zentralen Systeme wurde auf Basis der Implementierungs- und Betriebskosten des Hauptdiensteanbieters abgeschätzt. Die für die Vergütung herangezogenen Kosten des Hauptdiensteanbieters beinhalten auch die notwendigen Testkosten für die Fahrzeuggeräte-Software und IT-Systeme vor ihrer Produktivsetzung. Die Implementierungskosten wurden über die angenommene Nutzungsdauer abgeschrieben. Eine Reihe von Funktionen der Software der Fahrzeuggeräte kann mautdomänenübergreifend genutzt werden, wie beispielsweise das Betriebssystem, die Applikationsschnittstelle und das Gerätemanagement einschließlich der Fernwartung. Zusätzlich wird davon ausgegangen, dass der Teil der Fahrzeuggeräte-Software zur Unterstützung von satellitenbasierten Mautsystemen als Grundlage für die individuelle Implementierung in all diesen EETS-Gebieten genutzt werden kann. Deshalb erfolgt die Anwendung des Synergieeffekts in Höhe von 50 %. Für die Fahrzeuggeräte-Kommunikationskosten wurden die durchschnittlichen Kosten des Hauptdiensteanbieters herangezogen, wobei im Sinne der Ermittlung von tatsächlich marktgerechten Kosten nur zwei der aktuell drei in Nutzung befindlichen Mobilfunkanbieter berücksichtigt wurden. Es wird davon ausgegangen, dass entsprechende Verträge für Kommunikationsdienstleistungen europaweit gelten und nur geringfügig in Bezug auf Datenmengen und Bandbreiten variieren. Aus diesem Grunde werden Synergieeffekte in Höhe von 25 % angesetzt. Die EETS-Anbieter erhalten einen Aufschlag auf die Vergütung für die Fahrzeuggeräte-Kommunikationskosten, da die Fahrzeuggeräte des Hauptdiensteanbieters nur in Ausnahmefällen im Ausland kommunizieren müssen, während davon ausgegangen wird, dass Fahrzeuggeräte der EETS-Anbieter regelmäßig im Ausland kommunizieren müssen.
Die Höhe der Vergütung für die IT-Systeme für den Prozess der Erkennung von mautpflichtigen Abschnitten wurde auf Basis der Implementierungs- und Betriebskosten des Hauptdiensteanbieters abgeschätzt. Die Implementierungskosten wurden über die angenommene Nutzungsdauer abgeschrieben. Auch wenn die Systeme für die Erkennung der mautpflichtigen Befahrungen im Grundsatz auch in anderen satellitenbasierten Mautsystemen eingesetzt werden können, gibt es jedoch eine Reihe spezieller Anforderungen im EETS-Gebiet BFStrMG wie zum Beispiel die Vorgabe einer Mauttabelle, Spezialfälle der Mauterhebung und Fahrtenbildungsregeln. Deshalb wird für letztere Leistungen kein Synergieeffekt in Ansatz gebracht. Der Mauterheber behält sich vor, insbesondere diesen Aspekt bei der regelmäßigen Aktualisierung des Vergütungsmodells zu überprüfen. 4. Mautabrechnung und Auskehr an den Mauterheber Die Leistungen umfassen die Mautabrechnung gegenüber dem Nutzer und Mautauskehr gegenüber dem Mauterheber. Die Erbringung der Leistungen erfordert dabei IT-Systeme (z. B. SAP-System). Personalkosten für die Betreuung der Mautabrechnung wurden dem Nutzungs- und Zahlungsprovisionsentgelt zugeordnet. Die Höhe der Vergütung wurde auf Basis der Implementierungs- und Betriebskosten des Hauptdiensteanbieters abgeschätzt. Die für die Vergütung herangezogenen Kosten des Hauptdiensteanbieters beinhalten auch die notwendigen Testkosten für die IT-Systeme vor ihrer Produktivsetzung. Die Implementierungskosten wurden über die angenommene Nutzungsdauer abgeschrieben. Da die IT-Systeme zur Mautabrechnung gegenüber dem Nutzer auch mautdomänenübergreifend genutzt werden können, erfolgt die Anwendung des Synergieeffekts in Höhe von 25 % der Kosten des Hauptdiensteanbieters. Die EETS-Anbieter erhalten jedoch einen Aufschlag, um die individuellen Anforderungen des EETS-Gebiets BFStrMG an die Mautabrechnung zu berücksichtigen. Die personelle Betreuung des Auskehrprozesses wird ohne Synergieeffekt in der Vergütung berücksichtigt, da es sich hier um spezielle Anforderungen des Mauterhebers handelt, zum Beispiel die Auskehr ohne Rechnungsstellung des Mauterhebers sowie die Erstellung spezieller Reports. 5. Datenaustausch mit dem Mauterheber Die Leistungen umfassen alle Aufwände der EETS-Anbieter für den Betrieb der geforderten technischen Schnittstellen zum System des Mauterhebers und für den Fall der Nutzung des MED auch zum System des Hauptdiensteanbieters. Die Erbringung der Leistungen erfordert dabei IT-Systeme (zum Beispiel eine Datenaustauschplattform) und Personal. Die Höhe der Vergütung wurde auf Basis der Implementierungs- und Betriebskosten des Hauptdiensteanbieters abgeschätzt. Die für die Vergütung herangezogenen Kosten des Hauptdiensteanbieters beinhalten auch die notwendigen Testkosten für die IT-Systeme vor ihrer Produktivsetzung. Die Implementierungskosten wurden über die angenommene Nutzungsdauer abgeschrieben. Für die Nutzung der Back-Office-Kommunikation ist gemäß der Durchführungsverordnung (EU) 2020/204 zukünftig ein technischer Standard zu verwenden. Die technische Umsetzung im EETS-Gebiet BFStrMG ist bereits mit diesem technischen Standard kompatibel. Derzeit gibt es noch wesentliche Unterschiede in der Implementierung in den EETS-Gebieten. Es wird jedoch davon ausgegangen, dass zumindest die Umsetzung der Schnittstellen zur Unterstützung von satellitenbasierten Mautsystemen als Grundlage für die individuelle Implementierung in allen satellitenbasierten EETS-Gebieten genutzt werden kann. Deshalb erfolgt die Anwendung des Synergieeffekts in Höhe von 50 % in Bezug auf die Implementation und den Betrieb der Schnittstellen zum Mauterheber. Die EETS-Anbieter erhalten wegen spezifischer Anforderungen des Mauterhebers an die Schnittstellen und ihren Betrieb bei der Umsetzung des Datenaustauschs einen Aufschlag auf die Vergütung im Vergleich zu den Kosten des Hauptdiensteanbieters. Für die Implementierung und den Betrieb der Schnittstellen zum MED erfolgt keine Anwendung des Synergieeffekts. Auch wenn die Schnittstellen auf technischen Standards basieren, ist die aktuelle Umsetzung im EETS-Gebiet BFStrMG noch neuartig und mit einer Reihe individueller Anforderungen verbunden. V.1.3. Leistungen mit Zuordnung zum Nutzungs- und Zahlungsprovisionsentgelt Die Leistungen umfassen die Aufwände der EETS-Anbieter für die allgemeine Nutzerbetreuung und die Betreuung der Mautabrechnung gegenüber dem Nutzer, Aufwände zur Umsetzung von Anforderungen des Datenschutzes sowie die Unterstützung der Aktivitäten der Betreiberüberwachung. Zudem sind enthalten die Zahlungsabwicklung mit dem Nutzer über die verschiedenen Zahlungsmittelanbieter, Bonitätsprüfungen und Erteilung von Zahlungsgarantien sowie die Mautausfallhaftung und die Bankgarantie. Das Nutzungsentgelt umfasst die Personalkosten, die im Rahmen der allgemeinen Nutzerbetreuung sowie der Betreuung der Mautabrechnung entstehen, in Höhe der Kosten des Hauptdiensteanbieters. Dabei wurden auch ergänzende Personalkosten berücksichtigt, die für Prüfungen zur Bestimmung der CO2-Emissionsklassen im Zusammenhang mit der kommenden Einführung einer CO2-Maut erforderlich sind. Es wird davon ausgegangen, dass sich ein Teil der notwendigen Betreuung auf mautdomänenübergreifende Nutzeranfragen bezieht. Es wird deshalb der Synergieeffekt in Höhe von 50 % in Ansatz gebracht.
Aufwände für den Datenschutz umfassen die Umsetzung allgemeiner und spezialrechtlicher Datenschutzanforderungen, die sich im Rahmen des Betriebs des Mautsystems ergeben. Auch der Hauptdiensteanbieter hat die entsprechenden Anforderungen umzusetzen. Dafür werden Personalkosten vergütet. Für die Festsetzung der Höhe der Vergütung der EETS-Anbieter wurde dabei berücksichtigt, dass sich die Datenschutzanforderungen beim Hauptdiensteanbieter auch auf die Leistungsbereiche des manuellen Verfahrens und der Kontrolle beziehen, die auf den EETS-Anbieter nicht zutreffen. Synergieeffekte werden nicht angesetzt, auch wenn bestimmte allgemeine Datenschutzanforderungen mautdomänenübergreifend umgesetzt werden müssen. Vielmehr wird davon ausgegangen, dass mit steigender Fahrleistung bzw. steigendem Mautvolumen die Anzahl der datenschutzrechtlich zu bearbeitenden Sachverhalte steigt. Systemkosten für die Umsetzung der Anforderungen sind in den für die einzelnen Systeme abgeschätzten Implementierungs- und Betriebskosten abgedeckt, da die Anforderungen zum Datenschutz im Systemdesign berücksichtigt sind. Aufwände für die Betreiberüberwachung umfassen die personelle Unterstützung der Betreiberüberwachung des Mauterhebers. Dies betrifft insbesondere die personelle Unterstützung bei der Ermittlung und Abstimmung der vertraglich vereinbarten Quoten oder Audits der Betreiberüberwachung. Auch der Hauptdiensteanbieter hat die entsprechenden Anforderungen umzusetzen. Dafür werden Personalkosten vergütet. Für die Festsetzung der Höhe der Vergütung der EETS-Anbieter wurde dabei berücksichtigt, dass sich die Betreiberüberwachung beim Hauptdiensteanbieter auch auf die Leistungsbereiche des manuellen Verfahrens und der Kontrolle bezieht, die auf den EETS-Anbieter nicht zutreffen. Synergieeffekte werden nicht angesetzt, da angenommen wird, dass die Unterstützung der Betreiberüberwachung individuellen Anforderungen des EETS-Gebiets BFStrMG entspricht. Vielmehr wird davon ausgegangen, dass mit steigender Fahrleistung bzw. steigendem Mautvolumen ein höherer Aufwand für die Unterstützung in der Betreiberüberwachung entsteht, beispielsweise bei der Bewertung von Schlechtfällen der jeweiligen Quoten. Systemkosten sind in den für die einzelnen Systeme abgeschätzten Implementierungs- und Betriebskosten abgedeckt, da die Anforderungen zur Unterstützung der Betreiberüberwachung im Systemdesign berücksichtigt sind. Der Anteil des Nutzungsentgelts wird bestimmt, indem der wie vorstehend beschrieben ermittelte Aufwand für die allgemeine Nutzerbetreuung und die Betreuung der Mautabrechnung gegenüber dem Nutzer, den Datenschutz sowie die Unterstützung der Betreiberüberwachung auf ein Jahr berechnet und als Summe ins Verhältnis zum jährlichen Mautvolumen gesetzt wird, welches im automatischen Mauterhebungsverfahren des Hauptdiensteanbieters erhoben wird. Der Aufwand des EETS-Anbieters für die Zahlungsabwicklung mit dem Nutzer ist abhängig vom abgerechneten Mautvolumen und dem genutzten Zahlungsmittel. Für die Bestimmung des Anteils des Zahlungsprovisionsentgelts wurden die prozentuale Verteilung der Zahlungsmittel beim Hauptdiensteanbieter und die jeweiligen Zahlungsprovisionen und damit verbundene Kosten zum Zeitpunkt des Inkrafttretens der Richtlinie (EU) 2019/520 herangezogen. Dabei wurden aus Gründen der Vergleichbarkeit ausschließlich „post payment“ Zahlungsmittel des Hauptdiensteanbieters berücksichtigt. Das vom Hauptdiensteanbieter angebotene Guthabenverfahren bleibt unberücksichtigt. EETS-Anbieter erhalten einen Aufschlag auf die so ermittelten Kosten des Hauptdiensteanbieters, da die EETS-Anbieter im Gegensatz zum Hauptdiensteanbieter eine Bankgarantie für einen durchschnittlichen monatlichen Mautumsatz beibringen müssen. Sie übernehmen ebenfalls die Mautausfallhaftung für Nutzer für den Fall von fehlerhaft deklarierten statischen Fahrzeugparametern (einschließlich der CO2-Emissionsklasse) sowie bei nachgewiesenen Mautverstößen, bei denen der Mauterheber Nacherhebungen nicht gegenüber dem Nutzer durchsetzen kann. V.2. Vergütung für die Erreichung von Unternehmenszielen Gemäß Anlage 5 des EETS-Zulassungsvertrags muss der EETS-Anbieter eine Erfassungsquote von mindestens 99,500 % erreichen. Sofern der EETS-Anbieter im Betrachtungszeitraum diese Quote überschreitet, erhält er einen Bonus von 12,5 % der fiktiven Mauteinnahmen, die sich durch die höhere Erfassungsquote ergeben. V.3. Vergütung für Änderungsverlangen des Mauterhebers Die Herleitung der Vergütung für Änderungsverlangen des Mauterhebers ist ausführlich in Nummer 2.3 der Anlage 9 zum EETS-Zulassungsvertrag beschrieben. V.4. Gewinn- und Wagniszuschlag Der Hauptdiensteanbieter erhält auf die Vergütung der erbrachten Leistungen einen Gewinn- und Wagniszuschlag. Dementsprechend erhält der EETS-Anbieter ebenso einen Zuschlag auf die Bestandteile „Betriebsentgelt“, „Entgelt automatisches Verfahren“ sowie „Nutzungs- und Zahlungsprovisionsentgelt“. Durch die unterschiedliche Marktpositionierung von Hauptdiensteanbieter und EETS-Anbietern erhalten die EETS- Anbieter einen höheren Gewinn- und Wagniszuschlag auf die Bestandteile „Betriebsentgelt“ und „Entgelt automatisches Verfahren“ als der Hauptdiensteanbieter, um die höheren Risiken abzudecken.“
Artikel 2
Weitere Änderung der EEMD-Gebietsvorgabenverordnung
In der Anlage 1 der EEMD-Gebietsvorgabenverordnung vom 20. März 2018 (BAnz AT 27.03.2018 V1), die zuletzt
durch Artikel 1 dieser Verordnung geändert worden ist, wird die Tabelle wie folgt geändert:
1. Die Nummer 30_EET wird wie folgt gefasst:
Technisch-organisatorische
Vorgaben
„30_EET Gebührenklassen Die Maut muss nach Gebührenklassen differenziert werden können.
Die für die Maut relevanten Gebührenklassen ergeben sich aus
1. der Fahrzeugklassifizierung (Anzahl der Achsen, Euro-Emissions
klasse, Gewichtsklassen nach technisch zulässiger Gesamtmasse,
Kohlenstoffdioxid-Emissionsklasse),
2. der Ortsklasse eines Streckenabschnitts,
3. der Zeitklasse des Zeitpunkts der mautpflichtigen Nutzung.
Die Zuordnung der Gebührenklassen zu den anzuwendenden Maut
sätzen ist im BFStrMG festgelegt.
Die bei Einfahrt in einen mautpflichtigen Streckenabschnitt vorliegen
den gebührenrelevanten Parameter sind als Basis für die Mautberech
nung zu verwenden.
Änderungen und/oder Erweiterungen der Gebührenklassen sind mög
lich (siehe Nummer 39).“
2. Die Nummer 30_MED wird wie folgt gefasst:
„30_MED Gebührenklassen Der EETS-Anbieter muss die Positionsdaten und Merkmale der
Fahrzeugklassifizierung über die SST 005 vollständig übermitteln, um
dem Mauterheber eine Differenzierung der Maut nach Gebühren
klassen zu ermöglichen.
Die für die Maut relevanten Gebührenklassen ergeben sich aus
1. der Fahrzeugklassifizierung (Anzahl der Achsen, Euro-Emissions
klasse, Gewichtsklassen nach technisch zulässiger Gesamtmasse,
Kohlenstoffdioxid-Emissionsklasse),
2. der Ortsklasse eines Streckenabschnitts,
3. der Zeitklasse des Zeitpunkts der mautpflichtigen Nutzung.
Die Zuordnung der Gebührenklassen zu den anzuwendenden Maut
sätzen ist im BFStrMG festgelegt.
Änderungen und/oder Erweiterungen der Gebührenklassen sind mög
lich (siehe Nummer 39).“
3. In der Nummer 31_EET werden in Spalte 3 im Absatz 3 nach den Wörtern „z. B.“ die Wörter
„Sattelzugmaschinen, deren zulässiges Gesamtgewicht ohne Auflieger weniger als 7,5 t beträgt“ durch die
Wörter „ab dem 01.07.2024 situative Handwerkerausnahme gemäß § 1 Absatz 2 Satz 1 Nummer 10
BFStrMG“ ersetzt.
4. In der Nummer 31_MED werden in Spalte 3 im Absatz 3 nach den Wörtern „z. B.“ die Wörter
„Sattelzugmaschinen, deren zulässiges Gesamtgewicht ohne Auflieger weniger als 7,5 t beträgt“ durch die
Wörter „ab dem 01.07.2024 situative Handwerkerausnahme gemäß § 1 Absatz 2 Satz 1 Nummer 10
BFStrMG“ ersetzt.
5. Die Nummer 41 wird wie folgt geändert:
a) In Absatz 1 Nummer 2 werden nach dem Wort „Beteiligtendaten“ die Wörter „sowie für die Mauthöhe
maßgeblichen Merkmalen des Fahrzeugs oder der Fahrzeugkombination“ eingefügt.
b) In Absatz 1 Nummer 3 werden nach dem Wort „Beteiligtendaten“ die Wörter „und für die Mauthöhe
maßgeblichen Merkmalen des Fahrzeugs oder der Fahrzeugkombination“ eingefügt.
c) Am Ende von Absatz 3 werden nach dem Wort „Beteiligtendaten“ die Wörter „und für die Mauthöhe
maßgeblichen Merkmalen des Fahrzeugs oder der Fahrzeugkombination“ eingefügt.
6. In der Nummer 48 werden nach dem Wort „Erhebungsstatus“ die Wörter „„nicht erhebungsbereit““ durch die
Wörter „„noGoContractual (2)“ gemäß der Schnittstellenspezifikation SST 301“ ersetzt.
7. In der Nummer 49 wird Absatz 2 wie folgt gefasst:
„Zur Überprüfung der Korrektheit der in der Registrierung angegebenen Euro-Emissionsklasse, der technisch
zulässigen Gesamtmasse sowie der Kohlenstoffdioxid-Emissionsklasse (beziehungsweise der zu ihrer
Ermittlung notwendigen Fahrzeugeigenschaften) muss der EETS-Anbieter diese Informationen mit
entsprechenden, vom EETS-Nutzer bereitzustellenden Nachweisdokumenten abgleichen. Diese
Nachweisdokumente können die Zulassungsbescheinigung Teil I, die Konformitätsbescheinigung (COC), die
Kundeninformationsdatei (CIF) oder ein Sachverständigengutachten zum Fahrzeug sein. Sofern die
Registrierung eines Fahrzeugs mit der Kohlenstoffdioxid-Emissionsklasse 1 erfolgen soll, kann auf ihre
Validierung verzichtet werden.“
Artikel 3
Änderung der EEMD-Zulassungsverordnung
Die EEMD-Zulassungsverordnung vom 20. März 2018 (BAnz AT 27.03.2018 V2), die zuletzt durch Artikel 1 der
Verordnung vom 2. Februar 2023 (BGBl. 2023 I Nr. 32) geändert worden ist, wird wie folgt geändert:
1. Die Eingangsformel wird wie folgt geändert:
a) Die Abkürzung „BAG“ wird durch die Abkürzung „BALM“ ersetzt.
b) Das Wort „Güterverkehr“ wird durch die Wörter „Logistik und Mobilität“ ersetzt.
2. Die Anlage I wird wie folgt geändert:
a) Die Überschrift wird wie folgt geändert:
aa) Die Wörter „Verkehr und digitale Infrastruktur (BMVI)“ werden durch die Wörter „Digitales und Verkehr
(BMDV)“ ersetzt.
bb) Die Wörter „Güterverkehr (BAG)“ werden durch die Wörter „Logistik und Mobilität (BALM)“ ersetzt.
b) § 2 wird wie folgt gefasst:
aa) Absatz 1 wird wie folgt gefasst:
„(1) Bestandteile dieses Vertrags sind
1. der Nachweis der Registrierung als Anbieter nach § 4 MautSysG,
2. die Zusatzvereinbarung (Anlage 1), soweit von den Parteien als erforderlich erachtet,
3. Verfahren zur Feststellung der Gebrauchstauglichkeit Dokumente A und B (Anlagen 2 und 3),
4. der Zeit- und Projektplan (Anlage 4),
5. die Entgeltordnung (Anlage 5),
6. das Glossar (Anlage 6),
7. die Erklärung über die Gewährung einer Bankgarantie oder eines gleichwertigen Finanzinstruments,
8. gegebenenfalls Erklärungen/Schriftwechsel (Anlage 7).“
bb) Absatz 2 wird wie folgt gefasst:
„(2) Bei Widersprüchen in diesem Vertrag gelten nacheinander
1. dieser Vertrag,
2. die Zusatzvereinbarung (Anlage 1),
3. gegebenenfalls Erklärungen/Schriftwechsel (Anlage 7),
4. Verfahren zur Feststellung der Gebrauchstauglichkeit Dokumente A und B (Anlagen 2 und 3),
5. der Zeit- und Projektplan (Anlage 4),
6. das Glossar (Anlage 6).“
c) § 5 Absatz 4 wird wie folgt gefasst:
„(4) Der Mauterheber übermittelt dem Anbieter insbesondere folgende Dokumente:
1. Spezifikationen der Schnittstellen des Mauterhebers,
2. Verfahrensbeschreibung für die Durchführung der Gebrauchstauglichkeitsprüfung,
3. Muster-Zulassungsvertrag,
4. Verfahren zur Feststellung der Gebrauchstauglichkeit – Dokument B – Prüfkonzept nebst Anlagen.“
d) In § 7 Absatz 3 Satz 4 wird das Wort „Güterverkehr“ durch die Wörter „Logistik und Mobilität“ ersetzt.
e) § 8 Absatz 1 wird wie folgt gefasst:
„(1) Der Anbieter ist verpflichtet, für die im Rahmen dieser Vereinbarung ausgeführten Tätigkeiten auf
eigene Kosten eine Betriebshaftpflichtversicherung mit mindestens den folgenden Inhalten abzuschließen
und während der Laufzeit dieser Vereinbarung aufrechtzuerhalten:
1. Betriebsbeschreibung: „Mauterhebung als EETS-Anbieter auf den Straßen des EETS-Mautgebiets
BFStrMG inklusive aller betriebs- und branchenüblichen, betriebs- und branchennotwendigen und im
Betrieb der Versicherungsnehmerin bestehenden Zusatzrisiken“,
2. Deckung für gesetzliche Haftpflichtansprüche wegen Personen-, Sach- und daraus folgenden
Vermögensschäden mit einer Deckungssumme von mindestens 15 Mio. Euro (in Worten: fünfzehn
Millionen Euro) je Schadensfall. Der EETS-Anbieter muss sicherstellen, dass zu jederzeit ein
ausreichender Versicherungsschutz im Sinne des Satz 1 besteht; dies gilt auch nach Eintritt eines
Versicherungsfalles und der Inanspruchnahme der Versicherung.“
f) § 15 Absatz 3 wird wie folgt gefasst:
„(3) Der Anbieter verpflichtet sich, während des gesamten Prüfverfahrens und bis zu dem Zeitpunkt, in
dem die Daten mit Zustimmung des Mauterhebers gemäß § 16 unwiderruflich gelöscht oder vernichtet
werden, sicherzustellen, dass der Schutz der personenbezogenen und personenbeziehbaren Daten den
Anforderungen des deutschen und europäischen Datenschutzrechts entspricht. Der Anbieter wird darüber
hinaus jederzeit die erforderlichen technischen und organisatorischen Sicherheitsmaßnahmen nach dem
aktuellen Stand der Technik ergreifen, um die seinem Zugriff unterliegenden Daten, Prozesse und Systeme
sowie den Datenaustausch mit dem Mauterheber zu schützen, sodass jederzeit hinsichtlich Vertraulichkeit,
Verfügbarkeit und Integrität der Daten, Prozesse und Systeme ein dem im Einzelfall festgestellten
Schutzbedarf entsprechender Schutz vor technischer oder organisatorischer Kompromittierung
gewährleistet ist. Dabei ist für alle Vorgänge von dem jeweils höchsten Schutzbedarf auszugehen, die
1. personenbezogene und personenbeziehbare Daten und
2. den Datenaustausch oder Systemberührungen mit dem Mauterheber
betreffen.
Der Anbieter wird insbesondere jederzeit die erforderlichen technischen und organisatorischen
Sicherheitsmaßnahmen ergreifen, um alle beteiligten Daten, Systeme und Prozesse zu schützen, zu
überwachen und bei Kenntnis eines realisierten oder potenziellen Verlustes der Vertraulichkeit,
Verfügbarkeit oder Integrität von Daten, Systemen, oder Prozessen (insgesamt „Sicherheitsvorfall“) den
Mauterheber unverzüglich zu informieren und unverzüglich in der jeweils erforderlichen Art und Weise zu
reagieren, sodass insbesondere der Sicherheitsvorfall ausgeräumt oder seine Auswirkungen sowie damit
verbundene Schäden und Beeinträchtigungen des Mauterhebers oder Dritter soweit wie möglich begrenzt
und reduziert werden. Der Mauterheber kann verlangen, auf Veranlassung des Anbieters das
Informationsschutz-Management-System des Anbieters im Rahmen eines Audits von einem externen
Sachverständigen prüfen zu lassen.“
g) In § 16 Absatz 6 werden die Wörter „dieses Paragraphen gelten“ durch die Wörter „dieser Vorschrift gilt“
ersetzt.
h) § 17 wird wie folgt geändert:
aa) Absatz 3 wird wie folgt gefasst:
„(3) Nicht als Dritte im Sinne dieses Paragraphen gelten auf Seiten des Anbieters solche Personen,
die
1. mit Aufgaben befasst sind, die im Zusammenhang mit dieser Vereinbarung oder dem Prüfverfahren
stehen und/oder bestimmungsgemäß mit der Erfüllung der nach dieser Vereinbarung gegenüber dem
Mauterheber geschuldeten Verpflichtungen beschäftigt sind,
2. gegenüber dem Anbieter zur Vertraulichkeit insbesondere auch bezüglich der vertraulichen Daten
verpflichtet sind und
3. die vertraulichen Daten zur Ausführung der ihnen zugewiesenen Aufgaben benötigen.“
bb) Absatz 8 wird wie folgt gefasst:
„(8) Nicht als Dritte im Sinne dieses Paragraphen gelten auf Seiten des Mauterhebers solche
Personen, die
1. mit Aufgaben befasst sind, die im Zusammenhang mit dieser Vereinbarung oder dem Prüfverfahren
stehen und/oder bestimmungsgemäß mit der Erfüllung der nach dieser Vereinbarung gegenüber dem
Mauterheber geschuldeten Verpflichtungen beschäftigt sind,
2. gegenüber dem Mauterheber zur Vertraulichkeit insbesondere auch bezüglich der vertraulichen Daten
verpflichtet sind und
3. die vertraulichen Daten zur Ausführung der ihnen zugewiesenen Aufgaben benötigen.“
i) § 20 Absatz 5 wird wie folgt gefasst:
„(5) Der Mauterheber haftet nicht für eine Einschränkung oder Schäden des EETS-Anbieters aufgrund
1. von Maßnahmen des Baus, Betriebs, der Reparatur oder der Unterhaltung von Straßen des
mautpflichtigen Straßennetzes,
2. von Änderungen, Beschränkungen oder Einschränkungen des mautpflichtigen Streckennetzes,
3. aus der Bereitstellung und Durchführung der EETS-Mauterkennung für EETS-Anbieter durch einen dritten
Dienstleister. Davon ausgenommen ist die Erbringung des Mauterhebungsdienstes durch den nationalen
Betreiber im Auftrag des Mauterhebers.“
j) § 23 Absatz 3 wird wie folgt gefasst:
„(3) Eine Kündigung dieser Vereinbarung ist dem Anbieter jederzeit, dem Mauterheber nur aus wichtigem
Grund möglich. Ein wichtiger Grund liegt vor, wenn dem Mauterheber unter Berücksichtigung aller Umstände
des Einzelfalls und unter Abwägung der beiderseitigen Interessen die Fortsetzung des Vertragsverhältnisses
bis zur vereinbarten Beendigung oder bis zum Ablauf einer Kündigungsfrist nicht zugemutet werden kann,
insbesondere,
1. weil die Registrierung des Anbieters gemäß § 4 MautSysG oder bei der zuständigen Behörde eines
anderen Mitgliedstaats der Europäischen Union oder eines anderen Vertragsstaats des Abkommens
über den Europäischen Wirtschaftsraum weggefallen ist oder die sachlichen Voraussetzungen hierfür
vorliegen,
2. die Prüfung der Zulassungsvoraussetzungen nach § 10 Absatz 2 Satz 1 MautSysG ergeben hat, dass
diese nicht vorliegen und nicht geschaffen werden können,
3. wenn es wiederholt zu nicht unerheblichen Verzögerungen der Durchführung des Prüfverfahrens kommt,
die der Anbieter zu vertreten hat,
4. wenn der Anbieter gegen seine Verpflichtung zur unverzüglichen und vollständigen Auskehr der Maut
gemäß § 6 Absatz 2 verstößt oder die Sicherheit der Mauteinnahmen gemäß § 6 Absatz 3 nicht oder nicht
mehr gewährleistet ist,
5. wenn der Anbieter seine Verpflichtungen aus § 7 dieser Vereinbarung nicht erfüllt,
6. wenn der Anbieter nicht nur vorübergehend den Versicherungsschutz gemäß § 8 dieser Vereinbarung
nicht oder nicht in ausreichender Weise besitzt,
7. wenn der Anbieter ohne vorherige Zustimmung des Mauterhebers nach § 9 Rechte aus dieser
Vereinbarung an Dritte abgetreten hat,
8. wenn der Anbieter seine Verpflichtung zur Rückwirkungsfreiheit seines Mautdienst-Teilsystems gemäß
§ 11 dieser Vereinbarung verletzt und dem Mauterheber dadurch ein nicht unerheblicher Schaden
entstanden ist,
9. wenn der Anbieter in nicht unerheblicher Weise gegen seine Verpflichtungen zur Gewährleistung des
Datenschutzes gemäß § 14 dieser Vereinbarung verstoßen hat,
10. wenn der Anbieter in nicht unerheblicher Weise gegen seine Verpflichtungen zur Gewährleistung der
Datensicherheit gemäß § 15 dieser Vereinbarung verstoßen hat,
11. wenn der Anbieter in nicht unerheblicher Weise gegen seine Verpflichtungen im Zusammenhang mit der
Aufbewahrung von vertraulichen Unterlagen gemäß § 16 dieser Vereinbarung verstoßen hat,
12. wenn der Anbieter wiederholt, das heißt nach einem einmaligen Verstoß erneut in nicht unerheblicher
Weise gegen die Regelungen zur Geheimhaltung und Vertraulichkeit gemäß §17 dieser Vereinbarung
verstoßen hat.
Liegt ein wichtiger Grund für die Kündigung durch den Mauterheber vor, ist der Mauterheber zur Kündigung
ohne Einhaltung einer Frist berechtigt.“
k) In § 27 werden die Absätze 1 bis 3 wie folgt gefasst:
„(1) Sämtliche Mitteilungen gemäß oder im Zusammenhang mit dieser Vereinbarung sind in Textform und
in deutscher Sprache abzufassen und an die mit dem Mauterheber abgestimmten E-Mail-Adressen zu
richten. Satz 1 gilt nicht für förmliche Zustellungen, diese sind schriftlich und in deutscher Sprache
abzufassen.
(2) Förmliche Zustellungen an den Mauterheber in Zusammenhang mit dieser Vereinbarung sind an die
folgende Anschrift zu richten:
Bundesamt für Logistik und Mobilität (BALM), Werderstraße 34, 50672 Köln
(Empfangsberechtigter).
(3) Mitteilungen an den Anbieter im Zusammenhang mit dieser Vereinbarung sind an die mit dem Anbieter
abgestimmten E-Mail-Adressen zu richten.“
l) Die Anlage 2 wird wie folgt geändert:
aa) Die Überschrift wird wie folgt geändert:
aaa) Die Wörter „Verkehr und digitale Infrastruktur (BMVI)“ werden durch die Wörter „Digitales und
Verkehr (BMDV)“ ersetzt.
bbb) Die Wörter „Güterverkehr (BAG)“ werden durch die Wörter „Logistik und Mobilität (BALM)“ ersetzt.
bb) Die Tabelle wie folgt geändert:
aaa) In der Position „Schnittstellenprüfung“ wird in der Spalte „Mauterheber“ nach den Wörtern
„Testumgebung des“ das Wort „BAG“ durch das Wort „BALM“ ersetzt.
bbb) In der Position „Kompatibilitätstests“ wird in der Spalte „Mauterheber“ nach den Wörtern „und des“
das Wort „BAG“ durch das Wort „BALM“ ersetzt.
ccc) In der Position „EA-Fahrtests (optional)“ wird in der Spalte „Mauterheber“ nach den Wörtern „und
des“ das Wort „BAG“ durch das Wort „BALM“ ersetzt.
ddd) In der Position „Probebetrieb“ wird in der Spalte „Mauterheber“ nach den Wörtern „und des“ das
Wort „BAG“ durch das Wort „BALM“ ersetzt.
eee) In der Position „Pilotbetrieb“ wird in der Spalte „Mauterheber“ nach den Wörtern „und des“ das Wort
„BAG“ durch das Wort „BALM“ ersetzt.
m) Die Anlage 3 wird wie folgt geändert:
aa) Die Überschrift wird wie folgt geändert:
aaa) Die Wörter „Verkehr und digitale Infrastruktur (BMVI)“ werden durch die Wörter „Digitales und
Verkehr (BMDV)“ ersetzt.
bbb) Die Wörter „Güterverkehr (BAG)“ wird durch die Wörter „Logistik und Mobilität (BALM)“ ersetzt.
bb) Die Tabelle 2 wird wie folgt geändert:
aaa) In der Position „Vorgabe Nr. 14“ werden in der Spalte „Schwerpunkte der Prüfung“ nach den Wörtern
„„Bordgerät- straßenseitiges Kontrollequipment““ die Wörter „„Blocklist/Sperrliste““ durch das Wort
„„Sperrliste““ ersetzt.
bbb) In der Position „Vorgabe Nr. 14“ wird in der Spalte „Schwerpunkte der Prüfung“ nach den Wörtern
„Aspekte Anbindung“ das Wort „BAG“ durch das Wort „BALM“ ersetzt.
ccc) In der Position „Vorgabe Nr. 16“ werden in der Spalte „Schwerpunkte der Prüfung“ nach den Wörtern
„„Bordgerät- straßenseitiges Kontrollequipment““ die Wörter „„Blocklist/Sperrliste““ durch das Wort
„„Sperrliste““ ersetzt.
ddd) In der Position „Vorgabe Nr. 16“ wird in der Spalte „Schwerpunkte der Prüfung“ nach den Wörtern
„Aspekte Anbindung“ das Wort „BAG“ durch das Wort „BALM“ ersetzt.
eee) In der Position „Vorgabe Nr. 18“ werden in der Spalte „Schwerpunkte der Prüfung“ die Wörter
„„Blocklist/Sperrliste““ durch das Wort „„Sperrliste““ ersetzt und vor den Wörtern „im System“ ein
Anführungszeichen gestrichen.
fff) In der Position „Vorgabe Nr. 18“ wird in der Spalte „Schwerpunkte der Prüfung“ nach den Wörtern
„Aspekte Anbindung“ das Wort „BAG“ durch das Wort „BALM“ ersetzt.
ggg) In der Position „Vorgabe 19“ werden in der Spalte „Kurzbeschreibung“ die Wörter „Blocklist/
Sperrliste“ durch das Wort „Sperrliste“ ersetzt.
cc) In Abschnitt 4.2 „Prüforganisation, -umgebung und Rahmenbedingungen“ werden nach den Wörtern
„Testumgebung des“ die Wörter „EETS@BAG System“ durch die Wörter „BALM Zentralsystem“ ersetzt.
dd) In der Abbildung 2 „Testumgebung Phase 1“ werden die Wörter „BAG Zentralsystem“ durch die Wörter
„BALM Zentralsystem“ ersetzt.
ee) In Abschnitt 4.4.1 „Schnittstellenprüfung“ werden in der Position „P1-SSP-002“ in der Spalte
„Bezeichnung“ die Wörter „EETS@BAG System“ durch die Wörter „BALM Zentralsystem“ ersetzt.
n) Die Anlage 1 der Anlage 3 zur Prüfvereinbarung (Anlage 1 zum Dokument B – Prüfkonzept: Prüfkatalog
„Schnittstellenprüfung“) wird wie folgt geändert:
aa) Die Überschrift wird wie folgt geändert:
aaa) Die Wörter „Verkehr und digitale Infrastruktur (BMVI)“ werden durch die Wörter „Digitales und
Verkehr (BMDV)“ ersetzt.
bbb) Die Wörter „Güterverkehr (BAG)“ werden durch die Wörter „Logistik und Mobilität (BALM)“ ersetzt.
bb) Abschnitt 2 „Prüffälle“ wird wie folgt geändert:
aaa) In der Position „P1-SSP-001.1“ wird in der Spalte „Name“ nach dem Wort „vom“ das Wort „BAG“
durch das Wort „BALM“ ersetzt.
bbb) In der Position „P1-SSP-001.2“ wird in der Spalte „Name“ nach dem Wort „zum“ das Wort „BAG“
durch das Wort „BALM“ ersetzt.
ccc) In der Position „P1-SSP-001.2“ wird in der Spalte „Beschreibung“ nach dem Wort „das“ das Wort
„BAG“ jeweils durch das Wort „BALM“ ersetzt.
ddd) In der Position „P1-SSP-001.2“ wird in der Spalte „Ziel“ nach dem Wort „das“ das Wort „BAG“ jeweils
durch das Wort „BALM“ ersetzt.
eee) In der Position „P1-SSP-001.3“ wird in der Spalte „Name“ nach dem Wort „vom“ das Wort „BAG“
durch das Wort „BALM“ ersetzt.
fff) In der Position „P1-SSP-001.4“ wird in der Spalte „Name“ nach dem Wort „zum“ das Wort „BAG“
durch das Wort „BALM“ ersetzt.
ggg) In der Position „P1-SSP-001.4“ wird in der Spalte „Beschreibung“ nach dem Wort „das“ das Wort
„BAG“ jeweils durch das Wort „BALM“ ersetzt.
hhh) In der Position „P1-SSP-001.4“ wird in der Spalte „Ziel“ nach dem Wort „das“ das Wort „BAG“ jeweils
durch das Wort „BALM“ ersetzt.
iii) In der Position „P1-SSP-001.5“ wird in der Spalte „Name“ nach dem Wort „zum“ das Wort „BAG“
durch das Wort „BALM“ ersetzt.
jjj) In der Position „P1-SSP-001.5“ wird in der Spalte „Beschreibung“ nach dem Wort „das“ das Wort
„BAG“ jeweils durch das Wort „BALM“ ersetzt.
kkk) In der Position „P1-SSP-001.5“ wird in der Spalte „Ziel“ nach dem Wort „das“ das Wort „BAG“ jeweils
durch das Wort „BALM“ ersetzt.
o) Die Anlage 2 der Anlage 3 zur Prüfvereinbarung wird (Anlage 2 zum Dokument B – Prüfkonzept: Prüfkatalog
„DSRC-Kompatibilitätstests“) wie folgt geändert:
aa) Die Überschrift wird wie folgt geändert:
aaa) Die Wörter „Verkehr und digitale Infrastruktur (BMVI)“ werden durch die Wörter „Digitales und
Verkehr (BMDV)“ ersetzt.
bbb) Das Wort „Güterverkehr (BAG)“ wird durch die Wörter „Logistik und Mobilität (BALM)“ ersetzt.
bb) Der Abschnitt 2.1 wird wie folgt geändert:
aaa) In der Überschrift zu Abschnitt 2 „Prüffälle für SST301“ wird bei dem Wort „Version 2.1.“ die Ziffer „1“
durch die Ziffer „2“ ersetzt.
bbb) In der Position „DSRC_SFXX_ACXX_0010“ wird in der Spalte „Beschreibung“ im letzten Absatz das
Wort „BAG“ durch das Wort „BALM“ ersetzt.
ccc) In der Position „DSRC_SFXX_ACXX_0010“ wird in der Spalte „Ziel“ im letzten Absatz das Wort
„BAG“ durch das Wort „BALM“ ersetzt.
ddd) In der Position „DSRC_SFXX_HNG2_0010“ werden in der Spalte „Ziel“ im ersten Absatz die Wörter
„wieder aufnimmt“ durch das Wort „wiederaufnimmt“ ersetzt.
cc) Der Abschnitt 2.2 wird wie folgt geändert:
aaa) In der Position „KonB_DezKst_SVF_FG“ wird in der Spalte „Beschreibung“ nach dem Wort
„Kontrollbehörde“ jeweils das Wort „BAG“ durch das Wort „BALM“ ersetzt.
bbb) In der Position „KonB_DezKst_SVF_FG“ wird in der Spalte „Ziel“ nach dem Wort „Kontrollbehörde“
das Wort „BAG“ durch das Wort „BALM“ ersetzt.
ccc) In der Position „KonMa_KonZ_2.0_Berichte_weiterverarbeiten_in_KonB“ wird in der Spalte
„Beschreibung“ nach dem Wort „Kontrollbehörde“ das Wort „BAG“ durch das Wort „BALM“ ersetzt.
ddd) In der Position „KonZ_2.0_DezKst_SVF“ wird im letzten Absatz nach dem Wort „Kontrollbehörde“
das Wort „BAG“ durch das Wort „BALM“ ersetzt.
dd) Der Abschnitt 3 wird wie folgt gefasst:
„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 Es soll sichergestellt
mit einem profile, das von der OBU nicht werden, dass die OBU/
unterstützt wird. Die OBU soll nicht antworten. das DSRC-Modul das
Das wird wiederholt mit einem weiteren von Profil korrekt handhabt.
der OBU nicht unterstützten profile wiederholt.
DSRC_A0BA_BI02_0010 Die Bake sendet BSTs für eine von der OBU Es soll sichergestellt
nicht unterstütze Anwendung in der werden, dass die OBU/
mandApplicationList und leerer das DSRC-Modul
nonmandApplicationList. Die OBU soll nicht applicationIds korrekt
antworten. Das wird wiederholt mit einer handhabt.
weiteren von der OBU nicht unterstützten
Anwendung in der mandApplicationList und
der vorigen Anwendung in der
nonmandApplicationList.
Name/ID Beschreibung Ziel
DSRC_A0BA_BI03_0011 Die Bake sendet BSTs für eine von der OBU Es soll sichergestellt
nicht unterstütze Anwendung mit EID in der werden, dass die OBU/
mandApplicationList und AID=20 in der das DSRC-Modul
nonmandApplicationList. Die OBU soll nicht applicationIds korrekt
antworten. handhabt.
DSRC_A0BA_BV01_0010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AIDs 1, 20 und 21 werden, dass die OBU/
durch. Anschließend sendet sie ein ECHO.rq, das DSRC-Modul die
das die OBU beantworten soll. Dann schickt Initialisierung korrekt
sie eine BST, die die OBU nicht beantworten durchführt.
soll.
DSRC_A0BA_BV02_0010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AIDs 1, 20 und 21 werden, dass die OBU/
durch. Anschließend sendet sie ein ECHO.rq, das DSRC-Modul die
das die OBU beantworten soll, und zwei Initialisierung korrekt
RELEASEs. Dann schickt sie ein weiteres durchführt.
ECHO, das die OBU nicht beantworten soll.
DSRC_A0BA_BV03_0010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AIDs 1, 20 und 21 werden, dass die OBU/
durch. Anschließend sendet sie ein ECHO.rq, das DSRC-Modul die
das die OBU beantworten soll. Der ganze Initialisierung korrekt
Vorgang wird wiederholt, wobei erst die durchführt.
manufacturerID und dann die individualId der
BST verändert wird.
DSRC_A0BA_BV04_0010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AIDs 1, 20 und 21 werden, dass die OBU/
durch. Anschließend sendet sie ein ECHO.rq, das DSRC-Modul die
das die OBU beantworten soll. Der ganze Initialisierung korrekt
Vorgang wird wiederholt, wobei die beacon durchführt.
time der BST um 256 Sekunden erhöht wird.
DSRC_A0BA_BV09_0010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AIDs 1, 20 und 21 mit werden, dass die OBU/
profile=0 und leerer profileList durch. In der das DSRC-Modul das
VST soll der Wert von profile auf 0 gesetzt sein. Profil korrekt handhabt.
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.
DSRC_A0BA_BV10_0010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AIDs 1, 20 und 21 werden, dass die OBU/
durch. Die VST wird auf ein korrektes Format das DSRC-Modul die BST
hin überprüft. mit einer korrekten VST
beantwortet.
DSRC_A0DA_BI01_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie jeweils ein SET.rq für das DSRC-Modul
Attribute 16, 17, 18, 19, 20, 22, 46, 48, 55, 60, schreibgeschützte
62 und 63, das jeweils mit Fehlercode (einem Attribute nicht ändert,
Wert ungleich 0) beantwortet werden soll. auch wenn sie mittels SET
dazu aufgefordert wird.
Name/ID Beschreibung Ziel
DSRC_A0DA_BI02_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie ein SET.rq für das DSRC-Modul
Attribute 16, 17, 18, 19, 20, 22, 46, 48, 55, 60, schreibgeschützte
62 und 63, das mit Fehlercode (einem Wert Attribute nicht ändert,
ungleich 0) beantwortet werden soll. auch wenn sie mittels SET
dazu aufgefordert wird.
DSRC_A0DA_BI03_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie ein SET.rq für das DSRC-Modul
Attribute 0, 24 und 32, das mit Fehlercode schreibgeschützte
(einem Wert ungleich 0) beantwortet werden Attribute nicht ändert,
soll. auch wenn sie mittels SET
dazu aufgefordert wird.
DSRC_A0DA_BI04_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie jeweils ein SET.rq für das DSRC-Modul
Attribute 0, 24 und 32, das jeweils mit schreibgeschützte
Fehlercode (einem Wert ungleich 0) Attribute nicht ändert,
beantwortet werden soll. auch wenn sie mittels SET
dazu aufgefordert wird.
DSRC_A0DA_BI05_5010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie ein gemeinsames das DSRC-Modul
SET.rq für Attribute 49, 50, 51, 52, 53, 61, 64, schreibgeschützte
und ein weiteres gemeinsames SET.rq für die Attribute nicht ändert,
Attribute 99, 100 und 101, die mit Fehlercode auch wenn sie mittels SET
beantwortet werden sollen. dazu aufgefordert wird.
DSRC_A0DA_BI06_5010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie jeweils ein SET.rq für das DSRC-Modul
Attribute 49, 50, 51, 52, 53, 61, 64, 99, 100 und schreibgeschützte
101, das mit Fehlercode beantwortet werden Attribute nicht ändert,
soll. auch wenn sie mittels SET
dazu aufgefordert wird.
DSRC_A0DA_BI07_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie ein GET.rq mit das DSRC-Modul
ungültigen accessCredentials für Attribute 24 lesegeschützte Attribute
und 32, das mit Fehlercode (einem Wert nicht zurückgibt, wenn sie
ungleich 0) beantwortet werden soll. mittels GET dazu
aufgefordert wird.
DSRC_A0DA_BI08_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie ein GET.rq mit das DSRC-Modul
ungültigen accessCredentials für Attribute 16, lesegeschützte Attribute
17, 18, 19, 20, 22, 46, 48, 55, 60, 62 und 63, nicht zurückgibt, wenn sie
das mit Fehlercode (einem Wert ungleich 0) mittels GET dazu
beantwortet werden soll. aufgefordert wird.
DSRC_A0DA_BI09_5010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie ein gemeinsames das DSRC-Modul keine
GET.rq mit ungültigen accessCredentials für Attributwerte zurückgibt,
Attribute 49, 50, 51, 52, 53, 61, 64, und ein wenn die
weiteres gemeinsames GET.rq mit ungültigen AccessCredentials nicht
accessCredentials für die Attribute 99, 100 und korrekt sind.
101, die mit Fehlercode beantwortet werden
sollen.
Name/ID Beschreibung Ziel
DSRC_A0DA_BI10_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie ein das DSRC-Modul
GET_STAMPED.rq mit ungültigen lesegeschützte Attribute
accessCredentials für Attribute 24 und 32, nicht zurückgibt, wenn sie
das mit Fehlercode (einem Wert ungleich 0) mittels GET_STAMPED
beantwortet werden soll. dazu aufgefordert wird.
DSRC_A0DA_BI11_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie ein das DSRC-Modul
GET_STAMPED.rq mit ungültigen lesegeschützte Attribute
accessCredentials für Attribute 16, 17, 18, 19, nicht zurückgibt, wenn sie
20, 22, 46, 48, 55, 60, 62 und 63, das mit mittels GET_STAMPED
Fehlercode (einem Wert ungleich 0) dazu aufgefordert wird.
beantwortet werden soll.
DSRC_A0DA_BI12_5010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie ein gemeinsames das DSRC-Modul keine
GET-STAMPED.rq mit ungültigen Attributwerte zurückgibt,
accessCredentials für Attribute 49, 50, 51, 52, wenn die
53, 61, 64, und ein weiteres gemeinsames AccessCredentials nicht
GET-STAMPED.rq mit ungültigen korrekt sind.
accessCredentials für die Attribute 99, 100 und
101, die mit Fehlercode beantwortet werden
sollen.
DSRC_A0DA_BV01_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie ein GET.rq für das DSRC-Modul den
Attribute 24 und 32, das ordnungsgemäß GET-Befehl korrekt
beantwortet werden soll. handhabt.
DSRC_A0DA_BV02_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie ein GET.rq für das DSRC-Modul den
Attribut 24, das ordnungsgemäß beantwortet GET-Befehl korrekt
werden soll. Dann sendet sie ein GET.rq für handhabt.
Attribut 32, das ordnungsgemäß beantwortet
werden soll.
DSRC_A0DA_BV03_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie ein GET.rq für das DSRC-Modul den
Attribute 16, 17, 18, 19, 20, 22, 46, 48, 55, 60, GET-Befehl korrekt
62 und 63, das ordnungsgemäß beantwortet handhabt.
werden soll.
DSRC_A0DA_BV04_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie jeweils ein GET.rq für das DSRC-Modul den
Attribute 16, 17, 18, 19, 20, 22, 46, 48, 55, 60, GET-Befehl korrekt
62 und 63, das ordnungsgemäß beantwortet handhabt.
werden soll.
DSRC_A0DA_BV05_5010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie ein gemeinsames das DSRC-Modul den
GET.rq für Attribute 49, 50, 51, 52, 53, 61, 64, GET-Befehl korrekt
und ein weiteres gemeinsames GET.rq für die handhabt.
Attribute 99, 100 und 101, die mit Fehlercode
beantwortet werden sollen.
DSRC_A0DA_BV06_5010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie jeweils ein GET.rq für das DSRC-Modul den
Attribute 49, 50, 51, 52, 53, 61, 64, 99, 100 und GET-Befehl korrekt
101, das ordnungsgemäß beantwortet werden handhabt.
soll.
Name/ID Beschreibung Ziel
DSRC_A0DA_BV07_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie ein das DSRC-Modul den
GET_STAMPED.rq für Attribute 24 und 32, GET_STAMPED-Befehl
das ordnungsgemäß beantwortet werden soll. korrekt handhabt.
DSRC_A0DA_BV09_5010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie ein gemeinsames das DSRC-Modul den
GET-STAMPED.rq für Attribute 49, 50, 51, 52, GET_STAMPED-Befehl
53, 61, 64, und ein weiteres gemeinsames korrekt handhabt.
GET-STAMPED.rq für die Attribute 99, 100 und
101, die mit Fehlercode beantwortet werden
sollen.
DSRC_A0DA_BV10_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie ein das DSRC-Modul den
GET_STAMPED.rq für Attribute 16, 17, 18, 19, GET_STAMPED-Befehl
20, 22, 46, 48, 55, 60, 62 und 63, das korrekt handhabt.
ordnungsgemäß beantwortet werden soll.
DSRC_A0FU_BI02_0010 Die Bake führt vorab eine reguläre Es soll sichergestellt
Initialisierungsphase durch, um die werden, dass die OBU/
Bereitschaft der OBU zur Kommunikation zu das DSRC-Modul PDU-
überprüfen. Anschließend sendet sie je eine Nummern korrekt erkennt.
BST mit PDU-Nummern 0 und 1, die von der
OBU nicht beantwortet werden sollen.
DSRC_A0FU_BI03_0010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase durch. Dann sendet sie je werden, dass die OBU/
eine PDU mit mode=1 und flow control=7 und das DSRC-Modul PDU-
allen ungültigen Werten des Fragmentzählers, Fragmente korrekt
die von der OBU nicht beantwortet werden erkennt.
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.
DSRC_A0FU_BI04_0010 Die Bake sendet je eine BST mit allen Es soll sichergestellt
ungültigen Werten des Fragmentzählers, die werden, dass die OBU/
von der OBU nicht beantwortet werden sollen. das DSRC-Modul PDU-
Abschließend führt sie eine reguläre Fragmente korrekt
Initialisierung durch, um zu überprüfen, dass erkennt.
die OBU noch korrekt reagiert.
DSRC_A0FU_BI06_0010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase durch. Anschließend werden, dass die OBU/
sendet sie "chained" PDUs in einem Rahmen, das DSRC-Modul PDU-
von denen die erste einen Fehler erzeugen Nummern korrekt erkennt.
und die zweite mit "chaining error" beantwortet
werden soll.
DSRC_A0FU_BV01_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase durch. Anschließend werden, dass die OBU/
sendet sie ein GET.rq für ein geeignetes das DSRC-Modul den
Attribut, das ordnungsgemäß beantwortet GET-Befehl korrekt
werden soll. handhabt.
DSRC_A0FU_BV08_0010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase durch. Anschließend werden, dass die OBU/
sendet sie ein ACTION.rq mit mode=1 und das DSRC-Modul den
FlowControl=7 (zum Beispiel ECHO), das ACTION-Befehl korrekt
ordnungsgemäß beantwortet werden soll. handhabt.
DSRC_A0FU_BV09_0010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase durch. Anschließend werden, dass die OBU/
sendet sie ein SET_MMI.rq mit mode=0 und das DSRC-Modul den
FlowControl=4. Der Tester überprüft, ob die ACTION-Befehl korrekt
OBU das SET_MMI ausführt. handhabt.
Name/ID Beschreibung Ziel
DSRC_A0FU_BV10_0010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase durch. Anschließend werden, dass die OBU/
sendet sie ein SET_MMI.rq mit mode=0 und das DSRC-Modul den
FlowControl=1. Der Tester überprüft, ob die ACTION-Befehl korrekt
OBU das SET_MMI ausführt. handhabt.
DSRC_A0FU_BV11_0010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase durch. Anschließend werden, dass die OBU/
sendet sie ein SET_MM.rq mit mode=0 und das DSRC-Modul den
FlowControl=1 an die Broadcast-LID. Der ACTION-Befehl korrekt
Tester überprüft, ob die OBU das SET_MMI handhabt.
ausführt.
DSRC_A0FU_BV12_0010 Die Bake sendet ein SET_MMI.rq mit mode=0 Es soll sichergestellt
und FlowControl=1 an die Broadcast-LID. Der werden, dass die OBU/
Tester überprüft, ob die OBU das SET_MMI das DSRC-Modul den
ausführt. ACTION-Befehl korrekt
handhabt.
DSRC_A0FU_BV13_0010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase durch. Anschließend werden, dass die OBU/
sendet sie je ein ECHO.rq mit PDU number 2 das DSRC-Modul PDU-
bis 31, das jeweils ordnungsgemäß Fragmente korrekt
beantwortet werden soll. erkennt.
DSRC_A0FU_BV14_0010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase durch, wobei die OBU werden, dass die OBU/
Anwendungen für zwei ElementIDs !=0 das DSRC-Modul in einer
(EID1, EID2) anmelden soll. Dann sendet sie Transaktion PDUs für
ECHO.rq mit jeweils neuen Daten für EID1, mehrere Elemente
EID2, EID1 und EID2, die jeweils empfangen kann.
ordnungsgemäß beantwortet werden sollen.
DSRC_A0FU_BV16_0010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase durch. Anschließend werden, dass die OBU/
sendet sie "concatenated" (nicht "chained") das DSRC-Modul PDU-
PDUs in einem Rahmen, die jeweils Fragmente korrekt
ordnungsgemäß in einem Rahmen erkennt.
beantwortet werden sollen.
DSRC_A0FU_BV17_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase durch. Anschließend werden, dass die OBU/
sendet sie ein GET.rq für ein geeignetes das DSRC-Modul den
Attribut, das ordnungsgemäß beantwortet GET-Befehl korrekt
werden soll. Dann sendet sie ein GET.rq mit handhabt.
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.
DSRC_A0FU_BV19_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase durch. Anschließend werden, dass die OBU/
sendet sie ein GET_STAMPED.rq für ein das DSRC-Modul den
geeignetes Attribut, das ordnungsgemäß GET_STAMPED-Befehl
beantwortet werden soll. Dann sendet sie korrekt handhabt.
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.
Name/ID Beschreibung Ziel
DSRC_A0FU_BV20_0010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase durch. Anschließend werden, dass die OBU/
sendet sie ein SET_MMI.rq mit mode=0 und das DSRC-Modul den
flowControl=1, dessen Ausführung der Tester SET_MMI-Befehl korrekt
bestätigen soll. Dann sendet sie ein handhabt.
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.
DSRC_A0FU_BV21_0010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase durch. Anschließend werden, dass die OBU/
sendet sie ein ECHO.rq mit mode=0. Dann das DSRC-Modul den
sendet sie ein ECHO.rq mit mode=1 und ECHO-Befehl korrekt
flowControl=7, das von der OBU korrekt handhabt.
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.
DSRC_A0SE_BV01_0010 Für diesen Testfall wird der keyRef-Wert 1 Es soll sichergestellt
benutzt. Die Bake führt eine reguläre werden, dass die OBU/
Initialisierungsphase durch. Anschließend das DSRC-Modul den
sendet sie ein GET_STAMPED.rq für das GET_STAMPED-Befehl
Attribut 32, das regulär beantwortet werden korrekt handhabt.
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.
DSRC_A0SE_BV02_0010 Für diesen Testfall wird der keyRef-Wert 2 Es soll sichergestellt
benutzt. Die Bake führt eine reguläre werden, dass die OBU/
Initialisierungsphase durch. Anschließend das DSRC-Modul den
sendet sie ein GET_STAMPED.rq für ein GET_STAMPED-Befehl
geeignetes Attribut 32, das regulär beantwortet korrekt handhabt.
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.
DSRC_A0SE_BV03_0010 Für diesen Testfall wird der keyRef-Wert 3 Es soll sichergestellt
benutzt. Die Bake führt eine reguläre werden, dass die OBU/
Initialisierungsphase durch. Anschließend das DSRC-Modul den
sendet sie ein GET_STAMPED.rq für ein GET_STAMPED-Befehl
geeignetes Attribut 32, das regulär beantwortet korrekt handhabt.
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.
Name/ID Beschreibung Ziel
DSRC_A0SE_BV04_0010 Für diesen Testfall wird der keyRef-Wert 4 Es soll sichergestellt
benutzt. Die Bake führt eine reguläre werden, dass die OBU/
Initialisierungsphase durch. Anschließend das DSRC-Modul den
sendet sie ein GET_STAMPED.rq für ein GET_STAMPED-Befehl
geeignetes Attribut 32, das regulär beantwortet korrekt handhabt.
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.
DSRC_A0SE_BV05_0010 Für diesen Testfall wird der keyRef-Wert 5 Es soll sichergestellt
benutzt. Die Bake führt eine reguläre werden, dass die OBU/
Initialisierungsphase durch. Anschließend das DSRC-Modul den
sendet sie ein GET_STAMPED.rq für ein GET_STAMPED-Befehl
geeignetes Attribut 32, das regulär beantwortet korrekt handhabt.
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.
DSRC_A0SE_BV06_0010 Für diesen Testfall wird der keyRef-Wert 6 Es soll sichergestellt
benutzt. Die Bake führt eine reguläre werden, dass die OBU/
Initialisierungsphase durch. Anschließend das DSRC-Modul den
sendet sie ein GET_STAMPED.rq für ein GET_STAMPED-Befehl
geeignetes Attribut 32, das regulär beantwortet korrekt handhabt.
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.
DSRC_A0SE_BV07_0010 Für diesen Testfall wird der keyRef-Wert 7 Es soll sichergestellt
benutzt. Die Bake führt eine reguläre werden, dass die OBU/
Initialisierungsphase durch. Anschließend das DSRC-Modul den
sendet sie ein GET_STAMPED.rq für ein GET_STAMPED-Befehl
geeignetes Attribut 32, das regulär beantwortet korrekt handhabt.
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.
DSRC_A0SE_BV08_0010 Für diesen Testfall wird der keyRef-Wert 8 Es soll sichergestellt
benutzt. Die Bake führt eine reguläre werden, dass die OBU/
Initialisierungsphase durch. Anschließend das DSRC-Modul den
sendet sie ein GET_STAMPED.rq für ein GET_STAMPED-Befehl
geeignetes Attribut 32, das regulär beantwortet korrekt handhabt.
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.
Name/ID Beschreibung Ziel
DSRC_A1BA_BI01_0010 Die Bake sendet eine BST mit einem profile 13 Es soll sichergestellt
(hex D), das von der OBU/dem DSRC-Modul werden, dass die OBU/
nicht unterstützt wird. Die OBU/das DSRC- das DSRC-Modul das
Modul soll nicht antworten. Das wird wiederholt Profil korrekt handhabt.
mit einem weiteren von der OBU nicht
unterstützten profile 17 (hex 11) wiederholt.
DSRC_A1BA_BI02_0010 Die Bake sendet BSTs für die von der OBU Es soll sichergestellt
nicht unterstütze Anwendung 19 (hex 13) in werden, dass die OBU/
der mandApplicationList und leerer das DSRC-Modul
nonmandApplicationList. Die OBU soll nicht applicationIds korrekt
antworten. Das wird wiederholt mit einer handhabt.
weiteren von der OBU nicht unterstützten
Anwendung 31 (hex 1F) in der
mandApplicationList und 19 in der
nonmandApplicationList.
DSRC_A1BA_BI03_0011 Die Bake sendet BSTs für eine von der OBU/ Es soll sichergestellt
dem DSRC-Modul nicht unterstütze werden, dass die OBU/
Anwendung 19 (hex 13) mit EID in der das DSRC-Modul
mandApplicationList und AID=20 in der applicationIds korrekt
nonmandApplicationList. Die OBU/das DSRC- handhabt.
modul soll nicht antworten.
DSRC_A1BA_BV01_0010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase durch. Anschließend werden, dass die OBU/
sendet sie ein ECHO.rq, das die OBU/das das DSRC-Modul die
DSRC-Modul beantworten soll. Dann Initialisierung korrekt
wiederholt sie ihre BST (evtl. mit neuer durchführt.
BeaconTime, wenn diese sich mittlerweile
verändert hat), die die OBU nicht beantworten
soll.
DSRC_A1BA_BV02_0010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AIDs 1, 20 und 21 werden, dass die OBU/
durch. Anschließend sendet sie ein ECHO.rq, das DSRC-Modul die
das die OBU beantworten soll, und zwei Initialisierung korrekt
RELEASEs. Dann schickt sie ein weiteres durchführt.
ECHO, das die OBU nicht beantworten soll.
DSRC_A1BA_BV03_0010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase durch. Anschließend werden, dass die OBU/
sendet sie ein ECHO.rq, das die OBU das DSRC-Modul die
beantworten soll. Der ganze Vorgang wird Initialisierung korrekt
einmal wiederholt mit um 1 erhöhter durchführt.
manufacturerID in der BST und dann nochmals
wiederholt mit der vorigen, erhöhten
manufacturerID und um 1 erhöhter individualId
der BST.
DSRC_A1BA_BV04_0010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AIDs 1, 20 und 21 werden, dass die OBU/
durch. Anschließend sendet sie ein ECHO.rq, das DSRC-Modul die
das die OBU beantworten soll. Der ganze Initialisierung korrekt
Vorgang wird wiederholt, wobei die Beacon durchführt.
Time der BST um 256 Sekunden erhöht wird.
DSRC_A1BA_BV09_0010 Die Bake sendet eine BST mit einem profile 13 Es soll sichergestellt
(hex D), das von der OBU nicht unterstützt werden, dass die OBU/
wird. Die OBU soll nicht antworten. Das wird das DSRC-Modul das
mit einem weiteren von der OBU nicht Profil korrekt handhabt.
unterstützten profile 17 (hex 11) wiederholt.
DSRC_A1BA_BV10_0010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AIDs 1, 20 und 21 werden, dass die OBU/
durch. Die VST wird auf ein korrektes Format das DSRC-Modul die BST
hin überprüft. mit einer korrekten VST
beantwortet.
Name/ID Beschreibung Ziel
DSRC_A1DA_BI01_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie jeweils ein SET.rq für das DSRC-Modul
Attribute 16, 17, 18, 19, 20, 22, 46, 48, 55, 60, schreibgeschützte
62 und 63, das jeweils mit Fehlercode Attribute nicht ändert,
beantwortet werden soll. auch wenn sie mittels SET
dazu aufgefordert wird.
DSRC_A1DA_BI02_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie ein SET.rq für das DSRC-Modul
Attribute 16, 17, 18, 19, 20, 22, 46, 48, 55, 60, schreibgeschützte
62 und 63, das mit Fehlercode beantwortet Attribute nicht ändert,
werden soll. auch wenn sie mittels SET
dazu aufgefordert wird.
DSRC_A1DA_BI03_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie ein SET.rq für das DSRC-Modul
Attribute 0, 24 und 32, das mit Fehlercode schreibgeschützte
beantwortet werden soll. Attribute nicht ändert,
auch wenn sie mittels SET
dazu aufgefordert wird.
DSRC_A1DA_BI04_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie jeweils ein SET.rq für das DSRC-Modul
Attribute 0, 24 und 32, das jeweils mit schreibgeschützte
Fehlercode beantwortet werden soll. Attribute nicht ändert,
auch wenn sie mittels SET
dazu aufgefordert wird.
DSRC_A1DA_BI05_5010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie ein gemeinsames das DSRC-Modul
SET.rq für Attribute 49, 50, 51, 52, 53, 61, 64, schreibgeschützte
und ein weiteres gemeinsames SET.rq für die Attribute nicht ändert,
Attribute 99, 100 und 101, die mit Fehlercode auch wenn sie mittels SET
beantwortet werden sollen. dazu aufgefordert wird.
DSRC_A1DA_BI06_5010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie jeweils ein SET.rq für das DSRC-Modul
Attribute 49, 50, 51, 52, 53, 61, 64, 99, 100 und schreibgeschützte
101, das mit Fehlercode beantwortet werden Attribute nicht ändert,
soll. auch wenn sie mittels SET
dazu aufgefordert wird.
DSRC_A1DA_BI07_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie ein GET.rq mit das DSRC-Modul
ungültigen accessCredentials für Attribute 24 lesegeschützte Attribute
und 32, das mit Fehlercode beantwortet nicht zurückgibt, wenn sie
werden soll. mittels GET dazu
aufgefordert wird.
DSRC_A1DA_BI08_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie ein GET.rq mit das DSRC-Modul
ungültigen accessCredentials für Attribute 16, lesegeschützte Attribute
17, 18, 19, 20, 22, 46, 48, 55, 60, 62 und 63, nicht zurückgibt, wenn sie
das mit Fehlercode beantwortet werden soll. mittels GET dazu
aufgefordert wird.
Name/ID Beschreibung Ziel
DSRC_A1DA_BI09_5010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie ein gemeinsames das DSRC-Modul keine
GET.rq mit ungültigen accessCredentials für Attributwerte zurückgibt,
Attribute 49, 50, 51, 52, 53, 61, 64, und ein wenn die
weiteres gemeinsames GET.rq mit ungültigen AccessCredentials nicht
accessCredentials für die Attribute 99, 100 und korrekt sind.
101, die mit Fehlercode beantwortet werden
sollen.
DSRC_A1DA_BI10_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie ein das DSRC-Modul
GET_STAMPED.rq mit ungültigen lesegeschützte Attribute
accessCredentials für Attribute 24 und 32, nicht zurückgibt, wenn sie
das mit Fehlercode beantwortet werden soll. mittels GET_STAMPED
dazu aufgefordert wird.
DSRC_A1DA_BI11_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie ein das DSRC-Modul
GET_STAMPED.rq mit ungültigen lesegeschützte Attribute
accessCredentials für Attribute 16, 17, 18, 19, nicht zurückgibt, wenn sie
20, 22, 46, 48, 55, 60, 62 und 63, das mit mittels GET_STAMPED
Fehlercode beantwortet werden soll. dazu aufgefordert wird.
DSRC_A1DA_BI12_5010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie ein gemeinsames das DSRC-Modul keine
GET-STAMPED.rq mit ungültigen Attributwerte zurückgibt,
accessCredentials für Attribute 49, 50, 51, 52, wenn die
53, 61, 64, und ein weiteres gemeinsames AccessCredentials nicht
GET-STAMPED.rq mit ungültigen korrekt sind.
accessCredentials für die Attribute 99, 100 und
101, die mit Fehlercode beantwortet werden
sollen.
DSRC_A1DA_BV01_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie ein GET.rq für das DSRC-Modul den
Attribute 24 und 32, das ordnungsgemäß GET-Befehl korrekt
beantwortet werden soll. handhabt.
DSRC_A1DA_BV02_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie ein GET.rq für das DSRC-Modul den
Attribut 24, das ordnungsgemäß beantwortet GET-Befehl korrekt
werden soll. Dann sendet sie ein GET.rq für handhabt.
Attribut 32, das ordnungsgemäß beantwortet
werden soll.
DSRC_A1DA_BV03_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie ein GET.rq für das DSRC-Modul den
Attribute 16, 17, 18, 19, 20, 22, 46, 48, 55, 60, GET-Befehl korrekt
62 und 63, das ordnungsgemäß beantwortet handhabt.
werden soll.
DSRC_A1DA_BV04_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie jeweils ein GET.rq für das DSRC-Modul den
Attribute 16, 17, 18, 19, 20, 22, 46, 48, 55, 60, GET-Befehl korrekt
62 und 63, das ordnungsgemäß beantwortet handhabt.
werden soll.
Name/ID Beschreibung Ziel
DSRC_A1DA_BV05_5010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie ein gemeinsames das DSRC-Modul den
GET.rq für Attribute 49, 50, 51, 52, 53, 61, 64, GET-Befehl korrekt
und ein weiteres gemeinsames GET.rq für die handhabt.
Attribute 99, 100 und 101, das
ordnungsgemäß beantwortet werden soll.
DSRC_A1DA_BV06_5010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie jeweils ein GET.rq für das DSRC-Modul den
Attribute 49, 50, 51, 52, 53, 61, 64, 99, 100 und GET-Befehl korrekt
101, das ordnungsgemäß beantwortet werden handhabt.
soll.
DSRC_A1DA_BV07_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie ein das DSRC-Modul den
GET_STAMPED.rq für Attribute 24 und 32, das GET_STAMPED-Befehl
ordnungsgemäß beantwortet werden soll. korrekt handhabt.
DSRC_A1DA_BV09_5010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie ein gemeinsames das DSRC-Modul den
GET-STAMPED.rq für Attribute 49, 50, 51, 52, GET_STAMPED-Befehl
53, 61, 64, und ein weiteres gemeinsames korrekt handhabt.
GET-STAMPED.rq für die Attribute 99, 100 und
101, das ordnungsgemäß beantwortet werden
soll.
DSRC_A1DA_BV10_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase für AID 20 durch. werden, dass die OBU/
Anschließend sendet sie ein das DSRC-Modul den
GET_STAMPED.rq für Attribute 16, 17, 18, 19, GET_STAMPED-Befehl
20, 22, 46, 48, 55, 60, 62 und 63, das korrekt handhabt.
ordnungsgemäß beantwortet werden soll.
DSRC_A1FU_BI02_0010 Die Bake führt vorab eine reguläre Es soll sichergestellt
Initialisierungsphase durch, um die werden, dass die OBU/
Bereitschaft der OBU zur Kommunikation zu das DSRC-Modul PDU-
überprüfen. Anschließend sendet sie je eine Nummern korrekt erkennt.
BST mit PDU-Nummern 0 und 1, die von der
OBU nicht beantwortet werden sollen.
DSRC_A1FU_BI03_0010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase durch. Dann sendet sie je werden, dass die OBU/
eine PDU mit mode=1 und flow control=7 und das DSRC-Modul PDU-
allen ungültigen Werten des Fragmentzählers, Fragmente korrekt
die von der OBU nicht beantwortet werden erkennt.
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.
DSRC_A1FU_BI04_0010 Die Bake sendet je eine BST mit allen Es soll sichergestellt
ungültigen Werten des Fragmentzählers, die werden, dass die OBU/
von der OBU nicht beantwortet werden sollen. das DSRC-Modul PDU-
Abschließend führt sie eine reguläre Fragmente korrekt
Initialisierung durch, um zu überprüfen, dass erkennt.
die OBU noch korrekt reagiert.
DSRC_A1FU_BI06_0010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase durch. Anschließend werden, dass die OBU/
sendet sie "chained" PDUs in einem Rahmen, das DSRC-Modul PDU-
von denen die erste einen Fehler erzeugen Nummern korrekt erkennt.
und die zweite mit "chaining error" beantwortet
werden soll.
Name/ID Beschreibung Ziel
DSRC_A1FU_BV01_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase durch. Anschließend werden, dass die OBU/
sendet sie ein GET.rq für ein geeignetes das DSRC-Modul den
Attribut, das ordnungsgemäß beantwortet GET-Befehl korrekt
werden soll. handhabt.
DSRC_A1FU_BV08_0010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase durch. Anschließend werden, dass die OBU/
sendet sie ein ACTION.rq mit mode=1 und das DSRC-Modul den
FlowControl=7 (zum Beispiel ECHO), das ACTION-Befehl korrekt
ordnungsgemäß beantwortet werden soll. handhabt.
DSRC_A1FU_BV09_0010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase durch. Anschließend werden, dass die OBU/
sendet sie ein ACTION.rq mit mode=0 und das DSRC-Modul den
FlowControl=4 (zum Beispiel SET_MMI). Der ACTION-Befehl korrekt
Tester überprüft, ob die OBU das SET_MMI handhabt.
ausführt.
DSRC_A1FU_BV10_0010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase durch. Anschließend werden, dass die OBU/
sendet sie ein ACTION.rq mit mode=0 und das DSRC-Modul den
FlowControl=1 (zum Beispiel SET_MMI). Der ACTION-Befehl korrekt
Tester überprüft, ob die OBU das SET_MMI handhabt.
ausführt.
DSRC_A1FU_BV11_0010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase durch. Anschließend werden, dass die OBU/
sendet sie ein ACTION.rq mit mode=0 und das DSRC-Modul den
FlowControl=1 (zum Beispiel SET_MMI) an die ACTION-Befehl korrekt
Broadcast-LID. Der Tester überprüft, ob die handhabt.
OBU das SET_MMI ausführt.
DSRC_A1FU_BV12_0010 Die Bake sendet ein ACTION.rq mit mode=0 Es soll sichergestellt
und FlowControl=1 (zum Beispiel SET_MMI) werden, dass die OBU/
an die Broadcast-LID. Der Tester überprüft, ob das DSRC-Modul den
die OBU das SET_MMI ausführt. ACTION-Befehl korrekt
handhabt.
DSRC_A1FU_BV13_0010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase durch. Anschließend werden, dass die OBU/
sendet sie je ein ECHO.rq mit PDU number 2 das DSRC-Modul PDU-
bis 31, das jeweils ordnungsgemäß Fragmente korrekt
beantwortet werden soll. erkennt.
DSRC_A1FU_BV14_0010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase durch, wobei die OBU werden, dass die OBU/
Anwendungen für zwei ElementIDs !=0 (EID1, das DSRC-Modul in einer
EID2) anmelden soll. Dann sendet sie Transaktion PDUs für
ECHO.rq mit jeweils neuen Daten für EID1, mehrere Elemente
EID2, EID1 und EID2, die jeweils empfangen kann.
ordnungsgemäß beantwortet werden sollen.
DSRC_A1FU_BV16_0010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase durch. Anschließend werden, dass die OBU/
sendet sie "concatenated" (nicht "chained") das DSRC-Modul PDU-
PDUs in einem Rahmen, die jeweils Fragmente korrekt
ordnungsgemäß in einem Rahmen erkennt.
beantwortet werden sollen.
DSRC_A1FU_BV17_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase durch. Anschließend werden, dass die OBU/
sendet sie ein GET.rq für ein geeignetes das DSRC-Modul den
Attribut, das ordnungsgemäß beantwortet GET-Befehl korrekt
werden soll. Dann sendet sie ein GET.rq mit handhabt.
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.
Name/ID Beschreibung Ziel
DSRC_A1FU_BV19_0011 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase durch. Anschließend werden, dass die OBU/
sendet sie ein GET_STAMPED.rq für ein das DSRC-Modul den
geeignetes Attribut, das ordnungsgemäß GET_STAMPED-Befehl
beantwortet werden soll. Dann sendet sie korrekt handhabt.
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.
DSRC_A1FU_BV20_0010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase durch. Anschließend werden, dass die OBU/
sendet sie ein SET_MMI.rq mit mode=0 und das DSRC-Modul den
flowControl=1, dessen Ausführung der Tester SET_MMI-Befehl korrekt
bestätigen soll. Dann sendet sie ein handhabt.
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.
DSRC_A1FU_BV21_0010 Die Bake führt eine reguläre Es soll sichergestellt
Initialisierungsphase durch. Anschließend werden, dass die OBU/
sendet sie ein ECHO.rq mit mode=0. Dann das DSRC-Modul den
sendet sie ein ECHO.rq mit mode=1 und ECHO-Befehl korrekt
flowControl=7, das von der OBU korrekt handhabt.
beantwortet werden soll. Zuletzt sendet sie ein
ECHO.rq mit ungültigem ActionParameter, das
mit Fehlermeldung (ReturnStatus !=0)
beantwortet werden soll.
DSRC_A1SE_BV01_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann führt die das DSRC-Modul den
Bake eine reguläre Initialisierungsphase durch. GET_STAMPED-Befehl
Anschließend sendet sie ein korrekt handhabt.
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.
DSRC_A1SE_BV02_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann führt die das DSRC-Modul den
Bake eine reguläre Initialisierungsphase durch. GET_STAMPED-Befehl
Anschließend sendet sie ein korrekt handhabt.
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.
Name/ID Beschreibung Ziel
DSRC_A1SE_BV03_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann führt die das DSRC-Modul den
Bake eine reguläre Initialisierungsphase durch. GET_STAMPED-Befehl
Anschließend sendet sie ein korrekt handhabt.
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.
DSRC_A1SE_BV04_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann führt die das DSRC-Modul den
Bake eine reguläre Initialisierungsphase durch. GET_STAMPED-Befehl
Anschließend sendet sie ein korrekt handhabt.
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.
DSRC_A1SE_BV05_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann führt die das DSRC-Modul den
Bake eine reguläre Initialisierungsphase durch. GET_STAMPED-Befehl
Anschließend sendet sie ein korrekt handhabt.
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.
DSRC_A1SE_BV06_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann führt die das DSRC-Modul den
Bake eine reguläre Initialisierungsphase durch. GET_STAMPED-Befehl
Anschließend sendet sie ein korrekt handhabt.
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.
Name/ID Beschreibung Ziel
DSRC_A1SE_BV07_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann führt die das DSRC-Modul den
Bake eine reguläre Initialisierungsphase durch. GET_STAMPED-Befehl
Anschließend sendet sie ein korrekt handhabt.
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.
DSRC_A1SE_BV08_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann führt die das DSRC-Modul den
Bake eine reguläre Initialisierungsphase durch. GET_STAMPED-Befehl
Anschließend sendet sie ein korrekt handhabt.
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.
DSRC_LLC__BI01_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann sendet das DSRC-Modul einen
die Bake BSTs für AIDs 1, 20 und 21, bei der Rahmen mit falsch
die beiden Füllbits im LLC-Kontrollfeld auf die gesetzten Füllbits im
ungültigen Werte 00, 01 und 10 gesetzt sind. LLC-Kontrollfeld erkennt
Die OBU soll nicht antworten. Anschließend und ignoriert.
wird mit einer normalen BST überprüft, ob die
OBU korrekt reagiert.
DSRC_LLC__BI02_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann führt die das DSRC-Modul einen
Bake eine reguläre Initialisierungsphase für Rahmen mit nicht
AIDs 1, 20 und 21 durch. Anschließend sendet ganzzahliger Anzahl von
sie einen ECHO-Befehl, bei dem ein halbes Bytes erkennt und
Byte entfernt wird. Die OBU soll nicht ignoriert.
reagieren. Anschließend wird mit einem
korrekten ECHO-Befehl überprüft, ob die OBU
noch korrekt reagiert.
DSRC_LLC__BI03_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann führt die das DSRC-Modul einen
Bake eine reguläre Initialisierungsphase für Rahmen mit ungültigen
AIDs 1, 20 und 21 durch. Anschließend sendet modifier- und reserved-
sie ECHO-Befehle mit P-Bit=1, aber allen Bits im LLC-Kontrollfeld
ungültigen Werten der modifier-Bits. Die OBU erkennt und ignoriert.
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.
Name/ID Beschreibung Ziel
DSRC_LLC__BI04_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann führt die das DSRC-Modul ACn-
Bake eine reguläre Initialisierungsphase für Rahmen mit Broadcast-
AIDs 1, 20 und 21 durch. Anschließend sendet oder Multicast-LID
sie ein ECHO.rq mit der LID 0xFF, das die ignoriert.
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.
DSRC_LLC__BI05_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann sendet das DSRC-Modul einen
die Bake BSTs für AIDs 1, 20 und 21, bei der in Rahmen mit nicht
der Nachricht ein halbes Byte fehlt. Die OBU ganzzahliger Anzahl von
soll nicht antworten. Anschließend wird mit Bytes erkennt und
einer normalen BST überprüft, ob die OBU ignoriert.
korrekt reagiert.
DSRC_LLC__BI06_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann führt die das DSRC-Modul ACn-
Bake eine reguläre Initialisierungsphase für Befehle mit p-Bit=1, aber
AIDs 1, 20 und 21 durch. Anschließend sendet ohne LSDU ignoriert.
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.
DSRC_LLC__BI07_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann führt die das DSRC-Modul doppelt
Bake eine reguläre Initialisierungsphase für ACn-Befehle korrekt
AIDs 1, 20 und 21 durch. Anschließend sendet verarbeitet.
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.
DSRC_LLC__BV01_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann führt die das DSRC-Modul
Bake eine reguläre Initialisierungsphase für UI-Befehle austauschen
AIDs 1, 20 und 21 durch. Das P-Bit im LLC- kann.
Kontrollfeld der VST soll den Wert 0 haben.
DSRC_LLC__BV02_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann führt die das DSRC-Modul ACn-
Bake eine reguläre Initialisierungsphase für Befehle empfangen kann.
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.
Name/ID Beschreibung Ziel
DSRC_LLC__BV03_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann führt die das DSRC-Modul ACn-
Bake eine reguläre Initialisierungsphase für Befehle austauschen
AIDs 1, 20 und 21 durch. Danach sendet sie kann.
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.
DSRC_LLC__BV05_0010 Zunächst wird eine Dummytransaktion durch Es soll sichergestellt
geführt, um sicherzustellen, dass die OBU werden, dass die OBU/
kommunikationsbereit ist. Dann führt die Bake das DSRC-Modul die late
eine reguläre Initialisierungsphase für AIDs 1, response-prozedur I
20 und 21 durch. Dann sendet sie einen ACn- korrekt durchführt.
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.
DSRC_MAC__BI01_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann sendet das DSRC-Modul einen
die Bake eine BST für AIDs 1, 20 und 21, bei Rahmen mit zweifachem
der in der Nachricht zwei Bitfehler auftreten. Bitfehler in der Nachricht
Die OBU soll nicht antworten. Anschließend ignoriert.
wird mit einer ungestörten BST überprüft, ob
die OBU korrekt reagiert.
DSRC_MAC__BI02_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann sendet das DSRC-Modul einen
die Bake eine BST für AIDs 1, 20 und 21, bei Rahmen mit zweifachem
der in der FCS zwei Bitfehler auftreten. Die Bitfehler in der FCS
OBU soll nicht antworten. Anschließend wird ignoriert.
mit einer ungestörten BST überprüft, ob die
OBU korrekt reagiert.
DSRC_MAC__BI03_0010 Zunächst wird eine Dummytransaktion durch Es soll sichergestellt
geführt, um sicherzustellen, dass die OBU werden, dass die OBU/
kommunikationsbereit ist. Dann sendet die das DSRC-Modul einen
Bake eine BST für AIDs 1, 20 und 21, bei der in Rahmen mit 15
der Nachricht 15 aufeinanderfolgende Bit konsekutiven Bitfehlern in
invertiert werden. Die OBU soll nicht ant der Nachricht ignoriert.
worten. Anschließend wird mit einer
ungestörten BST überprüft, ob die OBU korrekt
reagiert.
DSRC_MAC__BI04_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann sendet das DSRC-Modul einen
die Bake eine BST für AIDs 1, 20 und 21, bei Rahmen ohne 0-Bit
der das Einfügen der 0-Bits unterbleibt. Die insertion in der LID
OBU soll nicht antworten. Anschließend wird ignoriert.
mit einer ungestörten BST überprüft, ob die
OBU korrekt reagiert.
Name/ID Beschreibung Ziel
DSRC_MAC__BI05_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann sendet das DSRC-Modul einen
die Bake eine BST für AIDs 1, 20 und 21, bei Rahmen mit einem Abort-
der das end flag durch ein Abort-Byte ersetzt Byte anstelle der end flag
wird. Die OBU soll nicht antworten. ignoriert.
Anschließend wird mit einer ungestörten BST
überprüft, ob die OBU korrekt reagiert.
DSRC_MAC__BI06_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann sendet das DSRC-Modul
die Bake eine BST für AIDs 1, 20 und 21, bei Rahmen erkennt und
der die ProfileList so lang ist, dass die maximal ignoriert, die länger als die
erlaubte Rahmenlänge (128 Bytes incl. Flags vom Standard erlaubten
und FCS) überschritten wird. Die OBU soll 128 Byte (incl. Flags und
nicht antworten. FCS) sind.
DSRC_MAC__BI07_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann führt die das DSRC-Modul eine
Bake eine reguläre Initialisierungsphase für falsche LID erkennt und
AIDs 1, 20 und 21 durch. Anschließend sendet ignoriert.
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.
DSRC_MAC__BI08_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann führt die das DSRC-Modul einen
Bake eine reguläre Initialisierungsphase für Rahmen ohne MAC-
AIDs 1, 20 und 21 durch. Anschließend sendet Kontrollfeld erkennt und
sie privateWindowRequests ohne MAC- ignoriert.
Kontrollfeld. Zuletzt wird überprüft, ob die OBU
noch auf valide window allocations reagiert.
DSRC_MAC__BI09_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann sendet das DSRC-Modul das
die Bake eine BST für AIDs 1, 20 und 21, bei A-Bit im MAC-Kontrollfeld
der das A-Bit im MAC-Kontrollfeld auf 0 beachtet.
gesetzt ist. Die OBU soll nicht antworten.
Anschließend wird mit einer normalen BST
überprüft, ob die OBU korrekt reagiert.
DSRC_MAC__BI10_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann sendet das DSRC-Modul in der
die Bake eine BST für AIDs 1, 20 und 21, bei BST das D-Bit im MAC-
der das D-Bit im MAC-Kontrollfeld auf 1 Kontrollfeld beachtet.
gesetzt ist. Die OBU soll nicht antworten.
Anschließend wird mit einer normalen BST
überprüft, ob die OBU korrekt reagiert.
DSRC_MAC__BI11_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann sendet das DSRC-Modul in
die Bake eine BST für AIDs 1, 20 und 21 und privaten Rahmen das
erwartet ein private window request. Danach D-Bit im MAC-Kontrollfeld
sendet sie ein private window allocation, bei beachtet.
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.
Name/ID Beschreibung Ziel
DSRC_MAC__BI12_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann sendet das DSRC-Modul einen
die Bake eine BST für AIDs 1, 20 und 21, bei Rahmen mit falsch
der das L-Bit im MAC-Kontrollfeld auf 0 gesetzt gesetztem L-Bit im MAC-
ist. Die OBU soll nicht antworten. Kontrollfeld erkennt und
Anschließend wird mit einer normalen BST ignoriert.
überprüft, ob die OBU korrekt reagiert.
DSRC_MAC__BI13_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann sendet das DSRC-Modul einen
die Bake eine BST für AIDs 1, 20 und 21 und Rahmen mit falsch
erwartet ein private window request. Danach gesetztem L-Bit im MAC-
sendet sie ein private window allocation, bei Kontrollfeld erkennt und
dem das L-Bit im MAC-Kontrollfeld auf 1 ignoriert.
gesetzt ist. Die OBU soll nicht antworten.
Anschließend wird mit einem korrekten private
window allocation überprüft, ob die OBU
korrekt reagiert.
DSRC_MAC__BI14_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann sendet das DSRC-Modul einen
die Bake eine BST für AIDs 1, 20 und 21 und Rahmen mit falsch
erwartet ein private window request. Danach gesetztem C/R-Bit im
sendet sie ein private window allocation, bei MAC-Kontrollfeld erkennt
dem das C/R-Bit im MAC-Kontrollfeld auf 1 und ignoriert.
gesetzt ist. Die OBU soll nicht antworten.
Anschließend wird mit einem korrekten private
window allocation überprüft, ob die OBU
korrekt reagiert.
DSRC_MAC__BI15_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann sendet das DSRC-Modul einen
die Bake eine BST für AIDs 1, 20 und 21 und Rahmen mit falsch
erwartet ein private window request. Danach gesetzten Füllbits im
sendet sie ein private window allocation, bei MAC-Kontrollfeld erkennt
dem die Füllbits im MAC-Kontrollfeld auf 1 und ignoriert.
gesetzt sind. Die OBU soll nicht antworten.
Anschließend wird mit einem korrekten private
window allocation überprüft, ob die OBU
korrekt reagiert.
DSRC_MAC__BI16_0010 Zunächst wird eine Dummytransaktion durch Es soll sichergestellt
geführt, um sicherzustellen, dass die OBU werden, dass die OBU/
kommunikationsbereit ist. Dann sendet die das DSRC-Modul einen
Bake eine BST für AIDs 1, 20 und 21, bei der Rahmen mit einer
das Radiosignal über 15 zusammenhängende Funkstörung über 15
Bit unterdrückt wird. Die OBU soll nicht zusammenhängende Bit
antworten. Anschließend wird mit einer ignoriert.
ungestörten BST überprüft, ob die OBU korrekt
reagiert.
DSRC_MAC__BI17_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann sendet das DSRC-Modul einen
die Bake eine BST für AIDs 1, 20 und 21, bei Rahmen mit einer
der das Radiosignal während der start flag Funkstörung während der
unterdrückt wird. Die OBU soll nicht antworten. start flag ignoriert.
Anschließend wird mit einer ungestörten BST
überprüft, ob die OBU korrekt reagiert.
Name/ID Beschreibung Ziel
DSRC_MAC__BI18_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann sendet das DSRC-Modul einen
die Bake eine BST für AIDs 1, 20 und 21, bei Rahmen mit einer
der das Radiosignal während der end flag Funkstörung während der
unterdrückt wird. Die OBU soll nicht antworten. end flag ignoriert.
Anschließend wird mit einer ungestörten BST
überprüft, ob die OBU korrekt reagiert.
DSRC_MAC__BI19_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann sendet das DSRC-Modul einen
die Bake eine BST für AIDs 1, 20 und 21 und Rahmen mit der
erwartet ein private window request. Danach Broadcast-LID anstelle
sendet sie ein private window allocation mit der der privaten ignoriert.
LID 0xFF. Die OBU soll nicht antworten.
Anschließend wird mit einem korrekten private
window allocation überprüft, ob die OBU
korrekt reagiert.
DSRC_MAC__BI20_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann sendet das DSRC-Modul einen
die Bake eine BST für AIDs 1, 20 und 21 und Rahmen mit einer
erwartet ein private window request. Dann Multicast-LID anstelle der
sendet sie ein private window allocation mit privaten ignoriert.
einer Multicast-LID. Die OBU soll nicht
antworten. Anschließend wird mit einem
korrekten private window allocation überprüft,
ob die OBU korrekt reagiert.
DSRC_MAC__BI21_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann sendet das DSRC-Modul in
die Bake eine BST für AIDs 1, 20 und 21 und privaten Rahmen das
erwartet ein private window request. Danach A-Bit im MAC-Kontrollfeld
sendet sie ein private window allocation, bei beachtet.
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.
DSRC_MAC__BI22_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann führt die das DSRC-Modul in
Bake eine reguläre Initialisierungsphase für privaten Rahmen das
AIDs 1, 20 und FIXME LA durch. Anschließend A-Bit im MAC-Kontrollfeld
sendet sie einen ACn-Befehl, wobei das A-Bit beachtet.
des Rahmens auf 0 gesetzt wird. Zuletzt wird
mit einem ACn-Befehl mit korrektem A-Bit
überprüft, ob die OBU noch korrekt reagiert.
DSRC_MAC__BI23_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann sendet das DSRC-Modul in
die Bake eine BST für AIDs 1, 20 und 21 und privaten Rahmen die LID
erwartet ein private window request. Dann beachtet.
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.
Name/ID Beschreibung Ziel
DSRC_MAC__BI24_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann sendet das DSRC-Modul private
die Bake eine BST für AIDs 1, 20 und 21 und window requests korrekt
erwartet ein private window request. Die Bake wiederholt.
ignoriert das window request und wiederholt
die BST. Die OBU soll ihr private window
request wiederholen.
DSRC_MAC__BV01_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann sendet das DSRC-Modul auch
die Bake eine BST für AIDs 1, 20 und 21, bei DSRC-Rahmen der durch
der die ProfileList so lang ist, dass die maximal den Standard festgelegten
erlaubte Rahmenlänge (128 Bytes incl. Flags Maximallänge korrekt
und FCS) erreicht wird. Die OBU soll mit einem verarbeiten kann.
private window request antworten.
DSRC_MAC__BV02_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann führt die das DSRC-Modul auch
Bake eine reguläre Initialisierungsphase für DSRC-Rahmen
AIDs 1, 20 und 21 durch. Anschließend sendet verarbeiten kann, die im
sie T1 nach dem Ende der VST ein ECHO.rq. vom Standard erlaubten
Eine Antwort der OBU wird erwartet. zeitlichen Mindestabstand
versendet wurden.
DSRC_MAC__BV03_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann sendet das DSRC-Modul jedes
die Bake eine BST für AIDs 1, 20 und 21 und der drei public uplink
erwartet ein private window request. Das wird windows benutzt.
X male wiederholt und dann ausgewetet, ob
die window requests zeitlich im erlaubten
Bereich lagen.
DSRC_MAC__BV04_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann führt die das DSRC-Modul auch
Bake eine reguläre Initialisierungsphase für DSRC-Rahmen
AIDs 1, 20 und 21 durch. Anschließend sendet verarbeiten kann, die im
sie ein SET_MMI.rq ohne window allocation vom Standard erlaubten
und dann unmittelbar im zeitlichen Abstand zeitlichen Mindestabstand
von T2 eine neue BST. Eine Antwort der OBU versendet wurden.
wird erwartet.
DSRC_MAC__BV05_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann führt die das DSRC-Modul bei
Bake eine reguläre Initialisierungsphase für privaten Rahmen das vom
AIDs 1, 20 und 21 durch. Dabei wird die Zeit Standard vorgegebene
zwischen dem Ende des end flag des private Timing einhält.
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.
DSRC_MAC__BV06_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann führt die das DSRC-Modul das
Bake eine reguläre Initialisierungsphase für S-Bit und das L-Bit des
AIDs 1, 20 und 21 durch. Die Bake ignoriert die MAC-Kontrollfeldes
VST und sendet ein private window allocation korrekt verarbeitet und
mit dem gleichen S-Bit wie beim vorigen Wiederholungen der VST
window allocation. Es wird erwartet, dass die korrekt verarbeiten kann.
OBU mit einer VST antwortet.
Name/ID Beschreibung Ziel
DSRC_MAC__BV07_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann führt die das DSRC-Modul das
Bake eine reguläre Initialisierungsphase für S-Bit und das L-Bit des
AIDs 1, 20 und 21 durch. Anschließend sendet MAC-Kontrollfeldes bei
die Bake ein ECHO mit ECHO_DATA1 und Rahmen mit LPDU korrekt
erwartet ein ECHO.rs mit ECHO_DATA1. verarbeitet.
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.
DSRC_MAC__BV08_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann sendet das DSRC-Modul jedes
die Bake eine BST für AIDs 1, 20 und 21 und der drei public uplink
erwartet ein private window request. Das wird windows benutzt.
X male wiederholt und dann ausgewertet, ob
die private window requests gleichmäßig
benutzt wurden.
DSRC_MAC__BV09_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann führt die das DSRC-Modul beide
Bake eine reguläre Initialisierungsphase für gültigen Werte des
AIDs 1, 20 und 21 durch, wobei das C/R-Bit C/R-Bit des MAC-
des private window allocation auf 1 gesetzt Kontrollfeldes eines
wird. Anschließend sendet die Bake ein private private window requests
window request mit C/R=0 und gleichem S-Bit korrekt verarbeitet.
wie vorher. Die OBU soll eine VST schicken.
DSRC_SFXX_2CCC_5010 Die Bake wird für CCC:2019 (SST301 v3.1) Dieser Testfall soll
konfiguriert. Wenn sich die OBU anmeldet, sicherstellen, dass EETS-
muss diese in der VST alle ContextMarks OBUs, die in der VST
anzeigen, die sie für CCC unterstützt. Die CCC:2015 und CCC:2019
Bake führt die Transaktion dann mit der EID anbieten, in beiden
der gültigen CCC:2019 (SST301 v3.1) Versionen eine CCC-
ContextMark durch. Transaktion erfolgreich
In einem zweiten Durchlauf wird die Bake für durchführen können. In
CCC:2015 (SST301 v2.2) konfiguriert. Wenn Anlehnung an die
sich die OBU anmeldet, muss diese in der VST Bitfehlerraten-Tests der
alle ContextMarks anzeigen, die sie für CCC EN300674-2-2 werden in
unterstützt. Die Bake führt die Transaktion diesem Labortest die
dann mit der EID der gültigen CCC:2015 Übertragungssicherheit im
(SST301v2.2) ContextMark durch. stabilen Laboraufbau
überprüft.
Name/ID Beschreibung Ziel
DSRC_SFXX_ABAA_5010 – Die Bake wird so konfiguriert, dass aus Es soll nachgewiesen
schließlich die Contextmark für CCC:2019 werden, dass das DUT
(SST301 v3.1) für die Transaktion benutzt alle von der eingestellten
wird. Achszahl (Attribut 19)
abhängigen Attribute
– Eine Initialisierung (BST-VST) mit einer (17, 46, 48, 62)
neuen Beacon-ID wird durchgeführt, um gleichzeitig ändert und so
festzustellen, ob die OBU/das DSRC- die Datenkonsistenz
Modul kommunikationsbereit ist. gewährleistet ist, wenn
– Die folgenden Schritte werden 10x wieder der Nutzer eine andere
holt: Achszahl einstellt. Somit
wird erwartet, dass sich
– Der Tester wird aufgefordert, den Wert der eine Achszahl-änderung
Achszahl auf einen neuen Wert einzustel im Bereich der
len und bestätigt die Einstellung. Kommunikationszone der
– Zwei CCC:2019(SST301 v3.1)-Transaktio Bake sich auf alle
nen werden durchgeführt mit einem zeit betroffenen Attribute
lichen Abstand von mehr als 15 Sekunden. gleichzeitig ausgewirkt
hat.
– Die Transaktionsdaten werden aus der
Bake ausgelesen. Dieser Test wurde im
Review CEN-TC278-
– Das Log wird am Ende der 10 Testwieder WG1_N2610_2_
holungen bezüglich der achszahlbezoge ISO_DIS_13143-1_
nen Attribute (19, 17, 46, 48, 62) aus Commenting_Form-
gewertet, wobei jede zweite Transaktion Response als sinnvoll an
berücksichtigt wird. gesehen, konnte jedoch
noch nicht in den norma
tiven Testfallkatalog auf
genommen werden, weil
hierfür noch keine direkte
Anforderung in der 12813
besteht. Für das BALM ist
dieser Test jedoch not
wendig, da inkonsistente
Daten eine Beweissiche
rung erschweren wurden.
DSRC_SFXX_ALAT_5010 – Eine Initialisierung (BST-VST) mit einer Es soll geprüft werden,
neuen Beacon-ID wird durchgeführt, um dass das DUT alle der für
festzustellen, ob das DUT kommunikati CCC (ISO 12813:2019
onsbereit ist. und Anlage 2
Einzeldokument 4.3.1
– Die Bake wird für eine CCC:2019(SST301 V3.1, Stand: 09.06.2022)
v3.1)-Transaktion in der Form konfiguriert, erforderlichen Attribute
dass jedes Attribut einzeln durch ein Get.rq (0, 16, 17, 18, 19, 20, 22,
abgefragt wird. 24, 32, 46, 48, 49, 50, 51,
– Nach der Attribute Abfrage wird die Baken 52, 53, 55, 60, 61, 62, 63,
übertragung angehalten. 64, 99, 100, 101)
unterstützt. Weiterhin
– Die Transaktionsdaten werden aus der sollen die
Bake ausgelesen. Identifikationsdaten des
– Das Log wird bezüglich der Attribute ent Moduls aus der VST
sprechend den Attributsformaten im Stan ermittelt werden, die aus
dard, der Wert gemäß den Vorgaben vom den Parametern CCC-
Einzeldokument 4.3.1 V3.1 und bzgl. der ContextMark,
Identifkationsdaten der VST ausgewertet. 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.
Name/ID Beschreibung Ziel
DSRC_SFXX_AWKT_0010 Eine Initialisierung (BST-VST) mit einer neuen Es soll nachgewiesen
Beacon-ID wird durchgeführt, um festzustellen, werden, dass die Dauer
ob das DUT kommunikationsbereit sind. vor dem Umschalten in
• Die Bake sendet danach eine neue BST den Energiesparmodus
mit der neuen Beacon-ID (1) und erwartet und damit die AwakeT-
Dauer des DUTs >100ms
ein private Windows.req vom DUT.
beträgt.
• Danach pausiert die Bake für 95 ms. Dieser Test erfolgt als
• Dann sendet die Bake eine zweite BST mit Labortest zur Verifizierung
einer neuen Beacon-ID (2) und erwartet der Anforderungen im
wieder ein private Windows.req vom DUT. Kapitel Interlayer
Management nach
• Die Dauer ab der BST mit Beacon-ID (1)
Einzeldokument 4.3.1
bis zum private window request nach der
Version 3.1 (Stand:
BST mit Beacon-ID (2) wird gemessen. 09.06.2022).
DSRC_SFXX_BCKT_5010 Eine Initialisierung (BST-VST) mit einer neuen Es soll nachgewiesen
Beacon-ID wird durchgeführt, um festzustellen, werden, dass die Dauer
ob das DUT kommunikationsbereit ist. Danach des BlockingTimer des
wird eine vollständige CCC:2019(SST301 DUT nicht größer als
v3.1)-Transaktion mit dem DUT mit einer 3 Sekunden ist. Dieser
neuen Beacon-ID (1) und einem Test erfolgt als Labortest
abschließenden Release (1) der Bake zur Verifizierung der
durchgeführt. Dann sendet Bake BSTs im Anforderungen im Kapitel
Abstand von 50 ms mit einer neuen Beacon-ID Interlayer Management
(2). Es wird die Zeit zwischen dem Release (1) nach Einzeldokument
und dem ersten darauffolgenden private 4.3.1 Version 3.1
window request ermittelt. (Stand: 09.06.2022).
DSRC_SFXX_BCKT_5011 Eine Initialisierung (BST-VST) mit einer neuen Es soll nachgewiesen
Beacon-ID wird durchgeführt, um festzustellen, werden, dass die Dauer
ob das DUT kommunikationsbereit ist. Danach des BlockingTimer des
wird eine vollständige CCC-Transaktion mit DUT nicht größer als
dem DUT mit einer neuen Beacon-ID (1) und 5 Sekunden ist.
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.
DSRC_SFXX_BLIM_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann sendet das DSRC-Modul alle
die Bake 200 Mal eine BST und registriert, ob empfangenen BSTs richtig
die OBU bis zuletzt mit einem private window auswertet.
request antwortet.
DSRC_SFXX_BV02_0001 • Eine Initialisierung (BST-VST) mit einer Es soll nachgewiesen
neuen Beacon-ID wird durchgeführt, um werden, dass das DUT
festzustellen, ob das DUT kommunika den RELEASE-Befehl mit
tionsbereit ist. einem ECHO.rq korrekt
verarbeitet.
• Für den eigentlichen Testfall wird eine
Initialisierung (BST-VST) mit einer neuen Der Testfall ist abgeleitet
BeaconID und einem anschließenden aus dem CCC
ISO_TS_13143-1:2020-11
EVENT-REPORT.request(RELEASE) mit
Normtestfall
Mode=0 und FlowControl=1 konfiguriert
TP/AP-BAS/OBU/BV/02
und aktiviert. (ECHO.rq mit Poll Bit=0,
• Danach wird mit der gleichen LID ein siehe ISO TS-13143-1).
ECHO.rq Command mit Poll Bit = 0 und
ohne Nutzdaten gesendet und überprüft,
ob die OBU/das DSRC Modul wider
Erwarten noch reagiert.
Name/ID Beschreibung Ziel
DSRC_SFXX_BV02_0002 • Eine Initialisierung (BST-VST) mit einer Es soll nachgewiesen
neuen Beacon-ID wird durchgeführt, um werden, dass das DUT
festzustellen, ob das DUT kommunikati den RELEASE-Befehl mit
onsbereit ist. derselben BST korrekt
verarbeitet.
• Für den eigentlichen Testfall wird eine
Initialisierung (BST-VST) mit einer neuen Der Testfall ist abgeleitet
Beacon-ID und einem anschließenden aus dem CCC
ISO_TS_13143-1:2020-11
EVENT-REPORT.request(RELEASE) mit
Normtestfall TP/AP-BAS/
Mode=0 und FlowControl=1 konfiguriert
OBU/BV/02
und aktiviert. (ECHO.rq mit Poll Bit=0,
• Danach wird mit der gleichen BST gesen siehe ISO TS-13143-1).
det und überprüft, ob das DUT wider Er (Sofortiges RELEASE).
warten reagiert.
• Anschließend wird nach 5s erneut die glei
che BST wiederholt und überprüft, ob das
DUT wider Erwarten reagiert.
DSRC_SFXX_BV02_0003 • Eine Initialisierung (BST-VST) mit einer Es soll nachgewiesen
neuen Beacon-ID wird durchgeführt, um werden, dass das DUT
festzustellen, ob das DUT kommunikati den RELEASE-Befehl mit
onsbereit ist. ECHO.rq (Poll Bit=1)
korrekt verarbeitet.
• Für den eigentlichen Testfall wird eine
Initialisierung (BST-VST) mit einer neuen Der Testfall ist abgeleitet
Beacon-ID durchgeführt, ein ECHO.rq aus dem CCC
ISO_TS_13143-1:2020-11
(Poll Bit=1) gesendet, das beantwortet
Normtestfall TP/AP-BAS/
werden soll, und anschließend mit einem
OBU/BV/02
EVENT-REPORT.request(RELEASE) mit (ECHO.rq mit Poll
Mode=0 und FlowControl=1 die Trans Bit=1: Initialisation, private
aktion abgeschlossen. ACn, RELEASE,
• Danach wird die gleiche BST wiederholt Initialisationsversuch).
und überprüft, ob das DUT wider Erwar
ten reagiert.
• Anschließend wird nach 5s erneut die glei
che BST wiederholt und überprüft, ob das
DUT wider Erwarten reagiert.
• Die Transaktionsdaten werden aus der
Bake ausgelesen und ausgewertet.
DSRC_SFXX_BV04_0010 Eine Initialisierung (BST-VST) mit einer neuen Es soll geprüft werden,
Beacon-ID wird durchgeführt, um festzustellen, dass das DUT den
ob das DUT kommunikationsbereit ist. Parameter beaconTime
• Für den eigentlichen Testfall wird eine der BST nach 256s
Initialisierung (BST-VST) mit einer neuen korrekt handhabt.
Beacon-ID mit mode=1 und Der Testfall ist abgeleitet
FlowControl=2 konfiguriert und aktiviert. aus dem CCC
ISO_TS_13143-1:2020-11
• Danach sendet die Bake ein ECHO.rq Normtestfall
Befehl, welcher von der OBU beantwortet TP/AP-BAS/OBU/BV/04.
werden soll.
• Nach 256 Sekunden sendet die Bake er
neut 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.
DSRC_SFXX_D003_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann führt die das DSRC-Modul korrekte
Bake Transaktionen mit zeitlichen Kontrollfeldkombinationen
Unterbrechungen und benutzt.
Übertragungswiederholungen durch.
Name/ID Beschreibung Ziel
DSRC_SFXX_DLAY_0010 Eine Initialisierung (BST-VST) mit einer neuen Es soll nachgewiesen
Beacon-ID wird durchgeführt, um festzustellen, werden, dass das DUT
ob das DUT kommunikationsbereit ist. auch bei unterschiedlich
• Dann führt die Bake eine Initialisierung langen Pausen, wie sie
(BST-VST) mit einer neuen Beacon-ID bei schwachen
Funkbedingungen üblich
durch.
sind,
• Danach sendet die Bake ein ECHO.rq, für kommunikationsbereit
das eine Antwort erwartet wird. Dieser bleibt.
ECHO.rq wird mit einer um 0.1 ms wach Dieser Test erfolgt als
senden Pause wiederholt bis eine Pause Labortest in Anlehnung an
von 1s erreicht wird. die Testspezifikation ISO/
• Wenn die OBU alle ECHO.rq beantwortet TS 14907-1:2015 Table
hat, ist der Testfall bestanden. B7-Traffic Conditions-
Shadowing.
DSRC_SFXX_HISX_5010 – Eine Initialisierung (BST-VST) mit einer In der Version 2019-11 hat
neuen Beacon-ID wird durchgeführt, um der ISO 12813 u.a. die
festzustellen, ob das DUT kommunika Attribute 99 (Extended
tionsbereit ist. OBUStatusHistoryPart1)
und 100 (ExtendedOBU
– Der Benutzer wird aufgefordert den Zu StatusHistoryPart2) neu
stand des DUTs (Go-1) einzustellen (an eingeführt.
Stromversorgung angeschlossen, GNSS
Dieser Testfall soll sicher
und Mobilfunk verfügbar, MMI zeigt Be
stellen, dass das DUT
triebsbereitschaft an).
gemäß Einzeldokument
– Die Bake führt eine CCC-Transaktion 4.3.1 Version 3.1 (Stand:
durch. Aus dem Transaktionslog werden 09.06.2022) Kap. 2.2
die Attribute 53, 61, 99 und 100 zur Aus diese Attribute korrekt
wertung ausgelesen. setzt.
– Der Benutzer wird aufgefordert für 5 Minu
ten das DUT in eine abgeschirmte Kammer
mit angeschlossener Stromversorgung ab
zulegen. (Kein GNSS und Mobilfunk ver
fügbar).
– Der Benutzer wird aufgefordert das DUT
aus der abgeschirmten Kammer rauszu
nehmen 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 Aus
wertung 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 Zeit
stempel hat, der weniger als 11 Minuten
alt und der Zustand noGo-0 ist.
– Der Benutzer wird aufgefordert für 5 Minu
ten 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
Name/ID Beschreibung Ziel
– 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 Strom
versorgung einzuschliessen.
– Die Bake führt eine CCC-Transaktion
durch. Aus dem Transaktionslog werden
die Attribute 53, 61, 99 und 100 zur Aus
wertung ausgelesen. Es wird erwartet,
dass der Zustand Go-1 erreicht ist.
Akzeptanzkriterium ist, dass
– die zuvor aktuellsten drei Einträge eine Po
sition 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ön
nen Abweichungen zum Erzwingen eines an
deren Status-Zustand beschrieben sein.
DSRC_SFXX_HNG1_0010 Eine Initialisierung (BST-VST) mit einer neuen Es soll geprüft werden,
Beacon-ID wird durchgeführt, um festzustellen, dass das DUT auch dann
ob das DUT kommunikationsbereit ist. sauber kommuniziert,
• Dann führt die Bake erneut eine Initialisie wenn die Bake nach der
rung (BST-VST) mit einer neuen Beacon- Initialisierung weitere
Transaktionsphasen mit
ID mit dem DUT durch.
einer anderen LID
• Die Bake sendet ein GET_STAMPED.rq durchführt (Was vom DUT
mit einer anderen LID für das Attribut 32, nicht beantworten werden
das mit einem GET_STAMPED.rq für die darf).
Attribute 24, 16, 19, 55, 22, 17, 61, 62 Dieser Test erfolgt als
verkettet ist, das DUT darf nicht darauf Labortest in Anlehnung an
reagieren. die Testspezifikation ISO/
• Die Bake sendet ein GET_STAMPED.rq TS 14907-1:2015 Table
mit einer anderen LID für die Attribute 32, B1-B3-Traffic Conditions-
60, 50, 52, 49, das DUT darf nicht darauf lateral and longitudinal
distance between OBUs.
reagieren.
• Die Bake sendet ein RELEASE mit einem
anderen LID, das DUT das darf nicht da
rauf 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.
Name/ID Beschreibung Ziel
DSRC_SFXX_HNG2_0010 Eine Initialisierung (BST-VST) mit einer neuen Es soll nachgewiesen
Beacon-ID wird durchgeführt, um festzustellen, werden, dass das DUT
ob das DUT kommunikationsbereit ist. auch dann sauber
• Dann führt die Bake erneut eine Initialisie kommuniziert, wenn die
rung (BST-VST) mit einer neuen Beacon- Bake die Kommunikation
nach der Initialisierung
ID mit dem DUT durch.
unterbricht und später
• Die Bake wartet für die Dauer von zwei wieder aufnimmt.
Datenaustauschphasen einer CCC-Trans Dieser Test erfolgt als
aktion (20 ms) Labortest in Anlehnung an
• Die Bake sendet ein RELEASE mit einer die Testspezifikation ISO/
anderen LID, das DUT darf nicht darauf TS 14907-1:2015 Table
reagieren. B7-Traffic Conditions-
Shadowing.
• 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.
DSRC_SFXX_HNG3_0010 Eine Initialisierung (BST-VST) mit einer neuen Es soll geprüft werden,
Beacon-ID wird durchgeführt, um festzustellen, dass das DUT auch dann
ob die OBU/DSRC-Modul sauber kommuniziert,
kommunikationsbereit ist. wenn die Bake nach der
• Dann führt die Bake erneut eine Initialisie Initialisierung die
rung (BST-VST) mit einer neuen Beacon- Kommunikation
unterbricht und wieder
ID mit der OBU/DSRC Modul durch.
neu initialisiert.
• Die Bake wartet für die Dauer einer Mit diesem Testfall soll in
gesamten CCC-Transaktion (30 ms). An einem Labortest die
schliessend führt die Bake erneut eine BALM-Anforderung für die
neue Initialisierung (BST-VST) mit einer Mobile Kontrolle nach
neuen Beacon-ID mit dem DUT durch. Einzeldokument 4.3.1
• Die Bake sendet ein GET_STAMPED.rq Version 3.1
mit der LID für das oben registrierte DUT (Stand:09.06.2022)
für das Attribut 32, welche mit einem überprüft werden, mit der
GET_STAMPED.rq für die Attribute 24, 16, nach einer
fehlgeschlagenen
19, 55, 22, 17, 61, 62 verkettet wurde.
Transaktion die CCC-
• Die Bake sendet ein GET_STAMPED.rq Transaktion mit einer
mit der LID für das oben registrierte DUT neuen Beacon-ID neu
für die Attribute 32, 60, 50, 52, 49. aufgesetzt werden kann.
• Die Bake sendet ein RELEASE mit der LID
für das oben registrierte DUT.
Name/ID Beschreibung Ziel
DSRC_SFXX_HNG4_0010 Eine Initialisierung (BST-VST) mit einer neuen Es soll geprüft werden,
Beacon-ID wird durchgeführt, um festzustellen, dass das DUT auch dann
ob das DUT kommunikationsbereit ist. sauber kommuniziert,
Dann führt die Bake erneut eine Initialisierung wenn die Bake nach der
(BST-VST) mit einer neuen Beacon-ID mit dem Initialisierung fehlerhafte
DUT durch. Frames versendet und
dann eine neue
• Die Bake sendet während der gesamten Transaktion durchführt.
Dauer (30 ms) einer CCC-Transaktion
Mit diesem Testfall soll in
Zufallsdaten (Fehlerhafte DSRC-Rah
einem Labortest geprüft
men). werden, dass die BALM-
• Anschliessend führt die Bake erneut eine Anforderung für die Mobile
neue Initialisierung (BST-VST) mit einer Kontrolle nach
neuen Beacon-ID mit dem DUT durch. Einzeldokument 4.3.1
• Die Bake sendet ein GET_STAMPED.rq Version 3.1
(Stand:09.06.2022), mit
mit der LID für die oben registrierte OBU/
der nach einer
das DSRC Modul für das Attribut 32, die fehlgeschlagenen
mit einem GET_STAMPED.rq für die Transaktion die CCC-
Attribute 24, 16, 19, 55, 22, 17, 61, 62 Transaktion mit einer
verkettet wurde. neuen Beacon-ID neu
• Die Bake sendet ein GET_STAMPED.rq aufgesetzt werden kann,
mit der LID für das oben registrierte DUT mit dem DUT erfüllt
für die Attribute 32, 60, 50, 52, 49. werden kann.
• Die Bake sendet ein RELEASE mit der LID
für das oben registrierte DUT.
DSRC_SFXX_LID_0010 Zunächst wird eine Dummytransaktion Es soll sichergestellt
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann wird das DSRC-Modul die LID
nach einer regulären Initialisierungsphase das korrekt handhabt.
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.
DSRC_SFXX_MV02_0010 Zunächst wird eine Dummytransaktion Es soll nachgewiesen
durchgeführt, um sicherzustellen, dass die werden, dass die OBU/
OBU kommunikationsbereit ist. Dann wird die das DSRC-Modul auf
OBU initialisiert. Anschließend werden jeweils Befehle der Bake reagiert,
zwei ECHO.rq so gesendet, dass ein die mit der kleinsten er
bestimmter Zeitabstand zwischen dem Ende laubten Verzögerung von
des ersten ECHO.rs und dem Anfang des T1 zwischen Ende der
zweiten ECHO.rq liegt. Dieser Zeitabstand Antwort auf den vorigen
wird schrittweise auf dem minimalen erlaubten Befehl und Anfang des
Abstand (T1) reduziert. neuen Befehls gesendet
werden.
Name/ID Beschreibung Ziel
DSRC_SFXX_SETA_5010 Eine Initialisierung (BST-VST) mit einer neuen Es soll nachgewiesen
Beacon-ID wird durchgeführt, um festzustellen, werden, dass vom Nutzer
ob das DUT kommunikationsbereit ist. Die alle Einstellmöglichkeiten
nächsten Schritte werden für alle der Achszahl korrekt im
Einstellmöglichkeiten der Achszahl wiederholt. entsprechenden
Der Tester stellt im DUT die Achszahl (initial Attribut 19 gespeichert
auf den kleinstmöglichen Wert) ein und und bei einer CCC:2019
bestätigt die Einstellung. Der Tester gibt die am (SST301 v3.1)-
DUT eingestellte Achszahl am Testplatz ein. Transaktion an die Bake
Die Bake führt eine CCC:2019(SST301 v3.1)- übertragen werden.
Transaktion (incl. Auslesung des Attributs 19)
durch. Die Transaktionsdaten werden darauf
untersucht, ob die über DSRC ausgelesene
Achszahl dem eingegebenen Wert entspricht.
DSRC_SFXX_SETG_5010 – Eine Initialisierung (BST-VST) mit einer Es soll nachgewiesen
neuen Beacon-ID wird durchgeführt, um werden, dass das vom
festzustellen, ob das DUT kommunika Nutzer eingestellte
tionsbereit ist. Gewicht korrekt im
entsprechenden Attribut
– Der Tester stellt in dem DUT (je nach Typ (55) gespeichert und bei
des DUTs) das Gewicht oder die Ge einer CCC:2019(SST301
wichtsklasse auf den kleinstmöglichen v3.1)-Transaktion an die
Wert ein und bestätigt die Einstellung. Bake übertragen wird.
– Die nächsten Schritte werden so wieder- Mit diesem Testfall wird
holt, dass nach Möglichkeit die Gewichte überprüft, in welchem
unterhalb und oberhalb der Gewichtsklas Einstellbereich die
segrenzen eingestellt werden. Gewichtseinstellung des
– Der Tester stellt im DUT das Gewicht bzw. DUTs veränderbar ist.
die Gewichtsklasse (initial auf den kleinst
möglichen Wert) ein und bestätigt die Ein
stellung.
– 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 un
tersucht, ob das über DSRC ausgelesene
Gewicht dem eingegebenen Wert ent
spricht.
DSRC_SFXX_STPW_5010 Zunächst wird die Sendeleistung der Bake auf Es soll nachgewiesen
den gewünschten Wert eingestellt und werden, dass eine OBU/
testweise eine Transaktion ausgelöst. Falls ein DSRC-Modul alle drei
keine Kommunikation mit der OBU erfolgt, wird public Anmeldefenster
der Testlauf abgebrochen. Dann werden bei gleichmäßig nutzt.
laufend wechselnder Beacon-ID im Dauertest Darüberhinaus werden
CCC:2019(SST301 v3.1)-Transaktionen Statistiken zur zeitlichen
durchgeführt. Nach Ablauf der Testdauer wird Lage der private windows
die Bake angehalten und das Log auf die requests erhoben.
zeitliche Lage der public windows requests
untersucht. Für eine tiefergehende Analyse
wird aus den Sendezeitpunkten zusätzlich ein
PDF und ein CSV erzeugt.
Name/ID Beschreibung Ziel
DSRC_SFXX_STPW_5015 Zunächst wird die Sendeleistung der Bake auf Es soll nachgewiesen
den gewünschten Wert eingestellt und werden, dass die OBU/
testweise eine Transaktion ausgelöst. Falls das DSRC-Modul das
keine Kommunikation mit der OBU erfolgt, wird erlaubte Zeitfenster für
der Testlauf abgebrochen. Dann werden bei Übertragungen in private
laufend wechselnder Beacon-ID im Dauertest uplink windows einhält.
CCC:2019(SST301 v3.1)-Transaktionen Darüberhinaus werden
durchgeführt. Nach Ablauf der Testdauer wird Statistiken zur zeitlichen
die Bake angehalten und das Log auf die Lage der Übertragungen
zeitliche Lage der private windows requests erhoben.
untersucht. Für eine tiefergehende Analyse
wird aus den Sendezeitpunkten zusätzlich ein
PDF und ein CSV erzeugt.
DSRC_SFXX_STPW_5020 Zunächst wird die Sendeleistung der Bake auf Es soll nachgewiesen
den gewünschten Wert eingestellt und werden, dass mehrere
testweise eine Transaktion ausgelöst. Falls DUT des gleichen
keine Kommunikation mit den OBUs erfolgt, Herstellers jeweils alle
wird der Testlauf abgebrochen. Dann werden drei public
bei laufend wechselnder Beacon-ID im Anmeldefenster
Dauertest CCC:2019(SST301 v3.1)- gleichmäßig nutzt.
Transaktionen durchgeführt. Nach Ablauf der Darüberhinaus werden
Testdauer wird die Bake angehalten und das Statistiken zur zeitlichen
Log auf die zeitliche Lage der private windows Lage der private windows
requests untersucht. Für eine tiefergehende requests erhoben.
Analyse wird aus den Sendezeitpunkten
zusätzlich ein PDF und ein CSV erzeugt.
DSRC_SFXX_STPW_5030 – Eine Initialisierung (BST-VST) mit einer Es soll nachgewiesen
neuen Beacon-ID wird durchgeführt, um werden, dass das DUT im
festzustellen, ob alle OBUs/DSRC-Module Zusammenspiel mit drei
(DUT und drei weitere DSRC-Module) weiteren OBUs (Module
kommunikationsbereit sind. verschiedener Typen und
Hersteller) alle drei public
– Die Bake wird für einen Dauertest konfigu Anmeldefenster
riert, der über eine Zeit von 5 Stunden mit gleichmäßig nutzt und die
folgenden Einstellungen durchgeführt wird: Module sich nicht
1. Beacon Change Intervall 15s gegenseitig stören.
(Erfahrungsgemäß halten
2. CCC:2019(SST301 v3.1)-Transaktionen
nicht alle Lieferanten von
für Max 15s DSRC Modulen die in der
3. Nach der Transaktion wird die Bake für Norm vorgegebenen
15s angehalten (Simulation des Verlas Zeiteinheiten für die Public
sens der Kommunikationszone) Windows ein).
– Nach Ablauf der Testdauer wird das Bake
log auf die zeitliche Lage der public win
dows requests untersucht. Darüberhinaus
werden Statistiken zur zeitlichen Lage der
public windows requests erhoben
(PublicWindows Zeit-Überlappung und
-Verletzungen).
DSRC_SFXX_STTD_5010 Zunächst wird testweise eine Transaktion Es soll nachgewiesen
ausgelöst. Falls keine Kommunikation mit der werden, dass die OBU/
OBU erfolgt, wird der Testlauf abgebrochen. das DSRC-Modul
Dann werden bei laufend wechselnder Transaktionen innerhalb
Beacon-ID im Dauertest CCC:2019(SST301 der vorgesehenen Dauer
v3.1)-Transaktionen durchgeführt. Nach Ablauf durchführen kann.
der Testdauer wird die Bake angehalten und Gemäß Kap. 4.2.1 der
aus dem Log die Verteilung der Gebietsvorgaben
Transaktionsdauern ermittelt. (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.
Name/ID Beschreibung Ziel
DSRC_SFXX_STTD_5020 Zunächst wird der Sende Pegel der Bake auf Es soll nachgewiesen
einem mittleren Wert eingestellt (zum Beispiel werden, dass die OBU/
30 dbm). Dann werden bei laufend das DSRC-Modul auch
wechselnder Beacon-ID im Dauertest bei mäßigen Kommunika
CCC:2019(SST301 v3.1)-Transaktionen tionsbedingungen Trans
durchgeführt. Nach Ablauf der Testdauer wird aktionen innerhalb der
die Bake angehalten und aus dem Log die vorgesehenen Dauer
Verteilung der Transaktionsdauern ermittelt. durchführen kann. Gemäß
Kap. 4.3.1 der Gebiets
vorgaben (Einzeldoku
ment 4.3.1 Version 3.1
(Stand: 09.06.2022)) wird
gefordert, dass eine un
gestörte Transaktion in
einer maximalen Trans
aktionszeit von 70 ms er
folgen soll.
DSRC_SFXX_STTD_5030 Zunächst wird der Sende Pegel der Bake auf Es soll nachgewiesen
einem niedrigen Wert eingestellt (zum Beispiel werden, dass die OBU/
27 dbm). Dann werden bei laufend das DSRC-Modul auch
wechselnder Beacon-ID im Dauertest bei schwachen
CCC:2019(SST301 v3.1) -Transaktionen Kommunikationsbedin
durchgeführt. Nach Ablauf der Testdauer wird gungen Transaktionen in
die Bake angehalten und aus dem Log die nerhalb der vorgesehenen
Verteilung der Transaktionsdauern ermittelt. Dauer durchführen kann.
Gemäß Kap. 4.3.1 der
Gebietsvorgaben (Einzel
dokument 4.3.1 Version
3.1 (Stand: 09.06.2022))
wird gefordert, dass eine
ungestörte Transaktion in
einer maximalen Trans
aktionszeit von 70 ms er
folgen soll.
DSRC_SFXX_STTD_5040 – Eine Initialisierung (BST-VST) mit einer Es soll nachgewiesen
neuen Beacon-ID wird durchgeführt, um werden, dass das DUT
festzustellen, ob alle OBUs/DSRC-Module Transaktionen innerhalb
kommunikationsbereit sind. der vorgesehenen
Transaktionzeiten (<70
– Die Bake wird für einen Dauertest konfigu ms) mit der DSRC Bake
riert, der über einen Zeitraum von 5 Stun durchführen kann, wenn
den mit folgenden Einstellungen durchge mehrere DSRC-Module
führt wird: (max 3 weitere Module
1. Beacon Change Intervall 15s verschiedener Typen und
Hersteller) gleichzeitig
2. CCC:2019(SST301 v3.1)-Transaktionen
kommunizieren.
für Max 15s
Dieser Test erfolgt als
3. Nach der Transaktion wird die Bake für Labortest in Anlehnung an
15s angehalten (Simulation des Verlas die Testspezifikation ETSI
sens der Kommunikationszone) TS 102 486-1-2 TP/MAC/
– Nach Ablauf der Testdauer wird aus den OBU/BV/01 und in
Bake-Logs die Verteilung pro OBU/DSRC Anlehnung an die
Modul Transaktionszeiten ermittelt. 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).
Name/ID Beschreibung Ziel
DSRC_SFXX_TRPT_5040 – Eine Initialisierung (BST-VST) mit einer Es soll nachgewiesen
neuen Beacon-ID wird durchgeführt, um werden, dass in einem
festzustellen, ob das DUT kommunika Dauerlauf das DUT alle
tionsbereit ist. CCC:2019(SST301 v3.1)-
Transaktionen erfolgreich
– Die Bake wird für einen Dauertest konfigu durchführt.
riert, der über einen Zeitraum von 5 Stun In Anlehnung an die
den mit folgenden Einstellungen durchge Bitfehlerraten-Tests der
führt wird: EN300674-2-2 wird in
1. Beacon Change Intervall 15s diesem Labortest die
Übertragungssicherheit im
2. CCC:2019(SST301 v3.1)-Transaktionen
stabilen Laboraufbau
für Max 15s überprüft.
3. Nach der Transaktion wird die Bake für
15s angehalten (Simulation des Verlas
sens der Kommunikationszone)
– Nach Ablauf der Testdauer wird aus dem
Backlog die Anzahl der durchgeführten
Transaktionen mit den zu erwartenden
Transaktionen verglichen.
DSRC_SFXX_UCON_5010 Eine Initialisierung (BST-VST) mit einer neuen In der Version 2019-11 hat
Beacon-ID wird durchgeführt, um festzustellen, der ISO 12813 u.a. das
ob das DUT kommunikationsbereit ist. Attribut 101
– Ein Fehler wird provoziert (zum Beispiel (UserConfirmation) neu
kein GNSS Empfang). eingeführt. Dieser Testfall
soll sicherstellen, dass
– Der Benutzer wird aufgefordert die Fehler das DUT dieses Attribut
meldung zu bestätigen. korrekt setzt.
– Die Bake führt eine CCC-Transaktion
durch. Aus dem Transaktionslog wird der
Zeitstempel der UserConfirmation ausge
lesen, der den Zeitpunkt der Bestätigung
entspricht.
DSRC_SFXX_WKUP_0010 – Eine Initialisierung (BST-VST) mit einer Es soll sichergestellt
neuen Beacon-ID wird durchgeführt, um werden, dass die
festzustellen, ob die OBU/DSRC-Module Wakeup-Dauer des DUTs
kommunikationsbereit sind. unter 20 ms liegt.
– Die Bake pausiert für 10 Sekunden.
– Dann sendet die Bake BSTs, bis sie ein pri
vate window request empfängt. Die Dauer
ab der ersten BST bis zum private window
request wird gemessen.
DSRC_SFXX_FUL1_5010 Das Dämpfungsglied wird für den Es soll sichergestellt wer
gewünschten Pegelverlauf eingestellt, die den, dass die OBU/das
Bake führt eine CCC:2019(SST301 v3.1)- DSRC-Modul unter Funk
Transaktion durch und das Log wird auf bedingungen [FootPrint
korrekte LID, Kontrollfelder und Vollständigkeit (KonSL)], die dem Wirk
der Transaktion überprüft. Der Testfall wird als betrieb möglichst nahe
Dauertest über einen einstellbaren Zeitraum kommen, ordnungsgemäß
wiederholt. Abschließend wird die Transaktionen durchfüh
Transaktionserfolgsrate ausgegeben, wobei ren kann.
für jeden Initialisierungsversuch der Bake Hinweis:
mindestens ein private request der Bake FootPrint (KonSL):
erwartet wird. DSRC_SFXX_FUL1_501
0-KonSL-LKW-3.5mSeitl-
plusLöcher.txt
Der Pegelverlauf basiert
auf der Messung einer
LKW-Passage an einer
KonSL, wobei die Mess
daten durch manuell ein
gefügte Pegeleinbrüche
künstlich verschlechtert
werden.
Name/ID Beschreibung Ziel
DSRC_SFXX_FUL2_5010 Das Dämpfungsglied wird für den Es soll sichergestellt wer
gewünschten Pegelverlauf eingestellt, die den, dass die OBU/das
Bake führt eine CCC:2019(SST301 v3.1)- DSRC-Modul unter Funk
Transaktion durch und das Log wird auf bedingungen [Footprint
korrekte LID, Kontrollfelder und Vollständigkeit (KonMA)], die dem Wirk
der Transaktion überprüft. Der Testfall wird als betrieb möglichst nahe
Dauertest über einen einstellbaren Zeitraum kommen, ordnungsgemäß
wiederholt. Abschließend wird die Transaktionen durchfüh
Transaktionserfolgsrate ausgegeben, wobei ren kann.
für jeden Initialisierungsversuch der Bake Hinweis:
mindestens ein private request der Bake Footprint (KonMA):
erwartet wird. DSRC_SFXX_FUL2_
5010-KonMa1-
plusLöcher.txt
Der Pegelverlauf basiert
auf der Messung einer
KonMA-Passage an ei
nem LKW, wobei die
Messdaten durch manuell
eingefügte Pegeleinbrü
che künstlich verschlech
tert werden.
SRC_SFXX_FUL3_5010 Das Dämpfungsglied wird für den Es soll sichergestellt wer
gewünschten Pegelverlauf eingestellt, die den, dass die OBU/das
Bake führt eine CCC:2019(SST301 v3.1)- DSRC-Modul unter Funk
Transaktion durch und das Log wird auf bedingungen [Footprint
korrekte LID, Kontrollfelder und Vollständigkeit (Sägezahn)], die dem
der Transaktion überprüft. Der Testfall wird als Wirkbetrieb möglichst
Dauertest über einen einstellbaren Zeitraum nahekommen, ordnungs
wiederholt. Abschließend wird die gemäß Transaktionen
Transaktionserfolgsrate ausgegeben, wobei durchführen kann.
für jeden Initialisierungsversuch der Bake Hinweis:
mindestens ein private request der Bake Footprint (Sägezahn):
erwartet wird. DSRC_SFXX_FUL3_
5010-Saegezahn.txt
Der Pegel wird jeweils um
2,8dB besser und ver
schlechtert sich dann wie
der langsam um 1,8 dB.
Das wird so lange wie
derholt, bis ein unge
dämpfter Kanal erreicht
ist.
DSRC_SFXX_2BKN_5010 Zunächst wird testweise eine Transaktion Es soll nachgewiesen
separat mit jeder der beteiligten Baken werden, dass das DSRC-
ausgelöst. Falls keine Kommunikation mit der Modul sich in einer worst
OBU erfolgt, wird der Testlauf abgebrochen. case-Situation, die aber
Dann werden bei gleichbleibender Beacon-ID bei einer Vorbeifahrt einer
an beiden Baken im Parallelbetrieb CCC:2019 KonMA unter der KonAU
(SST301 v3.1)-Transaktionen durchgeführt. Es auftritt, korrekt verhält.“
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.
ee) Abschnitt 3.2 wird wie folgt gefasst:
„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 Ein Test-LKW mit Test-
durchlaufen eine FzG, aber unzureichend
Gebrauchstauglichkeitsprüfung (GTP). Im deklarierter Achsklasse
Rahmen der Kompatibilitätstests wird die und/oder Gewichtsklasse
Umsetzung der funktionalen Anforderungen an erzeugt eine Fallgruppe 6
die EETS-Fahrzeuggeräte in einem E2E- (Falschdeklarierer).
Szenario überprüft. Korrekte und vollständige
In diesem Testfall wird die Erzeugung der DSRC-Daten (gemäß
Fallgruppe 6 (Falschdeklarierer) mit einem SST-Spezifikation 301
Test-FzG überprüft. Ein Test-FzG wird im Test- Version 3.0/3.1).
LKW (mit Anhänger) benutzt und auf eine
geringere Achszahl bzw. Gewichtsklasse per
sonalisiert, als der Test-LKW inklusive Anhän
ger tatsächlich besitzt. Bei einer Durchfahrt
unter der Test-Kontrollstelle wird überprüft, ob
die Test-Kontrollstelle gemäß aktuellem Tarif
parametermodell einen Falschdeklarier er
kennt.
Für die Kommunikation mit den EETS-Fahr
zeuggeräten müssen die Kontrollstellen neben
der Gebietsvorgaben V2.1/2.2 auch die Vor
gaben der Version 3.0/3.1 unterstützen. An
hand der ContextMark kann die Kontrollstelle
entscheiden, ob die weitere Kommunikation
nach den neuen Gebietsvorgaben 3.0/3.1 zu
erfolgen hat oder nicht.
AutoKST_SVF_ Der Testfall prüft ein häufig im Pilotbetrieb Ein Test-LKW mit falsch
FG06AV_2xFzG auftretendes Szenario: deklariertem Test-FzG
Ein mautpflichtiges Fahrzeug ist mit einem (FzG_1) und einem wei
Fahrzeuggerät (FzG_1) des EETS-Anbieters teren FzG (FzG_2) im
sowie einem zweiten deaktivierten/gesperrten Status NOK erzeugt einen
Fahrzeuggerät (FzG_2) eines weiteren Anbie Verdachtsfall der Fall
ters ausgestattet. Um einen Kontrollfall inklu gruppe 6 (Falschdeklarie
sive DSRC-Daten zu erzeugen, wird das rer).
Szenario in Form eines Falschdeklarierers Die DSRC-Daten beider
durchgeführt. Fahrzeuggeräte werden
FzG_1 und FzG_2 werden im Test-LKW (mit korrekt und vollständig
Anhä̈nger) positioniert. FzG_1 wird auf eine übertragen, wobei aus
geringere Achszahl bzw. Gewichtsklasse de schließlich eine Auffällig
klariert, als der Test-LKW inklusive Anhänger keit des im Rahmen der
tatsächlich besitzt. FzG_2 befindet sich im Gebrauchstauglichkeits
Status NOK (gesperrt/deaktiviert). prüfung zu testenden
EETS-Fahrzeuggeräts
Für die Kommunikation mit den EETS-Fahr (FzG_1) zum Fehlschla
zeuggeräten müssen die Kontrollstellen neben gen des Testfalls führen
der Gebietsvorgaben V2.1/2.2 auch die Vor kann.
gaben der Version 3.0/3.1 unterstützen.
Kommunikation gemäß
Anhand der ContextMark kann die Kontroll SST-Spezifikation 301
stelle entscheiden, ob die weitere Kommuni (Version 3.0/3.1).
kation nach den neuen Gebietsvorgaben 3.0/
3.1 zu erfolgen hat oder nicht.
Name/ID Beschreibung Ziel
AutoKST_SVF_FG07_ Fahrzeuggeräte von neuen EETS-Providern Ein Test-LKW mit Test-
mautfreier_Modus durchlaufen eine Gebrauchstauglichkeitsprü FzG, welches sich im
fung (GTP). Im Rahmen der Kompatibilitäts mautfreien Modus befin
tests wird die Umsetzung der funktionalen det, erzeugt eine Fall
Anforderungen an die EETS-Fahrzeuggeräte gruppe 7.
in einem E2E-Szenario überprüft. • Auswertung nach SST
In diesem Testfall wird die Erzeugung der 301 v.3.0/3.1 durch
Fallgruppe 7 mit einem Test-FzG überprüft. Attribut Extended
Ein Test-FzG wird im Test-LKW (mit Anhänger) OBUStatusHistory
angeschlossen. Anschließend wird das Test- Part1.
FzG so eingestellt, dass das Fahrzeug damit
• Korrekte und vollstän
im Gebiet BFstrMG nicht mautpflichtig ist.
dige DSRC-Daten
Bei der Durchfahrt an der Kontrollstelle wird (gemäß SST-Spezifi
überprüft ob die Kontrollstelle eine FG7
kation 301 Version
erkennt.
3.0/3.1).
Für die Kommunikation mit den EETS-Fahr
zeuggeräten müssen die Kontrollstellen neben
der Gebietsvorgaben V2.1/2.2 auch die Vor
gaben der Version 3.0 unterstützen.
Anhand der ContextMark kann die Kontroll
stelle entscheiden, ob die weitere Kommuni
kation nach den neuen Gebietsvorgaben
3.0/3.1 zu erfolgen hat oder nicht.
AutoKST_SVF_FG12 Fahrzeuggeräte von neuen EETS-Providern Ein LKW mit einem ein
durchlaufen eine Gebrauchstauglichkeits gebauten FzG, welches
prüfung (GTP). Im Rahmen der Kompatibili gesperrt ist, erzeugt eine
tätstests wird die Umsetzung der funktionalen FG 12
Anforderungen an die EETS-Fahrzeuggeräte Auswertung nach SST
in einem E2E-Szenario überprüft. 301 v.3.0/3.1 durch Attri
In diesem Testfall wird die Erzeugung der but ExtendedOBUStatus
Fallgruppe 12 mit einem Test-FzG überprüft. HistoryPart1: FzG-Status
Der Test-LKW dessen Test-FzG mit dem "noGoContractual" oder
Status "gesperrt" eingesetzt ist, passiert die "noGoPaymentMeans"
Kontrollstelle. Die DSRC-Daten aus dem Test- (Parameter entsprechen
FzG werden von der Test-Kontrollstelle aus der jeweiligen Testkon
gelesen. Der Status "gesperrt" wird festgestellt figuration)".
und die Test-Kontrollstelle erzeugt einen Ver
dachtsfall der Fallgruppe 12. Dieser wird • Korrekte und vollstän
anschließend an die Test-KonZ_2.0 gesendet. dige DSRC-Daten
Für die Kommunikation mit den EETS-Fahr (gemäß SST-Spezifi
zeuggeräten müssen die Kontrollstellen neben kation 301 Version
der Gebietsvorgaben V2.1/2.2 auch die Vor 3.0/3.1).
gaben der Version 3.0/3.1 unterstützen.
Anhand der ContextMark kann die Kontroll
stelle entscheiden, ob die weitere Kommuni
kation nach den neuen Gebietsvorgaben
3.0/3.1 zu erfolgen hat oder nicht.
AutoKST_SVF_FG16 Fahrzeuggeräte von neuen EETS-Providern Ein Test-LKW mit korrekt
durchlaufen eine Gebrauchstauglichkeits eingestelltem Test-FzG
prüfung (GTP). Im Rahmen der Kompatibili erzeugt die FG16
tätstests wird die Umsetzung der funktionalen (Gutzahler AV).
Anforderungen an die EETS-Fahrzeuggeräte Korrekte und vollständige
in einem E2E-Szenario überprüft. DSRC-Daten (gemäß
Der Test-LKW befindet sich im automatischen SST-Spezifikation 301
Verfahren. Das Test-FzG wurde den Klassifi Version 3.0/3.1).
kationsdaten entsprechend des Test-LKWs Die Falldaten werden
oder höher (Überzahler) konfiguriert. nicht an die KonZ_2.0
Der Test-LKW passiert die Test-Kontrollstelle, verschickt und in der Test-
der DSRC-Datensatz aus dem Test-FzG wird Kontrollstelle gelöscht.
ausgelesen.
Die Test-Kontrollstelle entscheidet aufgrund
der deklarierten Parameter und der Sensorik
daten auf FG16.
Der Fall wird nicht an die KonZ_2.0 verschickt
und in der Test-Kontrollstelle gelöscht.
Name/ID Beschreibung Ziel
AutoKST_ Fahrzeuggeräte von neuen EETS-Providern Ein Test-LKW mit einem
Verifikation_EETS_ durchlaufen eine Gebrauchstauglichkeits Test-FzG des EETS-
Masterkey prüfung (GTP). Im Rahmen des Kompatibili Anbieters passiert als
tätstests wird die Umsetzung der funktionalen Gutzahler die
Anforderungen an die EETS-Fahrzeuggeräte Kontrollstelle.
in einem E2E-Szenario überprüft. DSRC-Daten werden
In diesem Testfall wird der neu aufgespielte vollständig erfasst und
EETS-Masterkey auf der dezentralen Kom entschlüsselt (gemäß
ponente (KonAu/KonSL) verifiziert. SST-Spezifikation 301
Version 3.0/3.1).
KonB_DezKst_SVF_FG Fahrzeuggeräte von neuen EETS-Providern Sicherstellung, dass der
durchlaufen eine Gebrauchstauglichkeits Kontrollfall aus der
prüfung (GTP). Im Rahmen der Kompatibili KonZ_2.0 korrekt in der
tätstests wird die Umsetzung der funktionalen KonB ankommt.
Anforderungen an die EETS-Fahrzeuggeräte Gewährleistung
in einem E2E-Szenario überprüft. Interoperabilität
Ein Test-LKW passiert eine Kontrollstelle und Kontrollstelle zu
ein Verdachtsfall wird angelegt. Dieser Ver weiterführenden
dachtsfall wird in der KonZ2.0 mit der pas Systemen.
senden Fallgruppe gespeichert.
Kontrollfall- und Nacherhebungsdaten werden
aus der KonZ_2.0 in die KonB (zunächst aKA)
übertragen. Anschließend werden die Daten in
die VB übernommen und aufbereitet.
Übertragung bis ins SC-OWI sowie die
Rückantwort an die KonZ_2.0 werden
überprüft.
KonMa_auswinken_VKB Das Fahrzeug wird ausgewunken. Ein Erfolgreiches Erstellen
verkürzter Kontrollbericht (VKB, FG19) wird eines VKB (FG19).
ohne weitere Kontrolle erstellt.
KonMa_KonZ_2.0_ Dieser Testfall prüft die Weiterverarbeitung von Absicherung der
Berichte_weiterverarbeiten_ Kontrollfällen mit einem Kontrollbericht über Übermittlung von
in_KonB die KonZ_2.0 bis in die KonB. Fahrzeugkontrollfällen
Die Überprüfung erfolgt für den Kontrollfall, nach SC-OWI.
Kontrollfalldaten bzw. die erfassten Optional: Absicherung der
Beweismittel. Es wird die e-Akte in SC-OWI DSRC-Daten
überprüft. Anreicherung.
Optional: Die Anreichung der e-Akte mit den Vollständigkeit und
zugehörigen DSRC-Daten prüfen. inhaltliche Richtigkeit der
e-Akte in SC-OWI für
Fahrzeugkontrollfälle
prüfen.
KonMa_Mobile_Kontrolle Fahrzeuggeräte von neuen EETS-Providern Mit der KonMa wird eine
durchlaufen eine Gebrauchstauglichkeits Mobile Kontrolle gemäß
prüfung (GTP). Im Rahmen der Kompatibili den Testparametern
tätstests wird die Umsetzung der funktionalen erfolgreich durchgeführt.
Anforderungen an die EETS-Fahrzeuggeräte Die entsprechenden
in einem E2E-Szenario überprüft. DSRC-Daten des
Aufgrund einer Erweiterung der DSRC- Kontrollfalls werden
Schnittstelle muss die KonMa mit den DSRC- vollständig und korrekt
Formaten Gebietsvorgaben 2.1/2.2 und Ge angezeigt (gemäß SST-
bietsvorgaben 3.0/3.1 umgehen können. Spezifikation 301 Version
In diesem Testfall wird die Auslesung eines 3.0/3.1).
EETS-FzGs im Test-LKW mit einer KonMa im Die Fallgruppe wird durch
Modus mobile Kontrolle durchgeführt. die KonMa korrekt
Durchführung einer Mobile-Kontrolle angezeigt.
Die entsprechenden Daten des Kontrollfalls bei
einer DSRC-/OBE-Auslesung werden voll
ständig und korrekt angezeigt.
Name/ID Beschreibung Ziel
KonMa_Standkontrolle_ Fahrzeuggeräte von neuen EETS-Providern Mit der KonMa wird eine
Start_KB durchlaufen eine Gebrauchstauglichkeits Standkontrolle gemäß den
prüfung (GTP). Im Rahmen der Kompatibili genannten
tätstests wird die Umsetzung der funktionalen Testparametern im
Anforderungen an die EETS-Fahrzeuggeräte Szenario erfolgreich
in einem E2E-Szenario überprüft. gestartet.
Aufgrund einer Erweiterung der DSRC- Die entsprechenden
Schnittstelle muss die KonMa mit den DSRC- Daten des Kontrollfalls
Formaten Gebietsvorgaben 2.1/2.2 und Ge werden vollständig und
bietsvorgaben 3.0/3.1 umgehen können. korrekt angezeigt (gemäß
SST-Spezifikation 301
In diesem Testfall wird die Auslesung eines Version 3.0/3.1).
EETS-FzGs im Test-LKW mit einer KonMa im
Modus Standkontrolle mit dem Handheld Es wird die
durchgeführt. Das Test-FzG ist so eingestellt, Kontrollberichterstellung
dass das Fahrzeug damit im Gebiet BFstrMG durchgeführt.
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 Standkon
trolle zum Erstellen eines Kontrollberichts.
Auslesung der DSRC-Daten mit Handheld
Abschluss des Kontrollberichts.
KonZ_2.0_DezKst_SVF Fahrzeuggeräte von neuen EETS-Providern Überprüfung der korrekten
durchlaufen eine Weiterleitung des
Gebrauchstauglichkeitsprüfung (GTP). Verdachtsfalls von der
Im Rahmen der Kompatibilitätstests wird die Kontrollstelle an die
Umsetzung der funktionalen Anforderung an KonZ_2.0.
die EETS-Fahrzeuggeräte überprüft. Überprüfung aller
Die Test-Kontrollstelle erstellt einen relevanten DSRC-
Verdachtsfall und sendet diesen mit den Parameter in der
Beweismitteln an die Test-KonZ_2.0. Kontrollzentrale (gemäß
SST-Spezifikation 301
In der WebGUI wird nach dem KFZ- Version 3.0/3.1).“
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.
p) Die Überschrift der Anlage 3 der Anlage 3 zur Prüfvereinbarung (Anlage 3 zum Dokument B – Prüfkonzept:
Prüfkatalog „MED-Kompatibilitätstests“ wird wie folgt geändert:
aa) Die Wörter „Verkehr und digitale Infrastruktur (BMVI)“ werden durch die Wörter „Digitales und Verkehr
(BMDV)“ ersetzt.
bb) Die Wörter „Güterverkehr (BAG)“ werden durch die Wörter „Logistik und Mobilität (BALM)“ ersetzt.
q) Die Überschrift der Anlage 4 der Anlage 3 zur Prüfvereinbarung (Anlage 4 zum Dokument B – Prüfkonzept:
Prüfkatalog „Probebetrieb“) wird wie folgt geändert:
aa) Die Wörter „Verkehr und digitale Infrastruktur (BMVI)“ werden durch die Wörter „Digitales und Verkehr
(BMDV)“ ersetzt.
bb) Die Wörter „Güterverkehr (BAG)“ werden durch die Wörter „Logistik und Mobilität (BALM)“ ersetzt.
r) In der Anlage 5 zur Prüfvereinbarung wird in den Abschnitten 1 und 3 das Wort „BAG“ jeweils durch das Wort
„BALM“ ersetzt.
s) Die Anlage 6 zur Prüfvereinbarung wird wie folgt geändert:
aa) In der Position „Mauterheber“ wird in der Spalte „Definition“ das Wort „BAG“ durch das Wort „BALM“
ersetzt.
bb) In der Position „Zulassungsvertrag“ wird die Spalte „Definition“ wie folgt geändert:
aaa) Die Wörter „Verkehr und digitale Infrastruktur (BMVI)“ werden durch die Wörter „Digitales und
Verkehr (BMDV)“ ersetzt.
bbb) Die Wörter „Güterverkehr (BAG)“ werden durch die Wörter „Logistik und Mobilität (BALM)“ ersetzt.
3. Die Anlage II der EEMD-Zulassungsverordnung (EETS-Zulassungsvertrag) wird wie folgt geändert:
a) Die Überschrift des EETS-Zulassungsvertrages wird wie folgt geändert:
aa) Die Wörter „Verkehr und digitale Infrastruktur (BMVI)“ werden durch die Wörter „Digitales und Verkehr
(BMDV)“ ersetzt.
bb) Die Wörter „Güterverkehr (BAG)“ werden durch die Wörter „Logistik und Mobilität (BALM)“ ersetzt.
b) § 3 Absatz 2 wird wie folgt gefasst:
„(2) Der Anbieter versichert, dass die nachfolgenden Angaben am Tag der Unterzeichnung dieses
Vertrages vollständig und richtig sind:
1. Der Anbieter ist nach den auf ihn anwendbaren gesetzlichen Bestimmungen ordnungsgemäß gegründet
worden und besteht wirksam.
2. Der Anbieter ist uneingeschränkt berechtigt, diesen Vertrag abzuschließen und durchzuführen und besitzt
alle hierzu erforderlichen Zustimmungen.
3. Der Abschluss und die Durchführung dieses Vertrages verletzen nicht die Satzung,
Gesellschafterbeschlüsse oder eine Geschäftsordnung des Anbieters.
4. Der Abschluss und die Durchführung dieses Vertrages verletzen nicht für den Anbieter verbindliche
Rechtsvorschriften oder gerichtliche oder behördliche Entscheidungen, Verfügungen oder sonstige
Regelungen.
5. Es sind keine Insolvenz-, Reorganisations- oder ähnliche Verfahren im In- oder Ausland über das
Vermögen des Anbieters beantragt oder eröffnet worden. Auch wurden keine Zwangsvollstreckungs-
oder ähnliche Maßnahmen in das Vermögen oder einzelne Vermögensgegenstände des Anbieters
beantragt oder eingeleitet. Es bestehen keine Umstände, denen zufolge die Eröffnung solcher Verfahren
gerechtfertigt wäre. Insbesondere ist der Anbieter nicht überschuldet oder zahlungsunfähig und es liegt
auch kein Fall drohender Zahlungsunfähigkeit oder Überschuldung vor. Der Anbieter hat weder seine
Zahlungen eingestellt noch Schuldenbereinigungsabkommen oder ähnliche Vereinbarungen mit
Gläubigern abgeschlossen oder angeboten.
6. Die in [Anlage 3] dargestellte Übersicht über die gesellschaftsrechtlichen Beteiligungsverhältnisse des
Anbieters („Beteiligungsstruktur“) ist richtig und vollständig.“
c) In § 6 Absatz 3 wird das Wort „Güterverkehr“ durch die Wörter „Logistik und Mobilität“ ersetzt.
d) § 7 Absatz 1 wird wie folgt gefasst:
„(1) Der Anbieter ist verpflichtet, für die im Rahmen dieses Vertrages ausgeführten Tätigkeiten auf eigene
Kosten eine Betriebshaftpflichtversicherung mit mindestens den folgenden Inhalten abzuschließen und
während der Laufzeit dieses Vertrages aufrecht zu erhalten:
1. Betriebsbeschreibung: „Mauterhebung als EETS-Anbieter auf den Straßen des EETS-Mautgebiets
BFStrMG inklusive aller betriebs- und branchenüblichen, betriebs- und branchennotwendigen und im
Betrieb der Versicherungsnehmerin bestehenden Zusatzrisiken“,
2. Deckung für gesetzliche Haftpflichtansprüche wegen Personen-, Sach- und daraus folgenden
Vermögensschäden mit einer Deckungssumme von mindestens 15 Millionen Euro (in Worten: fünfzehn
Millionen Euro) je Schadensfall. Der EETS-Anbieter muss sicherstellen, dass zu jeder Zeit ein
ausreichender Versicherungsschutz im Sinne des Satz 1 besteht; dies gilt auch nach Eintritt eines
Versicherungsfalles und der Inanspruchnahme der Versicherung.“
e) § 10 Absatz 5 wird wie folgt gefasst:
„(5) Soweit vom Anbieter für die Durchführung des EETS der vom nationalen Betreiber im Auftrag des
Mauterhebers betriebene Mauterhebungsdienst genutzt wird, gelten ergänzend folgende
Mitwirkungspflichten des Mauterhebers:
1. Der nationale Betreiber ermöglicht dem Anbieter die Anbindung an den Mauterhebungsdienst. Dies betrifft
insbesondere die Übermittlung von Fahrspuren an den nationalen Betreiber über Schnittstelle 005 sowie
die Übertragung der Informationen zu ermittelten mautpflichtigen Fahrten über die Schnittstelle 007R an
den Anbieter.
2. Der Mauterheber wird den Anbieter mindestens vier Wochen vor einer geplanten Nicht-Verfügbarkeit des
Mauterhebungsdienstes über diese informieren.
3. Der Mauterheber wird Reklamationen von Mautschuldnern, die ein Anbieter an den Mauterheber oder den
nationalen Betreiber weiterleitet, bearbeiten, prüfen und beantworten sowie nach Möglichkeit entscheiden.
Der Mauterheber bemüht sich, die Reklamationen unverzüglich, spätestens jedoch innerhalb von 14 Tagen
nach Eingang zu bearbeiten und nach Möglichkeit zu entscheiden oder dem Anbieter zu antworten.
4. Der Mauterheber wird den Anbieter im Falle von Fehlvergebührungen des Mauterhebungsdienstes, die
dazu führen oder geführt haben, dass für Mautfahrten unrichtige Mautbeträge ermittelt und an Anbieter
übermittelt wurden, unverzüglich über die Fehlvergebührung informieren und eine Liste übermitteln, aus
der sich für jede Mautfahrt der korrekte Mautbetrag ergibt.“
f) § 16 wird wie folgt geändert:
aa) In Absatz 1 Satz 1 wird nach den Wörtern „zugänglich gemacht werden“ das Komma gestrichen.
bb) Absatz 3 wird wie folgt gefasst:
„(3) Nicht als Dritte im Sinne dieses Paragraphen gelten auf Seiten des Anbieters solche Personen,
die
1. mit Aufgaben befasst sind, die im Zusammenhang mit diesem Vertrag oder der Durchführung des
EETS stehen und/oder bestimmungsgemäß mit der Erfüllung der nach diesem Vertrag gegenüber
dem Mauterheber geschuldeten Verpflichtungen beschäftigt sind,
2. gegenüber dem Anbieter zur Vertraulichkeit, insbesondere auch bezüglich der vertraulichen Daten,
verpflichtet sind und
3. die vertraulichen Daten zur Ausführung der ihnen zugewiesenen Aufgaben benötigen.
Die Weiterreichung an mit dem Anbieter im Konzernverbund stehende Unternehmen
(„Konzernunternehmen“) ist nur gestattet, sofern und soweit dies zur konzerninternen Prüfung
erforderlich ist und den beteiligten Konzernunternehmen vollumfänglich die nach diesem Abschnitt
bestehende Vertraulichkeitsverpflichtung auferlegt worden ist.“
cc) Absatz 8 wird wie folgt gefasst:
„(8) Nicht als Dritte im Sinne dieses Paragraphen gelten auf Seiten des Mauterhebers solche
Personen, die
1. mit Aufgaben befasst sind, die im Zusammenhang mit diesem Vertrag oder der Durchführung des
EETS in sonstiger Weise stehen und/oder bestimmungsgemäß mit der Erfüllung der nach diesem
Vertrag dem Mauterheber obliegenden Verpflichtungen beschäftigt sind,
2. gegenüber dem Mauterheber zur Vertraulichkeit, insbesondere auch bezüglich der vertraulichen
Daten, verpflichtet sind und
3. die vertraulichen Daten zur Ausführung der ihnen obliegenden Aufgaben benötigen.“
g) § 17 Absatz 1 wird wie folgt gefasst:
„(1) Der Anbieter muss beim Betrieb seines EETS-Teilsystems die folgenden Qualitätsparameter erfüllen:
1. Der Anbieter muss eine Erfassungsquote von mindestens 99,500 % erreichen. Mit der Erfassungsquote
wird die Qualität der korrekten Mauterkennung für Befahrungen des mautpflichtigen Straßennetzes,
bezogen auf den vom EETS-Anbieter zu verantwortenden Anteil der Mauterhebung, ermittelt.
2. Der Anbieter muss eine DSRC-Quote von mindestens 98,500 % erreichen. Die DSRC-Quote wird durch
die Messung der korrekten DSRC Kommunikation der EETS-Fahrzeuggeräte mit den
Kontrolleinrichtungen des Mauterhebers ermittelt, wobei alle abrechnungsrelevanten Daten
(Fahrzeugparameter und Vertragsparameter) korrekt und vollständig übermittelt werden müssen.
3. Der Anbieter muss eine Sperrlistenquote von mindestens 99,900 % erreichen. Die Sperrlistenquote
bestimmt sich aus der Messung der Anzahl der Fahrzeuge, deren Bordgeräte die Erhebungsbereitschaft
signalisieren (Zustand grün), jedoch auf der Sperrliste aufgeführt sind.
4. Der Anbieter muss eine Nutzerlistenquote von mindestens 99,900 % erreichen. Die Nutzerlistenquote wird
aus der Messung der Qualität der Erstellung und Übermittlung der Nutzerliste vom Anbieter an den
Mauterheber ermittelt.
5. Der Anbieter muss eine Quote für abschnittsbezogene Erhebungsdaten, die nicht vom
Mauterhebungsdienst des Mauterhebers erzeugt wurden, von mindestens 99,000 % erreichen. Die
Quote für abschnittsbezogene Erhebungsdaten wird durch die Messung der Korrektheit und
Rechtzeitigkeit der Übermittlung von abschnittsbezogenen Erhebungsdaten (ABED) vom Anbieter an
den Mauterheber bestimmt.
6. Der Anbieter, der den Mauterhebungsdienst nutzt, muss eine Quote für Fahrspuren von mindestens
99,000 % erreichen. Die Quote für Fahrspuren wird durch die Messung der Korrektheit und
Rechtzeitigkeit der Übermittlung von Fahrspuren über die Schnittstelle 005 vom Anbieter an den
Mauterhebungsdienst bestimmt.
Die Einzelheiten zur Messung und Bewertung der einzelnen Qualitätsparameter sind in den
Qualitätsparametern für EETS-Anbieter (Anlage 5) geregelt.“
h) § 19 wird wie folgt geändert:
aa) In Absatz 1 wird vor dem Wort „Mautausfallhaftung“ ein Leerzeichen gestrichen.
bb) Absatz 3 wird wie folgt gefasst:
„(3) Die Haftung des Anbieters für die geschuldete Maut eines Nutzers nach Absatz 1 endet erst,
nachdem der Anbieter
1. das Bordgerät dieses Nutzers gesperrt hat und
2. dieses Bordgerät auf der Liste gesperrter Bordgeräte („Sperrliste“) nach § 26 MautSysG eingetragen
und dem Mauterheber diese Liste übermittelt hat. Die maximale Zeit zwischen den Übermittlungen
zweier aufeinander folgender Listen darf 24 Stunden nicht überschreiten.
Die Haftung nach Absatz 1 entfällt nicht für weitere Bordgeräte, die der Anbieter dem Mauterheber in
seinen Nutzerlisten nach § 4j BFStrMG für diesen Nutzer gemeldet hat.“
i) In § 20 wird nach Absatz 1 folgender Absatz 1a eingefügt:
„(1a) Der Mauterheber kann die Auszahlung der Änderungspauschale für ein Änderungsvorhaben im Fall
der Überschreitung der Umsetzungsfrist des Änderungsvorhabens aussetzen bis das Änderungsvorhaben
umgesetzt ist. Liegen dem Mauterheber gesicherte Erkenntnisse vor, dass der Anbieter Änderungsvorhaben,
für die er eine Änderungspauschale nach Ziffer 2.3 der Anlage 9 dieses Vertrages erhält, nicht innerhalb der
vom Mauterheber festgesetzten Frist umsetzen wird, kann er bereits ab Vorliegen dieser Erkenntnisse die
Auszahlung der Änderungspauschale für dieses Änderungsvorhaben aussetzen. Nach erfolgter tatsächlicher
Umsetzung des Änderungsvorhabens wird die einbehaltene Änderungspauschale ausgezahlt und
gegebenenfalls mit der Vertragsstrafe gemäß § 27 Absatz 3b dieses Vertrages verrechnet.“
j) In § 22 wird in Absatz 4 Satz 1 das Wort „Güterverkehr“ durch die Wörter „Logistik und Mobilität“ ersetzt.
k) § 23 Absatz 1 wird wie folgt gefasst:
„(1) Der Mauterheber kann auch nach Vertragsabschluss vom Anbieter die erneute Durchführung des
Verfahrens zur Feststellung der Gebrauchstauglichkeit verlangen, wenn
1. der Anbieter Änderungen an seinem EETS-Teilsystem vornimmt, die Auswirkungen auf die
Gebrauchstauglichkeit haben können,
2. der Mauterheber Änderungen an seinem EETS-Teilsystem oder am EETS-Gebiet BFStrMG vornimmt, die
Auswirkungen auf die Gebrauchstauglichkeit haben können,
3. der nationale Betreiber des Mautsystems Änderungen am Mautsystem oder am Mauterhebungsdienst
vornimmt, die Auswirkungen auf die Gebrauchstauglichkeit haben können,
4. bei der Durchführung des EETS im EETS-Gebiet BFStrMG nachhaltige technische Probleme auftreten,
5. das Verfahren zur Feststellung der Gebrauchstauglichkeit wesentlich geändert wird oder
6. bei begründetem Verdacht des Mauterhebers auf Nichterfüllung der Vorgaben durch den Anbieter.“
l) § 24 Absatz 6 wird wie folgt gefasst:
„(6) Der Mauterheber haftet nicht für eine Einschränkung oder Schäden des Anbieters
1. aufgrund von Maßnahmen des Baus, Betriebs, der Reparatur oder der Unterhaltung von Straßen des
mautpflichtigen Straßennetzes,
2. aufgrund von Änderungen, Beschränkungen oder Einschränkungen des mautpflichtigen Streckennetzes,
3. aus der Bereitstellung und Durchführung der EETS-Mauterkennung für Anbieter durch einen dritten
Dienstleister. Davon ausgenommen ist die Erbringung des Mauterhebungsdienstes durch den nationalen
Betreiber im Auftrag des Mauterhebers.“
m) § 27 wird wie folgt geändert
aa) Absatz 1 wird wie folgt gefasst:
„(1) Der Anbieter verwirkt eine Vertragsstrafe jeweils in Höhe von 25 000 Euro, wenn er schuldhaft
1. entgegen § 4 Absatz 1 dieses Vertrages eine Anzeige gegenüber dem Mauterheber unterlassen hat,
2. einen Versicherungsnachweis gemäß § 7 dieses Vertrages nicht, nicht rechtzeitig oder nicht
vollständig vorlegt,
3. entgegen § 11 Absatz 3 dieses Vertrages den Mauterheber nicht oder nicht rechtzeitig informiert,
4. dem Mauterheber Informationen nach § 11 Absatz 4 nicht zur Verfügung stellt,
5. dem Mauterheber Änderungen nach § 11 Absatz 5 nicht anzeigt oder
6. die von ihm errichteten straßenseitigen Einrichtungen nicht oder nicht ordnungsgemäß nach § 29
Absatz 3 entsorgt.
Im Fall von Nummer 6 wird die Vertragsstrafe für jeden Tag verwirkt, an dem der Anbieter seine
vertraglichen Pflichten nicht erfüllt.“
bb) Absatz 2 wird wie folgt gefasst:
„(2) Der Anbieter verwirkt eine Vertragsstrafe jeweils in Höhe von 75 000 Euro, wenn er schuldhaft
1. gegen Bestimmungen zum Datenschutz gemäß § 13 verstößt,
2. gegen Bestimmungen zur Datensicherheit gemäß § 14 verstößt,
3. gegen die Bestimmungen zur Aufbewahrung von vertraulichen Unterlagen gemäß § 15 dieses
Vertrages verstößt oder
4. gegen die Bestimmungen zur Geheimhaltung und Vertraulichkeit gemäß § 16 dieses Vertrages
verstößt.“
cc) Absatz 3 wird wie folgt gefasst:
„(3) Der Anbieter verwirkt eine Vertragsstrafe jeweils in Höhe von 15 % der monatlichen Vergütung
gemäß § 20, mindestens aber in Höhe von 100 000 Euro, wenn er schuldhaft
1. entgegen § 9 dieses Vertrages eine Verrechnung der an den Mauterheber auszukehrenden
Mauteinnahmen vornimmt oder die dem Mauterheber zustehenden Mauteinnahmen zum
Gegenstand einer Verpfändung oder Besicherung macht oder auf sonstige Weise mit Rechten
Dritter belastet,
2. entgegen § 11 Absatz 1 dieses Vertrages dem Mauterheber erhebliche Änderungen an seinem
EETS-Teilsystem nicht anzeigt,
3. entgegen § 11 Absatz 2 dieses Vertrages dem Mauterheber die von diesem angeforderten Daten nicht
oder nicht rechtzeitig übermittelt,
4. entgegen § 12 dieses Vertrages einer in § 12 genannten Stelle den uneingeschränkten Zutritt oder die
Einsicht in Daten verweigert,
5. entgegen § 12 Absatz 4 Verträge mit Dritten abschließt, ohne die Rechte nach § 12 zugunsten des
Mauterhebers zu vereinbaren,
6. entgegen § 8 dieses Vertrages eine Zustimmung des Mauterhebers nicht oder nicht rechtzeitig einholt,
7. entgegen § 29 Absatz 1 nach Beendigung dieses Vertrages die Maut nicht vollständig auskehrt oder
dem Mauterheber die für die Überprüfung nach § 29 Absatz 2 benötigten Daten nicht zur Verfügung
stellt oder
8. entgegen § 30 dieses Vertrages Bordgeräte nicht oder nicht rechtzeitig sperrt.
In den Fällen der Nummern 7 und 8 wird die Vertragsstrafe für jeden Tag verwirkt, an dem der Anbieter
seine vertraglichen Pflichten nicht erfüllt.“
dd) Nach Absatz 3a wird folgender Absatz 3b eingefügt:
„(3b) Der Anbieter verwirkt eine Vertragsstrafe in Höhe von 1 000 Euro, wenn er eine technische oder
prozessuale Änderung, für die er eine Änderungspauschale nach Ziffer 2.3 der Anlage 9 dieses Vertrages
erhält, nicht innerhalb der vom Mauterheber festgesetzten Frist umsetzt. Nach Ablauf der vom
Mauterheber gesetzten Frist wird die Vertragsstrafe für jeden Tag verwirkt, an dem der Anbieter seine
vertraglichen Pflichten nicht erfüllt.“
ee) Absatz 5 wird wie folgt gefasst:
„(5) Die Summe der Vertragsstrafen nach den Absätzen 1 bis 5 darf einen Betrag in Höhe von 10 %
der jährlichen Vergütung des Anbieters für das EETS-Gebiet BFStrMG pro Jahr – mindestens aber in
Höhe von 50 000 Euro – nicht überschreiten. Von der Regelung in Satz 1 sind die folgenden
Vertragsstrafen ausgenommen:
1. die Vertragsstrafe, die der Anbieter beim Unterschreiten des Qualitätsparameters „Erfassungsquote
EQ_nonMED“ gemäß Ziffer 3.1.2, bzw. „Erfassungsquote_MED“ gemäß Ziffer 3.2.2, der Anlage 5
dieses Vertrages verwirkt,
2. die Vertragsstrafe nach § 27 Absatz 3b. Die Summe der Vertragsstrafe nach § 27 Absatz 3b darf einen
Betrag in Höhe des Gesamtanspruchs auf Änderungspauschale für ein Änderungsvorhaben für die
jeweilige Vergütungsperiode gemäß Ziffer 2.3 der Anlage 9 dieses Vertrages nicht überschreiten.“
n) § 28 Absatz 3 wird wie folgt gefasst:
„(3) Der Mauterheber ist zur Kündigung dieses Vertrages ohne Einhaltung einer Frist berechtigt, wenn ein
wichtiger Grund vorliegt. Ein wichtiger Grund liegt insbesondere vor, wenn dem Mauterheber unter
Berücksichtigung aller Umstände des Einzelfalls und unter Abwägung der beiderseitigen Interessen die
Fortsetzung des Vertragsverhältnisses bis zur vereinbarten Beendigung oder bis zum Ablauf einer
Kündigungsfrist nicht zugemutet werden kann, insbesondere
1. weil die Registrierung des Anbieters gemäß § 4 MautSysG oder bei der zuständigen Behörde eines
anderen Mitgliedstaates der Europäischen Union oder eines anderen Vertragsstaates des Abkommens
über den Europäischen Wirtschaftsraum weggefallen ist oder die sachlichen Voraussetzungen hierfür
vorliegen,
2. die Prüfung der Zulassungsvoraussetzungen nach § 10 Absatz 2 Satz 1 MautSysG ergeben hat, dass
diese nicht vorliegen und nicht geschaffen werden können,
3. die vom Anbieter im Rahmen von § 3 dieses Vertrages gemachten Angaben unkorrekt oder unvollständig
gewesen sind,
4. durch den Wechsel des wirtschaftlich Berechtigten beim Anbieter wesentliche Interessen der
Bundesrepublik Deutschland beeinträchtigt werden,
5. der Anbieter in nicht unerheblicher Weise gegen seine Verpflichtungen nach § 5 dieses Vertrages
verstößt,
6. der Anbieter seine Verpflichtungen aus § 6 dieses Vertrages nicht erfüllt oder ein als Bankgarantie oder
gleichwertiges Finanzinstrument gestelltes Instrument unwirksam oder undurchsetzbar ist oder wird oder
ohne Ersatz endet,
7. der Anbieter nicht nur vorübergehend den Versicherungsschutz nach § 7 dieses Vertrages nicht oder in
nicht ausreichender Weise besitzt oder nicht nachweist,
8. der Mauterheber seine nach § 8 dieses Vertrages erforderliche Zustimmung endgültig verweigert hat,
9. der Anbieter in nicht unerheblicher Weise gegen seine Verpflichtungen aus § 9 dieses Vertrages verstößt,
10. der Anbieter wiederholt und in nicht unerheblicher Weise gegen seine Verpflichtungen aus § 11 dieses
Vertrages verstößt,
11. der Anbieter wiederholt und in nicht unerheblicher Weise gegen seine Verpflichtungen aus § 12 dieses
Vertrages verstößt,
12. der Anbieter in nicht unerheblicher Weise gegen seine Verpflichtungen zur Gewährleistung des
Datenschutzes gemäß § 13 dieses Vertrages verstößt,
13. der Anbieter in nicht unerheblicher Weise gegen seine Verpflichtungen zur Gewährleistung der
Datensicherheit gemäß § 14 dieses Vertrages verstößt,
14. der Anbieter wiederholt und in nicht unerheblicher Weise gegen seine Verpflichtungen aus § 15 dieses
Vertrages verstößt,
15. der Anbieter wiederholt und in nicht unerheblicher Weise gegen seine Verpflichtungen aus § 16 dieses
Vertrages verstößt; ein wichtiger Grund liegt auch dann vor, wenn es sich um einen einmaligen,
besonders schwerwiegenden Verstoß gegen die Verpflichtung zur Geheimhaltung handelt,
16. der Anbieter eine EETS-Erfassungsquote von 95,000 % innerhalb eines Kalenderjahres in mehr als zwei
Monaten oder in zwei aufeinanderfolgenden Monaten unterschreitet,
17. der Anbieter eine DSRC-Quote von 96,000 % innerhalb eines Kalenderjahres in mehr als zwei Monaten
oder in zwei aufeinanderfolgenden Monaten unterschreitet,
18. der Anbieter Nutzerlisten gemäß § 4j BFStrMG wiederholt nicht, nicht rechtzeitig oder nicht vollständig
überträgt,
19. der Anbieter wiederholt und in nicht unerheblichem Umfang entgegen § 19 Bordgeräte auf die Sperrliste
setzt, bevor er diese gesperrt hat,
20. der Anbieter sich weigert, das Verfahren zur Feststellung der Gebrauchstauglichkeit gemäß § 23 dieses
Vertrages erneut durchzuführen, oder das Verfahren nicht zu einer Feststellung der
Gebrauchstauglichkeit führt,
21. der Anbieter entgegen § 12 Absatz 1 MautSysG seine Verpflichtung innerhalb von 36 Monaten nach
seiner Registrierung Zulassungsverträge über alle mautpflichtigen Streckennetze mit elektronischen
Mautsystemen im Anwendungsbereich der Richtlinie (EU) 2019/520 in mindestens vier Mitgliedstaaten
der Europäischen Union abzuschließen, nicht erfüllt oder seine Verpflichtung zur Wiederherstellung der
Abdeckung der mautpflichtigen Streckennetze nicht erfüllt,
22. aufgrund von Rechtsänderungen auf nationaler oder europäischer Ebene die Grundlagen der
Mauterhebung im EETS-Gebiet BFStrMG oder die Grundlagen für die Indienststellung des EETS
wegfallen oder
23. der Anbieter wiederholt und in nicht unerheblicher Weise gegen die Vorgaben für das EETS-Gebiet
BFStrMG verstößt; ein wichtiger Grund liegt auch dann vor, wenn es sich um einen einmaligen,
besonders schwerwiegenden Verstoß gegen die Vorgaben für das EETS-Gebiet BFStrMG handelt.“
o) § 35 wird wie folgt geändert:
aa) Absatz 1 wird wie folgt gefasst:
„(1) Sämtliche Mitteilungen gemäß oder im Zusammenhang mit diesem Vertrag sind in Textform und in
deutscher Sprache abzufassen und an die mit dem Mauterheber abgestimmten E-Mail-Adressen zu
richten. Satz 1 gilt nicht für förmliche Zustellungen, diese sind schriftlich und in deutscher Sprache
abzufassen.“
bb) Absatz 2 wird wie folgt gefasst:
„(2) Förmliche Zustellungen an den Mauterheber in Zusammenhang mit diesem Vertrag sind an die
folgende Anschrift zu richten:
Bundesamt für Logistik und Mobilität (BALM), Werderstraße 34, 50672 Köln (Empfangsberechtigter)“.
cc) Absatz 3 wird wie folgt gefasst:
„(3) Mitteilungen an den Anbieter im Zusammenhang mit diesem Vertrag sind an die mit dem Anbieter
abgestimmten E-Mail-Adressen zu richten.“
p) In § 37 wird im letzten Satz nach den Wörtern „erkannt hätten” ein Punkt gestrichen.
q) Die Anlage 1 zum EETS-Zulassungsvertrag wird wie folgt geändert:
aa) Die Wörter „Verkehr und digitale Infrastruktur (BMVI)“ werden durch die Wörter „Digitales und Verkehr
(BMDV)“ ersetzt.
bb) Die Wörter „Güterverkehr (BAG)“ wird durch die Wörter „Logistik und Mobilität (BALM)“ ersetzt.
cc) In Abschnitt 2 wird nach der Angabe „SST 001“ das Wort „Blocklist“ durch das Wort „Sperrliste“ und die
Wörter „EETS-Blocklist“ durch die Wörter „EETS-Sperrliste“ ersetzt.
r) Die Anlage 5 zum EETS-Zulassungsvertrag wird wie folgt geändert:
aa) In Abschnitt 3.1.2 wird in Absatz 7 Satz 2 nach der Angabe „§ 28 Absatz 3 Satz 2“ die Angabe
„Buchstabe p“ durch die Angabe „Nummer 16“ ersetzt.
bb) In Abschnitt 3.2.2 wird in Absatz 8 Satz 2 nach der Angabe „§ 28 Absatz 3 Satz 2“ die Angabe
„Buchstabe p“ durch die Angabe „Nummer 16“ ersetzt.
cc) Abschnitt 3.3.1 wird wie folgt geändert:
aaa) In Absatz 7 Satz 2 wird nach der Angabe „§ 28 Absatz 3 Satz 2“ die Angabe „Buchstabe q“ durch die
Angabe „Nummer 17“ ersetzt.
bbb) Im letzten Absatz wird nach der Angabe „§ 28 Absatz 3 Satz 2“ die Angabe „Buchstabe q“ durch die
Angabe „Nummer 17“ ersetzt.
dd) In Abschnitt 3.5.1 wird im letzten Absatz nach dem Wort „Nummer“ die Angabe „3.4.1“ durch die Angabe
„3.5.1“ ersetzt.
s) Die Anlage 6 zum EETS-Zulassungsvertrag wird wie folgt geändert:
aa) In Abschnitt 1. (Vorbemerkung) wird das Wort „BAG“ durch das Wort „BALM“ ersetzt.
bb) In Abschnitt 3. (Fälligkeit) wird das Wort „BAG“ jeweils durch das Wort „BALM“ ersetzt.
t) In Anlage 7 zum EETS-Zulassungsvertrag wird bei der Position „Mauterheber“ in der Spalte „Definition“ das
Wort „BAG“ durch das Wort „BALM“ ersetzt.
Artikel 4
Inkrafttreten
(1) Diese Verordnung tritt vorbehaltlich des Absatzes 2 am Tag nach der Verkündung in Kraft.
(2) Artikel 2 tritt am 1. Dezember 2023 in Kraft.
Köln, den 27. November 2023
Der Präsident
des Bundesamtes für Logistik und Mobilität
Christian Hoffmann
Herausgeber: Bundesministerium der Justiz
Herkunft dieses Textes
Quelle: Bundesgesetzblatt, BGBl. 2023 I Nr. 329. Gesetze, Verordnungen und amtliche Bekanntmachungen sind amtliche Werke (§ 5 Abs. 1 UrhG) und genießen keinen Urheberrechtsschutz. Der Text ist unverändert wiedergegeben (§ 62 UrhG); Herkunft und Prüfwerte stehen hier (§ 63 UrhG).
Ableitung: pdf-layout ·
Prüfwert des Textes 8c42f0727278e1ac….