Car2X-Kommunikation, auch als

Transkript

1 Car2X von der Forschung zur Serienentwicklung Für den Verantwortlichen in der Serienentwicklung ergeben sich bei Car2X-Systemen neue Herausforderungen. Zum einen kommuniziert das zu evaluierende Car2X-Steuergerät mit vielen Fahrzeugen und Baken in seinem Umfeld. Dadurch erhöhen sich die Anzahl der ausgetauschten Informationen sowie deren Komplexität erheblich im Vergleich zur bisherigen Netzwerkentwicklung im Serienfahrzeug. Zum anderen haben IP- Standards inzwischen Einzug ins Fahrzeug gehalten, die nach IEEE p ist für die meisten Entwickler allerdings noch Neuland. Mit darauf abgestimmten Werkzeugen lassen sich diese Herausforderungen bereits meistern. Von Hans-Werner Schaal und Thomas Löffler Car2X-Kommunikation, auch als Vehicle-to-Vehicle- und Vehicleto-Infrastructure-Communication bekannt, ist der Austausch von Informationen zwischen Verkehrsteilnehmern und Infrastruktur. Ziel soll es sein, Sicherheit und Komfort zu erhöhen sowie den Verkehrsfluss zu optimieren. Das technische Gesamtsystem zur Sicherstellung von Car2X-Kommunikation wird als Intelligent Transport System (ITS) bezeichnet. Das Basiskonzept der Car2X-Kommunikation beruht auf dem Senden und Empfangen standardisierter Nachrichten über die sowie der Interpretation der enthaltenen Statusinformationen durch die Verkehrsteilnehmer. Gemäß der momentanen Verkehrssituation hält die (ITS-S) die Nachrichten stets aktuell und sendet diese zyklisch oder ereignisgesteuert. Die wichtigsten Statusinformationen werden über die Nachrichten Cooperative Aware ness Message (CAM), Decentralized Environmental Notification Message (DENM), Signal Phase and Time (SPaT) und Topology Specification (TO- PO) übertragen. Das Europäische Institut für Telekommunikationsnormierung (ETSI) hat die CAM- und DENM-Nachrichten bereits spezifiziert. SPaT und TOPO werden zur Zeit projektbezogen gehandhabt. Intelligente Verarbeitungseinheiten der empfangenden Verkehrsteilnehmer beispielsweise eines Fahrzeugs haben dadurch die Mög-

2 ! A WLAN-Empfangsbereich! B WLAN-Empfangsbereich Bild 1. Fahrzeug A bleibt liegen und sendet über sein ITS-S DENM-Nachrichten an Verkehrsteilnehmer B und C in seinem Umfeld. Diese erweitern den Empfangsbereich durch Weiterleitung der Nachricht. C Die ITS-S muss aus dem Kontext ihres Umfelds, also aus der Summe der von verschiedenen Quellen erhaltenen Nachrichten CAM, DENM, SPaT und TO- PO, ein hinreichend komplettes Bild der Verkehrssituation ab- und Maßnahmen für das eigene Fahrzeug einleiten. Die Echtzeitanforderungen sind dabei hoch. Nach Spezifikation müssen DENM im obigen Beispiel zwar nur mit 10 Hz aktualisiert werden. Allerdings wird die geforderte Latenzzeit im obigen Szenario mit weniger als 100 ms angegeben [1]. Eine Übertragung über GSM ist damit nicht mehr realistisch. Nur mit der WLAN-Technologie nach IEEE p oder LTE ist diese Echtzeitanforderung realisierbar. Die ITS-S von Fahrzeugen im Empfangsbereich müssen zunächst entscheiden, ob empfangene Nachrichten für das eigene Fahrzeug relevant sind: zum einen, ob sie betroffen sind, und zum anderen, ob sie weiterleiten. Betroffen sind sie, wenn sie sich auf derselben Straße befinden oder auf dem Weg dorthin. Das lässt sich über die Botschaftsinhalte Richtung (Heading) der empfangenen CAM-Nachricht und Wegepunkte (Waypoints) in der Nachricht DENM ermitteln. Weiter spielen der Kurs des eigenen Fahrzeugs sowie Informationen über Topologie und Status von Ampelanlagen eine Rolle. Schließlich muss die ITS-S bewerten, ob die Information für das Umfeld potenziell relevant ist. Wenn das der Fall ist, muss es diese korrekt weiterleiten. Software-Entwicklungswerkzeuge können den Systemverantwortlichen in allen Phasen entlang des V-Modells dabei unterstützen, die Funktion der ITS-S sicherzustellen. Anders als bei der auf ein einzelnes Fahrzeug beschränkten Netzwerkentwicklung ist die Betrachtung des Umfelds dabei unabdingbar. An das Werkzeug ergeben sich dabei die nachfolgenden Anforderungen. lichkeit, die sie unmittelbar betreffende Verkehrssituation weiträumig zu erfassen, den Fahrzeugführer bei Bedarf zu warnen, zu unterstützen oder sogar in die Fahrzeugführung einzugreifen. Szenario: ein liegengebliebenes Fahrzeug Am Beispiel eines von der ETSI definierten Car2X-Szenarios [1] werden im Folgenden die Anforderungen an Entwicklungswerkzeuge, die den Systemverantwortlichen der ITS-S bei der Entwicklung und Validierung unterstützen, abgeleitet. Ähnliche Verkehrsszenarien sind auch beim CAR 2 CAR Communication Consortium oder beim Projekt DRIVE C2X beschrieben [2]. Im Szenario Car Breakdown Warning soll vermieden werden, dass ein liegengebliebenes Fahrzeug für den nachfolgenden Verkehr eine Gefahr oder gar eine Unfallursache darstellt. Daher sendet die ITS-S des Fahrzeugs A eine standardisierte Nachricht, die innerhalb seines WLAN-Sendebereichs empfangen werden kann (Bild 1). Ein herannahendes Fahrzeug B empfängt, verarbeitet und leitet diese Nachricht weiter. Der WLAN-Sendebereich erweitert sich dadurch, so dass selbst entfernte Fahrzeuge C und Baken (Road Side Units, RSU) die Nachricht empfangen und ebenfalls weiterleiten können. Somit hat Fahrzeug C die Möglichkeit, den Gefahrenbereich noch zu umfahren. Dank der frühzeitigen Warnung kann Fahrzeug B rechtzeitig abbremsen, wenn etwa die Sicht durch Nebel oder Hindernisse eingeschränkt ist. Um Aktualität sicherzustellen und Fehlinformation zu vermeiden, wird unterschieden, ob die Nachricht von der ursprünglichen Quelle A stammt oder nur durch Sender, also die Empfängerfahrzeuge B und C, weitergeleitet wurde. Weil weitergeleitete Nachrichten zusätzlich eine Lebenszeit haben, werden sie nur über eine bestimmte Zeitspanne weitergegeben. Aufgrund der Geoposition und eines definierten Ausbreitungsgebietes (Dissemination Area) ist zudem festgelegt, ob die Fahrzeuge B oder C die Nachricht überhaupt weiterleiten. Anforderungen an die im Szenario Fehlersuche an der Messtechnisch lässt sich das obig dargestellte Szenario auf Bild 2 reduzieren, gegebenenfalls mit einer höheren Anzahl von en. Die Funktion der ITS-S ist zwar standardisiert, doch wird sie von unterschiedlichen Herstellern implementiert. Im Fehlerfall muss zunächst in der Regel analysiert werden, ob alle Beteiligten auf demselben Funkkanal senden und empfangen. Daher ist es notwendig, die als Kommunikationsmedium zu unterstützen. Erst wenn nachgewiesen ist, dass die Kommunikation über die korrekt funktioniert, ist eine Protokollanalyse sinnvoll. Protokollanalyse Der Verantwortliche für den ITS-S-Systemtest in der Serienentwicklung ist darauf angewiesen, dass ihm empfangene Nachrichteninhalte im Entwicklungswerkzeug applikationsorientiert präsentiert werden, also entweder als physikalische Größe mit Einheit oder interpretiert. So müssen die Signale Generation Time (in CAM und DENM) mit Einheit und das CAM-Signal Vehicle Type interpretiert, also beispielsweise als Car oder Motor Cycle dar- Hersteller 1 Hersteller 2 Analysewerkzeug Bild 2. Herausforderung : Die Überprüfung des Datenverkehrs kann nur mit einem IEEE p-kompatiblen Analysewerkzeug erfolgen. 20 Elektronik automotive

3 gestellt werden. Entsprechendes gilt für die DENM-Signale Event Position (mit Breitengrad, Längengrad) oder Cause Code (interpretiert). Visualisierung der Fahrzeugsignale auf einer geografischen Karte Leider ist selbst die interpretierte Darstellung der Botschaftsinhalte mit Filtermöglichkeit aufgrund der Anzahl der Verkehrsteilnehmer und der Komplexität der Kommunikation oft nicht ausreichend. Wichtiges muss unmittelbar erkennbar sein auch wenn es aus der Menge interpretierter Information nicht offensichtlich ist. Das oben beschriebene Szenario verdeutlicht, dass die Relevanz eines Car2X-Signals für das empfangende Fahrzeug nur im Kontext weiterer Verkehrsteilnehmer seines relevanten Umfelds ermittelt werden kann. Damit lässt es sich auch nur in diesem Kontext validieren. Zur Validierung müssen unter anderem die Geopositionen und die Richtungsvektoren der beteiligten Fahrzeuge in Betracht gezogen werden. Zur Klärung der Relevanz bietet sich eine Kartendarstellung an (Bild 3), die sich im Praxistest, zum Beispiel auf dem Testgelände in Helmond, Niederlande [3] und bei der Integrationsunterstützung des ITS World Congress [4] in Wien schon bewährt hat. Die Auswertung vereinfacht sich für den Entwickler deutlich, wenn den Sendern individuelle Zusatzinformationen wie Fabrikat, Fahrzeugtyp, Modell oder Nummernschild zugeordnet sind. Intuitive Symbole und Farb-Codes ermöglichen einen leichten Überblick über die Situation. So sind auf der Karte in Bild 3 mobile Sender als Pfeil, Wegepunkte als Fahne und RSUs als Kreise dargestellt. Probleme mit falsch gesendeter Fahrtrichtung (Heading) sind so im Gegensatz zur reinen Protokolldarstellung (Bild 4) unmittelbar erkennbar. Darüber hinaus lassen sich in die Karte topologische Informationen (TOPO) und Gefahreninformationen (DENM) einblenden, die für viele Szenarien ebenfalls eine Rolle spielen. Unmittelbare Verfügbarkeit und schnelle Rekonfiguration In der Praxis ist es hilfreich, wenn das Testsystem den kompletten Datenverkehr ohne große Rüstzeit sofort darstellen kann. Hierzu ist die Kenntnis des zugrundeliegenden Datenmodells erforderlich, das üblicherweise über Abstract Syntax Notation.1 (ASN.1) definiert ist. Allerdings kann ASN.1 keine Netzwerke darstellen und es fehlt die angesprochene Möglichkeit, Signale mit physikalischen Einheiten zu verwalten. Darum müssen diese Informationen ergänzend zur ASN.1-Beschreibung leicht im Analyse- und Entwicklungswerkzeug parametrierbar sein. Die ASN.1- Datei hingegen ist idealerweise automatisch importierbar. Wenn die Kommunikationsregeln aufgrund von Updates verändert werden, stehen dadurch die neuen Signalwerte im Werkzeug sofort wieder zur Verfügung ohne dass hierfür etwa rekompiliert werden muss. Stimulation und Simulation Selbst bei funktionierenden Prototypen besteht oft der Wunsch, an der Kommunikation aktiv teilzunehmen und

4 Bild 3. In der Karte werden Fahrzeuge mit Richtungspfeil und RSUs mit Kreisen dargestellt. Die in der DENM übertragenen Gefahreninformationen und die Wegepunkte, die zu dieser Gefahrenstelle führen, werden ebenso dargestellt wie das für diese Gefahr definierte Ausbreitungsgebiet der Nachricht. beispielsweise einzelne CAM-, DENM-, SPaT- oder TOPO-Nachrichten korrekt oder gar verfälscht zu senden. Dadurch prüft der Car2X-Entwickler erste Prototypen durch gezielte Stimulation effizient. Allerdings muss dazu das Entwicklungswerkzeug protokoll- und luftschnittstellenkonform sendefähig sein. Bei Testfahrten ist es hilfreich, RSUs oder andere Fahrzeuge, die in der Realität gar nicht vorhanden sind, in der vorher eingeführten Kartendarstellung einzublenden. Das Entwicklungswerkzeug kann so auf der Testfahrt die Rolle einzelner oder gar aller anderen Verkehrsteilnehmer übernehmen und deren Kommunikation auf der simulieren. Für das auf der Testfahrt befindliche ITS-S ist dann nicht erkennbar, ob empfangene Car2X-Signale der Realität oder der Simulation entstammen. Das setzt voraus, dass für alle Verkehrsteilnehmer separate Software-Modelle hinterlegt werden können, die einzeln aktivierbar sind und mit der Kartendarstellung verbunden werden können. Kompatibel zur Entwicklungsstrategie bisheriger Bussysteme simuliert. Weil die ITS-S in der Regel auch Teilnehmer an einem der oben genannten Fahrzeugbusse ist, bietet sich die Restbussimulation hier ebenfalls an. Entwicklungswerkzeuge für die Car2X-Kommunikation Wie müssen die geforderten Car2X-Erweiterungen für ein Entwicklungs- und Validierungswerkzeug für den Serieneinsatz aussehen? Der Schlüssel zur Lösung ist die Verbindung der obigen Ansätze mit den in der Automobilbranche üblichen und bewährten Vorgehensweisen bei der konventionellen Netzwerkentwicklung. Als Multibus- Werkzeuge haben sich CANoe und CANalyzer bei der Entwicklung der Fahrzeug-Bordnetze CAN, LIN, FlexRay, MOST und IP bewährt. Mit der Option Car2X werden diese Werkzeuge für die Entwicklung von Komfort- und Fahrerassistenzfunktionen erweitert. Hierzu wird der in Bild 5 dargestellte Simulationsaufbau um die ergänzt. Das Testsystem ersetzt bei Bedarf das gesamte Umfeld der ITS-S und kann sowohl senden als auch empfangen. Dabei sind die genannten Anforderungen Protokollanalyse, schnelle Rekonfiguration und Visualisierung durch eine Kartendarstellung bereits berücksichtigt. Um bei der Validierung gezielt Störinformation zu senden, steht der WLAN Packet Builder mit einer intuitiven Bedienoberfläche zur Verfügung. Er ermöglicht es, korrekte und verfälschte pwlan-pakete zu Testzwecken komfortabel zu erstellen und zu senden. Für komplexere Simulationen von Verkehrsszenarien mit Fahrzeugen und der Infrastruktur nutzt der Car2X-Entwickler spezifische, in CAPL oder als DLL bereitgestellte Funktionsbibliotheken. CANalyzer.Car2x deckt die wichtigsten Anforderungen an ein Car2X-Entwicklungswerkzeug, wie Protokollanalyse, Unterstützung der und Stimulation, bereits ab. Die Visualisierungs- und die schnelle Rekonfigurationsmöglichkeit erhöhen zudem die Nutzbarkeit des Entwicklungswerkzeugs erheblich. Darüber hinaus erweitert CANoe.Car2x den Anwendungsbereich um vielfältige Simulations- und Testfunktionen. Ausblick Zukünftige, auf ITS-S gestützte Fahrerassistenzsysteme werden weitere Fahrzeugdynamikdaten ergänzend zur Car2X-Kommunikation mit einbeziehen müssen, die an CAN-, FlexRay- oder IP- Netzwerken im Fahrzeug anliegen. Es wird daher zunehmend wichtig, dass das Entwicklungssystem sowohl die Car2X-Kommunikation als auch die Kommunikation auf den konventionellen Bussystemen zeitstempelgetreu und mehrkanalig darstellen kann. CA- Noe.Car2x und CANalyzer.Car2x sind dafür heute schon gerüstet. Bei der Analyse leistet das Kartenfenster einen wichtigen Beitrag. Der Aktuelle Fahrzeugnetzwerke basieren auf CAN, FlexRay, LIN, MOST und seit neuestem auch auf IP, zum Beispiel in Form der BroadR-Reach-Technologie [5]. Bei der Entwicklung einzelner Steuergeräte ist die Methodik der Restbussimulation gebräuchlich. Steuergeräte lassen sich damit parallel und unabhängig voneinander entwickeln. Der für das betrachtete Steuergerät relevante, aber noch nicht zur Verfügung stehende Netzwerkteil wird durch das Entwicklungswerkzeug in der Software Bild 4. Protokolldarstellung von Car2X-Informationen im Trace-Fenster von CANoe und CANalyzer. 22 Elektronik automotive

5 ASN.1 Knoten physik. Parameter Datenbasis Entwicklungswerkzeug Simulation der Verkehrsteilnehmer Virtuelles Teilsystem (eigenes Fahrzeug) CAN CAN (ECU under Test) I/O analoge und digitale I/Os, Zähler, PWM, etc. Validierung Test- Report XML/HTML Bild 5. ITS-S-Testsystem: Das Testsystem ersetzt bei Bedarf das gesamte Umfeld der und kann sowohl senden als auch empfangen. Der übliche Simulationsaufbau wird um die erweitert. Das ITS-S kann wie in der Realität über und lokale Bussysteme kommunizieren. (Bilder: Vector Informatik GmbH) nächste Entwicklungsschritt könnte sein, über diese Karte Szenarien und Rahmenbedingungen des Verhaltens der simulierten Verkehrsteilnehmer zu definieren. Als p-WLAN-Interface-Hardware für die Kommunikation zwischen Fahrzeugen sowie zwischen Fahrzeug und der Infrastruktur kann ein vorhandener, im Fahrzeug ohnehin verbauter Funkadapter verwendet werden. Dieser lässt sich gemeinsam mit der Fahrzeuganwendung oder exklusiv als Mess-Interface einsetzen. Das ist für viele Anwendungsfälle eine pragmatische und flexible Lösung. Für manche Aufgaben kann allerdings die Messgenauigkeit dieser Funkadapter nicht ausreichen. Deshalb wird zukünftig eine präzisere, weiterentwickelte Mess- Hardware zur Debatte stehen. eck Literatur: [1] ETSI, Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Definitions, ETSI TR V1.1.1 ( ) [2] CAR 2 CAR Communication Consortium, Related Projects, org/index.php?id=6&l=oksjfr [3] Making cooperative systems cooperate, DRIVE DITCM Helmond, NL, drive-c2x-ditcm-making-cooperativesystems-cooperate [4] ITS World Congress, Wien, itsworldcongress.com [5] Schaal, H.-W.: Ethernet und IP im Kraftfahrzeug. Elektronik automotive. Heft S. 38ff. Dipl.-Ing. Thomas Löffler ist Senior Software Development Engineer bei der Vector Informatik GmbH. Er ist verantwortlich für das Thema Car2X. Die Schwerpunkte sind die Produktdefinition und die Projektleitung von Kundenprojekten. Herr Löffler vertritt Vector in diversen Car2X-Arbeitsgruppen. thomas.loeffler@vector.com Dipl.-Ing. Hans-Werner Schaal studierte Nachrichtentechnik an der Universität Stuttgart und Electrical & Computer Engineering an der Oregon State University, USA. Er ist als Business Development Manager bei der Vector Informatik GmbH im Bereich der Produktlinie Open Networking und für IP und Car2X zuständig. Zuvor war Hans-Werner Schaal Entwicklungsingenieur, Projektleiter und Produktmanager in verschiedenen Branchen im Bereich Testwerkzeuge für mehrere Netzwerk-Technologien. hans-werner.schaal@vector.com Elektronik automotive