Kostenlose Beratung! Montag bis Freitag 8:00 - 16:00 Uhr Tel.: 03522 - 505076

FTS Future: Software Defined Radios (SDR)

2017 statteten Ihre Mobilfunk-Exerten von FTS Hennig das Institut für Verkehrstelematik der TU Dresden mit der nötigen Technik für die Forschung im Bereich der Software Defined Radios (SDR) aus. Als wir schon während der Beratung merkten, dass hier, in Kooperation mit dem Fraunhofer Institute for Transportation and Infrastructure Systems, ein Team aus sehr eifrigen und zudem noch außerordentlich kompetenten Profis an einem äußerst spannenden Thema arbeiten, staunten wir nicht schlecht. Darum baten wir Herrn Dipl.-Ing. Robert Richter um einen Gastbeitrag für unsere Leser. Zu unserem Glück war er sehr angetan von der Idee und ermöglicht uns mit dem folgenden Beitrag einen sehr umfassenden Einblick in die aktuellen Forschungen.

Software Defined Radios für Kommunikations- & Ortungsanwendungen

Zu Beginn klären wir erst einmal die grundlegende Frage: "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. Ein kommerzieller Anbieter für solche Software Defined Radios ist unter anderem die Firma National Instruments. Als Beispiel für SDR sei hier das NI USRP-2920 genannt (ursprünglich von der Firma Ettus Research) mit 20 MHz Bandbreite und einen Frequenzbereich von 50 MHz bis 2,2 GHz, welches von mir als Einsteigermodell eingestuft wurde.

Software Defined Radio NI USRP-2920

Software Defined Radio: NI USRP-2920 © National Instruments

Über die verbauten und auf hohe Übertragungsgeschwindigkeit ausgelegten A/D- 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, dass allein die Software die Funktion bestimmt!

Mit SDR möglich: Abbildung von Funkstandards in Software

Nach dem Motto „software eats the world“ können jetzt schon beispielsweise komplette GSM- oder LTE-Basisstationen, DAB+-Radios oder gar GPS-Empfänger und 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 (Synchronisation).

Mit den oben genannten Eigenschaften lassen sich SDR 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 stellte sich uns an dieser Stelle die Frage, wie man Software Defined Radios für verkehrliche Anwendungen sinnvoll einsetzen kann bzw. was könnte man mit SDR machen, was sonst unter normalen Bedingungen nahezu unmöglich ist? In unseren Köpfen entstanden unter anderem folgende Gedankenspiele dazu:

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 Global Positioning System (GPS) als bekanntestem Vertreter - 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 s.g. Green Light Optimated Speed Advisory Funktion (GLOSA) völlig ausreichend ist.

Dahinter verbirgt sich eigentlich nichts anderes als der „lang gehegte Traum“ davon, einem Fahrer im Fahrzeug zu übermitteln, wie lange es noch dauert bis eine Lichtsignalanlage auf rot oder grün umschaltet sowie ihm im Voraus zu berechnen und zu visualisieren, bei welcher zu fahrender Geschwindigkeit er bei grün die Kreuzung noch ohne anzuhalten passieren kann. Das nächste Bild zeigt dazu eine GLOSA Funktion des bereits abgeschlossenen Projektes EFA 2014/1.

Green Light Optimated Speed Advisory Function

GLOSA: "Green Light Optimated Speed Advisory Function" des Projektes EFA 2014/1 © TU Dresden

Komfortable Entwicklung von Assistenzfunktionen mit Software Defined Radios

Um diese Funktion vorab im Labor testen zu können, kommen nun die SDR 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:

Nachstellen einer Lichtsignalanlage

Für Punkt 1 wird folgendes Setup mit den abgebildeten Komponenten verwendet:

Versuchssetup für eine Realsimulation einer intelligenten Lichtsignalanlage

Versuchssetup für eine Realsimulation einer „smarten“ Lichtsignalanlage © TU Dresden

Als Lichtsignalanlage inklusive Steuergerät wird ein Modell von der Firma dresden elektronik verwendet (s. unten). 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 im 5 GHz Band 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 weltweit an eine 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.

Lichtsignalanlage der Firma dresden elektronik während SDR-GNSS Test SDR im Einsatz

Ampel von dresden elektronik (links) und SDR im Einsatz (rechts) © TU Dresden

Nachstellen eines fahrenden Fahrzeugs

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 mit den abgebildeten Komponenten verwendet:

Versuchssetup für Realsimulation zur intelligenten Annäherung an eine Ampel

Versuchssetup für Realsimulation einer „smarten“ Annäherung an eine Lichtsignalanlage © TU Dresden

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, dass 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 weltweit 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 www.gpsies.com entschieden. Wie in der folgenden Abbildung dargestellt, lassen sich direkt auf einer Kartenansicht GPS-Wegpunkte inklusive Geschwindigkeitszuweisung erstellen und in beliebige Ausgabeformate (zum Beispiel csv, gpx, …) konvertieren.

Screenshot: Webbasierte Anwendung zur Erstellung von Fahrtrajektorien

Webbasierte Anwendung zur Erstellung von Fahrtrajektorien © gpsies.com

Im Ergebnis kann jetzt eine Realfahrt eines Fahrzeuges, beispielsweise in einer 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 Radios

Als Software-Basis für die Generierung dient LabView mit einigen Lizenzen zur digitalen Signalverarbeitung.

Blockschaltbild der SW-Komponenten zur GPS-Signal Erstellung

Blockschaltbild der SW-Komponenten zur GPS-Signal Erstellung © TU Dresden

Die Ansteuerung erfolgt dabei über eine eigens adaptierte Eingabemaske, 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 der US-Regierung bezogen werden.

Screenshot: HMI

HMI zur Ansteuerung des SDRs und zur Feinjustierung der GNSS-Signalparameter © TU Dresden

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) frei editiert werden.

Trajektorienfile

Typisches Trajektorienfile – hier hinterlegt: Eine kurze Fahrt in Dresden © TU Dresden

Sind alle Daten vorhanden, wird das GPS-Signal mit Hilfe digitaler Signalverarbeitung im Labview (nächste Abbildung) 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.

LabView Blockdiagramm

Auszug aus dem LabView Blockdiagramm zum Erzeugen des hochfrequenten GNSS-Streams © TU Dresden

Ergebnis: Das Fahrzeug fährt - obwohl es steht!

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.

Im folgenden Bild sehen Sie das komplett nachgestellte GLOSA-Szenario mit zwei Fahrzeugen und einer LSA. LSA und Fahrzeuge sind dabei mit Roadside und Onboard Units zur Kommunikation nach dem ETSI-G5 Standard ausgerüstet. Gut zu sehen sind die beiden HF-Kabel (gesponsert von FTS Hennig), welche auf dem Boden geführt zur LSA und zum Fahrzeug führen. Über diese Kabel wird jeweils ein zeitlich synchronisierter, aber physikalisch getrennter GNSS-Stream den Units zugeführt.

Nachgestelltes GLOSA-Szenario

Nachgestelltes GLOSA-Szenario mit zwei Fahrzeugen und einer LSA © TU Dresden

Auf dem Monitor im nächsten Bild ist die GLOSA-Situation für den Fahrzeugführer gut zu erkennen, welche so dargestellt 1:1 im Fahrzeug auf dem Navigationsgerät angezeigt wird. Diese zeigt die komplette Anfahrt an den Kreuzungsbereich hin zur Lichtsignalanlage und blendet die zugehörige Grün- bzw. Rotzeit spurselektiv für den Fahrer ein.

Darstellung auf dem Navigationsgerät

1:1 Darstellung im Fahrzeug auf dem Navigationsgerät (Bildschirm) © TU Dresden

Direkt neben des GLOSA-Szenarios befand sich unser Messestand. Auf den beiden Laptops erzeugten wir mit den SDR die zeitlich synchronisierten, aber physikalisch getrennten GNSS-Signale für Fahrzeug und Lichtsignalanlage und kontrollieren die Zustände der Subsysteme.

LabView Blockdiagramm

Messestand mit SDR © TU Dresden

EIn Blick in die Fahrzeuge

Zuerst werfen wir einen Blick von hinten in das mit GNSS gespeiste Versuchsfahrzeug, welches die GLOSA-Funktionalitäten zeigt.

Mit GNSS gespeistes Versuchsfahrzeug

Mit GNSS gespeistes Versuchsfahrzeug © TU Dresden

Bei einem genaueren Blick in den Fahrzeuginnenraum (hinten) kann man auch erkennen, an welcher markierten Stelle unser GNSS gespeistes HF-Kabel zum Einsatz kommt - bereitgestellt durch FTS Hennig.

Nahaufnahme aus dem Versuchsfahrzeug

Nahaufnahme aus dem Versuchsfahrzeug © TU Dresden

Bei einem Blick in den Fahrzeuginnenraum (vorn) ist am Navigationsgerät deutlich zu erkennen, dass das Fahrzeug gerade „denkt“, es fahre auf eine Lichtsignalanlage zu.

Fahrzeuginnenraum des Versuchsfahrzeugs

Fahrzeuginnenraum des Versuchsfahrzeugs © TU Dresden

Dankbares Forschungsteam aus Dresden

Alles in allem gelang uns erfreulicherweise eine sehr gelungene und gut besuchte Demonstration der zukünftigen 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 dresden elektronik

Robert Baumbach und Erik Unger von der Fahrzeug Systemdaten GmbH

Cäcilia von Lienen und Henrik Liers von der Verkehrsunfallforschung an der TU Dresden GmbH

Selbstverständlich danken wir auch Olaf Hennig und seinem Team für die Unterstützung, das entgegenberachte Interesse und die Möglichkeit, diesen Beitrag zu veröffentlichen.

Professur Team der TU Dresden

Team der Professur für Informationstechnik für Verkehrssysteme
(von links nach rechts: Benjamin Reichelt, Robert Richter und Florian Pinzel )
© TU Dresden

Über den Autor

Dipl.-Ing. Robert Richter

Dipl.-Ing. Robert Richter (© R. Richter)

Dipl.-Ing. Robert Richter lehrt und forscht am Institut für Verkehrstelematik der Technischen Universität Dresden. Er beschäftigt sich seit Jahren mit diversen Themen aus dem Bereich "Mobilität und Verkehr" - und bleibt dabei nicht nur auf dem Boden. So arbeitet er im Rahmen des NELA Programms z.B. auch an Ansätzen für neuartige elektronische Luftfahrtsysteme mit.

Wir danken Herrn Richter für seinen Input, wünschen ihm viel Erfolg bei seinen Forschunsprojekten und freuen uns auf die weitere Zusammenarbeit. Mit etwas Glück dürfen wir in der Zukunft ja noch weitere interessante Ergebnisse bei uns präsentieren - Infos direkt von der Quelle.

Kommentare (0)

Schreiben Sie ein Kommentar

Die mit einem Stern (*) markierten Felder sind Pflichtfelder.