V2X und C-V2X: Testen auf Konformität und Stabilität

Nicht nur, dass sich Fahrzeuge der verschiedenen Hersteller und Marken untereinander verständigen können müssen – mit der Einbeziehung der Infrastruktur in ein V2X-Netzwerk wächst die Anzahl der beteiligten Kommunikationsteilnehmer und damit zwangsläufig auch die Zahl von möglichen Fehlerquellen. Bisher war der Testumfang auf klar definierbare Systemgrenzen beschränkt, die sich aus der Bordnetzarchitektur, den darin eingebetteten Sensoren und den Daten, die Letztere liefern, ergeben haben. Restbussimulationen in HiL-Testumgebungen sind deshalb schon seit langem etabliert und Stand der Technik. Mit der V2X-Kommunikation kommen nun jedoch externe Datenquellen ins Spiel, ohne die ein funktionales Testen der V2X-Anwendung gar nicht möglich ist.

Bild 1: Ein Beispiel für ein Lasttest-Szenario: Vier V2X-Stationen erzeugen insgesamt 256 DENM-Nachrichten pro Sekunde. Das Szenario wird in einem Editor erstellt und kann jederzeit reproduziert werden. Nordsys

Beim Testen von Kommunikationslösungen ist die Konformität und Kompatibilität auf der physikalischen Ebene eine Grundvoraussetzung für eine erfolgreiche Übertragung von Informationen. Fragen wie Frequenzstabilität oder Out-of-Band-Emissionen sind auch bei V2X-Testlösungen grundlegende Testumfänge. Allerdings sind sie nur der Anfang von weiterführenden Testverfahren, die für eine erfolgreiche Kommunikation erforderlich sind. Auf Transport- und Protokollebene ist die Konformität gegen die entsprechenden Spezifikationen zu testen. Bereits an diesem Punkt unterscheiden sich die Testverfahren für V2X-Systeme von anderen Kommunikationsstandards wie etwa WiFi oder Bluetooth.

Beim Datenaustausch über V2X gibt es bei der Kommunikation keinen bidirektionalen Datenstrom, der auf dem Prinzip „Anfrage und Antwort“ beruht. Vielmehr verwenden die Teilnehmer in einem V2X Netzwerk in der Regel Broadcasts (in einigen Fällen auch Multi- oder Unicast), um Informationen auszutauschen. Je nach Nachrichtentyp lassen sich diese Broadcast-Nachrichten entweder periodisch oder bei Eintreten eines definierten Ereignisses generieren und aussenden. Die Datenstruktur der Nachrichten, sprich der Aufbau, Feldlängen, Datentypen sowie die gültigen Wertebereiche der einzelnen Datenelemente sind hierbei standardisiert.

Basistest auf Konformität mit TTCN-3

Bei der Konformitätsprüfung des Kommunikationsstacks – also der Teil, der für den korrekten Aufbau und den spezifikationskonformen Inhalt einer Nachricht verantwortlich ist, kommt üblicherweise TTCN-3 als Testsprache zum Einsatz. Dabei wird der V2X-Softwarestack über eine speziell hierfür implementierte Testschnittstelle mit Test-Daten beschickt und die Ausgabedaten mit dem erwarteten Ergebnis oder einem Ergebnismuster verglichen. Die Prüfung auf Protokoll-Konformität ist schon seit vielen Jahren in der Telekommunikationsbranche der Standard. Mit den entsprechenden Tools wie etwa Titan lassen sich diese Tests in TTCN-3 erstellen und ausführen.

Diese Vorgehensweise liefert jedoch nur insofern valide Ergebnisse, als dass der Prüflauf immer nur einen begrenzten Satz von Test-Daten verwendet. Ob sich das System-Under-Test bei vom Test abweichenden Input-Daten ebenfalls korrekt verhält, lässt sich anhand dieser Methode nicht feststellen. Der Test auf Konformität mit der zugrundeliegenden Spezifikation beschränkt sich deshalb auf Konformität gegenüber den Testfällen. Letztlich lässt sich über diese Testmethode nur punktuell prüfen, ob der Kommunikationsstack die eingehenden Nachrichten entsprechend der Spezifikation verarbeitet und ausgehende Nachrichten korrekt erzeugt. Die auf TTCN-3 basierenden Testverfahren entsprechen damit einer klinischen Stichprobenprüfung auf Konformität. Das Dilemma dabei ist, dass es rein rechnerisch selbst bei relativ einfach aufgebauten Nachrichtentypen (zum Beispiel DENM) etwa 1040 Wertekombinationen gibt, die der Kommunikationsstack alle korrekt und vor allen Dingen zuverlässig abarbeiten können muss. Das Abtesten sämtlicher Kombinationen ist aufgrund der schieren Menge nicht möglich.

V2X-Lasttests – wie lässt sich die Last erzeugen?

Bild 2: Ein realitätsnahes Verkehrsszenario mit vielen V2X-Netzwerkknoten und verschiedenen Nachrichtentypen, einer Stausituation und Ampeln. Im Laborprüfstand wave bee hive können solche komplexen Testszenarien geprüft werden. Nordsys

Die Stabilität eines V2X-Systems hängt unter anderem damit zusammen, wie es auf eingehende Nachrichten reagiert. Nachrichten, die der Spezifikation entsprechen, muss das System sicher und zuverlässig verarbeiten. Die Frage, wie robust ein System ist, hängt im Wesentlichen von zwei Faktoren ab: Toleranz gegenüber malformated Messages, also fehlerhaften Nachrichten, sowie das Verhalten bei sehr hoher Last. Die Durchführung von Lasttests im Bereich der V2X-Kommunikation führt schnell zu der Frage, wie sich eine hohe Last – sehr viele Nachrichten von vielen Netzwerkknoten – erzeugen lassen kann. Die naheliegendste Lösung für die Lasterzeugung wäre die Ausrüstung einer ganzen Fahrzeugflotte mit V2X-Sendern für die Testdurchführung. Theoretisch ist dies zwar möglich, der Aufwand hierfür jedoch viel zu groß.

Bleibt die Installation und der Betrieb von hunderten V2X-Modems im Labor als Lastquelle? Allein der Anschaffungs- und Installationsaufwand wäre enorm. Der Betrieb auf engem Raum, etwa in einer Testkammer, ist auch angesichts der damit einhergehenden EMV-Probleme nicht ratsam. Hinzu kommt, dass die Modems alle gesteuert und synchronisiert sein müssen, um später reproduzierbare Testläufe für Regressionstests durchführen zu können. Ein weiterer Punkt, den es bei Lasttests zu berücksichtigen gilt, sind die verschiedenen Nachrichtentypen. In einem realen Lastszenario, wie es auch auf einer viel befahrenen, mehrspurigen Kreuzung der Fall ist, sind neben einer Vielzahl von CAM- und DENM- beziehungsweise BSM-Nachrichten auch noch Spatem-, Mapem- oder IVIM-Nachrichten in den Lasttest mit einzubeziehen. Die Anzahl der Nachrichten kann aber schnell bis zur Kanalauslastung führen. Die Betrachtung unterschiedlicher Nachrichtentypen ist deshalb erforderlich, da sich der Rechenaufwand bei den verschiedenen Nachrichtentypen unterscheidet. Ebenso spielen die Sendefrequenz und die Anzahl der Netzwerkknoten bei den Tests eine Rolle.

Das kleine 1×1 der Lastgenerierung

Es lassen sich beispielsweise 1000 Nachrichten pro Sekunde von 100 Netzkonten bei 10 Hz erzeugen, oder aber eben auch von 200 Netzkonten bei 5 Hz. In den beiden skizzierten Fällen sind zwar jeweils 1000 Nachrichten pro Sekunde für den Test das Volumen, die dabei entstehende Last für das zu prüfende System ist jedoch verschieden. Da in den derzeit spezifizierten Nachrichten nicht alle Datenelemente verpflichtend mit Werten befüllt sein müssen, lässt auch der Aspekt des tatsächlichen Payloads – also des Nachrichteninhalts – viel Spielraum für noch weiterführende Setups bei der Durchführung von Lasttests. Die derzeit häufig in Lastenheften gestellte Anforderung, dass das V2X-System x-tausend Nachrichten pro Sekunde verarbeiten können muss, greift daher ohne nähere Definitionen nach den oben skizzierten Kriterien viel zu kurz, ist aber in der Praxis weit verbreitet.

Die Teilnahme im V2X-Netzwerk ist im Realbetrieb mittels Zertifikatsketten abgesichert und wird auch als Security bezeichnet. Ausgehende Nachrichten sind dabei mit einem über den Nachrichteninhalt gebildeten Hash-Wert signiert. Die Empfängerseite validiert den Hash-Wert und damit die Gültigkeit des auf Senderseite verwendeten Zertifikats. Somit kann der Empfänger die Vertrauenswürdigkeit des Senders und des Nachrichteninhalts feststellen. Das bedeutet, dass alle eingehenden Nachrichten aller Netzwerkteilnehmer, entsprechend zu prüfen sind. Für die Durchführung von Lasttests bedeutet dies, dass sowohl die Validationsgeschwindigkeit von Nachrichten auf Empfängerseite und die Signierungsgeschwindigkeit von Nachrichten auf Senderseite, zu prüfen ist. Dabei ist die Anzahl der Nachrichten, die zu validieren sind, wesentlich größer. Um einen Lasttest korrekt durchzuführen, müssen alle Knoten im Netzwerk mit jeweils eigenen Zertifikaten für das Signieren der Nachrichten ausgestattet sein. Das heißt, dass alle eingehenden Nachrichten beim Prüfling mit einer für den Absender spezifischen Signatur versehen sind und jeweils zu verifizieren sind. Die Verwendung von denselben Zertifikaten für verschiedene Sender führt zu einem wenig aussagekräftigen Testergebnis, da das Verfizieren der mittels der Zertifikate erzeugten Signaturen nicht für jeden Netzwerkknoten separat durchgeführt werden muss, wie dies im realen Betrieb der Fall ist.

Blick auf die Applikationsebene

Bild 3: Detailsicht auf eine Stausituation an einer Autobahnabfahrt mit sich anschließender Ampelkreuzung. Die Anzahl der V2X-Netzknoten steigt in einem solchen Fall schnell an und erfordert entsprechende Tests. Nordsys

Für eine funktionierende V2X-Kommunikation ist die Standardisierung der Kommunikation unerlässlich. Naheliegend ist die Standardisierung nach dem OSI-Referenzmodell auf den Schichten eins bis fünf. In Wirklichkeit geht die erforderliche Standardisierung jedoch noch weiter und umfasst neben allen sieben OSI-Schichten noch zusätzlich die auf Schicht sieben aufsetzende ITS-Anwendungsebene (IST; Intelligent Transportation Systems). Voriges gilt zumindest für den Fall, dass das System ereignisgetriggerte Daten erzeugen und aussenden soll. Auf Seite des Empfängers ist die ITS-Anwendungsebene dagegen nicht näher standardisiert. Der Empfänger kann weitgehend selbst entscheiden, ob und wie er die empfangenen Daten verarbeitet.

Ein vereinfachtes Beispiel soll den beschriebenen Sachverhalt verdeutlichen: Die ITS-Anwendung Slow or Stationary Vehicle Warning (SSVW) soll vor langsam fahrenden oder stehenden Fahrzeugen warnen. Hierzu muss unter anderem definiert sein, ab wann ein Fahrzeug als stehendes Hindernis zu betrachten ist und bis zu welcher Geschwindigkeit es als langsam gilt. Die Bedingungen, unter denen dann die entsprechende Warnnachricht sich in Form einer DENM (Decentralized Enviromental Notification Message) erzeugen und senden lassen darf, sind entsprechend standardisiert. Die DENM selbst muss als Nachricht natürlich auch standardisiert sein.

Infrastruktur – alle reden mit

Externe Daten können von anderen Fahrzeugen stammen (V2V-Kommunikation) oder von der Infrastruktur (I2V-Kommunikation), wie etwa Lichtsignalanlagen. Insofern ist bei Testlösungen nicht nur der Restbus des eigenen Fahrzeuges zu betrachten, sondern insbesondere die Simulation des verkehrlichen Umfelds. In Analogie zum Bordnetz-Restbussimulation lässt sich diese als Restverkehrssimulation auf Ebene der V2X-Nachrichten bezeichnen.

Bild 4: Aufbau-Schema des Nordsys Test-Setup-Hil für wave bee hive. Nordsys

Da die Installation von hunderten V2X-Modems weder zur Erzeugung der beschriebenen Netzwerklast noch zur Restverkehrssimulation realisierbar ist, stellt sich die Frage, wie sich die zuvor geschilderten Tests mit vertretbarem Aufwand überhaupt durchführen lassen. Die Erzeugung von Netzwerklast wie auch des Restverkehrs kann in einem V2X-Netzwerk auch über simulierte Netzwerkteilnehmer erfolgen. Eine solche Netzwerksimulation stellt die Testlösung wave bee hive (hive = Bienenstock) von Nordsys bereit. Mit fünf Modems lassen sich bis zu 100 Netzknoten vollständig und inklusive Security abbilden, wobei das System nach oben skalierbar ist.

Die Restverkehrssimulation wie auch Netzknoten für die Lasterzeugung lassen sich per Mausklick in der im Teststand integrierten Software erzeugen. Die auf diese Weise erzeugten Testfälle oder auch komplexe Testszenarien sind zeitlich und räumlich reproduzierbar. Als Option lassen sich Verkehrssimulationen an den Teststand einbinden, wobei auch hier die Reproduzierbarkeit gegeben ist. Gerade die Reproduzierbarkeit von Testfällen für Regressionstests stellt bei V2X-Nachrichten ein Problem dar. Da die Nachrichten mit Zertifikaten zu signieren und über den Inhalt zu hashen sind, reicht ein simples Abspielen von Testdaten nicht aus. Der Test schlägt fehl, weil der Device Under Test weder Zeitstempel noch Signaturen als gültig einstufen würde.

(aok)