Anlage 3 zur Prüfvereinbarung

Digitale Gesetze

Anlage 3 zur Prüfvereinbarung - Digitale Gesetze

Version	Datum	Bearbeiter	Bearbeitung/Änderung
0.01	02.11.2010	BAG, TÜV	Erstellung Gliederungsentwurf
0.91	17.07.2012	RTDE, BAG	Fertigstellung
0.93	13.05.2013	RTDE, BAG	Komplettüberarbeitung zur Anpassung an veränderte Rahmenbedingungen
0.94	13.11.2014	BAG	Anpassung an aktuelle Version der Gebietsvorgaben
1.00	04.10.2017	BAG, RT	Grundlegende Überarbeitung: Anpassung an aktuelle Schnittstellenversionen und Umstellung der Prüfumgebung beim BAG.
1.1	05.10.2018	BAG, RT	Ergänzung um Kompatibilitätstests
1.2	26.02.2019	BAG, RT	Anpassung in 6.4
	09.03.2020	BAG	Grundlegende Überarbeitung: Redaktionelle Änderungen, Mauterhebungsdienst
	24.03.2020	BAG	Einarbeitung Zuarbeit TC zu SST005
1.9	17.09.2020	BAG, RT	Grundlegende Überarbeitung: Redaktionelle Änderungen, Anpassungen an Mauterhebungsdienst
1.91	30.10.2020	RT, BAG	Einarbeitung Reviewkommentare TC
1.95	04.12.2020	RT, BAG	Überarbeitung und QS nach Review Referat 42
1.95	04.12.2020	RT, BAG	Überarbeitung und QS nach Review Referat 42
1.96	07.05.2021	RT, BAG	Überarbeitung: Aufrechterhaltung Gebrauchstauglichkeit, Vertriebsmodell, Vorgaben an produktive Bordgeräte in Pilotphase
1.97	15.06.2021	RT, BAG	Ergänzung Bordgerätestatus Reporting während MED-Kompatibilitätstests
2.0	07.09.2021	RT, BAG	Redaktionelle Überarbeitung und Erstellung Version zur Veröffentlichung
2.1	12.01.2022	RT, BAG	Konkretisierung in Kapitel 5.2 (Zwischenversion)
2.2	01.03.2024	RT, BALM	Überarbeitung entsprechend den Änderungen im BFStrMG; Ergänzung Vorgaben Pilotbetrieb für Bordgeräte mit Smartphone-Bedienung in Kapitel 6.2

Die vom EETS-Anbieter bereitzustellende Dokumentation muss inhaltlich Folgendes umfassen:

1.: Ein Sicherheitskonzept, aus dem Informationen über das Sicherheitsmanagement, erkannte Bedrohungen der Prozesse und IT-Systeme des EETS-Anbieters und entsprechende Sicherheitsmaßnahmen hervorgehen.
2.: Aussagekräftige Beschreibungen der mautrelevanten Geschäftsprozesse des EETS-Anbieters.
3.: Beschreibungen der Betriebsprozesse und der betrieblichen Organisation
Darin sollten insbesondere die Ausgestaltung der IT-Serviceprozesse und die Organisationseinheiten des EETS-Anbieters, die für den Betrieb seines Teilsystems verantwortlich sind, einschließlich ihrer Aufgaben und Funktionen sowie ihrer Einbindung in die Gesamtorganisation, beschrieben werden.
4.: Ein Datenschutzkonzept, in dem der EETS-Anbieter ausführlich auf den Schutz von personenbezogenen und personenbeziehbaren Daten in seinem Teilsystem eingeht und die Umsetzung der für ihn geltenden Vorgaben zum Datenschutz beschreibt.
5.: Eine High-Level Systemdokumentation, die einen funktionalen Überblick über die vom EETS-Anbieter eingesetzten mautrelevanten IT-Komponenten, deren Schnittstellen und Hauptdatenflüsse gibt.
6.: Ein Risikomanagementplan in dem der EETS-Anbieter beschreibt, welche technischen, prozessualen, organisatorischen und finanziellen Risiken für seinen Geschäftsbetrieb bestehen und welche Maßnahmen zur Minimierung der Eintrittswahrscheinlichkeit bzw. Maßnahmen zur Reduktion der Risikoauswirkungen vorgesehen werden.
7.: Ein Systemweiterentwicklungskonzept, welches das angewandte Vorgehensmodell des EETS-Anbieters bei der Umsetzung von Veränderungen und Erweiterungen seines technischen Systems beschreibt und dabei insbesondere auf die Bewertung eventueller Auswirkungen auf die Schnittstellen zum Mauterheber und dessen Einbindung eingeht.
Aus dem Konzept soll ersichtlich sein, welche Phasen (z.B. Spezifikation, Test, Integration, Abnahme) bei einer Weiterentwicklung des Systems durchlaufen werden und in welchem zeitlichen Rahmen und welcher Regelmäßigkeit (z.B. feste Releasetermine) Weiterentwicklungsvorhaben umgesetzt werden.
8.: Ein Vertriebsmodell des EETS-Anbieters mit einer Gesamtübersicht der Rollen und Partner (Mauterheber, EETS-Anbieter, EETS-Nutzer, gegebenenfalls technische Dienstleister, Vertriebspartner, Reseller des EETS-Anbieters), die an der Leistungserbringung beteiligt sind. Das Vertriebsmodell muss die Vertragsverhältnisse sowie die Funktionen und Aufgaben der einzelnen Beteiligten beschreiben und die Finanz- bzw. Zahlungsflüsse darstellen.

Vorgabe		Schwerpunkte der Prüfung
Nr.	Kurzbeschreibung	Schwerpunkte der Prüfung
wirtschaftliche Vorgaben
1	Sicherheit - Bankgarantie oder gleichwertiges Finanzinstrument	Beschreibung des Prozesses, mit dem der EETS-Anbieter die aktuelle Höhe der Bankgarantie oder des gleichwertigen Finanzinstruments ermittelt und gegebenenfalls eine Anpassung auslöst. Prüfung, ob die Ansprüche des Mauterhebers über die Bankgarantie oder das gleichwertige Finanzinstrument abgedeckt sind. 1. Vorlage Bankgarantie/Nachweis über gleichwertiges Finanzinstrument 2. Schriftlicher Hinweis zur Kenntnisnahme und Akzeptanz der Vorgabe
2	Gebühren	Schriftlicher Hinweis zur Kenntnisnahme und Akzeptanz der Vorgabe
3	Mautauskehr	Schriftlicher Hinweis zur Kenntnisnahme und Akzeptanz der Vorgabe
4	Verlust von Mauteinnahmen	Schriftlicher Hinweis zur Kenntnisnahme und Akzeptanz der Vorgabe. Beschreibung der Maßnahmen zur Minimierung der Eintrittswahrscheinlichkeit bzw. Maßnahmen zur Reduktion der Auswirkungen bezüglich des Risikos der Inanspruchnahme der Zahlungshaftung. (Vorlage Risikomanagementplan)
5	gesamtschuldnerische Haftung	Schriftlicher Hinweis zur Kenntnisnahme und Akzeptanz der Vorgabe
6	Verzug	Schriftlicher Hinweis zur Kenntnisnahme und Akzeptanz der Vorgabe. Beschreibung des Geschäftsprozesses der Auskehr der Mauteinnahmen an den Mauterheber, insbesondere hinsichtlich der korrekten Berücksichtigung von Zahlungsfristen und Berechnung von Verzugszinsen bei der Erstellung der Tagesberichte.
7	Beachtung des Haushaltsrechts	Schriftlicher Hinweis zur Kenntnisnahme und Akzeptanz der Vorgabe.
8	Berechnung der Mauteinnahmen	Schriftlicher Hinweis zur Kenntnisnahme und Akzeptanz der Vorgabe
9	Mauterhebung und Mautauskehr	Beschreibung des Geschäftsprozesses der Auskehr der Mauteinnahmen an den Mauterheber, insbesondere hinsichtlich der korrekten Berücksichtigung der Wertstellungsfrist und der fristgerechten Auslösung von Überweisungen auf das Verrechnungskonto des Mauterhebers. Beschreibung der Umsetzung der Vorgaben des Mauterhebers in Bezug auf die Nachforderung/Verrechnung von Mauteinnahmen gemäß des Prozessdokuments „Informationen zu Nachforderung, Verrechnung und manueller Korrektur“ Beschreibung des Vertriebsmodells aus dem hervorgeht, dass der EETS-Anbieter die Vertragsbeziehung zum EETS-Nutzer hält und die Mautauskehr vom EETS-Anbieter an den Mauterheber direkt erfolgt. (Vorlage Vertriebsmodell) Beschreibung der Maßnahmen zur Minimierung der Eintrittswahrscheinlichkeit bzw. Maßnahmen zur Reduktion der Auswirkungen (insbesondere Sicherstellung der vollständigen Auskehr der Mautbeträge an den Mauterheber) bezüglich des Insolvenzrisikos des EETS-Anbieters. (Vorlage Risikomanagementplan)
10	Mautabrechnung	Beschreibung der Geschäftsprozesse der Abrechnung gegenüber dem Nutzer und der Auskehr der Mautbeträge an den Mauterheber. Hier sind insbesondere die Maßnahmen zur Sicherstellung der Vollständigkeit und Korrektheit der Summen, sowie die im Falle von Abweichungen geplanten Maßnahmen darzustellen. Es wird geprüft, ob die Maßnahmen zur Erkennung und Behebung von Fehlern ausreichend sind bzw. ob Rückzahlungen/ Gutschriften an EETS-Nutzer korrekt umgesetzt werden. Bei der Beschreibung sind die Vorgaben des Mauterhebers in Bezug auf die Entgegennahme und Bearbeitung von Reklamationen und Erstattungsanträgen gemäß des Prozessdokuments „Information für EETS-Anbieter – MED Reklamationsprozess“ sowie die Umsetzung von Vergutschriftungen gemäß des Prozessdokuments „Information für EETS-Anbieter – MED Vergutschriftungsprozess“ zu berücksichtigen.
11	Bericht über Mauteinnahmen	Beschreibung des Geschäftsprozesses der Auskehr der Mauteinnahmen an den Mauterheber insbesondere hinsichtlich der Erstellung der Tagesberichte und Gewährleistung der termingerechten Übermittlung. Erläuterung der geplanten Umsetzung der Schnittstelle „Tagesbericht“ im System des EETS-Anbieters (siehe Spezifikation der SST 008 –„Tagesbericht“).
12	Überwachung des EETS-Anbieters	Beschreibung der technischen Prozesse und Geschäftsprozesse zur Überwachung der Qualität der Systeme des EETS-Anbieters. Beschreibung der Prozesse der Datenübermittlung, Datenlöschung und Datenarchivierung in Verbindung mit den geltenden Löschvorgaben und -fristen. (Vorlage Datenschutzkonzept)
13	manuelle Korrektur von Daten	Beschreibung des Geschäftsprozesses der Fahrspurerhebung und Abrechnung der Mautbeträge gegenüber dem Nutzer. Hier sind insbesondere eventuell vorhandene Prozessschritte darzustellen, im Rahmen derer Fahrspurdaten, Mautbuchungsnachweise oder sonstige Abrechnungsdaten manuell bearbeitet werden. Im Prozess sollte berücksichtigt sein, dass der Auslöser einer solchen Korrektur auch der Mauterheber sein kann und dass im Prozess dahingehend unterschieden werden muss, ob die sich aus den Daten ergebenden Mautbeträge bereits an den Mauterheber ausgekehrt wurden oder nicht. Bei der Beschreibung sind die Vorgaben des Mauterhebers gemäß des Prozessdokuments „Information für EETS-Anbieter – MED Vergutschriftungsprozess“ zu berücksichtigen. Darstellung der Maßnahmen und Methoden, die zur Verhinderung von Missbrauch vorgesehen sind (z.B. Logging, lückenlose Dokumentation). (Vorlage Sicherheitskonzept)
technisch-organisatorische Vorgaben
14	Kompatibilität der EETS-Teilsysteme	Funktionale Beschreibung der vom EETS-Anbieter eingesetzten mautrelevanten IT-Komponenten sowie deren Schnittstellen und Hauptdatenflüsse zum/vom Mauterheber (High-Level-Systemdokumentation). Beschreibung aller Geschäftsprozesse und Erläuterung der geplanten Umsetzung der Schnittstellen „Bordgerät – straßenseitiges Kontrollequipment“, „Sperrliste“, „Nutzerlisten“, „Fahrspurdaten“, „Mautbuchungsnachweise“, „Tagesbericht“, Report „Information zu Auffälligkeiten bei Bordgeräten“ sowie der „übergreifenden Aspekte Anbindung MED“ und der „übergreifenden Aspekte Anbindung BALM“ im System des EETS-Anbieters (siehe Schnittstellenspezifikationen). IT-Serviceprozesse des EETS-Anbieters, die eine Verbindung zum Mauterheber haben, insbesondere in Hinblick auf die Art und Weise der Interaktion zwischen EETS-Anbieter und Mauterheber.
15	Beeinflussung des nationalen Mautsystems	Beschreibung der Berührungspunkte zwischen dem System des EETS-Anbieters und dem Mautsystem des nationalen Betreibers (Kontrolle, Mauterhebungsdienst), und mit Hilfe welcher Maßnahmen eine negative Beeinflussung ausgeschlossen wird.
16	Funktionen des EETS-Teilsystems	Funktionale Beschreibung der vom EETS-Anbieter eingesetzten mautrelevanten IT-Komponenten (High-Level-Systemdokumentation). Beschreibung der Geschäftsprozesse in den Bereichen Fahrspurerhebung und Mautabrechnung sowie Prozesse zur Unterstützung der Kontrolle und Überwachung des Mauterhebers. Beschreibung der IT-Serviceprozesse des EETS-Anbieters. Erläuterung der geplanten Umsetzung der Schnittstellen „Bordgerät – straßenseitiges Kontrollequipment“, „Sperrliste“, „Nutzerlisten“, „Fahrspurdaten“, „Mautbuchungsnachweise“, „Tagesbericht“, Report „Information zu Auffälligkeiten bei Bordgeräten“ sowie der „übergreifenden Aspekte Anbindung MED“ und der „übergreifenden Aspekte Anbindung BALM“ im System des EETS-Anbieters (siehe Schnittstellenspezifikationen).
17	Zeitbasis	Erläuterung der Verwendung der Zeitbasis in den Komponenten des EETS-Anbieter-Teilsystems und Beschreibung des Prozesses zur Zeitsynchronisation.
18	Schnittstellen	Funktionale Beschreibung der vom EETS-Anbieter geplanten Schnittstellen und Hauptdatenflüsse zum/vom Mauterheber (High-Level-Systemdokumentation). Beschreibung aller Geschäftsprozesse des EETS-Anbieters, die eine Verbindung zum Mauterheber haben, insbesondere in Hinblick auf die Art und Weise der Interaktion zwischen EETS-Anbieter und Mauterheber. Erläuterung der geplanten Umsetzung der Schnittstellen, insbesondere „Bordgerät – straßenseitiges Kontrollequipment“, „Sperrliste“, „Nutzerlisten“, „Fahrspurdaten“, „Mautbuchungsnachweise“, „Tagesbericht“, Report „Information zu Auffälligkeiten bei Bordgeräten“ sowie der „übergreifenden Aspekte Anbindung MED“ und der „übergreifenden Aspekte Anbindung BALM“ im System des EETS-Anbieters (siehe Schnittstellenspezifikationen).
19	Sperrliste	Beschreibung des Geschäftsprozesses der Sperrung von Bordgeräten. Hier sind insbesondere auch technische Sonderfälle darzustellen, wie z. B. technische Defekte des Bordgeräts, gestörte Kommunikation über Mobilfunk.
20	Nutzerliste	Beschreibung des Geschäftsprozesses, in dem Anfragen des Mauterhebers bezüglich Adress- und Fahrzeugdaten zu Ahndungszwecken behandelt werden, insbesondere hinsichtlich der Verfügbarkeit und Übermittlung der in Dokument 4.3.3 der Gebietsvorgaben, Schnittstellen 002b und 002c geforderten Informationen. Erläuterung der geplanten Umsetzung der Schnittstellen SST 002b/c „Adress- und Fahrzeugdaten und weitere Fahrzeuge eines EETS-Nutzers“ im System des EETS-Anbieters (siehe Dokument 4.3.3 − Spezifikation der Schnittstelle SST 002 – Nutzerlisten). Prüfung, wie entsprechende Meldungen über SST009 zu fehlenden Nutzerlisteneinträgen vom EETS-Anbieter berücksichtigt werden
21	Trustobjects	Beschreibung des Geschäftsprozesses des Austauschs der sicherheitsrelevanten Objekte zwischen EETS-Anbieter und Mauterheber. Erläuterung der geplanten Umsetzung der Schnittstelle 004 „Trustobjects“ im System des EETS-Anbieters (siehe Dokument 4.3.11 – Spezifikation der Schnittstelle SST 004 – Trustobjects). Prüfung, wie der Austausch sicherheitsrelevanter Daten für die Anbindung an den Mauterhebungsdienst mit dem nationalen Mautbetreiber vorgesehen wird.
22	Positionsdaten und Merkmale der Fahrzeugklassifizierung	Beschreibung des Geschäftsprozesses der Übermittlung der Positionsdaten und Merkmalen der Fahrzeugklassifizierung an den Mauterheber. Erläuterung der geplanten Umsetzung der Schnittstelle 005 „Fahrspuren“ im System des EETS-Anbieters (siehe Dokument 4.3.14, Spezifikation der Schnittstelle zum EETS-Anbieter SST 005 –Fahrspurdaten). Beschreibung der Prozessschritte der Erzeugung und Verarbeitung von Positionsdaten zu Fahrspuren durch die On-Board-Units des EETS-Anbieters bis zur Übermittlung der Fahrspuren an den Mauterheber über SST005. Dabei ist mindestens auf folgende Aspekte einzugehen: 1. Verarbeitung in der OBU • Regeln zur Übermittlung der Positionsdaten an die Zentrale • Gegebenenfalls vorhandene Sensor-Fusion • Stillstandserkennung • Tunnelerkennung • Prozess der Anreicherung der Fahrspur mit Fahrzeugparametern • Einhaltung der Vorgaben der Ortungsspezifikation (Anlage zur SST 005) 2. Verarbeitung in der Zentrale • Manuelle/Automatisierte Nachbearbeitung von Fahrspuren • Prozess der Anreicherung der Fahrspur mit Fahrzeugparametern • Regeln zur Bündelung und Übermittlung von Fahrspuren über die SST005
23	Mautbuchungsnachweise	Beschreibung des Geschäftsprozesses der Entgegennahme und Verarbeitung der Mautbuchungsnachweise vom Mauterheber. Erläuterung der geplanten Umsetzung der Schnittstelle 007R „Mautbuchungsnachweise“ im System des EETS-Anbieters (siehe Dokument 4.3.15, Spezifikation der Schnittstelle zum EETS-Anbieter SST 007R – Mautbuchungsnachweise). Angabe zum Format der gewünschten Übermittlung der tarifierten Abschnitte (nur IDs aus den Mautbasisdaten oder zusätzlich Texte) Angabe zu den gewünschten Regeln zur Zwangsbeendigung von Fahrten
24	Tagesbericht	Beschreibung des Geschäftsprozesses der Übermittlung des Tagesberichts. Erläuterung der geplanten Umsetzung der Schnittstelle 008 „Tagesbericht“ im System des EETS-Anbieters (siehe Dokument 4.3.6, Spezifikation der Schnittstelle zum EETS-Anbieter SST 008 − Tagesbericht). Prüfung ob zusätzlich vorgesehen ist, dass der EETS-Anbieter dem Mauterheber werktäglich bis spätestens 15.00 Uhr MEZ/MESZ eine E-Mail mit dem an den Mauterheber an diesem Werktag tatsächlich ausgekehrten Mauteinnahmen (Ist-Auskehrbetrag) übermittelt.
25	nicht ausgekehrte Mautbuchungsnachweise	Beschreibung des Geschäftsprozesses der Entgegennahme der Zahlungsaufforderungen des Mauterhebers wegen nachweislich nicht ausgekehrter Mautbuchungsnachweise sowie der EETS-Anbieter internen Weiterverarbeitung.
26	nicht einbringliche Nacherhebungen	Beschreibung des Geschäftsprozesses der Entgegennahme der Zahlungsaufforderungen des Mauterhebers wegen nicht einbringlicher Nacherhebungen sowie der EETS-Anbieter internen Weiterverarbeitung.
27	Mautbasisdaten	Sofern der EETS-Anbieter von der Möglichkeit Gebrauch machen will eine technische Schnittstelle zur Entgegennahme von Mautbasisdaten vorzuhalten: Beschreibung des Geschäftsprozesses der Entgegennahme der Mautbasisdaten und Beschreibung des Geschäftsprozesses des Mautbasisdatenmanagements, inklusive Entgegennahme und Verarbeitung der Mautbasisdaten des Mauterhebers im Teilsystem des EETS-Anbieters. Prüfung, ob diese Schnittstelle die Vorgaben der Schnittstelle 003 des Mauterhebers berücksichtigt
28	Überwachungsreports	Beschreibung des Geschäftsprozesses der Erfassung von Überwachungsdaten, inklusive Erstellung des geforderten Überwachungsreports. Vorlage eines beispielhaften Entwurfs eines Überwachungsreports in den vom Mauterheber geforderten Bereichen (siehe Vorgaben zu SST 013 – „Überwachungsreports“).
29	DSRC-Daten	Beschreibung des Geschäftsprozesses der Übermittlung der DSRC-Daten. Erläuterung der geplanten Umsetzung der Schnittstelle SST 301 „Fahrzeuggerät des EETS-Anbieters und straßenseitigem Kontrollequipment des Mauterhebers“ im System des EETS-Anbieters (siehe Dokument 4.3.1 − Spezifikation der DSRC-Schnittstelle zwischen einem Bordgerät und der straßenseitigen Ausrüstung im Mautgebiet BFStrMG) inklusive Angabe der unterstützten Versionen der SST 301
30	Gebührenklassen	Beschreibung der Geschäftsprozesse der Nutzerregistrierung, Fahrzeugregistrierung, Deklaration am Fahrzeuggerät vor Fahrtbeginn. Beschreibung des Geschäftsprozesses der Fahrspurerhebung, insbesondere hinsichtlich der Zuordnung der statischen, gebührenrelevanten Parameter zur jeweiligen Fahrspur (z.B. dezentral durch das Bordgerät oder durch das Zentralsystem des EETS-Anbieters) Beschreibung der Möglichkeiten zur Nutzerinteraktion (HMI) der OBU (Benutzerhandbuch der OBU, Informationsmaterial für Nutzer).
31	Nicht-mautpflichtige Befahrungen	Beschreibung der Geschäftsprozesse der Fahrspurerhebung und Mautbefreiung. Prüfung des Verfahrens zur Unterscheidung von mautpflichtigen und nichtmautpflichtigen Fahrzeugen, auch unter Berücksichtigung der Behandlung von Ausnahmen von der regulären Gebührenpflicht und der sich daraus ergebenden Folge, keine Fahrspurdaten über die Schnittstelle 005 an den Mauterheber zu übermitteln
32	Gebietsvorgabe ist entfallen
33	Zuordnung der Mauterhebung	Beschreibung des Geschäftsprozesses der Fahrspurerhebung. Beschreibung des Geschäftsprozesses der Mauterhebung. Es muss deutlich werden an welcher Stelle im Prozess die Zusammenführung zwischen Kfz-Kennzeichen und der Fahrspur erfolgt und wie einer falschen Zuordnung vorgebeugt wird.
34	Zuordnung des Bordgeräts	Beschreibung der Geschäftsprozesse der Nutzerregistrierung, Fahrzeugregistrierung sowie der Prozesse zur Änderung von Nutzer- bzw. Fahrzeugdaten. Beschreibung der Geschäftsprozesse der Fahrzeuggeräteinstallation und Inbetriebnahme, insbesondere für das Szenario, dass der Nutzer vorher bereits ein Fahrzeuggerät des EETS-Anbieters verwendet hat (OBU-Tausch). Prüfung der Unterstützung der folgenden Prozesse im Teilsystem des EETS-Anbieters inklusive Sicherstellung der Einhaltung der Gebietsvorgabe und Auswirkungen auf die Übermittlung von Nutzerlisten gemäß Gebietsvorgabe 20: 1. Fahrzeugverkauf mit Bordgerät, 2. Tausch des Bordgeräts in einem Fahrzeug 3. Weitergabe des Bordgeräts an ein anderes Fahrzeug.
35	Funktionsfähigkeit der Bordgeräte	Beschreibung des Geschäftsprozesses/ IT-Serviceprozesses des Systemmonitorings/-überwachung mit Fokus auf Monitoring der Fahrzeuggeräte. Beschreibung des Geschäftsprozesses des Remote-Device-Management der Fahrzeuggeräteflotte. Beschreibung des bei Auftreten von HW-Defekten an Fahrzeuggeräten (z.B. Überprüfung, Austausch, Reparatur, Neukonfiguration) ablaufenden Geschäftsprozesses.
36	Erhebungsbereitschaft des Bordgeräts	Beschreibung des Geschäftsprozesses/ IT-Serviceprozesses des Systemmonitorings/-überwachung mit Fokus auf Monitoring der Fahrzeuggeräte. Beschreibung der Anzeige- und Ausgabemöglichkeiten der Nutzerschnittstelle (HMI) der OBU bzw. der Applikation eines mit der OBU verbundenen Mobilgerätes (Benutzerhandbuch der OBU.)
37	Benutzerschnittstelle der Bordgeräte	Beschreibung der Möglichkeiten zur Nutzerinteraktion (HMI) der OBU (Benutzerhandbuch der OBU, Informationsmaterial für Nutzer).
38	Sicherstellung korrekter Mauterhebung	Beschreibung der IT-Serviceprozesse in den Bereichen Systemmonitoring/-überwachung, Backup sowie Desaster/Recovery. Beschreibung der Maßnahmen zur Minimierung der Eintrittswahrscheinlichkeit bzw. Maßnahmen zur Reduktion der Auswirkungen von Systemausfällen oder -störungen, insbesondere hinsichtlich der Sicherstellung der vollständigen Abrechnung und Auskehr der Mautbeträge (Risikomanagementplan).
39	Anpassungen des EETS-Teilsystems	Beschreibung des Vorgehens zur Umsetzung der genannten Veränderungen und Erweiterungen durch den EETS-Anbieter insbesondere hinsichtlich der durchzuführenden Phasen und der zu veranschlagenden Dauer. (Systemweiterentwicklungskonzept)
40	Gebietsvorgabe ist entfallen
41	Unterstützung der Kontrollprozesse	Beschreibung der Geschäftsprozesse der Nutzerregistrierung, Fahrzeugregistrierung und Änderungen der Angaben, insbesondere hinsichtlich der dabei erfassten Nutzer- und Fahrzeugdaten sowie deren Qualitätssicherung. Beschreibung der Geschäftsprozesse, die der EETS-Anbieter bezüglich der Befreiung einzelner Nutzer von der Mautpflicht vorsieht inklusive der vorgesehenen Maßnahmen zur Information der Nutzer über die Bestimmungen und Möglichkeiten der Mautbefreiung. Beschreibung des Geschäftsprozesses, in dem Anfragen des Mauterhebers bezüglich Adress- und Fahrzeugdaten zu Ahndungszwecken behandelt werden, insbesondere hinsichtlich der Verfügbarkeit und Übermittlung der in den Schnittstellen 002b und 002c geforderten Informationen. Beschreibung des Geschäftsprozesses der den Umgang mit Ansprüchen des Mauterhebers im Rahmen der Anbieterausfallhaftung beinhaltet. Erläuterung der geplanten Umsetzung der Schnittstelle SST 301 „Fahrzeuggerät des EETS-Anbieters und straßenseitigem Kontrollequipment des Mauterhebers“ im System des EETS-Anbieters (siehe Spezifikation der DSRC-Schnittstelle zwischen einem Bordgerät und der straßenseitigen Ausrüstung im Mautgebiet BFStrMG). Erläuterung der geplanten Umsetzung der Schnittstellen SST 002b/c „Adress- und Fahrzeugdaten bzw. weitere Fahrzeuge eines EETS-Nutzers“ im System des EETS-Anbieters (siehe Spezifikation der Schnittstelle SST 002 – Nutzerlisten).
42	Datenübermittlung für Kontrollzwecke	Erläuterung der geplanten Umsetzung der Schnittstelle SST 301 „Fahrzeuggerät des EETS-Anbieters und straßenseitigem Kontrollequipment des Mauterhebers“ im System des EETS-Anbieters (siehe Spezifikation der DSRC-Schnittstelle zwischen einem Bordgerät und der straßenseitigen Ausrüstung im Mautgebiet BFStrMG). Erläuterung der geplanten Umsetzung der Schnittstellen SST 002b/c „Adress- und Fahrzeugdaten und weitere Fahrzeuge eines EETS-Nutzers“ im System des EETS-Anbieters (siehe Spezifikation der Schnittstelle SST 002 –„Nutzerlisten“). Darstellung der Maßnahmen und Methoden zur Erkennung und Verhinderung von Manipulation am Fahrzeuggerät. (Vorlage Sicherheitskonzept)
43	Ermöglichung der Kontrolle	Erläuterung der geplanten Umsetzung der Schnittstelle SST 301 „Fahrzeuggerät des EETS-Anbieters und straßenseitigem Kontrollequipment des Mauterhebers“ im System des EETS-Anbieters (siehe Spezifikation der DSRC-Schnittstelle zwischen einem Bordgerät und der straßenseitigen Ausrüstung im Mautgebiet BFStrMG). Beschreibung der Anzeige- und Ausgabemöglichkeiten der Nutzerschnittstelle (HMI) der OBU (Benutzerhandbuch der OBU).
44	Information über technische Probleme	Beschreibung der IT-Serviceprozesse im Bereich Systemmonitoring/-überwachung. Hier sind insbesondere die Aktivitäten darzustellen, im Rahmen derer der Mauterheber über Störungen und Ausfälle informiert wird.
45	Sicherheit - Gefahren für Menschen, Sachgüter und Umwelt	Beschreibung der technischen Daten der für den Einsatz vorgesehenen OBU, insbesondere hinsichtlich der vorhandenen Typenzulassungen (Benutzerhandbuch der OBU). Hinweis: Für die in Verkehr gebrachten Geräte sollte die Erfüllung der Gebietsvorgabe bereits durch die entsprechenden Konformitätsnachweise der Baumuster erbracht sein.
46	Verkehrssicherheit	Beschreibung gegebenenfalls notwendiger straßenseitiger Komponenten im System des EETS-Anbieters (High-Level-Systemdokumentation). Sofern straßenseitige Einrichtungen vorgesehen werden, ist zu beschreiben, wie Beeinträchtigungen der Funktionsfähigkeit von anderen Einrichtungen, Einschränkungen der Verkehrssicherheit sowie der Arbeiten zum Ausbau und Erhalt der Straßeninfrastruktur ausgeschlossen werden.
47	Einbauten in Fahrbahn	Schriftlicher Hinweis zur Kenntnisnahme und Akzeptanz der Vorgabe.Beschreibung gegebenenfalls notwendiger straßenseitiger Komponenten im System des EETS-Anbieters (High-Level-Systemdokumentation).
48	Kommunikation mit straßenseitigen Einrichtungen	Geeignete Nachweise der korrekten Funktion der DSRC-Schnittstelle, wie beispielsweise vorhandene Zertifizierungen, Testabschlussberichte und/oder Testprotokolle.
49	gebührenrelevante Parameter	Beschreibung des Geschäftsprozesses der Fahrzeugregistrierung sowie des Prozesses zur Änderung von Fahrzeugdaten insbesondere im Hinblick auf die vorgesehenen Schritte zur Prüfung und Validierung der vom Nutzer angegebenen Parameter (z.B. Abgleich mit Fahrzeugpapieren, Anfrage beim nationalen Fahrzeugregister).
50	Änderung von Parametern	Beschreibung der Möglichkeiten zur Nutzerinteraktion (HMI) der OBU und/oder der Applikation eines mit der OBU verbundenen Mobilgerätes (Benutzerhandbuch der OBU, Informationsmaterial für Nutzer).
51	Sicherung von Daten	Vorlage des Sicherheitskonzepts des EETS-Anbieters, welches die in den IT-Systemen und Schnittstellen verarbeiteten Daten sowie die umgesetzten Maßnahmen zur Sicherung von Vertraulichkeit, Integrität, Authentizität und Verfügbarkeit beschreibt. Vorlage des Datenschutzkonzepts und Prüfung ob Maßnahmen zum Schutz personenbeziehbarer Daten und Einhaltung der Datenschutzanforderungen der nationalen Gesetze sowie der Datenschutz-Grundverordnung und Richtlinie 2002/58/EG des Europäischen Parlaments und des Rates vom 12. Juli 2002 über die Verarbeitung personenbezogener Daten und den Schutz der Privatsphäre in der elektronischen Kommunikation (ABl. L 201 vom 31.7.2002, S. 37), die zuletzt durch die Richtlinie 2009/136/EG (ABl. L 337 vom 18.12.2009, S. 11, L 241 vom 10.9.2013, S. 9; L 162 vom 23.6.2017, S. 6) geändert worden ist, beim EETS-Anbieter umgesetzt
52	Missbrauchsschutz	Beschreibung der Möglichkeiten zur Identifikation von betrügerischen Eingriffen sowie der dann durchzuführenden Maßnahmen zur Verhinderung von negativen Auswirkungen. (Vorlage Sicherheitskonzept)
53	Überwachung interner Einrichtungen des EETS-Anbieters	Beschreibung der IT-Serviceprozesse in den Bereichen Systemmonitoring/-überwachung, Backup sowie Desaster/Recovery. Beschreibung der Maßnahmen zur Minimierung der Eintrittswahrscheinlichkeit und Maßnahmen zur Reduktion der Auswirkungen von Systemausfällen oder -störungen, insbesondere hinsichtlich der Sicherstellung der vollständigen Abrechnung und Auskehr der Mautbeträge. (Risikomanagementplan)
54	Qualitätsparameter	Schriftlicher Hinweis zur Kenntnisnahme und Akzeptanz der Vorgabe. Beschreibung der technischen Prozesse und Geschäftsprozesse zur Umsetzung und Erfüllung der Qualitätsanforderungen.
55	System zur Qualitätsmessung	Beschreibung des Systems, das der EETS-Anbieter zur Messung und Überwachung der Qualität seines Systems und seiner Prozesse unterhält. (High-Level Systemdokumentation) Beschreibung der Maßnahmen zur Minimierung der Eintrittswahrscheinlichkeit und Reduktion der Auswirkungen von Qualitätsverschlechterungen. Beschreibung der Maßnahmen, die bei festgestellter Verschlechterung ergriffen werden, um die Qualität wiederherzustellen. (Risikomanagementplan)
56	Information zu Auffälligkeiten bei Bordgeräten	Beschreibung des Geschäftsprozesses, in dem die Entgegennahme und Verarbeitung der vom Mauterheber über die SST 009 an den EETS-Anbieter gesendeten Informationen zu Auffälligkeiten bei Bordgeräten vorgesehen wird. Beschreibung der Maßnahmen, die der EETS-Anbieter basierend auf den über SST 009 empfangenen Informationen zur Qualitätsüberwachung und Systemoptimierung ergreift.

Tabelle 2: Schwerpunkte bei der Prüfung der Dokumentation

1.

Die Testumgebung des Mauterhebers repräsentiert das EETS-Teilsystem des Mauterhebers, und umfasst die Schnittstellenprüfumgebung des Mauterhebers und die Testumgebung für die Kompatibilitätstests des nationalen Betreibers.

2.

Die Schnittstellenprüfumgebung des Mauterhebers umfasst die folgenden wirksystem-identischen Schnittstellen vom EETS-Teilsystem des Mauterhebers zum Teilsystem des EETS-Anbieters:

•: Schnittstelle 001 „Blocklist/Sperrliste“
•: Schnittstelle 002 „Nutzerlisten“
•: Schnittstelle 003 „Mautbasisdaten“ –Tests dieser Schnittstelle erfolgen nur im Fall, dass der EETS-Anbieter eine Übertragung von Mautbasisdaten über die Schnittstelle implementiert hat
•: Schnittstelle 008 „Tagesberichte“
•: Schnittstelle 099 „Acknowledgement/Quittungen“

3.

Die Testumgebung für die Kompatibilitätstests umfasst:

•: Schnittstelle 301 „DSRC-Kontrolldaten“
•: Technische Komponenten zur Prüfung der Kompatibilität der Bordgeräte des EETS-Anbieters mit den Kontrolleinrichtungen des nationalen Mautbetreibers (Laborkomponente, Kontrolleinrichtungen)
•: Schnittstelle 005 „Fahrspurdaten“
•: Schnittstelle 007R „Mautbuchungsnachweise“
•: Schnittstelle 009 Report „Information zu Auffälligkeiten bei Bordgeräten“
•: Schnittstelle 099a/c „Acknowledgement/Quittungen“
•: Technische Komponenten des Mauterhebungsdienstes
•: Ortungsreferenzsystem des nationalen Mautbetreibers zur Auswertung der MED-Kompatibilitätstests

4.

Das Teilsystem des EETS-Anbieters muss die folgenden Randbedingungen erfüllen:

•: Eingriffe in die Software des Teilsystems des EETS-Anbieters sind nach Absprache mit dem Mauterheber zur Behebung von Fehlern zulässig. Weiterhin müssen in Abstimmung mit dem Mauterheber die nach einer Fehlerbehebung erneut zu durchlaufenden Prüffälle festgelegt werden.
•: Die Anpassung der Konfiguration ist in Abstimmung mit dem Mauterheber zulässig.
•: Es kommen die für den Wirkbetrieb bestimmten Bordgeräte des EETS-Anbieters zum Einsatz.
•: Der EETS-Anbieter muss sicherstellen, dass ausschließlich Daten zur Testumgebung des Mauterhebers gesendet werden, die im Rahmen der Prüfungen erzeugt werden.

5.

Die im Rahmen der Phase 1 zwischen EETS-Anbieter und Mauterheber ausgetauschten Schlüssel unterliegen auf Seite des Mauterhebers keinem besonderen Schutzbedürfnis.

Ziel

Ziel dieses Prüfszenarios ist es, einerseits die technisch und fachlich korrekte Durchführung der Überwachungsprozesse des EETS-Anbieters gemäß SST 013 zu prüfen (im Folgenden Teil A), andererseits die Auswirkungen von möglichen Störungen im System des EETS-Anbieters auf den Mauterheber zu prüfen (im Folgenden Teil B). Dazu werden zwei Prüfziele gesetzt:

Teil A)

Prüfungen im Regelbetrieb

1.: Prüfung der technisch und fachlich korrekten Implementierung der Überwachungsprozesse beim EETS-Anbieter in einem dauerhaften Regelbetrieb
2.: Prüfung der Anwendung der SST 013

Teil B)

Prüfungen im Störungsbetrieb

1.: Prüfung der Überwachungsprozesse und des Monitorings bei Systemausfall des EETS-Anbieters durch Auslösung von Störungen
2.: Prüfung der internen Überwachung des EETS-Anbieters durch Auslösung von Störungen
3.: Prüfung der Anwendung der SST 016

Die im Rahmen des Prüfszenarios durchzuführenden Prüffälle ergeben sich aus dem Prüfkatalog „Probebetrieb“ Anlage [4].

Durchführung

Teil A):

1.: Der EETS-Anbieter überwacht sein Teilsystem und alle von ihm eingesetzten Bordgeräte. Die von ihm dabei gesammelten Daten werden zur Erstellung des Reports verwendet, der über die organisatorische SST 013 an den Mauterheber übermittelt wird.

Teil B):

1.: Der EETS-Anbieter führt technische Störungen an den Komponenten seines Teilsystems durch, deren Auftreten durch die Prozesse des Mauterhebers (in Bezug auf Schnittstellen zwischen den Zentralsystemen) und den nationalen Mautbetreiber (in Bezug auf die Bordgeräte) nachvollzogen werden kann.
2.: Die beim EETS-Anbieter aufgetretenen Störungen werden zur Erstellung des Reports herangezogen, der über die organisatorische SST 013 an den Mauterheber übermittelt wird.
3.: Der Mauterheber fragt Informationen zum technischen Zustand eines Bordgeräts an, die der EETS-Anbieter über die organisatorische Schnittstelle SST 016 bereitstellt.
4.: Die Durchführung der Prüffälle zum Teil B) des Prüfszenarios darf nicht parallel zu den restlichen Szenarien des Probebetriebs erfolgen, da negative Auswirkungen auf deren Testverlauf nicht ausgeschlossen werden können. Sinnvoll ist eine Durchführung am Ende des Probebetriebs.

Ziel	In diesem Szenario wird geprüft, ob der Ende-zu-Ende Prozess der Mauterhebung bis zum Empfang der Mautbuchungsnachweise unter Wirkbetriebsbedingungen technisch funktioniert und fachlich korrekt erfolgt. Die Nutzerreferenzgruppe repräsentiert im Pilotbetrieb die Gruppe der späteren EETS-Nutzer und verhält sich wirkbetriebskonform. Insofern handelt es sich um ein vom Prüfvorgang unbeeinflusstes Fahr- und Nutzerverhalten. Wenn nach Ablauf der Mindestdauer des Pilotbetriebs das unbeeinflusste Fahrverhalten der Nutzerreferenzgruppe nicht ausgereicht hat die Vorgaben des Szenarios abzudecken, so kann in Abstimmung mit dem Mauterheber darüber entschieden werden, ob spezielle Prüffahrten durchzuführen sind, oder ob auf den Nachweis der Erfüllung der Vorgabe verzichtet werden kann.
Vorbereitung	Vorbereitung des EETS-Anbieters 1. Die Nutzerreferenzgruppe wird bereitgestellt 2. Bereitstellung einer Liste mit den Fahrzeugen der Nutzerreferenzgruppe, die für die Teilnahme am automatischen Verfahren beim nationalen Mautbetreiber registriert sind 3. Parallele Ausstattung einiger Fahrzeuge der Nutzerreferenzgruppe mit vom Mauterheber bereitgestellten Geräten für Referenzmessungen (nach Aufforderung durch den Mauterheber). 4. Alle internen Prozesse des EETS-Anbieters sowie die Schnittstellen zum Mauterheber sind technisch und prozessual implementiert und wirkbetriebsbereit. 5. Einrichtung eines Servicedesks zur Meldung von Incidents und Information des Mauterhebers und des nationalen Mautbetreibers über die Kommunikationswege und -prozesse Vorbereitung des Mauterhebers 1. Optional: Aufforderung zur Ausstattung einiger Fahrzeuge der Nutzerreferenzgruppe mit Geräten für Referenzmessungen inklusive Bereitstellung der Geräte. 2. Alle internen Prozesse des Mauterhebers sowie die Schnittstellen zum EETS-Anbieter und zum nationalen Mautbetreiber sind technisch und prozessual implementiert und im Wirkbetrieb. Vorbereitung des nationalen Mautbetreibers 1. Sperrung der Bordgeräte der Fahrzeuge der Nutzerreferenzgruppe, die beim nationalen Mautbetreiber registriert sind, um Doppelbemautung zu vermeiden 2. Alle internen Prozesse des nationalen Mautbetreibers sowie die Schnittstellen zum EETS-Anbieter und zum Mauterheber sind technisch und prozessual implementiert und im Wirkbetrieb. 3. Der EETS-Servicedesk wurde für den EETS-Anbieter eingerichtet und der EETS-Anbieter wurde über die Kommunikationswege und -prozesse informiert
Durchführung	Die Nutzerreferenzgruppe fährt mit mautpflichtigen Fahrzeugen und Bordgeräten unter den Regeln für die Teilnahme am Wirkbetrieb (zum Beispiel Mitwirkungspflicht und korrekte Selbstdeklaration). Der EETS-Anbieter trägt dafür Sorge, dass die Nutzerreferenzgruppe bezüglich der Teilnahme am Pilotbetrieb ausreichend informiert ist. Der EETS-Anbieter überwacht die Nutzerreferenzgruppe hinsichtlich der Erfüllung der Prüfkriterien. Können die Kriterien nicht vollständig von der Nutzerreferenzgruppe abgedeckt werden, so können vom EETS-Anbieter zur Abdeckung dieser Prüfkriterien in Abstimmung mit dem Mauterheber besondere Nutzer eingesetzt werden.
Bewertung	Die Bewertung erfolgt auf Basis der Auswertung der erhobenen Daten. Die Prüfergebnisse werden vom EETS-Anbieter hinsichtlich der Erfüllung der Vorgaben des Prüfszenarios sowie der Prüfkriterien bewertet. Die Gesamtbewertung erfolgt abschließend durch den Mauterheber. Dabei umfasst die Prüfung mindestens, dass die vom EETS-Anbieter vorgelegten Prüfergebnisse hinsichtlich der Prüfkriterien abgeglichen, bewertet sowie dokumentiert werden. Einhaltung der folgenden Vorgaben für das Prüfszenario: 1. Es sind alle Gewichts- und Achsklassen sowie mindestens zwei verschiedene Schadstoffklassen und zwei verschiedene CO₂-Emissionsklassen abzudecken. 2. Jedes Fahrzeug darf nur ein Bordgerät des EETS-Anbieters enthalten. 3. Änderung der Achszahl durch Anhängen und Abkoppeln von Anhängern bzw. Wechsel eines Aufliegers bei einer Fahrtunterbrechung auf einem Rastplatz 4. Übermittlung einer vollständigen Nutzerliste durch den EETS-Anbieter 5. Übermittlung technisch korrekter und fachlich richtiger Fahrspuren an den MED über die Schnittstelle 005 6. Vollständiger Empfang der Mautbuchungsnachweise über die SST007R durch den EETS-Anbieter 7. eineindeutige Zuordnung von Kennzeichen (inklusive Nationalität) und Fahrzeug 8. eineindeutige Zuordnung von Bordgerät zu Fahrzeug 9. Erreichung der gemäß Zulassungsvertrag geforderten Quoten für: 9.1. Erfassungsquote 9.2. Sperrlistenquote 9.3. Nutzerlistenquote 9.4.

Ziel	In diesem Prüfszenario wird die korrekte Auskehr der Mautbeträge an den Mauterheber auf Einzeldatenbasis mit realen Fahrdaten geprüft.
Vorbereitung	Vorbereitung des EETS-Anbieters 1. Einrichten und Einbinden eines Abwicklungskontos 2. Anbindung an den wirkbetrieblichen Zahlverkehr sowie an alle relevanten internen und externen Schnittstellen Vorbereitung des Mauterhebers 1. Alle internen Prozesse des Mauterhebers sowie die Schnittstellen zum EETS-Anbieter und zum nationalen Mautbetreiber sind technisch und prozessual implementiert und im Wirkbetrieb.
Durchführung	Der EETS-Anbieter übermittelt regelmäßig die E-Mail (Ist-Auskehrbetrag) an den Mauterheber und erstellt und übermittelt regelmäßig die Tagesberichte und überweist den auszukehrenden Betrag auf das Abwicklungskonto. Die Zahlungseingänge müssen wirkbetriebskonform ablaufen und die reale Wertstellungsfrist berücksichtigen. Wenn eine Auskehr nach Ablauf der Wertstellungsfrist erfolgt, werden auch die anfallenden Zinsen korrekt berechnet, im Tagesbericht ausgewiesen und vollständig ausgekehrt. Das Prüfszenario wird mit realem Geldverkehr durchgeführt.
Bewertung	Die Bewertung erfolgt auf Basis der Auswertung der erhobenen Daten. Die Prüfergebnisse werden vom EETS-Anbieter hinsichtlich der Erfüllung der Vorgaben des Prüfszenarios sowie der Prüfkriterien bewertet. Die Gesamtbewertung erfolgt abschließend durch den Mauterheber. Dabei umfasst die Prüfung mindestens, dass die vom EETS-Anbieter vorgelegten Prüfergebnisse hinsichtlich der Prüfkriterien abgeglichen, bewertet sowie dokumentiert werden. Einhaltung der folgenden Vorgaben für das Prüfszenario: 1. fachlich korrekte und vollständige Auskehr des Gesamtbetrags (Prüfung der Auskehr der Mauteinnahmen an den Mauterheber in voller Höhe über die gesamte Laufzeit im Pilotbetrieb durch einen Ordnungsmäßigkeits- und einen Vollständigkeitsnachweis: Prüfung der Tagesberichte gegen Mautbuchungsnachweise) 2. korrekte Berücksichtigung der Wertstellungsfrist und Fälligkeit bei den Überweisungen auf das Abwicklungskonto 3. korrekte Anwendung der Zinsberechnungsmethodik 4. regelmäßige Erstellung und fristgerechte Übermittlung der E-Mail, mit dem Ist-Auskehrbetrag (jeweils am Stichtag der Auskehr bis 15:00 Uhr) 5. regelmäßige Erstellung und fristgerechte Übermittlung des Tagesberichts (spätestens 15:00 Uhr am auf den Stichtag der Auskehr folgenden Werktag)

Ziel	Ziel dieses Prüfszenarios ist es, einerseits die technisch und fachlich korrekte Durchführung der Überwachung des EETS-Anbieters und die Übermittlung der Informationen gemäß SST 013 zu prüfen, andererseits die Auswirkungen von möglichen Störungen im System des EETS-Anbieters auf den Mauterheber zu prüfen. Dazu werden folgende Bereiche überwacht: 1. Prüfung des Monitorings und der Implementierung der Überwachungsprozeduren beim EETS-Anbieter in einem dauerhaften Regelbetrieb 2. Prüfung der Anwendung der SST 013 Es darf nicht simuliert werden. Es darf keine Datenbearbeitung und -extraktion erfolgen, wenn diese nicht in definierten, nachvollziehbaren Betriebsprozessen vorgesehen sind
Vorbereitung	Vorbereitung des EETS-Anbieters 1. Die Prozesse des EETS-Anbieters zur Überwachung und Bereitstellung von Überwachungsdaten (SST 013 Reports) sind definiert und übergreifend implementiert.
Durchführung	Während der gesamten Laufzeit des Pilotbetriebs führt der EETS-Anbieter unter Wirkbetriebsbedingungen ein Monitoring und eine Überwachung seines Systems durch. Der EETS-Anbieter erzeugt entsprechende Überwachungsreports und übermittelt diese über SST 013 an den Mauterheber.
Bewertung	Die Bewertung erfolgt auf Basis der Auswertung der erhobenen Daten. Die Prüfergebnisse werden vom EETS-Anbieter hinsichtlich der Erfüllung der Vorgaben des Prüfszenarios sowie der Prüfkriterien bewertet. Die Gesamtbewertung erfolgt abschließend durch den Mauterheber. Dabei umfasst die Prüfung mindestens, dass die vom EETS-Anbieter vorgelegten Prüfergebnisse hinsichtlich der Prüfkriterien abgeglichen, bewertet sowie dokumentiert werden. Einhaltung der folgenden Vorgaben für das Prüfszenario: 1. Der EETS-Anbieter muss die Überwachungsdaten (Überwachungsreports) dem Mauterheber regelmäßig in korrekter und vollständiger Form über die SST 013 bereitstellen. 2. Regulär auftretende Störungen im Pilotbetrieb wurden durch den EETS-Anbieter mit den definierten Mitteln überwacht, erfasst und ausgewertet. 3. Die Überwachungsreports spiegeln mindestens die durch den Mauterheber wahrgenommenen Entwicklungen und Vorkommnisse (z.B. Störungen) im Teilsystem des EETS-Anbieters in korrekter Form wider.

Ziel	Die Korrektheit der Kontrollprozesse wird im Rahmen von Fahrten der Nutzerreferenzgruppe mit Kontrollen im realen Verkehr geprüft. Das Prüfszenario umfasst die Sachverhaltsermittlung (DSRC-Kommunikation des Bordgerätes mit den Kontrolleinrichtungen) und geht über die Sachverhaltsfeststellung bis zur Nacherhebung und Ahndung. Dies deckt einerseits den Prozess der Datenerhebung vom Bordgerät des EETS-Anbieters bis zum zentralseitigen Eingang beim Mauterheber ab. Weiterhin ist auch die notwendige Datenbereitstellung für die Zwecke der Ahndung und Nacherhebung (Fahrzeug-/Adressdaten, Bereitstellung Informationen zu weiteren Bordgeräten des EETS-Nutzers) davon umfasst. Berücksichtigt werden alle Einrichtungen der automatischen und der manuellen Kontrolle. Einrichtungen der Betriebskontrolle werden nicht berücksichtigt
Vorbereitung	Vorbereitung des EETS-Anbieters 1. Die Nutzerreferenzgruppe wird bereitgestellt. 2. Alle internen Prozesse des EETS-Anbieters sowie die Schnittstellen zum Mauterheber sind technisch und prozessual implementiert und wirkbetriebsbereit. Vorbereitung des Mauterhebers 1. Alle internen Prozesse des Mauterhebers sowie die Schnittstellen zum EETS-Anbieter und zum nationalen Mautbetreiber sind technisch und prozessual implementiert und im Wirkbetrieb. Vorbereitung des nationalen Mautbetreibers 1. Alle internen Prozesse des nationalen Mautbetreibers sowie die Schnittstellen zum EETS-Anbieter und zum Mauterheber sind technisch und prozessual implementiert und im Wirkbetrieb.
Durchführung	Die Nutzerreferenzgruppe des EETS-Anbieters befährt das mautpflichtige Streckennetz. Der EETS-Anbieter stellt über Schnittstelle 001 Sperrlisten bereit. Der Mauterheber führt alle relevanten Kontrollarten durch und ermittelt die dabei entstehenden Sachverhalte im Rahmen der übergreifenden Kontrollprozesse. Die Kontrolleure des Mauterhebers erfassen und dokumentieren dabei besondere Vorkommnisse und Auffälligkeiten in Bezug auf den Pilot-EETS-Anbieter (z.B. fortwährende Verbindungsabbrüche in der Kontrollkommunikation). Aufgenommene Kontrollfälle der EETS-Nutzer werden im Rahmen der Prozesse Nacherhebung und Ahndung beim Mauterheber verarbeitet. Für seine EETS-Nutzer stellt der EETS-Anbieter dem Mauterheber die Beteiligtendaten (Fahrzeug-/Adressdaten, Informationen zu weiteren Bordgeräten des EETS-Nutzers) über die Schnittstellen 002b und 002c bereit.
Bewertung	Die Bewertung erfolgt auf Basis der Auswertung der erhobenen Daten. Die Prüfergebnisse werden vom EETS-Anbieter hinsichtlich der Erfüllung der Vorgaben des Prüfszenarios sowie der Prüfkriterien bewertet. Die Gesamtbewertung erfolgt abschließend durch den Mauterheber. Dabei umfasst die Prüfung mindestens, dass die vom EETS-Anbieter vorgelegten Prüfergebnisse hinsichtlich der Prüfkriterien abgeglichen, bewertet sowie dokumentiert werden. Einhaltung der folgenden Vorgaben für das Prüfszenario: 1. Technisch korrekte Kommunikation zwischen den Bordgeräten des EETS-Anbieters und den Kontrolleinrichtungen über die Schnittstelle 301 2. Übermittlung fachlich korrekter Werte im Rahmen der DSRC-Kommunikation 3. Technisch korrekte Kommunikation über die Schnittstelen 002b und 002c sowie Übermittlung korrekter Beteiligtendaten zur Unterstützung der Prozesse Nacherhebung und Ahndung des Mauterhebers 4. Erreichung der gemäß Zulassungsvertrag geforderten DSRC-Quote

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

1.

eindeutige Referenznummer für das Prüfprotokoll

2.

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

3.

Datum der Fertigstellung des Prüfprotokolls

4.

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

5.

Angabe des Prüfszenarios

6.

Angaben zum EETS-Anbieter inklusive Firmenname und Anschrift

7.

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

8.

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

9.

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

10.

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

11.

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

12.

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

•: festgestellten Übereinstimmungen mit den erwarteten Ergebnissen
•: festgestellten Abweichungen von den erwarteten Ergebnissen inklusive Bewertung der festgestellten Abweichungen
•: festgestellte Auffälligkeiten bei der Durchführung der Prüffälle inklusive Bewertung der festgestellten Auffälligkeiten
•: Bewertungsvorschlag des EETS-Anbieters („bestanden", „bestanden mit Abweichungen/Auffälligkeiten“ oder „nicht bestanden“)

13.

abschließender Zusammenfassung des Prüfergebnisses

14.

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

15.

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

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

1.

eindeutige Referenznummer für den Szenariobericht

2.

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

3.

Datum der Fertigstellung des Berichts

4.

Angabe des Prüfszenarios

5.

Angaben zum EETS-Anbieter inklusive Firmenname und Anschrift

6.

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

7.

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

8.

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

9.

eindeutige Konfigurations- oder Versionsbezeichnung des Mauterhebers

10.

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

•: Beschreibung der Vorgabe
•: Beschreibung der Art und Weise der Erfüllung
•: Zeitpunkt der Erfüllung
•: Beschreibung eventuell festgestellter Abweichungen

11.

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

12.

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

13.

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

14.

digitale Unterschrift des Verantwortlichen für die Erstellung des Szenarioberichts

Version	Datum	Bearbeiter	Bearbeitung/Änderung
0.1	17.09.2020	RT, BAG	Erstellung erster unvollständiger Entwurf
1.0	04.12.2020	RT, BAG	Überarbeitung nach Review Prüfspezifikation SSP, QS und Finalisierung
1.1	07.09.2021	RT, BAG	Redaktionelle Überarbeitung und Ergänzung fehlende Beschreibung bei P1-SSP-006.1
1.2	01.03.2024	RT, BALM	Überarbeitung entsprechend der Änderungen im BFStrMG

ID	Name	Beschreibung	Ziel
P1-SSP-001.1	Übertragung von Transportschlüsseln vom BALM zum EA	Der Mauterheber überträgt die folgenden Transportschlüssel via SST004 (organisatorische Schnittstelle) jeweils einzeln an den EETS-Anbieter: • KPUB_BAG_ENC • KPUB_BAG_SIG Der EA implementiert die Transportschlüssel in seinem Zentralsystem und quittiert die erfolgreiche Implementierung .	Korrekte und vollständige Übertragung der Transportschlüssel an den EA und erfolgreiche Quittierung durch den EA
P1-SSP-001.2	Übertragung von Transportschlüsseln vom EA zum BALM	Der EA überträgt den folgenden Transportschlüssel via SST004 (organisatorische Schnittstelle) an das BALM: • KPUB_EP_SIG Das BALM implementiert den Transportschlüssel in seinem Zentralsystem und quittiert die erfolgreiche Implementierung.	Korrekte und vollständige Übertragung der Transportschlüssel an das BALM und erfolgreiche Quittierung durch das BALM
P1-SSP-001.3	Übertragung von Zertifikaten vom BALM zum EA	Der Mauterheber überträgt die folgenden Zertifikate via SST004 (organisatorische Schnittstelle) jeweils einzeln an den EETS-Anbieter: • CERT_BAG_HTTPS • CERT_BAG_HTTPS_AUTH • CERT_BAG_MAIL • CERT_BAG_NSIG • CERT_TA_BAG • CERT_ROOT_BAG Der EA implementiert die Zertifikate in seinem Zentralsystem und quittiert die erfolgreiche Implementierung.	Korrekte und vollständige Übertragung der Zertifikate an den EA und erfolgreiche Quittierung durch den EA
P1-SSP-001.4	Übertragung von Zertifikaten vom EA zum BALM	• Der EA überträgt die folgenden Zertifikate via SST004 (organisatorische Schnittstelle) an das BALM: • CERT_EP_HTTPS • CERT_EP_HTTPS_AUTH • CERT_EP_MAIL • CERT_EP_NSIG • CERT_TA_EP • CERT_ROOT_EP Das BALM implementiert die Zertifikate in seinem Zentralsystem und quittiert die erfolgreiche Implementierung.	Korrekte und vollständige Übertragung der Zertifikate an das BALM und erfolgreiche Quittierung durch das BALM
P1-SSP-001.5	Übertragung von Masterkeys vom EA zum BALM	Der EA überträgt die folgenden Masterkeys via SST004 (organisatorische Schnittstelle) an das BALM: • KM_CONTROL_MAC1 • KM_CONTROL_AC Das BALM implementiert die Masterkeys in seinem Zentralsystem und Kontrollstellen und quittiert die erfolgreiche Implementierung. Prüfung der DSRC-Kommunikation zwischen EETS-OBU und Kontrollstelle.	Korrekte und vollständige Übertragung der Masterkeys an das BALM sowie erfolgreiche Quittierung durch das BALM und erfolgreiche DSRC-Kommunikation zwischen EETS-OBU und Kontrollstelle.

ID	Name	Beschreibung	Ziel
P1-SSP-003.1	Neuanlage mehrerer Nutzer mit Fahrzeugen	Der EA legt im Rahmen einer Erstvertragsanlage mehrere neue EETS-Nutzer mit jeweils mehreren Fahrzeugen an und aktiviert für diese den Service für das deutsche Mautgebiet BFStrMG. Der EA aktualisiert die Nutzerliste, in dem er die neuen UserIds der EETS-Nutzer in die Nutzerliste einträgt, und übermittelt diese spezifikationskonform via SST002a an den Mauterheber	Nachweis, dass der EA UserIds von EETS-Nutzern vollständig und korrekt anlegt und diese via SST002a vollständig und spezifikationskonform innerhalb der Nutzerliste an den Mauerheber übermittelt.
P1-SSP-003.2	Abmelden eines Fahrzeugs	Der EA meldet der bereits angelegten und an den Mauterheber via SST002a gemeldeten UserId ab und aktualisiert die Nutzerliste. Anschließend übermittelt der EA die Nutzerliste spezifikationskonform via SST002a an den Mauterheber. Die abgemeldete UserID ist nicht mehr Bestandteil der Nutzerliste.	Nachweis, dass der EA UserIds von EETS-Nutzern vollständig und korrekt anlegt und diese via SST002a vollständig und spezifikationskonform innerhalb der Nutzerliste an den Mauerheber übermittelt. Nachweis, dass der EA UserId, die nicht mehr für den Dienst Deutschland bei ihm registriert sind von der Nutzerliste entfernt.
P1-SSP-003.3	Neues Bordgerät für bestehendes Fahrzeug	Das EETS-Bordgerät eines angelegten EETS-Fahrzeugs wird deinstalliert und ein neues Bordgerät wird in das Fahrzeug installiert. Dies führt dazu, dass die „alte“ UserId nicht mehr Bestandteil der Nutzerliste ist. Stattdessen wird die Nutzerliste um die „neue“ UserId ergänzt. Die aktualisierte Nutzerliste wird sodann an den Mauterheber via SST002a spezifikationskonform übermittelt.	Nachweis, dass der EA Änderungen in den Daten einer UserId korrekt verarbeitet und in seinem Zentralsystem korrekt anlegt und dass der EA die Änderungen bei der Aktualisierung der Nutzerliste korrekt berücksichtigt und sie via SST002a vollständig und spezifikationskonform an den Mauerheber übermittelt.

Version	Datum	Bearbeiter	Bearbeitung/Änderung
0.1	17.09.2020	RT, BAG	Erstellung erster unvollständiger Entwurf
0.2	30.10.2020	RT, BAG	Einarbeitung Review TC
1.0	04.12.2020	RT, BAG	QS und Finalisierung
2.0	07.07.2021	RT, BAG	Ergänzung Prüffälle für Version 3.0 der SST 301
2.1	01.03.2024	RT, BALM	Wegfall der Testfälle für SST 301 v2.1 Ergänzung betrieblicher Testfälle für SST 301 v3.1 Überarbeitung entsprechend der Änderungen des BFStrMG

Name/ID	Beschreibung	Ziel
DSRC_A0BA_BI01_0010	Die Bake sendet BSTs für AIDs 1, 20 und 21 mit einem profile, das von der OBU nicht unterstützt wird. Die OBU soll nicht antworten. Das wird wiederholt mit einem weiteren von der OBU nicht unterstützten profile wiederholt.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul das Profil korrekt handhabt.
DSRC_A0BA_BI02_0010	Die Bake sendet BSTs für eine von der OBU nicht unterstütze Anwendung in der mandApplicationList und leerer nonmandApplicationList. Die OBU soll nicht antworten. Das wird wiederholt mit einer weiteren von der OBU nicht unterstützten Anwendung in der mandApplicationList und der vorigen Anwendung in der nonmandApplicationList.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul applicationIds korrekt handhabt.
DSRC_A0BA_BI03_0011	Die Bake sendet BSTs für eine von der OBU nicht unterstütze Anwendung mit EID in der mandApplicationList und AID=20 in der nonmandApplicationList. Die OBU soll nicht antworten.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul applicationIds korrekt handhabt.
DSRC_A0BA_BV01_0010	Die Bake führt eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Anschließend sendet sie ein ECHO.rq, das die OBU beantworten soll. Dann schickt sie eine BST, die die OBU nicht beantworten soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul die Initialisierung korrekt durchführt.
DSRC_A0BA_BV02_0010	Die Bake führt eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Anschließend sendet sie ein ECHO.rq, das die OBU beantworten soll, und zwei RELEASEs. Dann schickt sie ein weiteres ECHO, das die OBU nicht beantworten soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul die Initialisierung korrekt durchführt.
DSRC_A0BA_BV03_0010	Die Bake führt eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Anschließend sendet sie ein ECHO.rq, das die OBU beantworten soll. Der ganze Vorgang wird wiederholt, wobei erst die manufacturerID und dann die individualId der BST verändert wird.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul die Initialisierung korrekt durchführt.
DSRC_A0BA_BV04_0010	Die Bake führt eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Anschließend sendet sie ein ECHO.rq, das die OBU beantworten soll. Der ganze Vorgang wird wiederholt, wobei die beacon time der BST um 256 Sekunden erhöht wird.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul die Initialisierung korrekt durchführt.
DSRC_A0BA_BV09_0010	Die Bake führt eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 mit profile=0 und leerer profileList durch. In der VST soll der Wert von profile auf 0 gesetzt sein. Der Vorgang wird wiederholt mit einer BST mit neuer BeaconID, profile=0 und profileList=1,U, wobei in der VST profile wieder den Wert 0 haben soll. Der Vorgang wird wiederholt mit einer BST mit neuer BeaconID, profile=1 und leerer profileList, wobei in der VST profile wieder den Wert 1 haben soll. Der Vorgang wird wiederholt mit einer BST mit neuer BeaconID, profile=1 und profileList=0,U, wobei in der VST profile wieder den Wert 1 haben soll. U hat den Wert eines Profils, das die OBU nicht unterstützt.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul das Profil korrekt handhabt.
DSRC_A0BA_BV10_0010	Die Bake führt eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Die VST wird auf ein korrektes Format hin überprüft.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul die BST mit einer korrekten VST beantwortet.
DSRC_A0DA_BI01_0011	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie jeweils ein SET.rq für Attribute 16, 17, 18, 19, 20, 22, 46, 48, 55, 60, 62 und 63, das jeweils mit Fehlercode (einem Wert ungleich 0) beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul schreibgeschützte Attribute nicht ändert, auch wenn sie mittels SET dazu aufgefordert wird.
DSRC_A0DA_BI02_0011	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein SET.rq für Attribute 16, 17, 18, 19, 20, 22, 46, 48, 55, 60, 62 und 63, das mit Fehlercode (einem Wert ungleich 0) beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul schreibgeschützte Attribute nicht ändert, auch wenn sie mittels SET dazu aufgefordert wird.
DSRC_A0DA_BI03_0011	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein SET.rq für Attribute 0, 24 und 32, das mit Fehlercode (einem Wert ungleich 0) beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul schreibgeschützte Attribute nicht ändert, auch wenn sie mittels SET dazu aufgefordert wird.
DSRC_A0DA_BI04_0011	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie jeweils ein SET.rq für Attribute 0, 24 und 32, das jeweils mit Fehlercode (einem Wert ungleich 0) beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul schreibgeschützte Attribute nicht ändert, auch wenn sie mittels SET dazu aufgefordert wird.
DSRC_A0DA_BI05_5010	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein gemeinsames SET.rq für Attribute 49, 50, 51, 52, 53, 61, 64, und ein weiteres gemeinsames SET.rq für die Attribute 99, 100 und 101, die mit Fehlercode beantwortet werden sollen.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul schreibgeschützte Attribute nicht ändert, auch wenn sie mittels SET dazu aufgefordert wird.
DSRC_A0DA_BI06_5010	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie jeweils ein SET.rq für Attribute 49, 50, 51, 52, 53, 61, 64, 99, 100 und 101, das mit Fehlercode beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul schreibgeschützte Attribute nicht ändert, auch wenn sie mittels SET dazu aufgefordert wird.
DSRC_A0DA_BI07_0011	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein GET.rq mit ungültigen accessCredentials für Attribute 24 und 32, das mit Fehlercode (einem Wert ungleich 0) beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul lesegeschützte Attribute nicht zurückgibt, wenn sie mittels GET dazu aufgefordert wird.
DSRC_A0DA_BI08_0011	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein GET.rq mit ungültigen accessCredentials für Attribute 16, 17, 18, 19, 20, 22, 46, 48, 55, 60, 62 und 63, das mit Fehlercode (einem Wert ungleich 0) beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul lesegeschützte Attribute nicht zurückgibt, wenn sie mittels GET dazu aufgefordert wird.
DSRC_A0DA_BI09_5010	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein gemeinsames GET.rq mit ungültigen accessCredentials für Attribute 49, 50, 51, 52, 53, 61, 64, und ein weiteres gemeinsames GET.rq mit ungültigen accessCredentials für die Attribute 99, 100 und 101, die mit Fehlercode beantwortet werden sollen.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul keine Attributwerte zurückgibt, wenn die AccessCredentials nicht korrekt sind.
DSRC_A0DA_BI10_0011	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein GET_STAMPED.rq mit ungültigen accessCredentials für Attribute 24 und 32, das mit Fehlercode (einem Wert ungleich 0) beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul lesegeschützte Attribute nicht zurückgibt, wenn sie mittels GET_STAMPED dazu aufgefordert wird.
DSRC_A0DA_BI11_0011	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein GET_STAMPED.rq mit ungültigen accessCredentials für Attribute 16, 17, 18, 19, 20, 22, 46, 48, 55, 60, 62 und 63, das mit Fehlercode (einem Wert ungleich 0) beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul lesegeschützte Attribute nicht zurückgibt, wenn sie mittels GET_STAMPED dazu aufgefordert wird.
DSRC_A0DA_BI12_5010	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein gemeinsames GET-STAMPED.rq mit ungültigen accessCredentials für Attribute 49, 50, 51, 52, 53, 61, 64, und ein weiteres gemeinsames GET-STAMPED.rq mit ungültigen accessCredentials für die Attribute 99, 100 und 101, die mit Fehlercode beantwortet werden sollen.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul keine Attributwerte zurückgibt, wenn die AccessCredentials nicht korrekt sind.
DSRC_A0DA_BV01_0011	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein GET.rq für Attribute 24 und 32, das ordnungsgemäß beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET-Befehl korrekt handhabt.
DSRC_A0DA_BV02_0011	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein GET.rq für Attribut 24, das ordnungsgemäß beantwortet werden soll. Dann sendet sie ein GET.rq für Attribut 32, das ordnungsgemäß beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET-Befehl korrekt handhabt.
DSRC_A0DA_BV03_0011	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein GET.rq für Attribute 16, 17, 18, 19, 20, 22, 46, 48, 55, 60, 62 und 63, das ordnungsgemäß beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET-Befehl korrekt handhabt.
DSRC_A0DA_BV04_0011	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie jeweils ein GET.rq für Attribute 16, 17, 18, 19, 20, 22, 46, 48, 55, 60, 62 und 63, das ordnungsgemäß beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET-Befehl korrekt handhabt.
DSRC_A0DA_BV05_5010	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein gemeinsames GET.rq für Attribute 49, 50, 51, 52, 53, 61, 64, und ein weiteres gemeinsames GET.rq für die Attribute 99, 100 und 101, die mit Fehlercode beantwortet werden sollen.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET-Befehl korrekt handhabt.
DSRC_A0DA_BV06_5010	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie jeweils ein GET.rq für Attribute 49, 50, 51, 52, 53, 61, 64, 99, 100 und 101, das ordnungsgemäß beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET-Befehl korrekt handhabt.
DSRC_A0DA_BV07_0011	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein GET_STAMPED.rq für Attribute 24 und 32, das ordnungsgemäß beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET_STAMPED-Befehl korrekt handhabt.
DSRC_A0DA_BV09_5010	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein gemeinsames GET-STAMPED.rq für Attribute 49, 50, 51, 52, 53, 61, 64, und ein weiteres gemeinsames GET-STAMPED.rq für die Attribute 99, 100 und 101, die mit Fehlercode beantwortet werden sollen.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET_STAMPED-Befehl korrekt handhabt.
DSRC_A0DA_BV10_0011	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein GET_STAMPED.rq für Attribute 16, 17, 18, 19, 20, 22, 46, 48, 55, 60, 62 und 63, das ordnungsgemäß beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET_STAMPED-Befehl korrekt handhabt.
DSRC_A0FU_BI02_0010	Die Bake führt vorab eine reguläre Initialisierungsphase durch, um die Bereitschaft der OBU zur Kommunikation zu überprüfen. Anschließend sendet sie je eine BST mit PDU-Nummern 0 und 1, die von der OBU nicht beantwortet werden sollen.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul PDU-Nummern korrekt erkennt.
DSRC_A0FU_BI03_0010	Die Bake führt eine reguläre Initialisierungsphase durch. Dann sendet sie je eine PDU mit mode=1 und flow control=7 und allen ungültigen Werten des Fragmentzählers, die von der OBU nicht beantwortet werden sollen. Abschließend sendet sie eine PDU mit mode=1 und flow control=7 und dem gültigen Wert des Fragmentzählers (0), die von der OBU beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul PDU-Fragmente korrekt erkennt.
DSRC_A0FU_BI04_0010	Die Bake sendet je eine BST mit allen ungültigen Werten des Fragmentzählers, die von der OBU nicht beantwortet werden sollen. Abschließend führt sie eine reguläre Initialisierung durch, um zu überprüfen, dass die OBU noch korrekt reagiert.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul PDU-Fragmente korrekt erkennt.
DSRC_A0FU_BI06_0010	Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie "chained" PDUs in einem Rahmen, von denen die erste einen Fehler erzeugen und die zweite mit "chaining error" beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul PDU-Nummern korrekt erkennt.
DSRC_A0FU_BV01_0011	Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein GET.rq für ein geeignetes Attribut, das ordnungsgemäß beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET-Befehl korrekt handhabt.
DSRC_A0FU_BV08_0010	Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein ACTION.rq mit mode=1 und FlowControl=7 (zum Beispiel ECHO), das ordnungsgemäß beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den ACTION-Befehl korrekt handhabt.
DSRC_A0FU_BV09_0010	Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein SET_MMI.rq mit mode=0 und FlowControl=4. Der Tester überprüft, ob die OBU das SET_MMI ausführt.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den ACTION-Befehl korrekt handhabt.
DSRC_A0FU_BV10_0010	Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein SET_MMI.rq mit mode=0 und FlowControl=1. Der Tester überprüft, ob die OBU das SET_MMI ausführt.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den ACTION-Befehl korrekt handhabt.
DSRC_A0FU_BV11_0010	Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein SET_MM.rq mit mode=0 und FlowControl=1 an die Broadcast-LID. Der Tester überprüft, ob die OBU das SET_MMI ausführt.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den ACTION-Befehl korrekt handhabt.
DSRC_A0FU_BV12_0010	Die Bake sendet ein SET_MMI.rq mit mode=0 und FlowControl=1 an die Broadcast-LID. Der Tester überprüft, ob die OBU das SET_MMI ausführt.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den ACTION-Befehl korrekt handhabt.
DSRC_A0FU_BV13_0010	Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie je ein ECHO.rq mit PDU number 2 bis 31, das jeweils ordnungsgemäß beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul PDU-Fragmente korrekt erkennt.
DSRC_A0FU_BV14_0010	Die Bake führt eine reguläre Initialisierungsphase durch, wobei die OBU Anwendungen für zwei ElementIDs !=0 (EID1, EID2) anmelden soll. Dann sendet sie ECHO.rq mit jeweils neuen Daten für EID1, EID2, EID1 und EID2, die jeweils ordnungsgemäß beantwortet werden sollen.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul in einer Transaktion PDUs für mehrere Elemente empfangen kann.
DSRC_A0FU_BV16_0010	Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie "concatenated" (nicht "chained") PDUs in einem Rahmen, die jeweils ordnungsgemäß in einem Rahmen beantwortet werden sollen.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul PDU-Fragmente korrekt erkennt.
DSRC_A0FU_BV17_0011	Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein GET.rq für ein geeignetes Attribut, das ordnungsgemäß beantwortet werden soll. Dann sendet sie ein GET.rq mit falschen AccessCredentials, das mit Fehlermeldung (ReturnStatus 1) beantwortet werden soll. Dann sendet sie jeweils ein GET.rq mit AttributeIdList mit nicht existierendem Attribut 31 und falscher EID, die jeweils mit Fehlermeldung (ReturnStatus !=0) beantwortet werden sollen.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET-Befehl korrekt handhabt.
DSRC_A0FU_BV19_0011	Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein GET_STAMPED.rq für ein geeignetes Attribut, das ordnungsgemäß beantwortet werden soll. Dann sendet sie jeweils ein GET_STAMPED.rq mit falschen AccessCredentials, das mit Fehlermeldung (ReturnStatus 1) beantwortet werden soll. Dann sendet sie jeweils ein GET_STAMPED.rq mit AttributeIdList mit nicht existierendem Attribut 31, falscher EID und ungültigem Wert für den keyRef-Parameter 19, die jeweils mit Fehlermeldung (ReturnStatus !=0) beantwortet werden sollen.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET_STAMPED-Befehl korrekt handhabt.
DSRC_A0FU_BV20_0010	Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein SET_MMI.rq mit mode=0 und flowControl=1, dessen Ausführung der Tester bestätigen soll. Dann sendet sie ein SET_MMI.rq mit mode=0 und flowControl=4, dessen Ausführung der Tester bestätigen soll und das von der OBU korrekt beantwortet werden soll. Zuletzt sendet sie ein SET_MMI.rq mit ungültigem ActionParameter, das mit Fehlermeldung (ReturnStatus !=0) beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den SET_MMI-Befehl korrekt handhabt.
DSRC_A0FU_BV21_0010	Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein ECHO.rq mit mode=0. Dann sendet sie ein ECHO.rq mit mode=1 und flowControl=7, das von der OBU korrekt beantwortet werden soll. Zuletzt sendet sie ein ECHO.rq mit ungültigem ActionParameter(hex. 11 01 20 04 12 34 56 78 70), das mit Fehlermeldung (ReturnStatus !=0) beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den ECHO-Befehl korrekt handhabt.
DSRC_A0SE_BV01_0010	Für diesen Testfall wird der keyRef-Wert 1 benutzt. Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein GET_STAMPED.rq für das Attribut 32, das regulär beantwortet werden soll. Dann sendet sie jeweils ein GET_STAMPED.rq mit ungültigen accesssCredentials, für ein ungültiges Attribut 31, für eine ungültige EID und mit ungültigem keyRef 19, die jeweils mit Fehlercode beantwortet werden sollen. Die Verwendung korrekter Authenticators ist Bestandteil der Testprüfung.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET_STAMPED-Befehl korrekt handhabt.
DSRC_A0SE_BV02_0010	Für diesen Testfall wird der keyRef-Wert 2 benutzt. Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein GET_STAMPED.rq für ein geeignetes Attribut 32, das regulär beantwortet werden soll. Dann sendet sie jeweils ein GET_STAMPED.rq mit ungültigen accesssCredentials, für ein ungültiges Attribut 31, für eine ungültige EID und mit ungültigem keyRef 19, die jeweils mit Fehlercode beantwortet werden sollen. Die Verwendung korrekter Authenticators ist Bestandteil der Testprüfung.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET_STAMPED-Befehl korrekt handhabt.
DSRC_A0SE_BV03_0010	Für diesen Testfall wird der keyRef-Wert 3 benutzt. Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein GET_STAMPED.rq für ein geeignetes Attribut 32, das regulär beantwortet werden soll. Dann sendet sie jeweils ein GET_STAMPED.rq mit ungültigen accesssCredentials, für ein ungültiges Attribut 31, für eine ungültige EID und mit ungültigem keyRef 19, die jeweils mit Fehlercode beantwortet werden sollen. Die Verwendung korrekter Authenticators ist Bestandteil der Testprüfung.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET_STAMPED-Befehl korrekt handhabt.
DSRC_A0SE_BV04_0010	Für diesen Testfall wird der keyRef-Wert 4 benutzt. Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein GET_STAMPED.rq für ein geeignetes Attribut 32, das regulär beantwortet werden soll. Dann sendet sie jeweils ein GET_STAMPED.rq mit ungültigen accesssCredentials, für ein ungültiges Attribut 31, für eine ungültige EID und mit ungültigem keyRef 19, die jeweils mit Fehlercode beantwortet werden sollen. Die Verwendung korrekter Authenticators ist Bestandteil der Testprüfung.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET_STAMPED-Befehl korrekt handhabt.
DSRC_A0SE_BV05_0010	Für diesen Testfall wird der keyRef-Wert 5 benutzt. Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein GET_STAMPED.rq für ein geeignetes Attribut 32, das regulär beantwortet werden soll. Dann sendet sie jeweils ein GET_STAMPED.rq mit ungültigen accesssCredentials, für ein ungültiges Attribut 31, für eine ungültige EID und mit ungültigem keyRef 19, die jeweils mit Fehlercode beantwortet werden sollen. Die Verwendung korrekter Authenticators ist Bestandteil der Testprüfung.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET_STAMPED-Befehl korrekt handhabt.
DSRC_A0SE_BV06_0010	Für diesen Testfall wird der keyRef-Wert 6 benutzt. Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein GET_STAMPED.rq für ein geeignetes Attribut 32, das regulär beantwortet werden soll. Dann sendet sie jeweils ein GET_STAMPED.rq mit ungültigen accesssCredentials, für ein ungültiges Attribut 31, für eine ungültige EID und mit ungültigem keyRef 19, die jeweils mit Fehlercode beantwortet werden sollen. Die Verwendung korrekter Authenticators ist Bestandteil der Testprüfung.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET_STAMPED-Befehl korrekt handhabt.
DSRC_A0SE_BV07_0010	Für diesen Testfall wird der keyRef-Wert 7 benutzt. Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein GET_STAMPED.rq für ein geeignetes Attribut 32, das regulär beantwortet werden soll. Dann sendet sie jeweils ein GET_STAMPED.rq mit ungültigen accesssCredentials, für ein ungültiges Attribut 31, für eine ungültige EID und mit ungültigem keyRef 19, die jeweils mit Fehlercode beantwortet werden sollen. Die Verwendung korrekter Authenticators ist Bestandteil der Testprüfung.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET_STAMPED-Befehl korrekt handhabt.
DSRC_A0SE_BV08_0010	Für diesen Testfall wird der keyRef-Wert 8 benutzt. Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein GET_STAMPED.rq für ein geeignetes Attribut 32, das regulär beantwortet werden soll. Dann sendet sie jeweils ein GET_STAMPED.rq mit ungültigen accesssCredentials, für ein ungültiges Attribut 31, für eine ungültige EID und mit ungültigem keyRef 19, die jeweils mit Fehlercode beantwortet werden sollen. Die Verwendung korrekter Authenticators ist Bestandteil der Testprüfung.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET_STAMPED-Befehl korrekt handhabt.
DSRC_A1BA_BI01_0010	Die Bake sendet eine BST mit einem profile 13 (hex D), das von der OBU/dem DSRC-Modul nicht unterstützt wird. Die OBU/das DSRC-Modul soll nicht antworten. Das wird wiederholt mit einem weiteren von der OBU nicht unterstützten profile 17 (hex 11) wiederholt.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul das Profil korrekt handhabt.
DSRC_A1BA_BI02_0010	Die Bake sendet BSTs für die von der OBU nicht unterstütze Anwendung 19 (hex 13) in der mandApplicationList und leerer nonmandApplicationList. Die OBU soll nicht antworten. Das wird wiederholt mit einer weiteren von der OBU nicht unterstützten Anwendung 31 (hex 1F) in der mandApplicationList und 19 in der nonmandApplicationList.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul applicationIds korrekt handhabt.
DSRC_A1BA_BI03_0011	Die Bake sendet BSTs für eine von der OBU/dem DSRC-Modul nicht unterstütze Anwendung 19 (hex 13) mit EID in der mandApplicationList und AID=20 in der nonmandApplicationList. Die OBU/das DSRC-modul soll nicht antworten.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul applicationIds korrekt handhabt.
DSRC_A1BA_BV01_0010	Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein ECHO.rq, das die OBU/das DSRC-Modul beantworten soll. Dann wiederholt sie ihre BST (evtl. mit neuer BeaconTime, wenn diese sich mittlerweile verändert hat), die die OBU nicht beantworten soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul die Initialisierung korrekt durchführt.
DSRC_A1BA_BV02_0010	Die Bake führt eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Anschließend sendet sie ein ECHO.rq, das die OBU beantworten soll, und zwei RELEASEs. Dann schickt sie ein weiteres ECHO, das die OBU nicht beantworten soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul die Initialisierung korrekt durchführt.
DSRC_A1BA_BV03_0010	Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein ECHO.rq, das die OBU beantworten soll. Der ganze Vorgang wird einmal wiederholt mit um 1 erhöhter manufacturerID in der BST und dann nochmals wiederholt mit der vorigen, erhöhten manufacturerID und um 1 erhöhter individualId der BST.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul die Initialisierung korrekt durchführt.
DSRC_A1BA_BV04_0010	Die Bake führt eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Anschließend sendet sie ein ECHO.rq, das die OBU beantworten soll. Der ganze Vorgang wird wiederholt, wobei die Beacon Time der BST um 256 Sekunden erhöht wird.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul die Initialisierung korrekt durchführt.
DSRC_A1BA_BV09_0010	Die Bake sendet eine BST mit einem profile 13 (hex D), das von der OBU nicht unterstützt wird. Die OBU soll nicht antworten. Das wird mit einem weiteren von der OBU nicht unterstützten profile 17 (hex 11) wiederholt.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul das Profil korrekt handhabt.
DSRC_A1BA_BV10_0010	Die Bake führt eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Die VST wird auf ein korrektes Format hin überprüft.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul die BST mit einer korrekten VST beantwortet.
DSRC_A1DA_BI01_0011	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie jeweils ein SET.rq für Attribute 16, 17, 18, 19, 20, 22, 46, 48, 55, 60, 62 und 63, das jeweils mit Fehlercode beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul schreibgeschützte Attribute nicht ändert, auch wenn sie mittels SET dazu aufgefordert wird.
DSRC_A1DA_BI02_0011	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein SET.rq für Attribute 16, 17, 18, 19, 20, 22, 46, 48, 55, 60, 62 und 63, das mit Fehlercode beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul schreibgeschützte Attribute nicht ändert, auch wenn sie mittels SET dazu aufgefordert wird.
DSRC_A1DA_BI03_0011	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein SET.rq für Attribute 0, 24 und 32, das mit Fehlercode beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul schreibgeschützte Attribute nicht ändert, auch wenn sie mittels SET dazu aufgefordert wird.
DSRC_A1DA_BI04_0011	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie jeweils ein SET.rq für Attribute 0, 24 und 32, das jeweils mit Fehlercode beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul schreibgeschützte Attribute nicht ändert, auch wenn sie mittels SET dazu aufgefordert wird.
DSRC_A1DA_BI05_5010	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein gemeinsames SET.rq für Attribute 49, 50, 51, 52, 53, 61, 64, und ein weiteres gemeinsames SET.rq für die Attribute 99, 100 und 101, die mit Fehlercode beantwortet werden sollen.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul schreibgeschützte Attribute nicht ändert, auch wenn sie mittels SET dazu aufgefordert wird.
DSRC_A1DA_BI06_5010	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie jeweils ein SET.rq für Attribute 49, 50, 51, 52, 53, 61, 64, 99, 100 und 101, das mit Fehlercode beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul schreibgeschützte Attribute nicht ändert, auch wenn sie mittels SET dazu aufgefordert wird.
DSRC_A1DA_BI07_0011	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein GET.rq mit ungültigen accessCredentials für Attribute 24 und 32, das mit Fehlercode beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul lesegeschützte Attribute nicht zurückgibt, wenn sie mittels GET dazu aufgefordert wird.
DSRC_A1DA_BI08_0011	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein GET.rq mit ungültigen accessCredentials für Attribute 16, 17, 18, 19, 20, 22, 46, 48, 55, 60, 62 und 63, das mit Fehlercode beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul lesegeschützte Attribute nicht zurückgibt, wenn sie mittels GET dazu aufgefordert wird.
DSRC_A1DA_BI09_5010	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein gemeinsames GET.rq mit ungültigen accessCredentials für Attribute 49, 50, 51, 52, 53, 61, 64, und ein weiteres gemeinsames GET.rq mit ungültigen accessCredentials für die Attribute 99, 100 und 101, die mit Fehlercode beantwortet werden sollen.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul keine Attributwerte zurückgibt, wenn die AccessCredentials nicht korrekt sind.
DSRC_A1DA_BI10_0011	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein GET_STAMPED.rq mit ungültigen accessCredentials für Attribute 24 und 32, das mit Fehlercode beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul lesegeschützte Attribute nicht zurückgibt, wenn sie mittels GET_STAMPED dazu aufgefordert wird.
DSRC_A1DA_BI11_0011	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein GET_STAMPED.rq mit ungültigen accessCredentials für Attribute 16, 17, 18, 19, 20, 22, 46, 48, 55, 60, 62 und 63, das mit Fehlercode beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul lesegeschützte Attribute nicht zurückgibt, wenn sie mittels GET_STAMPED dazu aufgefordert wird.
DSRC_A1DA_BI12_5010	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein gemeinsames GET-STAMPED.rq mit ungültigen accessCredentials für Attribute 49, 50, 51, 52, 53, 61, 64, und ein weiteres gemeinsames GET-STAMPED.rq mit ungültigen accessCredentials für die Attribute 99, 100 und 101, die mit Fehlercode beantwortet werden sollen.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul keine Attributwerte zurückgibt, wenn die AccessCredentials nicht korrekt sind.
DSRC_A1DA_BV01_0011	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein GET.rq für Attribute 24 und 32, das ordnungsgemäß beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET-Befehl korrekt handhabt.
DSRC_A1DA_BV02_0011	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein GET.rq für Attribut 24, das ordnungsgemäß beantwortet werden soll. Dann sendet sie ein GET.rq für Attribut 32, das ordnungsgemäß beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET-Befehl korrekt handhabt.
DSRC_A1DA_BV03_0011	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein GET.rq für Attribute 16, 17, 18, 19, 20, 22, 46, 48, 55, 60, 62 und 63, das ordnungsgemäß beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET-Befehl korrekt handhabt.
DSRC_A1DA_BV04_0011	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie jeweils ein GET.rq für Attribute 16, 17, 18, 19, 20, 22, 46, 48, 55, 60, 62 und 63, das ordnungsgemäß beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET-Befehl korrekt handhabt.
DSRC_A1DA_BV05_5010	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein gemeinsames GET.rq für Attribute 49, 50, 51, 52, 53, 61, 64, und ein weiteres gemeinsames GET.rq für die Attribute 99, 100 und 101, das ordnungsgemäß beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET-Befehl korrekt handhabt.
DSRC_A1DA_BV06_5010	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie jeweils ein GET.rq für Attribute 49, 50, 51, 52, 53, 61, 64, 99, 100 und 101, das ordnungsgemäß beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET-Befehl korrekt handhabt.
DSRC_A1DA_BV07_0011	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein GET_STAMPED.rq für Attribute 24 und 32, das ordnungsgemäß beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET_STAMPED-Befehl korrekt handhabt.
DSRC_A1DA_BV09_5010	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein gemeinsames GET-STAMPED.rq für Attribute 49, 50, 51, 52, 53, 61, 64, und ein weiteres gemeinsames GET-STAMPED.rq für die Attribute 99, 100 und 101, das ordnungsgemäß beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET_STAMPED-Befehl korrekt handhabt.
DSRC_A1DA_BV10_0011	Die Bake führt eine reguläre Initialisierungsphase für AID 20 durch. Anschließend sendet sie ein GET_STAMPED.rq für Attribute 16, 17, 18, 19, 20, 22, 46, 48, 55, 60, 62 und 63, das ordnungsgemäß beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET_STAMPED-Befehl korrekt handhabt.
DSRC_A1FU_BI02_0010	Die Bake führt vorab eine reguläre Initialisierungsphase durch, um die Bereitschaft der OBU zur Kommunikation zu überprüfen. Anschließend sendet sie je eine BST mit PDU-Nummern 0 und 1, die von der OBU nicht beantwortet werden sollen.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul PDU-Nummern korrekt erkennt.
DSRC_A1FU_BI03_0010	Die Bake führt eine reguläre Initialisierungsphase durch. Dann sendet sie je eine PDU mit mode=1 und flow control=7 und allen ungültigen Werten des Fragmentzählers, die von der OBU nicht beantwortet werden sollen. Abschließend sendet sie eine PDU mit mode=1 und flow control=7 und dem gültigen Wert des Fragmentzählers (0), die von der OBU beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul PDU-Fragmente korrekt erkennt.
DSRC_A1FU_BI04_0010	Die Bake sendet je eine BST mit allen ungültigen Werten des Fragmentzählers, die von der OBU nicht beantwortet werden sollen. Abschließend führt sie eine reguläre Initialisierung durch, um zu überprüfen, dass die OBU noch korrekt reagiert.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul PDU-Fragmente korrekt erkennt.
DSRC_A1FU_BI06_0010	Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie "chained" PDUs in einem Rahmen, von denen die erste einen Fehler erzeugen und die zweite mit "chaining error" beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul PDU-Nummern korrekt erkennt.
DSRC_A1FU_BV01_0011	Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein GET.rq für ein geeignetes Attribut, das ordnungsgemäß beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET-Befehl korrekt handhabt.
DSRC_A1FU_BV08_0010	Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein ACTION.rq mit mode=1 und FlowControl=7 (zum Beispiel ECHO), das ordnungsgemäß beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den ACTION-Befehl korrekt handhabt.
DSRC_A1FU_BV09_0010	Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein ACTION.rq mit mode=0 und FlowControl=4 (zum Beispiel SET_MMI). Der Tester überprüft, ob die OBU das SET_MMI ausführt.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den ACTION-Befehl korrekt handhabt.
DSRC_A1FU_BV10_0010	Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein ACTION.rq mit mode=0 und FlowControl=1 (zum Beispiel SET_MMI). Der Tester überprüft, ob die OBU das SET_MMI ausführt.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den ACTION-Befehl korrekt handhabt.
DSRC_A1FU_BV11_0010	Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein ACTION.rq mit mode=0 und FlowControl=1 (zum Beispiel SET_MMI) an die Broadcast-LID. Der Tester überprüft, ob die OBU das SET_MMI ausführt.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den ACTION-Befehl korrekt handhabt.
DSRC_A1FU_BV12_0010	Die Bake sendet ein ACTION.rq mit mode=0 und FlowControl=1 (zum Beispiel SET_MMI) an die Broadcast-LID. Der Tester überprüft, ob die OBU das SET_MMI ausführt.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den ACTION-Befehl korrekt handhabt.
DSRC_A1FU_BV13_0010	Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie je ein ECHO.rq mit PDU number 2 bis 31, das jeweils ordnungsgemäß beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul PDU-Fragmente korrekt erkennt.
DSRC_A1FU_BV14_0010	Die Bake führt eine reguläre Initialisierungsphase durch, wobei die OBU Anwendungen für zwei ElementIDs !=0 (EID1, EID2) anmelden soll. Dann sendet sie ECHO.rq mit jeweils neuen Daten für EID1, EID2, EID1 und EID2, die jeweils ordnungsgemäß beantwortet werden sollen.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul in einer Transaktion PDUs für mehrere Elemente empfangen kann.
DSRC_A1FU_BV16_0010	Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie "concatenated" (nicht "chained") PDUs in einem Rahmen, die jeweils ordnungsgemäß in einem Rahmen beantwortet werden sollen.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul PDU-Fragmente korrekt erkennt.
DSRC_A1FU_BV17_0011	Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein GET.rq für ein geeignetes Attribut, das ordnungsgemäß beantwortet werden soll. Dann sendet sie ein GET.rq mit falschen AccessCredentials, das mit Fehlermeldung (ReturnStatus 1) beantwortet werden soll. Dann sendet sie jeweils ein GET.rq mit AttributeIdList mit nicht existierendem Attribut 31 und falscher EID, die jeweils mit Fehlermeldung (ReturnStatus !=0) beantwortet werden sollen.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET-Befehl korrekt handhabt.
DSRC_A1FU_BV19_0011	Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein GET_STAMPED.rq für ein geeignetes Attribut, das ordnungsgemäß beantwortet werden soll. Dann sendet sie jeweils ein GET_STAMPED.rq mit falschen AccessCredentials, das mit Fehlermeldung (ReturnStatus 1) beantwortet werden soll. Dann sendet sie jeweils ein GET_STAMPED.rq mit AttributeIdList mit nicht existierendem Attribut 31, falscher EID und ungültigem Wert für den keyRef-Parameter 19, die jeweils mit Fehlermeldung (ReturnStatus !=0) beantwortet werden sollen.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET_STAMPED-Befehl korrekt handhabt.
DSRC_A1FU_BV20_0010	Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein SET_MMI.rq mit mode=0 und flowControl=1, dessen Ausführung der Tester bestätigen soll. Dann sendet sie ein SET_MMI.rq mit mode=0 und flowControl=4, dessen Ausführung der Tester bestätigen soll und das von der OBU korrekt beantwortet werden soll. Zuletzt sendet sie ein SET_MMI.rq mit ungültigem ActionParameter, das mit Fehlermeldung (ReturnStatus !=0) beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den SET_MMI-Befehl korrekt handhabt.
DSRC_A1FU_BV21_0010	Die Bake führt eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein ECHO.rq mit mode=0. Dann sendet sie ein ECHO.rq mit mode=1 und flowControl=7, das von der OBU korrekt beantwortet werden soll. Zuletzt sendet sie ein ECHO.rq mit ungültigem ActionParameter, das mit Fehlermeldung (ReturnStatus !=0) beantwortet werden soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den ECHO-Befehl korrekt handhabt.
DSRC_A1SE_BV01_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein GET_STAMPED.rq für ein geeignetes Attribut 32, das regulär beantwortet werden soll. Danach sendet sie jeweils ein GET_STAMPED.rq mit ungültigen accesssCredentials, für ein ungültiges Attribut 31, für eine ungültige EID und mit ungültigem keyRef 19, die jeweils mit Fehlercode beantwortet werden sollen. Für diesen Testfall wird der keyRef-Wert 1 benutzt.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET_STAMPED-Befehl korrekt handhabt.
DSRC_A1SE_BV02_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein GET_STAMPED.rq für ein geeignetes Attribut 32, das regulär beantwortet werden soll. Danach sendet sie jeweils ein GET_STAMPED.rq mit ungültigen accesssCredentials, für ein ungültiges Attribut 31, für eine ungültige EID und mit ungültigem keyRef 19, die jeweils mit Fehlercode beantwortet werden sollen. Für diesen Testfall wird der keyRef-Wert 1 benutzt.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET_STAMPED-Befehl korrekt handhabt.
DSRC_A1SE_BV03_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein GET_STAMPED.rq für ein geeignetes Attribut 32, das regulär beantwortet werden soll. Danach sendet sie jeweils ein GET_STAMPED.rq mit ungültigen accesssCredentials, für ein ungültiges Attribut 31, für eine ungültige EID und mit ungültigem keyRef 19, die jeweils mit Fehlercode beantwortet werden sollen. Für diesen Testfall wird der keyRef-Wert 3 benutzt.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET_STAMPED-Befehl korrekt handhabt.
DSRC_A1SE_BV04_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein GET_STAMPED.rq für ein geeignetes Attribut 32, das regulär beantwortet werden soll. Danach sendet sie jeweils ein GET_STAMPED.rq mit ungültigen accesssCredentials, für ein ungültiges Attribut 31, für eine ungültige EID und mit ungültigem keyRef 19, die jeweils mit Fehlercode beantwortet werden sollen. Für diesen Testfall wird der keyRef-Wert 4 benutzt.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET_STAMPED-Befehl korrekt handhabt.
DSRC_A1SE_BV05_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein GET_STAMPED.rq für ein geeignetes Attribut 32, das regulär beantwortet werden soll. Danach sendet sie jeweils ein GET_STAMPED.rq mit ungültigen accesssCredentials, für ein ungültiges Attribut 31, für eine ungültige EID und mit ungültigem keyRef 19, die jeweils mit Fehlercode beantwortet werden sollen. Für diesen Testfall wird der keyRef-Wert 5 benutzt.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET_STAMPED-Befehl korrekt handhabt.
DSRC_A1SE_BV06_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein GET_STAMPED.rq für ein geeignetes Attribut 32, das regulär beantwortet werden soll. Danach sendet sie jeweils ein GET_STAMPED.rq mit ungültigen accesssCredentials, für ein ungültiges Attribut 31, für eine ungültige EID und mit ungültigem keyRef 19, die jeweils mit Fehlercode beantwortet werden sollen. Für diesen Testfall wird der keyRef-Wert 6 benutzt.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET_STAMPED-Befehl korrekt handhabt.
DSRC_A1SE_BV07_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein GET_STAMPED.rq für ein geeignetes Attribut 32, das regulär beantwortet werden soll. Danach sendet sie jeweils ein GET_STAMPED.rq mit ungültigen accesssCredentials, für ein ungültiges Attribut 31, für eine ungültige EID und mit ungültigem keyRef 19, die jeweils mit Fehlercode beantwortet werden sollen. Für diesen Testfall wird der keyRef-Wert 7 benutzt.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET_STAMPED-Befehl korrekt handhabt.
DSRC_A1SE_BV08_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase durch. Anschließend sendet sie ein GET_STAMPED.rq für ein geeignetes Attribut 32, das regulär beantwortet werden soll. Danach sendet sie jeweils ein GET_STAMPED.rq mit ungültigen accesssCredentials, für ein ungültiges Attribut 31, für eine ungültige EID und mit ungültigem keyRef 19, die jeweils mit Fehlercode beantwortet werden sollen. Für diesen Testfall wird der keyRef-Wert 8 benutzt.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul den GET_STAMPED-Befehl korrekt handhabt.
DSRC_LLC__BI01_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake BSTs für AIDs 1, 20 und 21, bei der die beiden Füllbits im LLC-Kontrollfeld auf die ungültigen Werte 00, 01 und 10 gesetzt sind. Die OBU soll nicht antworten. Anschließend wird mit einer normalen BST überprüft, ob die OBU korrekt reagiert.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen mit falsch gesetzten Füllbits im LLC-Kontrollfeld erkennt und ignoriert.
DSRC_LLC__BI02_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Anschließend sendet sie einen ECHO-Befehl, bei dem ein halbes Byte entfernt wird. Die OBU soll nicht reagieren. Anschließend wird mit einem korrekten ECHO-Befehl überprüft, ob die OBU noch korrekt reagiert.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen mit nicht ganzzahliger Anzahl von Bytes erkennt und ignoriert.
DSRC_LLC__BI03_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Anschließend sendet sie ECHO-Befehle mit P-Bit=1, aber allen ungültigen Werten der modifier-Bits. Die OBU soll nicht reagieren. Dann sendet sie ECHO-Befehle mit P-Bit=1, aber allen ungültigen Werten der reserved-Bits. Die OBU soll nicht reagieren. Abschließend wird mit einem korrekten ECHO-Befehl überprüft, ob die OBU noch korrekt reagiert.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen mit ungültigen modifier- und reserved-Bits im LLC-Kontrollfeld erkennt und ignoriert.
DSRC_LLC__BI04_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Anschließend sendet sie ein ECHO.rq mit der LID 0xFF, das die OBU nicht beantworten soll. Danach sendet sie ECHO.rq an alle Multicast-LIDs, die die OBU ebenfalls nicht beantworten soll. Nach jedem ungültigen Rahmen wird mit einem gültigen ECHO.rq an die OBU überprüft, ob sie noch auf valide ACn-Befehle reagiert.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul ACn-Rahmen mit Broadcast- oder Multicast-LID ignoriert.
DSRC_LLC__BI05_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake BSTs für AIDs 1, 20 und 21, bei der in der Nachricht ein halbes Byte fehlt. Die OBU soll nicht antworten. Anschließend wird mit einer normalen BST überprüft, ob die OBU korrekt reagiert.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen mit nicht ganzzahliger Anzahl von Bytes erkennt und ignoriert.
DSRC_LLC__BI06_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Anschließend sendet sie ein ECHO.rq mit P-Bit im LLC-Kontrollfeld=1, aber ohne LSDU, der von der OBU ignoriert werden soll. Abschließend wird mit einem gültigen ECHO.rq an die OBU überprüft, ob sie noch auf valide ACn-Befehle reagiert.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul ACn-Befehle mit p-Bit=1, aber ohne LSDU ignoriert.
DSRC_LLC__BI07_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Anschließend sendet sie ein ECHO.rq, das von der OBU beantwortet werden soll. Die Bake wiederholt das ECHO.rq unverändert und erwartet die gleiche Antwort wie vorher. Danach sendet die Bake einen ECHO.rq mit invertiertem n-Bit und anderen ECHO-Daten und erwartet eine korrekte Antwort auf den neuen Befehl.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul doppelt ACn-Befehle korrekt verarbeitet.
DSRC_LLC__BV01_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Das P-Bit im LLC-Kontrollfeld der VST soll den Wert 0 haben.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul UI-Befehle austauschen kann.
DSRC_LLC__BV02_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Danach sendet sie ein SET_MMI.rq als AC0-Befehl; als Antwort wird eine AC1-Antwort mit Final-Bit=0 und status subfield=NR_OK erwartet. Dann sendet die Bake ein SET_MMI.rq als AC1-Befehl; als Antwort wird eine AC0-Antwort mit Final-Bit=0 und status subfield=NR_OK erwartet.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul ACn-Befehle empfangen kann.
DSRC_LLC__BV03_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Danach sendet sie ein ECHO.rq als AC0-Befehl; als Antwort wird eine AC1-Antwort mit Final-Bit=1 und status subfield=OK_OK erwartet. Dann sendet die Bake ein ECHO.rq als AC1-Befehl; als Antwort wird eine AC0-Antwort mit Final-Bit=1 und status subfield=OK_OK erwartet.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul ACn-Befehle austauschen kann.
DSRC_LLC__BV05_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Dann sendet sie einen ACn-Befehl, der dazu führt, dass die OBU die late response-Prozedur ausführt. Als Antwort wird ein Rahmen mit LLC status subfield=NE_OK erwartet. Die Bake wiederholt BSTs, bis die angenommene Verarbeitungsdauer der OBU abgelaufen ist, und erwartet dann ein private window request. Die Bake sendet ein private window response und erwartet die Antwort auf den ACn-Befehl in einem UI-Rahmen.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul die late response-prozedur I korrekt durchführt.
DSRC_MAC__BI01_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21, bei der in der Nachricht zwei Bitfehler auftreten. Die OBU soll nicht antworten. Anschließend wird mit einer ungestörten BST überprüft, ob die OBU korrekt reagiert.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen mit zweifachem Bitfehler in der Nachricht ignoriert.
DSRC_MAC__BI02_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21, bei der in der FCS zwei Bitfehler auftreten. Die OBU soll nicht antworten. Anschließend wird mit einer ungestörten BST überprüft, ob die OBU korrekt reagiert.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen mit zweifachem Bitfehler in der FCS ignoriert.
DSRC_MAC__BI03_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21, bei der in der Nachricht 15 aufeinanderfolgende Bit invertiert werden. Die OBU soll nicht antworten. Anschließend wird mit einer ungestörten BST überprüft, ob die OBU korrekt reagiert.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen mit 15 konsekutiven Bitfehlern in der Nachricht ignoriert.
DSRC_MAC__BI04_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21, bei der das Einfügen der 0-Bits unterbleibt. Die OBU soll nicht antworten. Anschließend wird mit einer ungestörten BST überprüft, ob die OBU korrekt reagiert.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen ohne 0-Bit insertion in der LID ignoriert.
DSRC_MAC__BI05_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21, bei der das end flag durch ein Abort-Byte ersetzt wird. Die OBU soll nicht antworten. Anschließend wird mit einer ungestörten BST überprüft, ob die OBU korrekt reagiert.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen mit einem Abort-Byte anstelle der end flag ignoriert.
DSRC_MAC__BI06_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21, bei der die ProfileList so lang ist, dass die maximal erlaubte Rahmenlänge (128 Bytes incl. Flags und FCS) überschritten wird. Die OBU soll nicht antworten.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul Rahmen erkennt und ignoriert, die länger als die vom Standard erlaubten 128 Byte (incl. Flags und FCS) sind.
DSRC_MAC__BI07_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Anschließend sendet sie privateWindowRequests, bei der die LID 5 statt der vorgesehenen 4 Byte lang ist und bei der die ersten 4 der 5 Byte der LID der OBU entsprechen. Zuletzt wird überprüft, ob die OBU noch auf valide window allocations reagiert.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul eine falsche LID erkennt und ignoriert.
DSRC_MAC__BI08_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Anschließend sendet sie privateWindowRequests ohne MAC-Kontrollfeld. Zuletzt wird überprüft, ob die OBU noch auf valide window allocations reagiert.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen ohne MAC-Kontrollfeld erkennt und ignoriert.
DSRC_MAC__BI09_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21, bei der das A-Bit im MAC-Kontrollfeld auf 0 gesetzt ist. Die OBU soll nicht antworten. Anschließend wird mit einer normalen BST überprüft, ob die OBU korrekt reagiert.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul das A-Bit im MAC-Kontrollfeld beachtet.
DSRC_MAC__BI10_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21, bei der das D-Bit im MAC-Kontrollfeld auf 1 gesetzt ist. Die OBU soll nicht antworten. Anschließend wird mit einer normalen BST überprüft, ob die OBU korrekt reagiert.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul in der BST das D-Bit im MAC-Kontrollfeld beachtet.
DSRC_MAC__BI11_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21 und erwartet ein private window request. Danach sendet sie ein private window allocation, bei dem das D-Bit im MAC-Kontrollfeld auf 1 gesetzt ist. Die OBU soll nicht antworten. Anschließend wird mit einem korrekten private window allocation überprüft, ob die OBU korrekt reagiert.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul in privaten Rahmen das D-Bit im MAC-Kontrollfeld beachtet.
DSRC_MAC__BI12_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21, bei der das L-Bit im MAC-Kontrollfeld auf 0 gesetzt ist. Die OBU soll nicht antworten. Anschließend wird mit einer normalen BST überprüft, ob die OBU korrekt reagiert.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen mit falsch gesetztem L-Bit im MAC-Kontrollfeld erkennt und ignoriert.
DSRC_MAC__BI13_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21 und erwartet ein private window request. Danach sendet sie ein private window allocation, bei dem das L-Bit im MAC-Kontrollfeld auf 1 gesetzt ist. Die OBU soll nicht antworten. Anschließend wird mit einem korrekten private window allocation überprüft, ob die OBU korrekt reagiert.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen mit falsch gesetztem L-Bit im MAC-Kontrollfeld erkennt und ignoriert.
DSRC_MAC__BI14_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21 und erwartet ein private window request. Danach sendet sie ein private window allocation, bei dem das C/R-Bit im MAC-Kontrollfeld auf 1 gesetzt ist. Die OBU soll nicht antworten. Anschließend wird mit einem korrekten private window allocation überprüft, ob die OBU korrekt reagiert.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen mit falsch gesetztem C/R-Bit im MAC-Kontrollfeld erkennt und ignoriert.
DSRC_MAC__BI15_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21 und erwartet ein private window request. Danach sendet sie ein private window allocation, bei dem die Füllbits im MAC-Kontrollfeld auf 1 gesetzt sind. Die OBU soll nicht antworten. Anschließend wird mit einem korrekten private window allocation überprüft, ob die OBU korrekt reagiert.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen mit falsch gesetzten Füllbits im MAC-Kontrollfeld erkennt und ignoriert.
DSRC_MAC__BI16_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21, bei der das Radiosignal über 15 zusammenhängende Bit unterdrückt wird. Die OBU soll nicht antworten. Anschließend wird mit einer ungestörten BST überprüft, ob die OBU korrekt reagiert.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen mit einer Funkstörung über 15 zusammenhängende Bit ignoriert.
DSRC_MAC__BI17_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21, bei der das Radiosignal während der start flag unterdrückt wird. Die OBU soll nicht antworten. Anschließend wird mit einer ungestörten BST überprüft, ob die OBU korrekt reagiert.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen mit einer Funkstörung während der start flag ignoriert.
DSRC_MAC__BI18_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21, bei der das Radiosignal während der end flag unterdrückt wird. Die OBU soll nicht antworten. Anschließend wird mit einer ungestörten BST überprüft, ob die OBU korrekt reagiert.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen mit einer Funkstörung während der end flag ignoriert.
DSRC_MAC__BI19_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21 und erwartet ein private window request. Danach sendet sie ein private window allocation mit der LID 0xFF. Die OBU soll nicht antworten. Anschließend wird mit einem korrekten private window allocation überprüft, ob die OBU korrekt reagiert.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen mit der Broadcast-LID anstelle der privaten ignoriert.
DSRC_MAC__BI20_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21 und erwartet ein private window request. Dann sendet sie ein private window allocation mit einer Multicast-LID. Die OBU soll nicht antworten. Anschließend wird mit einem korrekten private window allocation überprüft, ob die OBU korrekt reagiert.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul einen Rahmen mit einer Multicast-LID anstelle der privaten ignoriert.
DSRC_MAC__BI21_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21 und erwartet ein private window request. Danach sendet sie ein private window allocation, bei dem das A-Bit im MAC-Kontrollfeld auf 0 gesetzt ist. Die OBU soll nicht antworten. Anschließend wird mit einem korrekten private window allocation überprüft, ob die OBU korrekt reagiert.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul in privaten Rahmen das A-Bit im MAC-Kontrollfeld beachtet.
DSRC_MAC__BI22_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und FIXME LA durch. Anschließend sendet sie einen ACn-Befehl, wobei das A-Bit des Rahmens auf 0 gesetzt wird. Zuletzt wird mit einem ACn-Befehl mit korrektem A-Bit überprüft, ob die OBU noch korrekt reagiert.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul in privaten Rahmen das A-Bit im MAC-Kontrollfeld beachtet.
DSRC_MAC__BI23_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21 und erwartet ein private window request. Dann sendet sie ein private window allocation mit gültiger, aber von der LID des private windows request abweichender LID. Die OBU soll nicht antworten. Anschließend wird mit einem korrekten private window allocation überprüft, ob die OBU korrekt reagiert.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul in privaten Rahmen die LID beachtet.
DSRC_MAC__BI24_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21 und erwartet ein private window request. Die Bake ignoriert das window request und wiederholt die BST. Die OBU soll ihr private window request wiederholen.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul private window requests korrekt wiederholt.
DSRC_MAC__BV01_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21, bei der die ProfileList so lang ist, dass die maximal erlaubte Rahmenlänge (128 Bytes incl. Flags und FCS) erreicht wird. Die OBU soll mit einem private window request antworten.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul auch DSRC-Rahmen der durch den Standard festgelegten Maximallänge korrekt verarbeiten kann.
DSRC_MAC__BV02_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Anschließend sendet sie T1 nach dem Ende der VST ein ECHO.rq. Eine Antwort der OBU wird erwartet.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul auch DSRC-Rahmen verarbeiten kann, die im vom Standard erlaubten zeitlichen Mindestabstand versendet wurden.
DSRC_MAC__BV03_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21 und erwartet ein private window request. Das wird X male wiederholt und dann ausgewetet, ob die window requests zeitlich im erlaubten Bereich lagen.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul jedes der drei public uplink windows benutzt.
DSRC_MAC__BV04_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Anschließend sendet sie ein SET_MMI.rq ohne window allocation und dann unmittelbar im zeitlichen Abstand von T2 eine neue BST. Eine Antwort der OBU wird erwartet.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul auch DSRC-Rahmen verarbeiten kann, die im vom Standard erlaubten zeitlichen Mindestabstand versendet wurden.
DSRC_MAC__BV05_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Dabei wird die Zeit zwischen dem Ende des end flag des private window allocation und dem ersten Bit der Präambel der VST sowie dem Ende des letzten Bit der end flag der VST gemessen. Beide Werte sollen die Vorgaben aus dem Standard einhalten.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul bei privaten Rahmen das vom Standard vorgegebene Timing einhält.
DSRC_MAC__BV06_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Die Bake ignoriert die VST und sendet ein private window allocation mit dem gleichen S-Bit wie beim vorigen window allocation. Es wird erwartet, dass die OBU mit einer VST antwortet.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul das S-Bit und das L-Bit des MAC-Kontrollfeldes korrekt verarbeitet und Wiederholungen der VST korrekt verarbeiten kann.
DSRC_MAC__BV07_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch. Anschließend sendet die Bake ein ECHO mit ECHO_DATA1 und erwartet ein ECHO.rs mit ECHO_DATA1. Dann sendet die Bake ein ECHO mit ECHO_DATA2 und dem gleichen Wert des s-Bits wie zuvor und erwartet ein ECHO.rs mit ECHO_DATA2. Dann sendet die Bake ein private window allocation mit dem gleichen Wert des S-Bit und erwartet ein ECHO.rs mit ECHO_DATA2.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul das S-Bit und das L-Bit des MAC-Kontrollfeldes bei Rahmen mit LPDU korrekt verarbeitet.
DSRC_MAC__BV08_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake eine BST für AIDs 1, 20 und 21 und erwartet ein private window request. Das wird X male wiederholt und dann ausgewertet, ob die private window requests gleichmäßig benutzt wurden.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul jedes der drei public uplink windows benutzt.
DSRC_MAC__BV09_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake eine reguläre Initialisierungsphase für AIDs 1, 20 und 21 durch, wobei das C/R-Bit des private window allocation auf 1 gesetzt wird. Anschließend sendet die Bake ein private window request mit C/R=0 und gleichem S-Bit wie vorher. Die OBU soll eine VST schicken.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul beide gültigen Werte des C/R-Bit des MAC-Kontrollfeldes eines private window requests korrekt verarbeitet.
DSRC_SFXX_2CCC_5010	Die Bake wird für CCC:2019 (SST301 v3.1) konfiguriert. Wenn sich die OBU anmeldet, muss diese in der VST alle ContextMarks anzeigen, die sie für CCC unterstützt. Die Bake führt die Transaktion dann mit der EID der gültigen CCC:2019 (SST301 v3.1) ContextMark durch. In einem zweiten Durchlauf wird die Bake für CCC:2015 (SST301 v2.2) konfiguriert. Wenn sich die OBU anmeldet, muss diese in der VST alle ContextMarks anzeigen, die sie für CCC unterstützt. Die Bake führt die Transaktion dann mit der EID der gültigen CCC:2015 (SST301v2.2) ContextMark durch.	Dieser Testfall soll sicherstellen, dass EETS-OBUs, die in der VST CCC:2015 und CCC:2019 anbieten, in beiden Versionen eine CCC-Transaktion erfolgreich durchführen können. In Anlehnung an die Bitfehlerraten-Tests der EN300674-2-2 werden in diesem Labortest die Übertragungssicherheit im stabilen Laboraufbau überprüft.
DSRC_SFXX_ABAA_5010	– Die Bake wird so konfiguriert, dass ausschließlich die Contextmark für CCC:2019 (SST301 v3.1) für die Transaktion benutzt wird. – Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob die OBU/das DSRC- Modul kommunikationsbereit ist. – Die folgenden Schritte werden 10x wiederholt: – Der Tester wird aufgefordert, den Wert der Achszahl auf einen neuen Wert einzustellen und bestätigt die Einstellung. – Zwei CCC:2019(SST301 v3.1)-Transaktionen werden durchgeführt mit einem zeitlichen Abstand von mehr als 15 Sekunden. – Die Transaktionsdaten werden aus der Bake ausgelesen. – Das Log wird am Ende der 10 Testwiederholungen bezüglich der achszahlbezogenen Attribute (19, 17, 46, 48, 62) ausgewertet, wobei jede zweite Transaktion berücksichtigt wird.	Es soll nachgewiesen werden, dass das DUT alle von der eingestellten Achszahl (Attribut 19) abhängigen Attribute (17, 46, 48, 62) gleichzeitig ändert und so die Datenkonsistenz gewährleistet ist, wenn der Nutzer eine andere Achszahl einstellt. Somit wird erwartet, dass sich eine Achszahländerung im Bereich der Kommunikationszone der Bake sich auf alle betroffenen Attribute gleichzeitig ausgewirkt hat. Dieser Test wurde im Review CEN-TC278-WG1_N2610_2_ ISO_DIS_13143-1_ Commenting_Form- Response als sinnvoll angesehen, konnte jedoch noch nicht in den normativen Testfallkatalog aufgenommen werden, weil hierfür noch keine direkte Anforderung in der 12813 besteht. Für das BALM ist dieser Test jedoch notwendig, da inkonsistente Daten eine Beweissicherung erschweren wurden.
DSRC_SFXX_ALAT_5010	– Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit ist. – Die Bake wird für eine CCC:2019(SST301 v3.1)-Transaktion in der Form konfiguriert, dass jedes Attribut einzeln durch ein Get.rq abgefragt wird. – Nach der Attribute Abfrage wird die Bakenübertragung angehalten. – Die Transaktionsdaten werden aus der Bake ausgelesen. – Das Log wird bezüglich der Attribute entsprechend den Attributsformaten im Standard, der Wert gemäß den Vorgaben vom Einzeldokument 4.3.1 V3.1 und bzgl. der Identifkationsdaten der VST ausgewertet.	Es soll geprüft werden, dass das DUT alle der für CCC (ISO 12813:2019 und Anlage 2 Einzeldokument 4.3.1 V3.1, Stand: 09.06.2022) erforderlichen Attribute (0, 16, 17, 18, 19, 20, 22, 24, 32, 46, 48, 49, 50, 51, 52, 53, 55, 60, 61, 62, 63, 64, 99, 100, 101) unterstützt. Weiterhin sollen die Identifikationsdaten des Moduls aus der VST ermittelt werden, die aus den Parametern CCC-ContextMark, ManufacturerID und EquipmentClass bestehen. Dieses ist ein modifizierter Normtestfall (TP/AP-BAS/OBU/BV/10 und TP/AP-DAT/OBU/BV/04 der Norm CCC ISO_TS_13143-1:2020) zur Dokumentation der DUT-Identifikations- und Attributedaten.
DSRC_SFXX_AWKT_0010	Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit sind. • Die Bake sendet danach eine neue BST mit der neuen Beacon-ID (1) und erwartet ein private Windows.req vom DUT. • Danach pausiert die Bake für 95 ms. • Dann sendet die Bake eine zweite BST mit einer neuen Beacon-ID (2) und erwartet wieder ein private Windows.req vom DUT. • Die Dauer ab der BST mit Beacon-ID (1) bis zum private window request nach der BST mit Beacon-ID (2) wird gemessen.	Es soll nachgewiesen werden, dass die Dauer vor dem Umschalten in den Energiesparmodus und damit die AwakeT-Dauer des DUTs >100ms beträgt. Dieser Test erfolgt als Labortest zur Verifizierung der Anforderungen im Kapitel Interlayer Management nach Einzeldokument 4.3.1 Version 3.1 (Stand: 09.06.2022).
DSRC_SFXX_BCKT_5010	Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit ist. Danach wird eine vollständige CCC:2019(SST301 v3.1)-Transaktion mit dem DUT mit einer neuen Beacon-ID (1) und einem abschließenden Release (1) der Bake durchgeführt. Dann sendet Bake BSTs im Abstand von 50 ms mit einer neuen Beacon-ID (2). Es wird die Zeit zwischen dem Release (1) und dem ersten darauffolgenden private window request ermittelt.	Es soll nachgewiesen werden, dass die Dauer des BlockingTimer des DUT nicht größer als 3 Sekunden ist. Dieser Test erfolgt als Labortest zur Verifizierung der Anforderungen im Kapitel Interlayer Management nach Einzeldokument 4.3.1 Version 3.1 (Stand: 09.06.2022).
DSRC_SFXX_BCKT_5011	Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit ist. Danach wird eine vollständige CCC-Transaktion mit dem DUT mit einer neuen Beacon-ID (1) und einem abschließenden Release (1) der Bake durchgeführt. Dann sendet Bake BSTs im Abstand von 50 ms mit einer neuen Beacon-ID (2). Es wird die Zeit zwischen dem Release (1) und dem privaten Windows.req auf die BST mit der Beacon-ID (2) ermittelt.	Es soll nachgewiesen werden, dass die Dauer des BlockingTimer des DUT nicht größer als 5 Sekunden ist.
DSRC_SFXX_BLIM_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann sendet die Bake 200 Mal eine BST und registriert, ob die OBU bis zuletzt mit einem private window request antwortet.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul alle empfangenen BSTs richtig auswertet.
DSRC_SFXX_BV02_0001	• Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit ist. • Für den eigentlichen Testfall wird eine Initialisierung (BST-VST) mit einer neuen BeaconID und einem anschließenden EVENT-REPORT.request(RELEASE) mit Mode=0 und FlowControl=1 konfiguriert und aktiviert. • Danach wird mit der gleichen LID ein ECHO.rq Command mit Poll Bit = 0 und ohne Nutzdaten gesendet und überprüft, ob die OBU/das DSRC Modul wider Erwarten noch reagiert.	Es soll nachgewiesen werden, dass das DUT den RELEASE-Befehl mit einem ECHO.rq korrekt verarbeitet. Der Testfall ist abgeleitet aus dem CCC ISO_TS_13143-1:2020-11 Normtestfall TP/AP-BAS/OBU/BV/02 (ECHO.rq mit Poll Bit=0, siehe ISO TS-13143-1).
DSRC_SFXX_BV02_0002	• Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit ist. • Für den eigentlichen Testfall wird eine Initialisierung (BST-VST) mit einer neuen Beacon-ID und einem anschließenden EVENT-REPORT.request(RELEASE) mit Mode=0 und FlowControl=1 konfiguriert und aktiviert. • Danach wird mit der gleichen BST gesendet und überprüft, ob das DUT wider Erwarten reagiert. • Anschließend wird nach 5s erneut die gleiche BST wiederholt und überprüft, ob das DUT wider Erwarten reagiert.	Es soll nachgewiesen werden, dass das DUT den RELEASE-Befehl mit derselben BST korrekt verarbeitet. Der Testfall ist abgeleitet aus dem CCC ISO_TS_13143-1:2020-11 Normtestfall TP/AP-BAS/OBU/BV/02 (ECHO.rq mit Poll Bit=0, siehe ISO TS-13143-1). (Sofortiges RELEASE).
DSRC_SFXX_BV02_0003	• Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit ist. • Für den eigentlichen Testfall wird eine Initialisierung (BST-VST) mit einer neuen Beacon-ID durchgeführt, ein ECHO.rq (Poll Bit=1) gesendet, das beantwortet werden soll, und anschließend mit einem EVENT-REPORT.request(RELEASE) mit Mode=0 und FlowControl=1 die Transaktion abgeschlossen. • Danach wird die gleiche BST wiederholt und überprüft, ob das DUT wider Erwarten reagiert. • Anschließend wird nach 5s erneut die gleiche BST wiederholt und überprüft, ob das DUT wider Erwarten reagiert. • Die Transaktionsdaten werden aus der Bake ausgelesen und ausgewertet.	Es soll nachgewiesen werden, dass das DUT den RELEASE-Befehl mit ECHO.rq (Poll Bit=1) korrekt verarbeitet. Der Testfall ist abgeleitet aus dem CCC ISO_TS_13143-1:2020-11 Normtestfall TP/AP-BAS/OBU/BV/02 (ECHO.rq mit Poll Bit=1: Initialisation, private ACn, RELEASE, Initialisationsversuch).
DSRC_SFXX_BV04_0010	Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit ist. • Für den eigentlichen Testfall wird eine Initialisierung (BST-VST) mit einer neuen Beacon-ID mit mode=1 und FlowControl=2 konfiguriert und aktiviert. • Danach sendet die Bake ein ECHO.rq Befehl, welcher von der OBU beantwortet werden soll. • Nach 256 Sekunden sendet die Bake erneut eine BST mit gleicher Beacon-ID mit mode=1 und FlowControl=2, die von der OBU mit einer neuen LID (und in der Folge VST) wieder beantwortet werden soll.	Es soll geprüft werden, dass das DUT den Parameter beaconTime der BST nach 256s korrekt handhabt. Der Testfall ist abgeleitet aus dem CCC ISO_TS_13143-1:2020-11 Normtestfall TP/AP-BAS/OBU/BV/04.
DSRC_SFXX_D003_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann führt die Bake Transaktionen mit zeitlichen Unterbrechungen und Übertragungswiederholungen durch.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul korrekte Kontrollfeldkombinationen benutzt.
DSRC_SFXX_DLAY_0010	Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit ist. • Dann führt die Bake eine Initialisierung (BST-VST) mit einer neuen Beacon-ID durch. • Danach sendet die Bake ein ECHO.rq, für das eine Antwort erwartet wird. Dieser ECHO.rq wird mit einer um 0.1 ms wachsenden Pause wiederholt bis eine Pause von 1s erreicht wird. • Wenn die OBU alle ECHO.rq beantwortet hat, ist der Testfall bestanden.	Es soll nachgewiesen werden, dass das DUT auch bei unterschiedlich langen Pausen, wie sie bei schwachen Funkbedingungen üblich sind, kommunikationsbereit bleibt. Dieser Test erfolgt als Labortest in Anlehnung an die Testspezifikation ISO/TS 14907-1:2015 Table B7-Traffic Conditions-Shadowing.
DSRC_SFXX_HISX_5010	– Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit ist. – Der Benutzer wird aufgefordert den Zustand des DUTs (Go-1) einzustellen (an Stromversorgung angeschlossen, GNSS und Mobilfunk verfügbar, MMI zeigt Betriebsbereitschaft an). – Die Bake führt eine CCC-Transaktion durch. Aus dem Transaktionslog werden die Attribute 53, 61, 99 und 100 zur Auswertung ausgelesen. – Der Benutzer wird aufgefordert für 5 Minuten das DUT in eine abgeschirmte Kammer mit angeschlossener Stromversorgung abzulegen. (Kein GNSS und Mobilfunk verfügbar). – Der Benutzer wird aufgefordert das DUT aus der abgeschirmten Kammer rauszunehmen und 5 Minuten zu warten (bis es GNSS bereit ist). – Die Bake führt eine CCC-Transaktion durch. Aus dem Transaktionslog werden die Attribute 53, 61, 99 und 100 zur Auswertung ausgelesen. Es wird erwartet, dass der Zustand in Go-1 erreicht ist. Akzeptanzkriterium ist, dass – die zuvor aktuellsten zwei Einträge zwei Positionen weitergerückt sind, – der aktuellste Eintrag einen Zeitstempel hat, der weniger als 6 Minuten alt und der Zustand Go-1 ist. – der zweite aktuellste Eintrag einen Zeitstempel hat, der weniger als 11 Minuten alt und der Zustand noGo-0 ist. – Der Benutzer wird aufgefordert für 5 Minuten die Stromversorgung abzuziehen. – Die Bake führt eine CCC-Transaktion durch. Aus dem Transaktionslog werden die Attribute 53, 61, 99 und 100 zur Auswertung ausgelesen. Es wird erwartet, dass der Zustand in noGoUserSwitchOff-3 erreicht ist. Akzeptanzkriterium ist, dass –
DSRC_SFXX_HNG1_0010	Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit ist. • Dann führt die Bake erneut eine Initialisierung (BST-VST) mit einer neuen Beacon-ID mit dem DUT durch. • Die Bake sendet ein GET_STAMPED.rq mit einer anderen LID für das Attribut 32, das mit einem GET_STAMPED.rq für die Attribute 24, 16, 19, 55, 22, 17, 61, 62 verkettet ist, das DUT darf nicht darauf reagieren. • Die Bake sendet ein GET_STAMPED.rq mit einer anderen LID für die Attribute 32, 60, 50, 52, 49, das DUT darf nicht darauf reagieren. • Die Bake sendet ein RELEASE mit einem anderen LID, das DUT das darf nicht darauf reagieren. • Die Bake sendet ein GET_STAMPED.rq mit der LID für das oben registrierte DUT für das Attribut 32, das mit einem GET_STAMPED.rq für die Attribute 24, 16, 19, 55, 22, 17, 61, 62 verkettet wurde. • Die Bake sendet ein GET_STAMPED.rq mit der LID für das oben registrierte DUT für die Attribute 32, 60, 50, 52, 49. • Die Bake sendet ein RELEASE mit der LID für das oben registrierte DUT.	Es soll geprüft werden, dass das DUT auch dann sauber kommuniziert, wenn die Bake nach der Initialisierung weitere Transaktionsphasen mit einer anderen LID durchführt (Was vom DUT nicht beantworten werden darf). Dieser Test erfolgt als Labortest in Anlehnung an die Testspezifikation ISO/TS 14907-1:2015 Table B1-B3-Traffic Conditions-lateral and longitudinal distance between OBUs.
DSRC_SFXX_HNG2_0010	Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit ist. • Dann führt die Bake erneut eine Initialisierung (BST-VST) mit einer neuen Beacon-ID mit dem DUT durch. • Die Bake wartet für die Dauer von zwei Datenaustauschphasen einer CCC-Transaktion (20 ms) • Die Bake sendet ein RELEASE mit einer anderen LID, das DUT darf nicht darauf reagieren. • Die Bake sendet ein GET_STAMPED.rq mit der LID für das oben registrierte DUT für das Attribut 32, welches mit einem GET_STAMPED.rq für die Attribute 24, 16, 19, 55, 22, 17, 61, 62 verkettet wurde. • Die Bake sendet ein GET_STAMPED.rq mit der LID für das oben registrierte DUT für die Attribute 32, 60, 50, 52, 49. • Die Bake sendet ein RELEASE mit der LID für das oben registrierte DUT.	Es soll nachgewiesen werden, dass das DUT auch dann sauber kommuniziert, wenn die Bake die Kommunikation nach der Initialisierung unterbricht und später wieder aufnimmt. Dieser Test erfolgt als Labortest in Anlehnung an die Testspezifikation ISO/TS 14907-1:2015 Table B7-Traffic Conditions-Shadowing.
DSRC_SFXX_HNG3_0010	Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob die OBU/DSRC-Modul kommunikationsbereit ist. • Dann führt die Bake erneut eine Initialisierung (BST-VST) mit einer neuen Beacon-ID mit der OBU/DSRC Modul durch. • Die Bake wartet für die Dauer einer gesamten CCC-Transaktion (30 ms). Anschliessend führt die Bake erneut eine neue Initialisierung (BST-VST) mit einer neuen Beacon-ID mit dem DUT durch. • Die Bake sendet ein GET_STAMPED.rq mit der LID für das oben registrierte DUT für das Attribut 32, welche mit einem GET_STAMPED.rq für die Attribute 24, 16, 19, 55, 22, 17, 61, 62 verkettet wurde. • Die Bake sendet ein GET_STAMPED.rq mit der LID für das oben registrierte DUT für die Attribute 32, 60, 50, 52, 49. • Die Bake sendet ein RELEASE mit der LID für das oben registrierte DUT.	Es soll geprüft werden, dass das DUT auch dann sauber kommuniziert, wenn die Bake nach der Initialisierung die Kommunikation unterbricht und wieder neu initialisiert. Mit diesem Testfall soll in einem Labortest die BALM-Anforderung für die Mobile Kontrolle nach Einzeldokument 4.3.1 Version 3.1 (Stand:09.06.2022) überprüft werden, mit der nach einer fehlgeschlagenen Transaktion die CCC-Transaktion mit einer neuen Beacon-ID neu aufgesetzt werden kann.
DSRC_SFXX_HNG4_0010	Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit ist. Dann führt die Bake erneut eine Initialisierung (BST-VST) mit einer neuen Beacon-ID mit dem DUT durch. • Die Bake sendet während der gesamten Dauer (30 ms) einer CCC-Transaktion Zufallsdaten (Fehlerhafte DSRC-Rahmen). • Anschliessend führt die Bake erneut eine neue Initialisierung (BST-VST) mit einer neuen Beacon-ID mit dem DUT durch. • Die Bake sendet ein GET_STAMPED.rq mit der LID für die oben registrierte OBU/das DSRC Modul für das Attribut 32, die mit einem GET_STAMPED.rq für die Attribute 24, 16, 19, 55, 22, 17, 61, 62 verkettet wurde. • Die Bake sendet ein GET_STAMPED.rq mit der LID für das oben registrierte DUT für die Attribute 32, 60, 50, 52, 49. • Die Bake sendet ein RELEASE mit der LID für das oben registrierte DUT.	Es soll geprüft werden, dass das DUT auch dann sauber kommuniziert, wenn die Bake nach der Initialisierung fehlerhafte Frames versendet und dann eine neue Transaktion durchführt. Mit diesem Testfall soll in einem Labortest geprüft werden, dass die BALM-Anforderung für die Mobile Kontrolle nach Einzeldokument 4.3.1 Version 3.1 (Stand:09.06.2022), mit der nach einer fehlgeschlagenen Transaktion die CCC-Transaktion mit einer neuen Beacon-ID neu aufgesetzt werden kann, mit dem DUT erfüllt werden kann.
DSRC_SFXX_LID_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird nach einer regulären Initialisierungsphase das erste GET der CCC-Transaktion gesendet, das ordnungsgemäß beantwortet werden soll. Dann wird der GET-Befehl mit zwei verschiedenen, verfälschten LIDs wiederholt, die beide nicht beantwortet werden sollen. Dann sendet die Bake jeweils ein RELEASE an zwei verfälschte LIDs. Anschließend sendet die Bake den zweiten GET-Befehl der Transaktion an die OBU, der beantwortet werden soll. Dann sendet die Bake den gleichen GET-Befehl an zwei verfälschte LIDs, wobei die OBU nicht antworten soll.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul die LID korrekt handhabt.
DSRC_SFXX_MV02_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird die OBU initialisiert. Anschließend werden jeweils zwei ECHO.rq so gesendet, dass ein bestimmter Zeitabstand zwischen dem Ende des ersten ECHO.rs und dem Anfang des zweiten ECHO.rq liegt. Dieser Zeitabstand wird schrittweise auf dem minimalen erlaubten Abstand (T1) reduziert.	Es soll nachgewiesen werden, dass die OBU/das DSRC-Modul auf Befehle der Bake reagiert, die mit der kleinsten erlaubten Verzögerung von T1 zwischen Ende der Antwort auf den vorigen Befehl und Anfang des neuen Befehls gesendet werden.
DSRC_SFXX_SETA_5010	Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit ist. Die nächsten Schritte werden für alle Einstellmöglichkeiten der Achszahl wiederholt. Der Tester stellt im DUT die Achszahl (initial auf den kleinstmöglichen Wert) ein und bestätigt die Einstellung. Der Tester gibt die am DUT eingestellte Achszahl am Testplatz ein. Die Bake führt eine CCC:2019(SST301 v3.1)-Transaktion (incl. Auslesung des Attributs 19) durch. Die Transaktionsdaten werden darauf untersucht, ob die über DSRC ausgelesene Achszahl dem eingegebenen Wert entspricht.	Es soll nachgewiesen werden, dass vom Nutzer alle Einstellmöglichkeiten der Achszahl korrekt im entsprechenden Attribut 19 gespeichert und bei einer CCC:2019(SST301 v3.1)-Transaktion an die Bake übertragen werden.
DSRC_SFXX_SETG_5010	– Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit ist. – Der Tester stellt in dem DUT (je nach Typ des DUTs) das Gewicht oder die Gewichtsklasse auf den kleinstmöglichen Wert ein und bestätigt die Einstellung. – Die nächsten Schritte werden so wiederholt, dass nach Möglichkeit die Gewichte unterhalb und oberhalb der Gewichtsklassegrenzen eingestellt werden. – Der Tester stellt im DUT das Gewicht bzw. die Gewichtsklasse (initial auf den kleinstmöglichen Wert) ein und bestätigt die Einstellung. – Der Tester gibt das am DUT eingestellte Gewicht am Testplatz ein. – Die Bake führt eine CCC:2019(SST301 v3.1)-Transaktion (incl. Auslesung des Attributs 55) durch. – Die Transaktionsdaten werden darauf untersucht, ob das über DSRC ausgelesene Gewicht dem eingegebenen Wert entspricht.	Es soll nachgewiesen werden, dass das vom Nutzer eingestellte Gewicht korrekt im entsprechenden Attribut (55) gespeichert und bei einer CCC:2019(SST301 v3.1)-Transaktion an die Bake übertragen wird. Mit diesem Testfall wird überprüft, in welchem Einstellbereich die Gewichtseinstellung des DUTs veränderbar ist.
DSRC_SFXX_STPW_5010	Zunächst wird die Sendeleistung der Bake auf den gewünschten Wert eingestellt und testweise eine Transaktion ausgelöst. Falls keine Kommunikation mit der OBU erfolgt, wird der Testlauf abgebrochen. Dann werden bei laufend wechselnder Beacon-ID im Dauertest CCC:2019(SST301 v3.1)-Transaktionen durchgeführt. Nach Ablauf der Testdauer wird die Bake angehalten und das Log auf die zeitliche Lage der public windows requests untersucht. Für eine tiefergehende Analyse wird aus den Sendezeitpunkten zusätzlich ein PDF und ein CSV erzeugt.	Es soll nachgewiesen werden, dass eine OBU/ein DSRC-Modul alle drei public Anmeldefenster gleichmäßig nutzt. Darüberhinaus werden Statistiken zur zeitlichen Lage der private windows requests erhoben.
DSRC_SFXX_STPW_5015	Zunächst wird die Sendeleistung der Bake auf den gewünschten Wert eingestellt und testweise eine Transaktion ausgelöst. Falls keine Kommunikation mit der OBU erfolgt, wird der Testlauf abgebrochen. Dann werden bei laufend wechselnder Beacon-ID im Dauertest CCC:2019(SST301 v3.1)-Transaktionen durchgeführt. Nach Ablauf der Testdauer wird die Bake angehalten und das Log auf die zeitliche Lage der private windows requests untersucht. Für eine tiefergehende Analyse wird aus den Sendezeitpunkten zusätzlich ein PDF und ein CSV erzeugt.	Es soll nachgewiesen werden, dass die OBU/das DSRC-Modul das erlaubte Zeitfenster für Übertragungen in private uplink windows einhält. Darüberhinaus werden Statistiken zur zeitlichen Lage der Übertragungen erhoben.
DSRC_SFXX_STPW_5020	Zunächst wird die Sendeleistung der Bake auf den gewünschten Wert eingestellt und testweise eine Transaktion ausgelöst. Falls keine Kommunikation mit den OBUs erfolgt, wird der Testlauf abgebrochen. Dann werden bei laufend wechselnder Beacon-ID im Dauertest CCC:2019(SST301 v3.1)-Transaktionen durchgeführt. Nach Ablauf der Testdauer wird die Bake angehalten und das Log auf die zeitliche Lage der private windows requests untersucht. Für eine tiefergehende Analyse wird aus den Sendezeitpunkten zusätzlich ein PDF und ein CSV erzeugt.	Es soll nachgewiesen werden, dass mehrere DUT des gleichen Herstellers jeweils alle drei public Anmeldefenster gleichmäßig nutzt. Darüberhinaus werden Statistiken zur zeitlichen Lage der private windows requests erhoben.
DSRC_SFXX_STPW_5030	– Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob alle OBUs/DSRC-Module (DUT und drei weitere DSRC-Module) kommunikationsbereit sind. – Die Bake wird für einen Dauertest konfiguriert, der über eine Zeit von 5 Stunden mit folgenden Einstellungen durchgeführt wird: 1. Beacon Change Intervall 15s 2. CCC:2019(SST301 v3.1)-Transaktionen für Max 15s 3. Nach der Transaktion wird die Bake für 15s angehalten (Simulation des Verlassens der Kommunikationszone) – Nach Ablauf der Testdauer wird das Bakelog auf die zeitliche Lage der public windows requests untersucht. Darüberhinaus werden Statistiken zur zeitlichen Lage der public windows requests erhoben (PublicWindows Zeit-Überlappung und -Verletzungen).	Es soll nachgewiesen werden, dass das DUT im Zusammenspiel mit drei weiteren OBUs (Module verschiedener Typen und Hersteller) alle drei public Anmeldefenster gleichmäßig nutzt und die Module sich nicht gegenseitig stören. (Erfahrungsgemäß halten nicht alle Lieferanten von DSRC Modulen die in der Norm vorgegebenen Zeiteinheiten für die Public Windows ein).
DSRC_SFXX_STTD_5010	Zunächst wird testweise eine Transaktion ausgelöst. Falls keine Kommunikation mit der OBU erfolgt, wird der Testlauf abgebrochen. Dann werden bei laufend wechselnder Beacon-ID im Dauertest CCC:2019(SST301 v3.1)-Transaktionen durchgeführt. Nach Ablauf der Testdauer wird die Bake angehalten und aus dem Log die Verteilung der Transaktionsdauern ermittelt.	Es soll nachgewiesen werden, dass die OBU/das DSRC-Modul Transaktionen innerhalb der vorgesehenen Dauer durchführen kann. Gemäß Kap. 4.2.1 der Gebietsvorgaben (Einzeldokument 4.3.1 Version 3.1 (Stand: 09.06.2022)) wird gefordert, dass eine ungestörte Transaktion in einer maximalen Transaktionszeit von 70 ms erfolgen soll.
DSRC_SFXX_STTD_5020	Zunächst wird der Sende Pegel der Bake auf einem mittleren Wert eingestellt (zum Beispiel 30 dbm). Dann werden bei laufend wechselnder Beacon-ID im Dauertest CCC:2019(SST301 v3.1)-Transaktionen durchgeführt. Nach Ablauf der Testdauer wird die Bake angehalten und aus dem Log die Verteilung der Transaktionsdauern ermittelt.	Es soll nachgewiesen werden, dass die OBU/das DSRC-Modul auch bei mäßigen Kommunikationsbedingungen Transaktionen innerhalb der vorgesehenen Dauer durchführen kann. Gemäß Kap. 4.3.1 der Gebietsvorgaben (Einzeldokument 4.3.1 Version 3.1 (Stand: 09.06.2022)) wird gefordert, dass eine ungestörte Transaktion in einer maximalen Transaktionszeit von 70 ms erfolgen soll.
DSRC_SFXX_STTD_5030	Zunächst wird der Sende Pegel der Bake auf einem niedrigen Wert eingestellt (zum Beispiel 27 dbm). Dann werden bei laufend wechselnder Beacon-ID im Dauertest CCC:2019(SST301 v3.1) -Transaktionen durchgeführt. Nach Ablauf der Testdauer wird die Bake angehalten und aus dem Log die Verteilung der Transaktionsdauern ermittelt.	Es soll nachgewiesen werden, dass die OBU/das DSRC-Modul auch bei schwachen Kommunikationsbedingungen Transaktionen innerhalb der vorgesehenen Dauer durchführen kann. Gemäß Kap. 4.3.1 der Gebietsvorgaben (Einzeldokument 4.3.1 Version 3.1 (Stand: 09.06.2022)) wird gefordert, dass eine ungestörte Transaktion in einer maximalen Transaktionszeit von 70 ms erfolgen soll.
DSRC_SFXX_STTD_5040	– Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob alle OBUs/DSRC-Module kommunikationsbereit sind. – Die Bake wird für einen Dauertest konfiguriert, der über einen Zeitraum von 5 Stunden mit folgenden Einstellungen durchgeführt wird: 1. Beacon Change Intervall 15s 2. CCC:2019(SST301 v3.1)-Transaktionen für Max 15s 3. Nach der Transaktion wird die Bake für 15s angehalten (Simulation des Verlassens der Kommunikationszone) – Nach Ablauf der Testdauer wird aus den Bake-Logs die Verteilung pro OBU/DSRC Modul Transaktionszeiten ermittelt.	Es soll nachgewiesen werden, dass das DUT Transaktionen innerhalb der vorgesehenen Transaktionzeiten (<70 ms) mit der DSRC Bake durchführen kann, wenn mehrere DSRC-Module (max 3 weitere Module verschiedener Typen und Hersteller) gleichzeitig kommunizieren. Dieser Test erfolgt als Labortest in Anlehnung an die Testspezifikation ETSI TS 102 486-1-2 TP/MAC/OBU/BV/01 und in Anlehnung an die Testspezifikation ISO/TS 14907-1:2015 Table B3-Traffic Conditions-Lateral distance between OBEs unter Berücksichtigung der Allgemeinen Vorgaben nach Einzeldokument 4.3.1 Version 3.1 (Stand: 09.06.2022).
DSRC_SFXX_TRPT_5040	– Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit ist. – Die Bake wird für einen Dauertest konfiguriert, der über einen Zeitraum von 5 Stunden mit folgenden Einstellungen durchgeführt wird: 1. Beacon Change Intervall 15s 2. CCC:2019(SST301 v3.1)-Transaktionen für Max 15s 3. Nach der Transaktion wird die Bake für 15s angehalten (Simulation des Verlassens der Kommunikationszone) – Nach Ablauf der Testdauer wird aus dem Backlog die Anzahl der durchgeführten Transaktionen mit den zu erwartenden Transaktionen verglichen.	Es soll nachgewiesen werden, dass in einem Dauerlauf das DUT alle CCC:2019(SST301 v3.1)-Transaktionen erfolgreich durchführt. In Anlehnung an die Bitfehlerraten-Tests der EN300674-2-2 wird in diesem Labortest die Übertragungssicherheit im stabilen Laboraufbau überprüft.
DSRC_SFXX_UCON_5010	Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob das DUT kommunikationsbereit ist. – Ein Fehler wird provoziert (zum Beispiel kein GNSS Empfang). – Der Benutzer wird aufgefordert die Fehlermeldung zu bestätigen. – Die Bake führt eine CCC-Transaktion durch. Aus dem Transaktionslog wird der Zeitstempel der UserConfirmation ausgelesen, der den Zeitpunkt der Bestätigung entspricht.	In der Version 2019-11 hat der ISO 12813 u.a. das Attribut 101 (UserConfirmation) neu eingeführt. Dieser Testfall soll sicherstellen, dass das DUT dieses Attribut korrekt setzt.
DSRC_SFXX_WKUP_0010	– Eine Initialisierung (BST-VST) mit einer neuen Beacon-ID wird durchgeführt, um festzustellen, ob die OBU/DSRC-Module kommunikationsbereit sind. – Die Bake pausiert für 10 Sekunden. – Dann sendet die Bake BSTs, bis sie ein private window request empfängt. Die Dauer ab der ersten BST bis zum private window request wird gemessen.	Es soll sichergestellt werden, dass die Wakeup-Dauer des DUTs unter 20 ms liegt.
DSRC_SFXX_FUL1_5010	Das Dämpfungsglied wird für den gewünschten Pegelverlauf eingestellt, die Bake führt eine CCC:2019(SST301 v3.1)-Transaktion durch und das Log wird auf korrekte LID, Kontrollfelder und Vollständigkeit der Transaktion überprüft. Der Testfall wird als Dauertest über einen einstellbaren Zeitraum wiederholt. Abschließend wird die Transaktionserfolgsrate ausgegeben, wobei für jeden Initialisierungsversuch der Bake mindestens ein private request der Bake erwartet wird.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul unter Funkbedingungen [FootPrint (KonSL)], die dem Wirkbetrieb möglichst nahe kommen, ordnungsgemäß Transaktionen durchführen kann. Hinweis: FootPrint (KonSL): DSRC_SFXX_FUL1_5010-KonSL-LKW-3.5mSeitl-plusLöcher.txt Der Pegelverlauf basiert auf der Messung einer LKW-Passage an einer KonSL, wobei die Messdaten durch manuell eingefügte Pegeleinbrüche künstlich verschlechtert werden.
DSRC_SFXX_FUL2_5010	Das Dämpfungsglied wird für den gewünschten Pegelverlauf eingestellt, die Bake führt eine CCC:2019(SST301 v3.1)-Transaktion durch und das Log wird auf korrekte LID, Kontrollfelder und Vollständigkeit der Transaktion überprüft. Der Testfall wird als Dauertest über einen einstellbaren Zeitraum wiederholt. Abschließend wird die Transaktionserfolgsrate ausgegeben, wobei für jeden Initialisierungsversuch der Bake mindestens ein private request der Bake erwartet wird.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul unter Funkbedingungen [Footprint (KonMA)], die dem Wirkbetrieb möglichst nahekommen, ordnungsgemäß Transaktionen durchführen kann. Hinweis: Footprint (KonMA): DSRC_SFXX_FUL2_ 5010-KonMa1- plusLöcher.txt Der Pegelverlauf basiert auf der Messung einer KonMA-Passage an einem LKW, wobei die Messdaten durch manuell eingefügte Pegeleinbrüche künstlich verschlechtert werden.
SRC_SFXX_FUL3_5010	Das Dämpfungsglied wird für den gewünschten Pegelverlauf eingestellt, die Bake führt eine CCC:2019(SST301 v3.1)-Transaktion durch und das Log wird auf korrekte LID, Kontrollfelder und Vollständigkeit der Transaktion überprüft. Der Testfall wird als Dauertest über einen einstellbaren Zeitraum wiederholt. Abschließend wird die Transaktionserfolgsrate ausgegeben, wobei für jeden Initialisierungsversuch der Bake mindestens ein private request der Bake erwartet wird.	Es soll sichergestellt werden, dass die OBU/das DSRC-Modul unter Funkbedingungen [Footprint (Sägezahn)], die dem Wirkbetrieb möglichst nahekommen, ordnungsgemäß Transaktionen durchführen kann. Hinweis: Footprint (Sägezahn): DSRC_SFXX_FUL3_ 5010-Saegezahn.txt Der Pegel wird jeweils um 2,8dB besser und verschlechtert sich dann wieder langsam um 1,8 dB. Das wird so lange wiederholt, bis ein ungedämpfter Kanal erreicht ist.
DSRC_SFXX_2BKN_5010	Zunächst wird testweise eine Transaktion separat mit jeder der beteiligten Baken ausgelöst. Falls keine Kommunikation mit der OBU erfolgt, wird der Testlauf abgebrochen. Dann werden bei gleichbleibender Beacon-ID an beiden Baken im Parallelbetrieb CCC:2019 (SST301 v3.1)-Transaktionen durchgeführt. Es wird erwartet, dass das DSRC Modul beim Empfang einer BST die laufende Transaktion unterbricht und zur anderen RSU wechselt, und dass das Modul nach dem Ablauf der 2. Bake-Testphase noch Transaktionen mit einer einzelnen Bake durchführen kann. Nach Ablauf der Testdauer wird ermittelt, ob die OBUs die Bakenbefehle immer mit der korrekten LID und gemäß des Protokollablaufs beantwortet haben.	Es soll nachgewiesen werden, dass das DSRC-Modul sich in einer worst case-Situation, die aber bei einer Vorbeifahrt einer KonMA unter der KonAU auftritt, korrekt verhält.
DSRC_SFXX_CO2C_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird mit der Bake eine CCC-2019-Transaktion durchgeführt. Abschließend wird das Bakenlog ausgelesen und überprüft, ob die genannten Bits des Teilattributs VehicleSpecificCharacteristics.FutureCharacteristics korrekt gesetzt sind. Erwartetes Ergebnis: Die Bit-Struktur im Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics ist korrekt gesetzt: SS = 01'B OOO = 000'B	Das Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics hat die Bit-Struktur FSSOOOPP und muss für die Bit-Struktur SSOOO wie folgt belegt werden mit: SS – cO2Scheme, muss mit 01'B belegt werden, um die CO₂-Schemadefinition gemäß EU-Verordnung 2022/362 Artikel 1 (11), der Artikel 7ga in Richtlinie 1999/62 einfügt, zu referenzieren. OOO – cO2Class, muss mit 000'B belegt werden, wenn keine CO₂-Emissionsklasse zugeordnet werden kann, ansonsten mit den Werten 001'B, 010'B, 011'B, 100'B, 101'B für die CO₂-Emissionsklassen 1 bis 5.
DSRC_SFXX_CO2C_0011	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird mit der Bake eine CCC-2019-Transaktion durchgeführt. Abschließend wird das Bakenlog ausgelesen und überprüft, ob die genannten Bits des Teilattributs VehicleSpecificCharacteristics.FutureCharacteristics korrekt gesetzt sind. Erwartetes Ergebnis: Die Bit-Struktur im Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics ist korrekt gesetzt: SS = 01'B OOO = 001'B	Das Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics hat die Bit-Struktur FSSOOOPP und muss für die Bit-Struktur SSOOO wie folgt belegt werden mit: SS – cO2Scheme, muss mit 01'B belegt werden, um die CO₂-Schemadefinition gemäß EU-Verordnung 2022/362 Artikel 1 (11), der Artikel 7ga in Richtlinie 1999/62 einfügt, zu referenzieren. OOO – cO2Class, muss mit 000'B belegt werden, wenn keine CO₂-Emissionsklasse zugeordnet werden kann, ansonsten mit den Werten 001'B, 010'B, 011'B, 100'B, 101'B für die CO₂-Emissionsklassen 1 bis 5.
DSRC_SFXX_CO2C_0012	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird mit der Bake eine CCC-2019-Transaktion durchgeführt. Abschließend wird das Bakenlog ausgelesen und überprüft, ob die genannten Bits des Teilattributs VehicleSpecificCharacteristics.FutureCharacteristics korrekt gesetzt sind. Erwartetes Ergebnis: Die Bit-Struktur im Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics ist korrekt gesetzt: SS = 01'B OOO = 010'B	Das Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics hat die Bit-Struktur FSSOOOPP und muss für die Bit-Struktur SSOOO wie folgt belegt werden mit: SS – cO2Scheme, muss mit 01'B belegt werden, um die CO₂-Schemadefinition gemäß EU-Verordnung 2022/362 Artikel 1 (11), der Artikel 7ga in Richtlinie 1999/62 einfügt, zu referenzieren. OOO – cO2Class, muss mit 000'B belegt werden, wenn keine CO₂-Emissionsklasse zugeordnet werden kann, ansonsten mit den Werten 001'B, 010'B, 011'B, 100'B, 101'B für die CO₂-Emissionsklassen 1 bis 5.
DSRC_SFXX_CO2C_0013	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird mit der Bake eine CCC-2019-Transaktion durchgeführt. Abschließend wird das Bakenlog ausgelesen und überprüft, ob die genannten Bits des Teilattributs VehicleSpecificCharacteristics.FutureCharacteristics korrekt gesetzt sind. Erwartetes Ergebnis: Die Bit-Struktur im Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics ist korrekt gesetzt: SS = 01'B OOO = 011'B	Das Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics hat die Bit-Struktur FSSOOOPP und muss für die Bit-Struktur SSOOO wie folgt belegt werden mit: SS – cO2Scheme, muss mit 01'B belegt werden, um die CO₂-Schemadefinition gemäß EU-Verordnung 2022/362 Artikel 1 (11), der Artikel 7ga in Richtlinie 1999/62 einfügt, zu referenzieren. OOO – cO2Class, muss mit 000'B belegt werden, wenn keine CO₂-Emissionsklasse zugeordnet werden kann, ansonsten mit den Werten 001'B, 010'B, 011'B, 100'B, 101'B für die CO₂-Emissionsklassen 1 bis 5.
DSRC_SFXX_CO2C_0014	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird mit der Bake eine CCC-2019-Transaktion durchgeführt. Abschließend wird das Bakenlog ausgelesen und überprüft, ob die genannten Bits des Teilattributs VehicleSpecificCharacteristics.FutureCharacteristics korrekt gesetzt sind. Erwartetes Ergebnis: Die Bit-Struktur im Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics ist korrekt gesetzt: SS = 01'B OOO = 100'B	Das Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics hat die Bit-Struktur FSSOOOPP und muss für die Bit-Struktur SSOOO wie folgt belegt werden mit: SS – cO2Scheme, muss mit 01'B belegt werden, um die CO₂-Schemadefinition gemäß EU-Verordnung 2022/362 Artikel 1 (11), der Artikel 7ga in Richtlinie 1999/62 einfügt, zu referenzieren. OOO – cO2Class, muss mit 000'B belegt werden, wenn keine CO₂-Emissionsklasse zugeordnet werden kann, ansonsten mit den Werten 001'B, 010'B, 011'B, 100'B, 101'B für die CO₂-Emissionsklassen 1 bis 5.
DSRC_SFXX_CO2C_0015	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird mit der Bake eine CCC-2019-Transaktion durchgeführt. Abschließend wird das Bakenlog ausgelesen und überprüft, ob die genannten Bits des Teilattributs VehicleSpecificCharacteristics.FutureCharacteristics korrekt gesetzt sind. Erwartetes Ergebnis: Die Bit-Struktur im Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics ist korrekt gesetzt: SS = 01'B OOO = 101'B	Das Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics hat die Bit-Struktur FSSOOOPP und muss für die Bit-Struktur SSOOO wie folgt belegt werden mit: SS – cO2Scheme, muss mit 01'B belegt werden, um die CO₂-Schemadefinition gemäß EU-Verordnung 2022/362 Artikel 1 (11), der Artikel 7ga in Richtlinie 1999/62 einfügt, zu referenzieren. OOO – cO2Class, muss mit 000'B belegt werden, wenn keine CO₂-Emissionsklasse zugeordnet werden kann, ansonsten mit den Werten 001'B, 010'B, 011'B, 100'B, 101'B für die CO₂-Emissionsklassen 1 bis 5.
DSRC_SFXX_CO2S_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird mit der Bake eine CCC-2019-Transaktion durchgeführt. Abschließend wird das Bakenlog ausgelesen und überprüft, ob die genannten Bits des Teilattributs VehicleSpecificCharacteristics.FutureCharacteristics korrekt gesetzt sind. Erwartetes Ergebnis: Die Bits im Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics sind korrekt gesetzt: PP = 00'B	Optionaler Testfall: Das Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics hat die Bit-Struktur FSSOOOPP und die Teilstruktur PP kann wie folgt belegt werden mit: – PP – suspensionType – Die Komponente sollte korrekt nach folgenden Vorgaben belegt werden, wird durch den Mauterheber jedoch derzeit nicht ausgewertet: – 00'B – means information is not available, – 01'B – means the vehicle uses air suspensions, – 10'B – means the vehicle uses hydraulic suspensions, – 11'B – means the vehicle uses electric suspensions. Dieser Testfall soll nachweisen, dass die Komponente PP nach geeigneter Personalisierung des DUT den Wert 00'B hat.
DSRC_SFXX_CO2S_0011	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird mit der Bake eine CCC-2019-Transaktion durchgeführt. Abschließend wird das Bakenlog ausgelesen und überprüft, ob die genannten Bits des Teilattributs VehicleSpecificCharacteristics.FutureCharacteristics korrekt gesetzt sind. Erwartetes Ergebnis: Die Bits im Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics sind korrekt gesetzt: PP = 01'B	Optionaler Testfall: Das Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics hat die Bit-Struktur FSSOOOPP und die Teilstruktur PP kann wie folgt belegt werden mit: – PP – suspensionType – Die Komponente sollte korrekt nach folgenden Vorgaben belegt werden, wird durch den Mauterheber jedoch derzeit nicht ausgewertet: – 00'B – means information is not available; – 01'B – means the vehicle uses air suspensions – 10'B – means the vehicle uses hydraulic suspensions – 11'B – means the vehicle uses electric suspensions. Dieser Testfall soll nachweisen, dass die Komponente PP nach geeigneter Personalisierung des DUT den Wert 01'B hat.
DSRC_SFXX_CO2S_0012	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird mit der Bake eine CCC-2019-Transaktion durchgeführt. Abschließend wird das Bakenlog ausgelesen und überprüft, ob die genannten Bits des Teilattributs VehicleSpecificCharacteristics.FutureCharacteristics korrekt gesetzt sind. Erwartetes Ergebnis: Die Bits im Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics sind korrekt gesetzt: PP = 10'B	Optionaler Testfall: Das Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics hat die Bit-Struktur FSSOOOPP und die Teilstruktur PP kann wie folgt belegt werden mit: – PP – suspensionType – Die Komponente sollte korrekt nach folgenden Vorgaben belegt werden, wird durch den Mauterheber jedoch derzeit nicht ausgewertet: – 00'B – means information is not available; – 01'B – means the vehicle uses air suspensions – 10'B – means the vehicle uses hydraulic suspensions – 11'B – means the vehicle uses electric suspensions. Dieser Testfall soll nachweisen, dass die Komponente PP nach geeigneter Personalisierung des DUT den Wert 10'B hat.
DSRC_SFXX_CO2S_0013	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird mit der Bake eine CCC-2019-Transaktion durchgeführt. Abschließend wird das Bakenlog ausgelesen und überprüft, ob die genannten Bits des Teilattributs VehicleSpecificCharacteristics.FutureCharacteristics korrekt gesetzt sind. Erwartetes Ergebnis: Die Bits im Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics sind korrekt gesetzt: PP = 11'B	Optionaler Testfall: Das Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics hat die Bit-Struktur FSSOOOPP und die Teilstruktur PP kann wie folgt belegt werden mit: – PP – suspensionType – Die Komponente sollte korrekt nach folgenden Vorgaben belegt werden, wird durch den Mauterheber jedoch derzeit nicht ausgewertet: – 00'B – means information is not available; – 01'B – means the vehicle uses air suspensions – 10'B – means the vehicle uses hydraulic suspensions – 11'B – means the vehicle uses electric suspensions. Dieser Testfall soll nachweisen, dass die Komponente PP nach geeigneter Personalisierung des DUT den Wert 11'B hat.
DSRC_SFXX_FXXX_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird mit der Bake eine CCC-2019-Transaktion durchgeführt. Abschließend wird das Bakenlog ausgelesen und überprüft, ob die genannten Bits des Teilattributs VehicleSpecificCharacteristics.FutureCharacteristics korrekt gesetzt sind. Erwartetes Ergebnis: Die Bits im Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics sind korrekt gesetzt: – F = 0'B oder 1'B	Optionaler Testfall: Das Teilattribut VehicleSpecificCharacteristics.FutureCharacteristics hat die Bit-Struktur FSSOOOPP und kann wie folgt belegt werden mit: – F – futureElement, kann mit 0'B oder 1'B belegt werden Der Testfall soll nachweisen, dass die Komponente F korrekt belegt ist, sofern der EETS-Anbieter die Belegung dieses Datenelements unterstützt.
DSRC_SFXX_TSPS_0010	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird mit der Bake eine CCC-2019-Transaktion durchgeführt. Danach wird das Bakenlog ausgelesen und die tspStatus-Werte extrahiert. Abschließend wird überprüft, ob die tspStatus-Werte und ihre Bedeutung inhaltlich zum jeweiligen Statuswechsel passen. Erwartetes Ergebnis: Alle gefundenen tspStatus haben in Bezug auf den jeweiligen Statuswechsel einen plausiblen Wert gemäß EETS-Anbieterspezifikation.	Optionaler Testfall: Die Attribute UserConfirmation, ExtendedOBUStatusHistoryPart1 und ExtendedOBUStatusHistoryPart2 haben jeweils tspStatus-Teilattribute, die bei Statuswechsel einen EETS-Anbieterspezifischen Statuscode enthalten können. Die Bedeutung der tspStatus-Werte kann von jedem EETS-Anbieter frei festgelegt werden und laut Gebietsvorgaben kann der Mauterheber den Mautdienstanbieter ersuchen, die Bedeutung einer speziellen Belegung des Datenelements zu erläutern. Der Testfall soll den tspStatus-Wert auslesen und dieser soll in Bezug auf den durchgeführten Statuswechsel einen plausiblen Grund gemäß EETS-Anbieterspezifikation aufzeigen.
DSRC_SFXX_VSDE_0000	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird mit der Bake eine CCC-2019-Transaktion durchgeführt das Bakenlog ausgelesen und überprüft, ob der Wert des Teilattributs VehicleSpecificCharacteristics.descriptiveCharacteristics den vorgegebenen Wert hat. Erwartetes Ergebnis: Das Teilattribut VehicleSpecificCharacteristics.descriptiveCharacteristics hat jeweils den vorgegebenen Wert. Optional: Falls ein Dienstanbieter das Teilattribut fachlich nutzt, so wird eine manuelle Prüfung auf korrekte Belegung durchgeführt und dies im Testreport dokumentiert.	Optionaler Testfall: Das Teilattribut VehicleSpecificCharacteristics.descriptiveCharacteristics kann optional durch den Dienstanbieter belegt werden. Dieser Testfall soll nachweisen, dass die Komponente descriptiveCharacteristics nach geeigneter Personalisierung des DUT den Wert 0 hat. Dieser Testfall soll prüfen, ob der Parameter descriptiveCharacteristics dem in der Konfigurationsmatrix der OBU vorgegebenen Wert entspricht.
DSRC_SFXX_VSEE_0000	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Für die Werte 0 (Minimalwert), 2 (Zwischenwert), 7 (Maximalwert) und 15 (Zusatzwert) wird jeweils – der Tester aufgefordert, eine geeignete personalisierte OBU vor der Testbake zu positionieren – mit der Bake eine CCC-2019-Transaktion durchgeführt – das Bakenlog ausgelesen und überprüft, ob der Wert des Teilattributs VehicleSpecificCharacteristics.environmentalCharacteristics.euroValue den vorgegebenen Wert hat. Erwartetes Ergebnis: Das Teilattribut VehicleSpecificCharacteristics.environmentalCharacteristics.euroValue hat jeweils den vorgegebenen Wert.	Das Teilattribut VehicleSpecificCharacteristics.environmentalCharacteristics.euroValue kann mit Werten von 0 bis 7 einschließlich, sowie 15 belegt werden. Dieser Testfall soll exemplarisch anhand einiger Werte nachweisen, dass die OBU den gültigen Wertebereich unterstützt.
DSRC_SFXX_VSEN_0000	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Für die Werte 0 (Minimalwert), 28 (Zwischenwert), 52 (Maximalwert) und 255 (Zusatzwert) wird jeweils – der Tester aufgefordert, eine geeignete personalisierte OBU vor der Testbake zu positionieren – mit der Bake eine CCC-2019-Transaktion durchgeführt – das Bakenlog ausgelesen und überprüft, ob der Wert des Teilattributs VehicleSpecificCharacteristics.engineCharacteristics den vorgegebenen Wert hat. Erwartetes Ergebnis: Das Teilattribut VehicleSpecificCharacteristics.engineCharacteristics hat jeweils den vorgegebenen Wert.	Optionaler Testfall: Das Teilattribut VehicleSpecificCharacteristics.engineCharacteristics kann durch den Dienstanbieter optional mit Werten von 0 bis einschließlich 52 und 255 belegt werden. Dieser Testfall soll exemplarisch anhand einiger Werte nachweisen, dass die OBU den gültigen Wertebereich unterstützt.
DSRC_SFXX_GNSS_0000	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird mit der Bake eine CCC-2019-Transaktion durchgeführt. Abschließend wird das Bakenlog ausgelesen und überprüft, ob das Attribut korrekt geparst werden kann, ob die GPS-Position der tatsächlichen OBU-Position entspricht und die letzte Aktualisierung höchstens 60 Sekunden vor der Transaktion erfolgt ist. Erwartetes Ergebnis: Das Attribut hat die richtige Länge und kann geparst werden, die GPS-Position laut Attribut entspricht den GPS-Koordinaten des Testlabors und die letzte Aktualisierung liegt höchstens 60 Sekunden zurück.	Die Attributdefinition hat sich in den letzten Versionen der Norm (ISO FDIS 12813) mehrfach geändert. Es ist möglich, dass es dadurch bei der Implementierung des Attributs bei den OBU-Lieferanten zu Fehlern gekommen ist. Die gültige Version basiert auf ISO FDIS 12813:2023. Der Testfall soll nachweisen, dass – die Kodierung des Attributs gemäß PER (packed encoding rules) korrekt umgesetzt wurde, andernfalls ob die akzeptierte Umsetzung gemäß dem legacy encoding korrekt implementiert ist – die OBU die GPS-Position korrekt setzt – die OBU das Attribut im vorgesehenen Zeitrahmen aktualisiert
DSRC_SFXX_HISN_0012	Zunächst wird eine Dummytransaktion durchgeführt, um sicherzustellen, dass die OBU kommunikationsbereit ist. Dann wird der Tester aufgefordert, die OBU in den Zustand 2-„noGoContractual“ zu versetzen. Dazu muss evtl. Unterstützung vom Dienstanbieter angefordert werden. Mit der Bake wird eine CCC-2019-Transaktion durchgeführt. Abschließend wird das Bakenlog ausgelesen und überprüft, ob im Attribut ExtendedOBUStatusHistoryPart1 bzw. ExtendedOBUStatusHistoryPart2 der StatusIndicator korrekt gesetzt ist. Erwartetes Ergebnis: Der Status 2-„noGoContractual“ wurde erreicht.	Der StatusIndicator im Attribut ExtendedOBUStatusHistoryPart1 und ExtendedOBUStatusHistoryPart2 zeigt an, ob die OBU erhebungsbereit ist bzw. welche Art von Störung vorliegt. Dieser Testfall soll zeigen, dass der Wert des StatusIndicators unter den passenden Umständen den Wert 2-„noGoContractual“ annimmt.

Name/ID	Beschreibung	Ziel
AutoKST_SVF_FG06AV	Fahrzeuggeräte von neuen EETS-Anbietern durchlaufen eine Gebrauchstauglichkeitsprüfung (GTP). Im Rahmen der Kompatibilitätstests wird die Umsetzung der funktionalen Anforderungen an die EETS-Fahrzeuggeräte in einem E2E-Szenario überprüft. In diesem Testfall wird die Erzeugung der Fallgruppe 6 (Falschdeklarierer) mit einem Test-FzG überprüft. Ein Test-FzG wird im Test-LKW (mit Anhänger) benutzt und auf eine geringere Achszahl bzw. Gewichtsklasse personalisiert, als der Test-LKW inklusive Anhänger tatsächlich besitzt. Bei einer Durchfahrt unter der Test-Kontrollstelle wird überprüft, ob die Test-Kontrollstelle gemäß aktuellem Tarifparametermodell einen Falschdeklarier erkennt.	Ein Test-LKW mit Test-FzG, aber unzureichend deklarierter Achsklasse und/oder Gewichtsklasse erzeugt eine Fallgruppe 6 (Falschdeklarierer). Korrekte und vollständige DSRC-Daten (gemäß SST-Spezifikation 301).
AutoKST_SVF_ FG06AV_2xFzG	Der Testfall prüft ein häufig im Pilotbetrieb auftretendes Szenario: Ein mautpflichtiges Fahrzeug ist mit einem Fahrzeuggerät (FzG_1) des EETS-Anbieters sowie einem zweiten deaktivierten/gesperrten Fahrzeuggerät (FzG_2) eines weiteren Anbieters ausgestattet. Um einen Kontrollfall inklusive DSRC-Daten zu erzeugen, wird das Szenario in Form eines Falschdeklarierers durchgeführt. FzG_1 und FzG_2 werden im Test- LKW (mit Anhänger) positioniert. FzG_1 wird auf eine geringere Achszahl bzw. Gewichtsklasse deklariert, als der Test-LKW inklusive Anhänger tatsächlich besitzt. FzG_2 befindet sich im Status NOK (gesperrt/deaktiviert).	Ein Test-LKW mit falsch deklariertem Test-FzG (FzG_1) und einem weiteren FzG (FzG_2) im Status NOK erzeugt einen Verdachtsfall der Fallgruppe 6 (Falschdeklarierer). Die DSRC-Daten beider Fahrzeuggeräte werden korrekt und vollständig übertragen, wobei ausschließlich eine Auffälligkeit des im Rahmen der Gebrauchstauglichkeitsprüfung zu testenden EETS-Fahrzeuggeräts (FzG_1) zum Fehlschlagen des Testfalls führen kann. Kommunikation gemäß SST-Spezifikation 301.
AutoKST_SVF_FG07_ mautfreier_Modus	In diesem Testfall wird die Erzeugung der Fallgruppe 7 mit einem Test-FzG überprüft. Ein Test-FzG wird im Test-LKW (mit Anhänger) angeschlossen. Anschließend wird das Test-FzG so eingestellt, dass das Fahrzeug damit im Gebiet BFStrMG nicht mautpflichtig ist. Bei der Durchfahrt an der Kontrollstelle wird überprüft, ob die Kontrollstelle eine FG7 erkennt.	Ein Test-LKW mit Test-FzG, welches sich im mautfreien Modus befindet, erzeugt eine Fallgruppe 7. – Auswertung nach SST 301 durch Attribut ExtendedOBUStatusHistoryPart1. Korrekte und vollständige DSRC-Daten (gemäß SST-Spezifikation 301).
AutoKST_SVF_FG12	In diesem Testfall wird die Erzeugung der Fallgruppe 12 mit einem Test-FzG überprüft. Der Test-LKW, dessen Test-FzG mit dem Status „gesperrt“ eingesetzt ist, passiert die Kontrollstelle. Die DSRC-Daten aus dem Test-FzG werden von der Test-Kontrollstelle ausgelesen. Der Status „gesperrt“ wird festgestellt und die Test-Kontrollstelle erzeugt einen Verdachtsfall der Fallgruppe 12. Dieser wird anschließend an die Test-KonZ_2.0 gesendet.	Ein LKW mit einem eingebauten FzG, welches gesperrt ist, erzeugt eine FG-12-Auswertung nach SST 301 durch Attribut ExtendedOBUStatusHistoryPart1: FzG-Status „noGoContractual“ oder „noGoPaymentMeans“ (Parameter entsprechen der jeweiligen Testkonfiguration). Korrekte und vollständige DSRC-Daten (gemäß SST-Spezifikation 301).
AutoKST_SVF_FG16	Der Test-LKW befindet sich im automatischen Verfahren. Das Test-FzG wurde den Klassifikationsdaten entsprechend des Test-LKWs oder höher (Überzahler) konfiguriert. Der Test-LKW passiert die Test-Kontrollstelle, der DSRC-Datensatz aus dem Test-FzG wird ausgelesen. Die Test-Kontrollstelle entscheidet aufgrund der deklarierten Parameter und der Sensorikdaten auf FG16. Der Fall wird nicht an die KonZ_2.0 verschickt und in der Test-Kontrollstelle gelöscht.	Ein Test-LKW mit korrekt eingestelltem Test-FzG erzeugt die FG16 (Gutzahler AV). Korrekte und vollständige DSRC-Daten (gemäß SST-Spezifikation 301). Die Falldaten werden nicht an die KonZ_2.0 verschickt und in der Test-Kontrollstelle gelöscht.
AutoKST_ Verifikation_EETS_ Masterkey	In diesem Testfall wird der neu aufgespielte EETS-Masterkey auf der dezentralen Komponente (KonAu/KonSL) verifiziert.	Ein Test-LKW mit einem Test-FzG des EETS-Anbieters passiert als Gutzahler die Kontrollstelle. DSRC-Daten werden vollständig erfasst und entschlüsselt (gemäß SST-Spezifikation 301).
FzG_Parameter_Eingabe	Variable Fahrzeugparameter dürfen während der Fahrt (am Fahrzeuggerät selbst oder über eine App auf einem mit dem Fahrzeuggerät verbundenen Mobilgerät) nicht geändert werden. In diesem Testfall wird geprüft, ob das Test-Fahrzeuggerät eine Anpassung der variablen Fahrzeugparameter während der Fahrt unterbindet.	Anpassung der variablen Fahrzeugparameter während der Fahrt nicht mehr möglich.
KonB_DezKst_SVF_FG	Ein Test-LKW passiert eine Kontrollstelle und ein Verdachtsfall wird angelegt. Dieser Verdachtsfall wird in der KonZ_2.0 mit der passenden Fallgruppe gespeichert. Kontrollfall- und Nacherhebungsdaten werden aus der KonZ_2.0 in die KonB (zunächst aKA) übertragen. Anschließend werden die Daten in die VB übernommen und aufbereitet. Übertragung bis ins SC-OWI sowie die Rückantwort an die KonZ_2.0 werden überprüft.	Sicherstellung, dass der Kontrollfall aus der KonZ_2.0 korrekt in der KonB ankommt. Gewährleistung Interoperabilität Kontrollstelle zu weiterführenden Systemen.
KonMa_auswinken_VKB	Das Fahrzeug wird ausgewunken. Ein verkürzter Kontrollbericht (VKB, FG19) wird ohne weitere Kontrolle erstellt.	Erfolgreiches Erstellen eines VKB (FG19).
KonMa_KonZ_ Berichte_weiterverarbeiten_ in_KonB	Dieser Testfall prüft die Weiterverarbeitung von Kontrollfällen mit einem Kontrollbericht über die KonZ_2.0 bis in die KonB. Die Überprüfung erfolgt für den Kontrollfall, Kontrollfalldaten bzw. die erfassten Beweismittel. Es wird die e-Akte in SC-OWI überprüft. Optional: Die Anreichung der e-Akte mit den zugehörigen DSRC-Daten prüfen.	Absicherung der Übermittlung von Fahrzeugkontrollfällen nach SC-OWI. Optional: Absicherung der DSRC-Daten-Anreicherung. Vollständigkeit und inhaltliche Richtigkeit der e-Akte in SC-OWI für Fahrzeugkontrollfälle prüfen.
KonMa_Mobile_Kontrolle	In diesem Testfall wird die Auslesung eines EETS-FzGs im Test-LKW mit einer KonMa im Modus mobile Kontrolle durchgeführt. Durchführung einer Mobilen Kontrolle. Die entsprechenden Daten des Kontrollfalls bei einer DSRC-/OBE-Auslesung werden vollständig und korrekt angezeigt.	Mit der KonMa wird eine Mobile Kontrolle gemäß den Testparametern erfolgreich durchgeführt. Die entsprechenden DSRC-Daten des Kontrollfalls werden vollständig und korrekt angezeigt (gemäß SST-Spezifikation 301). Die Fallgruppe wird durch die KonMa korrekt angezeigt.
KonMa_Standkontrolle_ Start_KB	In diesem Testfall wird die Auslesung eines EETS-FzGs im Test-LKW mit einer KonMa im Modus Standkontrolle mit dem Handheld durchgeführt. Das Test-FzG ist so eingestellt, dass das Fahrzeug damit im Gebiet BFStrMG nicht mautpflichtig ist. Bei der Kontrolle wird festgestellt, dass es sich bei dem Fahrzeug um ein mautpflichtiges Fahrzeug handelt und sich demnach eine FG7 (Nichtzahler) ergibt. Beginnen und Durchführung der Standkontrolle zum Erstellen eines Kontrollberichts. Auslesung der DSRC-Daten mit Handheld. Abschluss des Kontrollberichts.	Mit der KonMa wird eine Standkontrolle gemäß den genannten Testparametern im Szenario erfolgreich gestartet. Die entsprechenden Daten des Kontrollfalls werden vollständig und korrekt angezeigt (gemäß SST-Spezifikation 301). Es wird die Kontrollberichterstellung durchgeführt.
KonZ_2.0_DezKst_SVF	Die Test-Kontrollstelle erstellt einen Verdachtsfall und sendet diesen mit den Beweismitteln an die Test-KonZ_2.0. In der WebGUI wird nach dem KFZ-Kennzeichen selektiert und anhand des von der Test-Kontrollstelle gelesenen Kennzeichens überprüft. In diesem Testfall wird die Verarbeitung eines Verdachtsfalls in der Test-KonZ_2.0 einer durch die Test-Kontrollstelle durchgeführten Fahrt überprüft. Nach der Sachverhaltsfeststellung wird der Verdachtsfall in der Kontrollfallverwaltung verarbeitet, bis der fertige Kontrollfall an das SC-OWI (KonB) exportiert wird.	Überprüfung der korrekten Weiterleitung des Verdachtsfalls von der Kontrollstelle an die KonZ_2.0. Überprüfung aller relevanten DSRC-Parameter in der Kontrollzentrale (gemäß SST-Spezifikation 301).

Version	Datum	Bearbeiter	Bearbeitung/Änderung
0.1	17.09.2020	RT, BAG	Erstellung erster unvollständiger Entwurf
0.2	30.10.2020	RT, BAG	Überarbeitung nach Vorlage Prüfspezifikation KT MED
1.0	04.12.2020	RT, BAG	Überarbeitung nach Vorlage Prüfspezifikation KT MED v1.0, QS und Finalisierung
1.1	18.06.2021	RT, BAG	Ergänzung Fahrmanöver MF_09 und MF_10 in P1-KTM-001
1.2	01.03.2024	RT, BALM	Redaktionelle Überarbeitung entsprechend der Änderungen im BFStrMG und Umbenennung BAG in BALM

ID	Name	Beschreibung	Ziel
FS_01	Ortungstest	Es werden die in den folgenden Zeilen beschriebenen Messfahrten mit unterschiedlichen Fahrszenarien durchgeführt. Die durch die EETS-Fahrzeuggeräte aufgezeichneten Fahrspuren werden nach Abschluss aller Messfahrten ausgewertet.	Alle im Rahmen der Messfahrten eingesetzten EETS-Fahrzeuggeräte erfüllen die Qualitätsanforderungen hinsichtlich der Ortung.
	MF_01: Geradeausfahrt unter normalen Bedingungen	Mit diesem Test wird das normale am häufigsten auftretende Fahrverhalten der Nutzer getestet. Es werden alle Fahrten auf der Autobahn ohne besondere Einstellungen durchgeführt.	Das Verhalten der initialen Sensorfunktion der EETS-OBUs wird unter Normalbedingungen überprüft.
	MF_02: Autobahnfahrt/Landstraße – normales Fahren mit wechselnden Bedingungen	Fahrszenario zur Simulation von Fahrverhalten bei wechselnden Bedingungen. Es ist eine Testzeit von minimal 7,5 Stunden angesetzt, um Daten für typische reale GNSS-Empfangsbedingungen zu erhalten.	Das Langzeitverhalten und die Stabilität in einem typischen Produktivszenario werden getestet.
	MF_03: Gebirge	Fahrszenario zur Simulation von Fahrverhalten bei starken GNSS-Abschattungen und abwechslungsreichem Gelände.	Es wird das Verhalten der EETS-FzG bei Satellitenabschattung (Bäume, Berge) und gleichzeitig kurvenreicher Strecke getestet. Unter Umständen kann auch ein GNSS-Ausfall provoziert werden um das Aufsetzverhalten (Reakquisition) zu testen
	MF_04: Stadtfahrt	Fahrszenario zur Fahrt im eng bebauten Gebiet (Stadtfahrt). Eine Besonderheit bei den Stadtfahrten stellen Reflexionen des GPS-Signals dar. Dieser Test soll insbesondere die Fähigkeiten der Sensorfusion in solchen Fällen und die Handhabung von Multipath-Effekten in der GNSS-Hardware überprüfen	Es wird das Verhalten der EETS-FzG bei eng bebauten Straßen und hohen Gebäuden getestet
	MF_05: Achterfahrt unter normalen Bedingungen	Der Test prüft, ob die GNSS-Sensorik, -Algorithmik oder die Sensorfusion die Messergebnisse verzerren, verzögern oder verfälschen (z.B. die Kurven verziehen, überschwinden, stark abrunden, etc.).	Ziel dieser Tests ist es eine Abhängigkeit aus der ohne GNSS zurückgelegten Strecke, dem Streckenverlauf und der Abweichung über die Strecke zu ermitteln.
	MF_06: Rückwärtsfahrt/Wendemanöver	Fahrszenario zur Simulation von Fahrverhalten bei Park- und Wendemanövern.	Der Test prüft, ob bei Umkehrung der Fahrtrichtung die Sensorik die korrekte Bewegung vollzieht (oder ob z.B. stattdessen eine Vorwärtsfahrt erzeugt wird).
	MF_07: Langsamfahrt Autobahn (Stau)	Fahrszenario zur Simulation von Fahrverhalten bei geringen Geschwindigkeiten.	Das Verhalten bei langsamer Fahrt oder Beinahe-Stillstand unterscheidet sich erheblich vom Normalbetrieb. Dies wird mit diesem Test geprüft.
	MF_08: Wiederholte Autobahnfahrt	Bei diesem Testfall wird die wiederholte Auf- und Abfahrt auf Autobahnen simuliert. Dabei wird dazwischen jeweils ein gerades Stück Autobahn befahren. Dieser Test dient der Erkennung von möglicherweise auftretenden Drifts, also dem seitlichen „Abwandern“ der Positionen	Es wird das Verhalten der Geräte bei wiederholtem Wechsel von geradeaus befahrbaren Straßenabschnitten und Kurvensegmenten getestet.
	MF_09: Tunnelfahrt	Durchführung mehrere Tunnelbefahrungen zur Bewertung der Reakquisitionszeit nach Ausfahrt aus dem Tunnel.	Der Test bewertet die Reakquisitionszeit nach einer Tunnelbefahrung
	MF_10: Statischer Test (Stillstand)	Dieses Szenario dient der Simulation von Fahrverhalten bei Stillstand des Fahrzeugs.	Der Test bewertet die Einhaltung der Ortungsanforderungen beim Stillstand des Fahrzeugs.

Version	Datum	Bearbeiter	Bearbeitung/Änderung
0.1	17.09.2020	RT, BAG	Erstellung erster unvollständiger Entwurf
0.2	30.10.2020	RT, BAG	Überarbeitung nach Review und Abstimmung mit BAG und TC
1.0	04.12.2020	RT, BAG	QS und Finalisierung
1.1	01.03.2024	RT, BALM	Überarbeitung entsprechend der Änderungen des BFStrMG

ID	Name	Beschreibung	Ziel
P2.001.1	Befahrung des mautpflichtigen Streckennetzes	Mehrtägige Befahrung des deutschen mautpflichtigen Streckennetzes	Nachweis der Übermittlung korrekter Fahrspurdaten und Verarbeitung zu Mautbuchungsnachweisen
P2.001.2	Sonderfahrten - Änderung Achs- und Gewichtsklasse	Durchführung von Änderungen in den tarifrelevanten Fahrzeugparametern (Achs- und Gewichtsklasse) durch An- und Abhängen eines Anhängers innerhalb des deutschen Mautnetzes (BFStrMG), wobei das mautpflichtige Netz während der Testfalldurchführung nicht verlassen wird.	Nachweis der Übermittlung korrekter Fahrspurdaten inklusive veränderter tarifrelevanten Fahrzeugparametern und Verarbeitung zu Mautbuchungsnachweisen basierend auf den geänderten Fahrzeugparametern
P2.001.3	Sonderfahrten - Tausch des Bordgeräts in einem Fahrzeug	Das Bordgerät eines bereits beim EA registrierten Nutzers wird ausgetauscht und ein neues Bordgerät in das Fahrzeug installiert. Vor dem Tausch erfolgt eine Befahrung des mautpflichtigen Streckennetzes.	Nachweis der korrekten Aktualisierung und Übermittlung der Nutzerlisten an den Mauterheber im Falle des Tauschs eines Bordgeräts
P2.001.4	Sonderfahrten - Weitergabe des Bordgeräts an ein anderes Fahrzeug	Das Bordgerät eines bereits beim EA registrierten Nutzers wird aus dem Fahrzeug ausgebaut und in ein anderes Fahrzeug installiert. Vor dem Ausbau erfolgt eine Befahrung des mautpflichtigen Streckennetzes.	Nachweis der korrekten Aktualisierung und Übermittlung der Nutzerlisten an den Mauterheber im Falle der Weitergabe des Bordgeräts
P2.001.5	Zwangsbeendigung	Durchführung einer Befahrung des mautpflichtigen Netzes mit einer längeren Fahrtunterbrechung auf dem mautpflichtigen Netz	Nachweis der Übermittlung korrekter Fahrspurdaten und Verarbeitung zu Mautbuchungsnachweisen auch im Falle von längeren Fahrtunterbrechungen auf dem mautpflichtigen Netz
P2.001.6	Fahrt mit Fahrzeug unterhalb der Mautpflichtgrenze (≤ 3,5 t)	Durchführung einer Befahrung des mautpflichtigen Streckennetzes mit einem unterhalb der Mautpflichtgrenze deklarierten Bordgerät	Nachweis, dass keine Fahrspurdaten für nicht-mautpflichtige Fahrzeuge übermittelt werden
P2.001.7	Fahrt mit Fahrzeug ohne aktiven Vertrag für das Mautgebiet BFStrMG	Durchführung einer Befahrung des mautpflichtigen Streckennetzes mit einem Bordgerät ohne aktiven Vertrag für das Mautgebiet BFStrMG	Nachweis, dass keine Fahrspurdaten für Fahrzeuge ohne aktiven Vertrag für das Mautgebiet BFStrMG übermittelt werden

1.	Anlage [1]	– Prüfkatalog Schnittstellentests
2.	Anlage [2]	– Prüfkatalog DSRC-Kompatibilitätstests
3.	Anlage [3]	– Prüfkatalog MED-Kompatibilitätstests
4.	Anlage [4]	– Prüfkatalog Probebetrieb

Ausrüstung	Verantwortlich
Bereitstellung der für die Durchführung der Kontrolle notwendigen Einrichtungen	Nationaler Mautbetreiber i.A. des Mauterhebers
Bereitstellung, Betrieb und Administration der Schnittstellenprüfumgebung	Mauterheber
Bereitstellung, Betrieb und Administration der Testumgebung für die Kompatibilitätstests	Nationaler Mautbetreiber i.A. des Mauterhebers und Mauterheber
Bereitstellung, Betrieb und Administration des Ortungsreferenzsystems für die Kompatibilitätstests	Nationaler Mautbetreiber i.A. des Mauterhebers
Bereitstellung und Betrieb von Fahrzeugen für die Kompatibilitätstests, in die die Bordgeräte des EETS-Anbieters verbaut werden	Nationaler Mautbetreiber i.A. des Mauterhebers
betriebsbereites Zentralsystem im wirkbetriebsnahen Erprobungssystem oder im Wirkbetriebssystem des EETS-Anbieter	EETS-Anbieter
Bordgeräte in ausreichender Zahl samt notwendigem Zubehör (z.B. Verkabelung, Befestigungsmaterial)	EETS-Anbieter

Prüfszenario	Bezeichnung	Schwerpunkt der Prüfung
P1-SSP-001	Austausch von sicherheitsrelevanten Objekten (SST 004)	korrekter Austausch und Verwendung sicherheitsrelevanter Objekte
P1-SSP-002	technische Prüfung der Schnittstellen zwischen BALM Zentralsystem und EETS-Anbieter (SST 001, SST 002, SST 008, SST 099)	korrekter Kommunikationsablauf
P1-SSP-003	Verwalten der Nutzerliste (Userlist SST 002a)	Vollständigkeit und fachliche Korrektheit der Fahrzeug- und Bordgerätedaten
P1-SSP-004	Verwalten der Blocklist/Sperrliste (SST 001)	Vollständigkeit und fachliche Korrektheit der Blocklist/Sperrliste
P1-SSP-005	Verwalten von Nutzeradress- und Fahrzeugdaten (SST 002b)	Vollständigkeit und fachliche Korrektheit der Nutzeradress- und Fahrzeugdaten
P1-SSP-006	Verwalten der Fahrzeugliste von EETS-Nutzern (SST 002c)	Vollständigkeit und fachliche Korrektheit der Fahrzeugliste von EETS-Nutzern
P1-SSP-007	Erzeugung von Tagesberichten (SST 008)	fachliche Korrektheit der Tagesberichte
P1-SSP-008 (optional)	Übertragung der Mautbasisdaten (SST 003) an den EETS-Anbieter	Technische Funktionsfähigkeit der Übermittlung der Mautbasisdaten an den EETS-Anbieter. Die Durchführung ist optional, in Abhängigkeit davon, ob der EETS-Anbieter die Umsetzung der Schnittstelle beabsichtigt.

Prüfszenario	Bezeichnung	Schwerpunkt der Prüfung
DSRC - Kompatibilitätstests
P1-KTD-001	Betriebliche DSRC-Kompatibilitätstests der SST 301 – DSRC-Kommunikation	Einhaltung der betrieblichen und technischen Vorgaben der DSRC-Kommunikation
P1-KTD-002	Fachliche DSRC-Kompatibilitätstests der SST 301 – DSRC-Kommunikation	Korrekte fachliche Belegung der Informationen und Attribute der DSRC-Kommunikation
MED - Kompatibilitätstests
P1-KTM-001	Ortungstests der Bordgeräte	Prüfung der Einhaltung der Anforderungen an die Ortungsqualität
P1-KTM-002	Erhebungstest unter Alltagsbedingungen	Empfang und fachliche Korrektheit der Fahrspuren, Übermittlung von Mautbuchungsnachweisen, Übermittlung Auffälligkeiten bei Bordgeräten

Prüfszenario	Beschreibung
P2-001	korrekte Mauterhebung
P2-002	korrekte Abrechnung und Auskehr
P2-003	Überwachung des EETS-Anbieters
P2-004	Szenario ist entfallen
P2-005	korrekte Kontrollprozesse

Prüfszenario	Beschreibung
P0-001	Prüfung der Dokumentation des Teilsystems des EETS-Anbieters

Prüfszenario	Beschreibung
P3-001	korrekte Mauterhebung
P3-002	korrekte Abrechnung und Auskehr
P3-003	Überwachung des EETS-Anbieters
P3-004	Szenario ist entfallen
P3-005	korrekte Kontrollprozesse