Startseite » Branchen » Automobil »

So gelingen Softwaretests für das autonome Fahren

V2X-Kommunikation
Testen unter Volllast

Anzeige
Die Vehicle to everything (V2X) Kommunikation ist eine Voraussetzung für das autonome Fahren. Doch Fahrzeuge vieler Hersteller müssen sich untereinander verständigen können. Zudem wächst die Anzahl der beteiligten Kommunikationsteilnehmer und damit auch die Zahl möglicher Fehlerquellen. Damit erbeben sich hohe Anforderungen an Softwaretests.

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. Sprich: 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 muss die Konformität gegen die entsprechenden Spezifikationen getestet werden. Bereits an diesem Punkt unterscheiden sich die Testverfahren für V2X-Systeme von anderen Kommunikationsstandards wie etwa Wifi oder Bluetooth. Um diesen Zusammenhang besser zu verstehen, ist ein gedanklicher Ausflug in die generelle Funktionsweise der V2X-Kommunikation erforderlich:

Beim Datenaustausch über V2X gibt es bei der Kommunikation keinen bidirektionale 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 werden diese Broadcast-Nachrichten entweder periodisch oder bei Eintreten eines definierten Ereignisses (Events) generiert und ausgesendet. Die Datenstruktur der Nachrichten, sprich der Aufbau, Feldlängen, Datentypen sowie die gültigen Wertebereiche der einzelnen Datenelemente sind hierbei standardisiert. Wobei an dieser Stelle anzumerken ist, dass es nicht einen weltweiten Standard für die Nachrichtenformate gibt, sondern verschiedene.

Bei der Konformitätsprüfung des Kommunikationsstacks – also der Teil, der für den korrekten Aufbau und den spezifikationskonformen Inhalt einer Nachricht verantwortlich ist – wird üblicherweise auf TTCN-3 als Testsprache gesetzt. 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 wird schon seit vielen Jahren in der Telekommunikationsbranche verwendet und hat sich bewährt. Mit den entsprechenden Tools wie etwa Titan können diese Tests in TTCN-3 erstellt und ausgeführt werden.

Diese Vorgehensweise ist in sich korrekt und Stand der Technik, sie 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 kann über diese Testmethode nur punktuell geprüft werden, 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 etwa 1040 Wertekombinationen gibt, die der Kommunikationsstack alle korrekt und zuverlässig abarbeiten können muss. Das Testen sämtlicher Kombinationen ist aufgrund der schieren Menge nicht möglich.

Wie lässt sich für V2X-Lasttests
die Last erzeugen?

Die Stabilität eines V2X-Systems hängt unter anderem damit zusammen, wie es auf eingehende Nachrichten reagiert. Nachrichten, die der Spezifikation entsprechen, müssen selbstredend sicher und zuverlässig verarbeitet werden. 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 eine hohe Last – sprich sehr viele Nachrichten von vielen Netzwerkknoten – erzeugt werden 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. Doch der Aufwand hierfür ist viel zu groß. Dies gilt auch für die Installation und den Betrieb von hunderten V2X-Modems im Labor als Lastquelle. 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, die man einbeziehen müsste. Betrachtet man die Verkehrssituation zum Beispiel in den Großstädten Chinas mit mehrstöckigen Fahrbahnen, wird schnell klar, dass die Anzahl der Nachrichten bis zur Kanalauslastung führen kann. Die Betrachtung unterschiedlicher Nachrichtentypen ist deshalb erforderlich, da der Rechenaufwand sich bei den verschiedenen Nachrichtentypen unterscheidet. Ebenso spielen die Sendefrequenz und die Anzahl der Netzwerkknoten bei den Tests eine Rolle.

So können beispielsweise 1.000 Nachrichten pro Sekunde von 100 Netzkonten bei 10 Hz erzeugt werden, oder aber eben auch von 200 Netzkonten bei 5 Hz. In den beiden skizzierten Fällen werden zwar jeweils 1.000 Nachrichten pro Sekunde für den Test herangezogen, die dabei entstehende Last für das zu prüfende System ist jedoch verschieden. Wie bereits erwähnt, spielt es auch eine Rolle, um welche Nachrichtentypen es sich handelt. 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, „das V2X-System muss x-tausend Nachrichten pro Sekunde verarbeiten können“ greift daher ohne nähere Definitionen nach den skizzierten Kriterien viel zu kurz.

Die Teilnahme im V2X-Netzwerk ist im Realbetrieb mittels Zertifikatsketten abgesichert. Gemeinhin wird dies als Security bezeichnet. Ausgehende Nachrichten werden 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 geprüft werden sollten.

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 geprüft werden muss. Dabei ist die Anzahl der Nachrichten, die Validiert werden müssen, 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 bedeutet, dass alle eingehenden Nachrichten beim Prüfling mit einer für den Absender spezifischen Signatur versehen sind und jeweils verifiziert werden müssen. 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.

Auf die Signaturen kommt es an

Die Durchführung von realitätsnahen Lasttests kann letztlich nur mittels signierter Nachrichten erfolgen. Insofern bietet es sich an, auch das korrekte Signieren und Verifizieren durch den Prüfling im Testsystem mit zu berücksichtigen. Dabei ist zu prüfen, ob der Prüfling korrekte Signaturen aus validen Zertifikaten erzeugt. In der Empfangsrichtung müssen das Device und der Test gültige Signaturen erkennen und die Nachrichteninhalte anschließend verarbeiten. Im Fall des Empfangs von nicht signierten oder ungültig signierten Nachrichten muss das System dies zumindest erkennen. Wie mit solchen Nachrichten dann zu verfahren ist, bleibt dem jeweiligen Hersteller überlassen. In der Regel werden ungültig signierte Nachrichten verworfen.

Für eine funktionierende V2X-Kommunikation ist die Standardisierung der Kommunikation unerlässlich. Naheliegend ist die Standardisierung nach dem OSI-Referenzmodell auf den Schichten 1–5. In Wirklichkeit geht die erforderliche Standardisierung jedoch noch weiter und umfasst neben allen sieben OSI-Schichten noch zusätzlich die auf Schicht 7 aufsetzende ITS-Anwendungsebene (ITS = Intelligent Transportation Systems). Voriges gilt zumindest für den Fall, dass ereignisgetriggerte Daten erzeugt und ausgesendet werden sollen. Auf Seite des Empfängers ist die ITS-Anwendungsebene dagegen nicht näher standardisiert. Das heißt, der Empfänger kann weitgehend selbst entscheiden, ob und wie er die empfangenen Daten verarbeitet.

Das Szenario erfordert für funktionale Tests eine andere Vorgehensweise als für in sich geschlossene Bordnetze: Bestandteil des Testszenarios ist nicht mehr nur die Restbussimulation wie im fahrzeugeignen Bordnetz. Es muss zusätzlich eine Restverkehrssimulation bereit gestellt werden, die zumindest die Nachrichten auf der Luftschnittstelle möglichst realitätsnah abbildet. Eine nähergehende Betrachtung des umgebenden Verkehrs ist meist nicht nötig, denn letztlich sind nur die ausgesendeten Nachrichten für den Test entscheidend.

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 (das Ego-Fahrzeug) zu betrachten, sondern insbesondere die Simulation des verkehrlichen Umfelds. In Analogie zur Bordnetz-Restbussimulation kann diese als „Restverkehrssimulation“ auf Ebene der V2X-Nachrichten bezeichnet werden. ■

Nordsys GmbH
Mittelweg 7
38106 Braunschweig
Tel. +495312969880
www.nordsys.de


Der Autor

Manfred Miller
Geschäftsführender
Gesellschafter
Nordsys
www.nordsys.de

Anzeige
Newsletter

Jetzt unseren Newsletter abonnieren

Videos Control 2019

Die besten Videos von der Messe

Quality Engineering
Titelbild QUALITY ENGINEERING 5
Ausgabe
5.2020
LESEN
ABO
Webinare & Webcasts

Technisches Wissen aus erster Hand

Whitepaper

Whitepaper zum Thema QS

Anzeige
Anzeige

Industrie.de Infoservice
Vielen Dank für Ihre Bestellung!
Sie erhalten in Kürze eine Bestätigung per E-Mail.
Von Ihnen ausgesucht:
Weitere Informationen gewünscht?
Einfach neue Dokumente auswählen
und zuletzt Adresse eingeben.
Wie funktioniert der Industrie.de Infoservice?
Zur Hilfeseite »
Ihre Adresse:














Die Konradin Verlag Robert Kohlhammer GmbH erhebt, verarbeitet und nutzt die Daten, die der Nutzer bei der Registrierung zum Industrie.de Infoservice freiwillig zur Verfügung stellt, zum Zwecke der Erfüllung dieses Nutzungsverhältnisses. Der Nutzer erhält damit Zugang zu den Dokumenten des Industrie.de Infoservice.
AGB
datenschutz-online@konradin.de