Einsatz von Software Defined Radios für Kommunikations- und Ortungsanwendungen

Was sind überhaupt Software Defined Radios, kurz SDR und wofür setzt man diese sinnvoll ein?

Ein SDR besteht prinzipiell erst einmal aus einem einstellbaren breitbandigen Radio Frontend ohne Funktion. Das bedeutet, es kann einen bestimmten Frequenzbereich mit einer bestimmten Bandbreite bedienen. Als Beispiel sei hier das allseits beliebte USRP-2920 von National Instruments (früher Ettus Research), mit 20 MHz Bandbreite und einen Frequenzbereich von 50 MHz bis 2,2 GHz, genannt (vgl. Abbildung 1).

Über einen verbauten Hochgeschwindigkeits‑A/D‑Wandler und ‑D/A‑Wandler für das sogenannte Basisband‑I/Q‑Streaming können, über einen Host‑PC mit entsprechender Gigabit‑Ethernet Anbindung, beliebige Kommunikations- und Ortungssignale erzeugt werden. Die Betonung liegt hier auf dem Wort „können“.

Das bedeutet, allein die Software bestimmt die Funktion!

Mit SDR möglich: Abbildung von Funkstandards in Software

Nach dem Motto „software eats the world“ können mittlerweile beispielsweise komplette GSM-/LTE-Basisstationen, DAB+-Radios oder gar GPS-Empfänger/-sender nachgebildet werden. Die Grenzen für den Einsatz liegen dabei nur an den Parametern der Hardware bezüglich Breitbandigkeit, Frequenzbereich, Leistung der A/D und D/A-Wandler sowie der eingesetzten Clock.

Mit den oben genannten Eigenschaften lassen sich SDRs damit natürlich vielfältig in der Forschung und Entwicklung einsetzen. Ein besonderer Reiz liegt dabei in der Generierung, der Aufzeichnung und der Wiedergabe von hochfrequenten Signalen.

Diesbezüglich stellt sich nun die Frage, wie man SDRs für verkehrliche Anwendungen sinnvoll einsetzen kann bzw. was könnte man mit SDRs machen, was sonst unter normalen Bedingungen nahezu unmöglich ist?

Nutzung von SDR zum Testen für hochautomatisiertes Fahren

Folgende Gedanken/-spiele dazu:

• Ein vollautomatisiertes und später autonom fahrendes Fahrzeug muss vollumfänglich hinsichtlich seiner Funktionen (Fahr- und Betriebsstrategien) getestet sein um überhaupt eine Erstzulassung (Homologation) zu bestehen.
• Alle dazu erdenklichen verkehrlichen Szenarien können in Echt-(-zeit) nicht getestet werden. Dafür sind zum einen manche Szenarien und Ereignisse extrem selten und zum anderen würde die schiere Vielzahl der restlichen, alle derzeitigen Testmöglichkeiten an ihre Grenzen bringen.
• Als These sei hier gestellt – Selbst wenn autonome Fahrzeuge auf beispielsweise 500.000.000.000 km Testfahrten trainiert und untersucht werden, ist dies nicht ausreichend.

Siehe hierzu auch den Vortrag von Prof. Amnon Shashua auf der “AI Automotive” 2017 (ab 13:00min):

Schlussfolgerungen:

• Man muss also den Zeitbezug der zu trainierenden Szenarien eliminieren bzw. ausreichend verringern um sinnvoll testen zu können.
• Man muss weiterhin in der Lage sein die Szenarios zum Training entweder hinreichend genau nachzustellen oder aus der Realität (Testfahrt) aufzeichnen und später reproduzierbar wiedergeben.
• Man muss sich Gedanken machen, welche Signale für eine virtuelle Systemfunktionalität überhaupt relevant sind. Dies meint vereinfacht, wie kann ich dem Fahrzeug vorgaukeln, dass es fährt obwohl es im Labor steht?
• Software Defined Radios können dazu einen Beitrag leisten.

Verkehrstelematische Anwendungen der Zukunft

Für verkehrstelematische Anwendungen der Zukunft, wie beispielsweise das vollautomatisierte und später das autonome Fahren sind besonders Ortungssignale aller derzeitigen Global Navigation Satellite Systems (GNSS) mit dem bekanntesten Vertreter, dem Global Positioning System (GPS) relevant. Diese werden dabei als Basissignale für eine Eigenortung und für die Navigation verwendet.

Solch ein Ortungssignal ist neben vielen anderen Signalen ein essentieller Bestandteil für spätere Fahrfunktionen. Es sei gesagt, dass es daneben noch viele andere relevante Signale gibt, welche über eine Multisensordatenfusion vielfältige Funktionen und Integritätsbetrachtungen ermöglichen. In diesem Beitrag beschränken wir uns aber auf das GPS-Signal, welches für den Test einer sogenannten Green Light Optimated Speed Advisory Funktion (GLOSA) völlig ausreichend ist. Dahinter verbirgt sich eigentlich nichts anderes als der „lang gehegte Traum“ einen Fahrer im Fahrzeug zu übermitteln, wie lange es noch dauert bis eine Lichtsignalanlage auf Rot oder Grün umschaltet sowie ihm vorausberechnen und zu visualisieren, bei welcher zu fahrender Geschwindigkeit er bei Grün die Kreuzung noch ohne anzuhalten passieren kann. Die Abbildung 2 zeigt dazu eine Green Light Optimated Speed Advisory Function des Projektes EFA 2014/1.

Komfortable Entwicklung von Assistenzfunktionen mit Software Defined Radio

Um diese Funktion vorab im Labor zu testen kommen nun die SDRs zum Einsatz. Dabei muss konkret ein Szenario mit technischen Teilsystemen nachgestellt werden, welches eine Anfahrt auf eine beliebige Lichtsignalanlage in einer Stadt so real wie möglich darstellt.

Nachfolgende Teilsysteme sind dazu relevant:

• Eine Lichtsignalanlage mit Kommunikations- und Ortungsmodul der sogenannten Road Side Unit (RSU).
• Ein im städtischen Bereich fahrendes Fahrzeug mit Kommunikations- und Ortungsmodul der sogenannten On Board Unit (OBU)

Kommunizierende Lichtsignalanlage

Für den Punkt 1 wird folgendes Setup (vgl. Abbildung 3) mit den abgebildeten Komponenten verwendet:

Als Lichtsignalanlage inklusive Steuergerät wird ein Modell von der Firma dresden elektronik verwendet (vergleiche Abbildung 4 bis 6). Die Technik ohne RSU-Modul befindet sich bereits an ausgewählten Kreuzungen in Dresden im Einsatz.  Bei der Road Side Unit handelt es sich um ein Gerät von Cohda Wireless, welches ETSI-G5 Konform nach dem Car2Car-Standard IEEE 802.11p funken kann. In der oben gezeigten Abbildung ist der Signalfluss folgendermaßen:

• Schritt 1 – Die Lichtsignalanlage startet und das Steuergerät läuft mit dem hinterlegten Signalphasen (Rot, Gelb, Grün).
• Schritt 2 – Angekoppelt via CAN-Bus an das Steuergerät ist die RSU, welche die Signalphasen in eine  standardkonforme Signal Phase and Timing (SPaT) Nachricht packt und diese zyklisch broadcastet.
• Schritt 3 – Die Aussendung dieser Nachricht funktioniert aber nur, wenn ein gültiges GPS- Positionssignal an  der LSA anliegt. Dafür wird mit dem abgebildeten Software Defined Radio von National Instruments (NI), ein hochfrequentes standardkonformes GPS-Signal generiert, bei dem ein beliebiger weltweiter Standort der LSA zugewiesen werden kann. Dieses Signal wird jetzt physisch statt der GPS-Antenne mit einen HF-Kabel an den Eingang der RSU gegeben.

Im Ergebnis kann jetzt eine funktionierende Lichtsignalanlage an eine weltweite beliebige Position gesetzt werden.

Es ist anzumerken, dass für einen optimierten Laboraufbau nur das Lichtsignalanlagensteuergerät und die RSU benötigt werden um eine komplette reale Lichtsignalanlage nachzubilden.

Kommunikation im Fahrzeug

Für den Punkt 2 – Ein im städtischen Bereich fahrendes Fahrzeug mit Kommunikations- und Ortungsmodul der sogenannten On Board Unit (OBU) – wird folgendes Setup (vgl. Abbildung 7) mit den abgebildeten Komponenten verwendet:

Als Versuchsfahrzeug kann ein beliebiges Fahrzeug gewählt werden, indem die Möglichkeit der Integration einer Onboard Unit sowie einer Visualisierung von Car2X Nachrichten besteht.

Wir greifen dazu auf ein Versuchsfahrzeug der HTW/TUD-Nachwuchsforschergruppe zurück. Bei diesem ist die notwendige Technik bereits verbaut.  Bei der Onboard  Unit handelt es sich ebenfalls um ein Gerät von Cohda Wireless, welches ETSI-G5 Konform nach dem Car2Car-Standard IEEE 802.11p funken kann. In der oben gezeigten Abbildung ist der Signalfluss folgendermaßen:

• Schritt 1 – Fahrzeug startet und mit ihm fährt die Onboard Unit hoch, welche in unserem Fall auf  standardkonforme Signal Phase and Timing (SPaT) Nachrichten wartet, welche die Rot/Grün-Zeiten einer Lichtsignalanlage enthalten.
• Schritt 2 – Angekoppelt via CAN-Bus an die OBU ist das Navigationsgerät, welches die Nachrichten einer Lichtsignalanlage visualisiert auf eine Karte abbilden kann. Des Weiteren werden die eigene Fahrzeugposition und der Fahrtverlauf angezeigt.
• Schritt 3 – Um dem Fahrzeug vorzugaukeln das es fährt, wird ein sich zeitlich und örtlich änderndes gültiges GPS- Positionssignal benötigt. Dafür wird mit dem abgebildeten Software Defined Radio von National Instruments (NI), ein hochfrequentes standardkonformes GPS-Signal generiert, bei dem eine beliebige weltweite gefahrene Trajektorie dem Fahrzeug zugewiesen werden kann. Dieses Signal wird jetzt physisch statt der GPS-Antenne mit einen HF-Kabel an den Eingang der OBU gegeben. Um die Erstellung der Fahrtrajektorie so einfach wie möglich zu gestalten kann diese über diverse Tracker Programme zur Routenplanung auch online generiert werden. Wir haben uns hier für den freien Dienst von http://www.gpsies.com entschieden. Wie in der Abbildung 8 dargestellt lassen sich direkt auf einer Kartenansicht GPS-Wegpunkte inklusiver Geschwindigkeitszuweisung erstellen und in beliebige Ausgabeformate (zum Beispiel csv, gpx, …) konvertieren.

Im Ergebnis kann jetzt eine Realfahrt eines Fahrzeuges in einer beispielsweisen städtischen Umgebung generiert werden.

Es ist anzumerken, dass für einen optimierten Laboraufbau nur eine Onboard Unit mit einer entsprechenden Visualisierung benötigt wird, um eine komplette reale Fahrt eines Fahrzeugs in einer beliebigen Umgebung nachzubilden.

Doch wie wird ein reales GPS-Signal nun konkret erzeugt und was benötigt man weiterführend neben dem GPS-Track an Inputdaten dafür?

Generierung beliebiger GPS Signale mit Hilfe von Software Defined Radio

Software Basis für die Generierung ist LabView mit einigen Lizenzen für die Digitale Signalverarbeitung (vergleiche Abbildung 9).

Die Ansteuerung erfolgt dabei über eine eigens adaptierte Eingabemaske (vergleiche Abbildung 10) in der alle benötigten Inputdaten ausgewählt werden können und bei der während der Signalgenerierung eine Kontrollmöglichkeit des GPS-Signalstreams besteht. Die benötigten Input Daten für den Almanach und die Ephemeriden, also vereinfacht die gültigen Positionen von Satelliten im Orbit mit Epochenbezug, können von Webseiten des US-Governments bezogen werden.

Das File der Trajektorie bzw. einer festen GPS-Position kann per Syntax  hinsichtlich einer Abfolge von WGS-84 Koordinaten, Geschwindigkeiten und Durations zwischen den Punkten nach folgender Syntax (vergleiche Abbildung 11) frei editiert werden.

Sind alle Daten vorhanden wird das GPS-Signal mit Hilfe digitaler Signalverarbeitung im Labview (vergleiche Abbildung 12) erzeugt und als HF-Stream mit einem Output von 1,575 GHz bei ca. 1,1 MHz Bandbreite am Antennenausgang des USRPS (Rx/Tx) zur Verfügung gestellt. Abschließend dazu noch ein paar Worte zur Signalstärke der erzeugten GNSS-Signale. In einer echten Umgebung liegt das zivile, sogenannte GPS-L1 komplett im Rauschen bei ca. -140 bis – 160 dBm. Dies ist eigentlich auch verständlich, wenn man sich die Entfernung der GPS-Satelliten zum Empfänger auf der Erde vorstellt (ca. 20200 km). Allein die schiere Freiraumdämpfung  auf die Entfernung bezogen und die zusätzlichen Einflüsse von  Ionosphäre und Troposphäre bewirken, dass das Satellitenortungssignal, in Laufzeit und Phase verfälscht, sehr stark gedämpft beim Empfänger ankommt. Erzeugen wir nun künstliche GPS-Signale müssen wir die abgegebene Signalstärke (ca. 0 dBm, also 1 mW) des SDR stark begrenzen, da ansonsten unsere genutzten GPS-Empfänger in der Roadside und Onboard Unit dieses Signal nicht verarbeiten würden (overload des GPS Signals ab GNSS-Receiver). Um dies zu erreichen helfen bereits die 20m langen verwendeten HF-Kabel. Diese haben bereits eine dämpfende Wirkung von ca. 1dB/m, sodass wir noch maximal einen Dämpfungssteller von 30dB dazwischenschalten müssen um in einem für die GPS-Empfänger verarbeitbaren Signalbereich zu kommen. Zusätzlich verhindert noch ein DC-Blocker eine Spannungszufuhr zum HF-Ausgangs des SDRs durch den angeschlossenen GPS-Empfänger der OBU/RSU. In der Regel sind dies zwischen 3 und 5 V DC um eine aktive Antenne zu speisen. Dies würde den HF-Ausgang des verwendeten SDRs (USRPs) beschädigen können.

Ergebnis: Das Fahrzeug fährt obwohl es steht

Das Ergebnis – eine Live vorgeführte GLOSA-Funktionalität eines in einer Halle befindlichen stehenden Fahrzeuges und einer Lichtsignalanlage – mit allen echten Systemkomponenten, wurde auf der Exhibition der ASAM-Conference 2017 in Dresden ausgestellt und live vorgeführt. Dazu abschließend einige Impressionen mit kurzen Bilderläuterungen (Abbildungen 13 bis 19).

Alles in allem eine sehr gelungene und gut besuchte Demonstration der zukünftigen Car2X-Technik. Wir freuen uns auf eine spannende Zukunft und sagen hiermit auch herzlich Danke an alle Beteiligten Partner wie:

• Mike Ludwig und Erik Brenner von der Firma dresden elektronik (DE),
• Robert Baumbach und Erik Unger von der Firma Fahrzeug Systemdaten GmbH (FSD),
• Olaf Henning von der Firma Funk- &Telefonsysteme Hennig e.K.,
• Cäcilia von Lienen und Henrik Liers von der Verkehrsunfallforschung an der TU Dresden GmbH (VuFo).

---

Über den Autor: Dipl.-Ing. Robert Richter ist Wissenschaftlicher Mitarbeiter und Gruppenleiter für Forschung und Labore am Lehrstuhl Informationstechnik für Verkehrssysteme an der TU Dresden