<ul><li>Paralleler Remote-Zugriff für größtmögliche Entwicklungseffizienz: Steigende Komplexität beherrschen</li><li>Automatisiertes Fahren durch Drohnenaufzeichnung und Simulation absichern: Ground Truth im Fokus</li><li>Interview: »Künstliche Intelligenz muss für den Anwender verständlich sein«</li><li>Fahrzeug-Bordnetz: Intelligente Regelung elektrischer Verbraucher</li></ul>

Anfang April sind auf der A2 im Kreis Gütersloh ein Lkw und zwei Autos ineinander gekracht – es gab ein Todesopfer, sechs Verletzte und eine stundenlange Sperrung der Autobahn. Nur einer von etlichen schwerwiegenden Unfällen, die vor Kurzem stattfanden. Wie so oft war hier menschliches Versagen die Hauptursache.

Müdigkeit, überhöhte Geschwindigkeit, Rücksichtslosigkeit, Alkohol am Steuer oder Ablenkung: der Mensch ist im Straßenverkehr der größte Risikofaktor. Auch wenn sich die meisten für ausgezeichnete Fahrer:innen halten – mit dem Menschen wird sich die Vision von null Unfalltoten nicht verwirklichen lassen.

Auf dem Weg zur Vision Zero wird also automatisiertes Fahren eine wichtige Rolle spielen. Ein höherer Fahrkomfort, die Möglichkeit, während der Fahrt zu arbeiten oder zu entspannen, ein besserer Verkehrsfluss und damit weniger CO2-Emissionen und Kraftstoffverbrauch und vor allem eine höhere Verkehrssicherheit – alle diese Vorteile sprechen für einen Einsatz der Technik.

Natürlich könnte man auch relativ sicher und umweltfreundlich mit der Bahn fahren und dabei die Zeit sinnvoll nutzen. So einen die Bahn denn lässt. Denn nicht nur Technik und Infrastruktur sind anfällig. Auch (sicherlich zu Recht) streikende Mitarbeiter haben in der Vergangenheit für Reiseausfälle gesorgt. Zudem bringen Unwetter den Bahnverkehr häufig zum Erliegen, während es auf der Straße noch rollt. Und selbst wenn die Bahn fährt – wie oft sind Sie schon zu spät angekommen?

Sicherlich muss noch einiges passieren, bevor wir hinter dem Lenkrad sitzen, ohne es zu benutzen. Angefangen von technischen Herausforderungen sowie Safety und Security über die Infrastruktur und die Fähigkeit unseres Straßennetzes, autonomes Fahren zuzulassen, bis hin zu rechtlichen Aspekten, ethischen Fragestellungen und zur Akzeptanz für ein derartiges System in der Gesellschaft. Denn bei allen Chancen, die automatisiertes Fahren mit sich bringt – wer in ein selbstfahrendes Auto steigt, muss die Kontrolle abgeben und der Maschine vertrauen.

Vertrauen ist allerdings nicht von jetzt auf gleich da. Es wird sich nur langsam aufgrund von positiven Erfahrungen mit der Technik aufbauen. Als Adaptive Cruise Control eingeführt wurde, gab es etliche Stimmen, die meinten: »Brauche ich nicht«. Die gleichen, die später davon schwärmten, welche Erleichterung damit einhergeht. Schon damals ein deutlicher Komfortgewinn. Wenn ich auf der Autobahn die Spur wechseln möchte, aber ein Fahrzeug im toten Winkel übersehe, bin ich äußerst dankbar, wenn mich mein Auto warnt. Verlässlichkeit sorgt für einen Vertrauensaufbau – es zu behalten, ist aber ein stetiger Prozess. Vertrauen hingegen zu erschüttern, geht schnell: Teslas „Autopilot“ hat der Branche sicherlich kein Gefallen getan.

Konkretes Fachwissen schafft ebenfalls Vertrauen. Daher erhalten Sie mit unseren Schwerpunkten „Automatisiertes Fahren“ und „Künstliche Intelligenz“ ab Seite 22 fundierte Fachinformationen.

Stefanie Eckardt, Chefredakteurin <a href="mailto:stefanie.eckardt@hanser.de">stefanie.eckardt@hanser.de</a>

16:9

Editorial - Hauptartikel

Fahrerassistenzsysteme / Automatisiertes Fahren

Elektronik

Kfz-Elektronik

Paralleler Remote-Zugriff für größtmögliche Entwicklungseffizienz

Entwicklungsstandorte für Steuergeräte und Fahrzeuge, Testaufbauten und Versuchsflotten sind mittlerweile weltweit verteilt. Herausforderung für den Entwickler: Der Zugriff auf die verteilten Versuchsträger und der gleichzeitige Ablauf sich wiederholender Aufgaben. Ein remotefähiger Diagnosetester hilft dabei, diese Anforderungen zu erfüllen.

Entwicklungsstandorte für Steuergeräte und Fahrzeuge, Testaufbauten und Versuchsflotten sind mittlerweile weltweit verteilt. Herausforderung für den Entwickler: Der Zugriff auf die verteilten Versuchsträger und der gleichzeitige Ablauf sich wiederholender Aufgaben.

Entwicklungsprojekte werden zunehmend von Teams bearbeitet, deren Mitglieder global verteilt oder pandemiebedingt im Homeoffice sind. Der Fernzugriff auf Testobjekte ermöglicht dabei eine effiziente Vernetzung globaler und heimischer Arbeitskapazitäten. Hinzu kommt, dass sich beim Testen und Erproben sehr zeitintensive Aufgaben pro Versuchsträger oder Fahrzeug wiederholen. Entwickler müssen also zum einen auf global verteilte Fahrzeuge und Versuchsträger zugreifen können. Zum anderen ist es wichtig, dass sich wiederholende Aufgaben effizient und somit möglichst gleichzeitig ablaufen. Der Einsatz eines remotefähigen Diagnosetesters, der die hohen Anforderungen der immer komplexer werdenden Entwicklungslandschaft und die damit verbundenen Diagnosefunktionen abdeckt, ist dabei essenziell.

Hardware als Rarität in der globalen Entwicklungslandschaft

 Um den hohen Anforderungen und der steigenden Komplexität in der Entwicklung gerecht zu werden, sind Entwicklungsstandorte für Steuergeräte und Fahrzeuge, Testaufbauten und Prüfstände sowie Versuchsflotten heute global verteilt. So lässt sich im Prinzip 24 Stunden am Tag an einem Projekt gearbeitet werden: Aus Europa wird ein Projekt vom asiatischen Entwickler übernommen und in die USA weitergegeben. Steuerungsfunktionen werden in Fernost entwickelt, in Indien getestet und der Prototypenaufbau erfolgt in Deutschland. In den meisten Fällen ist jedoch die Hardware – das können Steuergeräte, Prüfstände oder Testfahrzeuge sein – gerade in frühen Entwicklungs- und Testphasen rar. Um teure Reisen zu vermeiden und ein nahtloses Zusammenspiel aller weltweit verteilten Entwickler zu ermöglichen, ist der Zugriff auf den Testträger (Device under Test, DUT) aus der Ferne heute ein Muss. Für einen Fernzugriff spielen verschiedene Faktoren – auch in Kombination – eine große Rolle und sind zwingend zu beachten: Infrastruktur, Bandbreite und Latenzen, Netzwerk, IT-Sicherheit, Fahrzeugzustand, die verwendeten Tools sowie die Fahrzeugabsicherung (Security).

Sobald ein Steuergerät nicht mehr unabhängig von der Umgebung entwickelt wird, sind meist mehrere Parteien beteiligt. Die Diagnose (Bild 1) übernimmt mehrere Rollen: Sie wird zwar ebenfalls zunächst entwickelt und freigegeben, dient danach aber auch zur Verifikation der Funktionen. Darüber hinaus spielt sie eine weitere entscheidende Rolle: Sie stellt die Basis für die Aktualisierung der Steuergeräte-Software zur Verfügung. Das geschieht in der Regel über Diagnose-Kommunikationsprotokolle. Gleiches gilt für Variantenkodierung sowie verschiedene Diagnosefunktionen, zum Beispiel das Auslesen von Messwerten und Fehlerspeicheroperationen.

All diese Aufgaben lassen sich vom Entwickler direkt am Testobjekt mit der im jeweiligen Testfall benötigten Umgebung durchführen. Bei Bedarf kann der Entwickler dann aus der Ferne über das Netzwerk auf den Versuchsträger zugreifen. Durch geschickte Testabläufe kann die Zeit am Testobjekt optimiert werden, zum Beispiel indem Testdaten offline ausgewertet und dokumentiert werden, während ein anderer Kollege bereits wieder testet.

Die zu erledigenden Aufgaben in der Entwicklung wiederholen sich dabei pro Versuchsträger oder Fahrzeug, was letztlich zeitintensiv ist. Ein Beispiel ist das Auslesen und Dokumentieren des Bau- und Versionsstandes einer Versuchsflotte an einem Erprobungstag: Am Testfahrzeug wird ein Fahrzeug-Interface angesteckt, die Tester-Applikation verbunden und automatische oder interaktive Tests durchgeführt. Ein Prozedere, das jeweils pro Fahrzeug und Auslesezeitpunkt durchgeführt werden muss, zum Beispiel vor und nach der Versuchsfahrt. Gleiches gilt für Prüfstände und Testaufbauten mit ähnlichen Aufgaben. Muss auf ein Steuergerät eine neue Software aufgespielt werden, möchte man nicht alle Prüfstände einzeln und nacheinander updaten, sondern im besten Fall gleichzeitig ansteuern, so dass alle Versuchsträger auf demselben Stand sind.

Herausforderungen des parallelen Remote-Zugriffs

Zusammengefasst besteht die Herausforderung also zum einen darin, dass Entwickler problemlos auf die global verteilten Fahrzeuge und Versuchsträger zugreifen können. Dabei müssen die hohen Anforderungen der Remote-Diagnose in Hinsicht auf Infrastruktur, Bandbreite, Latenzen und IT-Sicherheit beachtet werden. Zum anderen ist es wichtig, dass sich wiederholende Aufgaben effizient durchführen lassen. Die Lösung für maximale Entwicklungseffizienz in der Diagnose ist ein Diagnosetester, mit dem alle zu erledigenden Aufgaben bearbeitet werden können und der die Kombination aus parallelem und Remote-Zugriff ermöglicht.

Die Umsetzung eines solchen Fernzugriffs kann auf verschiedene Methoden erfolgen, sei es LAN/WLAN an einem Standort oder ein Wide Area Network (WAN) auch außerhalb der Firmendomain, etwa über 4G/5G beispielsweise für ein Testfahrzeug. Notwendig ist der Einsatz eines modernen netzwerkfähigen Fahrzeug-Interface (Vehicle Communication Interface, VCI). Sobald es im Firmennetzwerk registriert ist, lässt es sich grundsätzlich dezentral ansprechen. Die Erweiterung bestehender VCIs um Diagnosefunktionen funktioniert im Grunde ähnlich. Sie ermöglichen den Austausch von Daten und sind meist in Prüfständen und nahezu immer in Testfahrzeugen installiert. Da die Verbindungsqualität insbesondere bei Testfahrten stark variieren kann, geschieht der Datenaustausch dabei in der Regel asynchron. Eine Diagnoselösung muss daher an dieses Verhalten angepasst sein.

Mit einem modernen Entwicklungstester wird über ein Kommunikations-APIs auf das VCI zugegriffen und der Remote-Zugriff geöffnet. Die eigentlichen Diagnoseabläufe werden dabei im VCI autark durchgeführt, sodass eine starke Unabhängigkeit von der Übertragungsstrecke erreicht wird. In der Tester-Applikation werden hier nur die Diagnoseaufgaben ausgelöst und Ergebnisse dargestellt sowie die Anbindung an das Backend ermöglicht.

Softing DTS.monaco – All-in-One-Werkzeug

Die heutigen globalen Entwicklungslandschaften (Bild 2) verlangen Entwicklungstester, die Diagnose sowohl lokal als auch in Remote-Szenarien unterstützen. Softing DTS.monaco ist ein Beispiel für einen solchen Entwicklungstester. Der Tester wird bereits in zahlreichen Entwicklungszentren weltweit für umfangreiche Diagnoseaufgaben eingesetzt. Diese reichen von ODX und Expert Use Cases über die Steuergerätefreigabe bis hin zur Inbetriebnahme von HiL-Systemen und Prüfständen. Auch für die Aktualisierung und Validierung von Fahrzeugen bei Testfahrten ist das Tool regelmäßig im Einsatz.

In Verbindung mit einem WLAN-fähigen VCI, wie zum Beispiel dem VIN|ING 2000 von Softing, kann der Tester universell für alle Diagnose- und Kommunikations-Anwendungsfälle eingesetzt werden. Die Darstellung ist dabei jeweils genau auf die Aufgabe zugeschnitten. Beispiele sind:

<ul><li>Steuergeräte-Identifikation</li><li>Fehlerspeicheroperationen</li><li>Flash-Programmierung</li><li>Auslesen von Messwerten</li><li>Variantenkodierung</li><li>Stellgliedtest</li></ul>

Diese Funktionen werden intern über eine funktionale API implementiert, die die Laufzeitumgebung für die Standards OTX und ODX erweitert. Diese Schnittstelle kann auch remote aufgerufen werden, sodass eine zweite Instanz des Prüfgeräts aus der Ferne angeschlossen werden kann. Das ermöglicht nun die oben beschriebenen globalen Zusammenarbeitsmodelle: Der Entwickler erstellt beispielsweise eine neue Software und stellt sie zentral zur Verfügung. Ein Tester stellt die Software zum passenden Zeitpunkt bereit und beginnt mit dem Testen. Treten Probleme auf, kann sich der Entwickler aus der Ferne einschalten, eigene Tests durchführen und eventuelle Fehler direkt über ein Remote-Software-Update beheben. Anschließend können die eigentlichen Tests fortgesetzt werden.

Ob im Fahrversuch, in der Produktionsvorbereitung oder Prüfstandswartung: Häufig erfolgen mehrere Programmier- und Prüfaufgaben parallel. In Kombination mit dem Diagnose-Interface VIN|ING 2000 von Softing – in der Konfiguration als Smart-VCI mit integriertem Diagnoselaufzeitsystem – ist es möglich, remote auf das Testobjekt zuzugreifen. Das kann einerseits – kostengünstig und erprobt für den Einsatz im Fahrzeug und in der Produktionslinie – sequenziell erfolgen. Andererseits ist mit der neuen Multitest-Oberfläche von Softing DTS die Skalierung über das Netzwerk einfach möglich. Dabei können bis zu acht Verbindungen zur selben Zeit angesteuert werden, unabhängig davon, ob die Versuchsträger am gleichen Ort oder Remote verfügbar sind. Und auch unterschiedliche Testobjekte und Fahrzeugtypen lassen sich gleichzeitig an verschiedenen Standorten bearbeiten.

Voraussetzung dafür ist, dass die zum jeweiligen Testobjekt passenden Diagnosedaten auf das VCI geladen werden. Im nächsten Schritt müssen die Darstellungselemente der grafischen Oberfläche mit dem jeweiligen VCI verknüpft werden. Anschließend ist es mit der „Multitest“-Oberfläche möglich, alle Testabläufe in den VCIs getrennt oder gemeinsam zu starten, anzuhalten und Testergebnisse parallel (Bild 3) zu dokumentieren. Weitere Anwendungsfälle wie Steuergeräte- und Fahrzeugaktualisierungen sind vorbereitet.

Softing DTS ist ein über Jahrzehnte gewachsenes Expertenwerkzeug für die professionelle Steuergeräte- und Fahrzeugdiagnose. Die modulare Architektur ermöglicht eine individuelle Anpassung der angebotenen Funktionen an die jeweiligen Anforderungen und Arbeitsschritte des Prüfprozesses. Basierend auf herstellerübergreifenden Erfahrungen setzt das Tool jetzt zusätzlich die Vorteile des Remote- und des parallelen Zugriffs um. In Verbindung mit einem WLAN-fähigen VCI, zum Beispiel dem VIN|ING 2000, ermöglicht Softing DTS.monaco maximale Entwicklungseffizienz in der Fahrzeugdiagnose.  (eck)

<a href="http://www.automotive.softing.com">www.automotive.softing.com</a>

Claudio Amato ist als Produktmanager bei der Softing Automotive Electronics GmbH für das Diagnostic Tool Set verantwortlich.

Claudio Amato ist als Produktmanager bei der Softing Automotive Electronics GmbH für das Diagnostic Tool Set verantwortlich.

Bild 1: Softing DTS.monaco im Remote-Einsatz

Bild 2: Heutige Entwicklungslandschaften machen Entwicklungstester notwendig, die Diagnose lokal und in Remote-Szenarien unterstützen.

Softing

Messtechnik, Testlösungen, Diagnose

Störfestigkeit und Störerunterdrückung verifizieren

Beim automatisierten Fahren spielt GNSS eine wichtige Rolle. Um Störquellen aufzuspüren und die ausgesendeten Störsignale unterdrücken zu können, müssen GNSS-Empfänger mehrkanalig ausgelegt sein. Für die Verifizierung von Störfestigkeit und Störunterdrückung hat Rohde & Schwarz eine Lösung entwickelt.

Beim automatisierten Fahren spielt GNSS eine wichtige Rolle. Um Störquellen aufzuspüren und die ausgesendeten Störsignale unterdrücken zu können, müssen GNSS-Empfänger mehrkanalig ausgelegt sein.

Sebastian Kehl-Waas und Dr. Markus Irsigler

Nicht nur militärische Fahr- und Flugzeuge sind auf störungsfreie GNSS-Signale angewiesen. Hier unterdrücken in der Regel Anti-Jam-Systeme durch räumliche Filterung die Signale aus Störquellen. In ähnlicher Weise können solche Lösungen auch die Satelliten-Navigationssignale für das autonome Fahren und Fliegen vor Störsignalen schützen. Damit GNSS-Empfänger Störquellen aufspüren und die ausgesendeten Störsignale unterdrücken können, müssen sie mehrkanalig ausgelegt sein. So kann durch die phasenkohärente Signalverarbeitung der Signale mehrerer Antennen die Signaleinfallsrichtung des Störers bestimmt und der Störer ausgeblendet werden. Rohde & Schwarz bietet eine Lösung an, mit der sich die Störfestigkeit und Störerunterdrückung verifizieren lässt.

Mehrkanalempfänger können Signale mehrerer verteilter Empfangsantennen oder eines Antennen-Arrays gleichzeitig verarbeiten. Das lässt sich nutzen, um mit Signalanalysemethoden einerseits Rückschlüsse auf die Richtung der einfallenden Signale zu ziehen und andererseits das Antennendiagramm derart anzupassen, dass unerwünschte Signale ausgeblendet werden.

Bei der GNSS-basierten Positionsbestimmung bedeutet das, dass Satelliten-Navigationssignale (GNSS) verstärkt und Jamming- oder Spoofing-Signale, die vom Boden oder aus der Luft ausgehen unterdrückt werden können. Wurde die Technologie bisher vor allem für militärische Anwendungen eingesetzt, kann sie künftig auch einen wichtigen Beitrag zur robusten Navigation beim automatisierten Fahren und Fliegen liefern. Typische Störquellen sind hier Harmonische von Sendern in der Umgebung, Tactical-Air-Navigations- und zivil genutzte DME-Signale zur Flugnavigation oder auch LTE-Signale. Zudem finden sogenannte Personal Privacy Devices (PPD) immer weiter Verbreitung. Das sind GNSS-Jammer, die durch das Abstrahlen von Schmal- oder Breitbandsignalen die GNSS-Positionierung stören. Eine neue Lösung von Rohde & Schwarz ermöglicht es die Robustheit von GNSS-Empfängern gegenüber Störsignalen umfassend zu prüfen, bei Bedarf auch innerhalb einer realitätsnahen Hardware-in-the-Loop-Umgebung (HiL).

Mehrkanalige GNSS-Empfänger zur Störsignalunterdrückung

Zur Unterdrückung ungewollter Signale nutzen GNSS-Empfänger oft sogenannte Controlled Reception Pattern Antennas (CRPA). Diese bestehen aus einem Antennen-Array und einer Signalverarbeitungseinheit. Die angeschlossenen Antennen sind dabei streng geometrisch angeordnet, um eine vollständige Abdeckung aller möglichen Einfallsrichtungen zu erreichen. Durch geeignete Gewichtung der Signale der Einzelantennen in der Signalverarbeitungseinheit lässt sich die Gesamtempfangscharakteristik des Antennen-Arrays verändern (Bild 1). So werden Störsignale entweder gezielt ausgeblendet (Nulling) oder der Empfang der gewünschten GNSS-Signale in deren Einfallsrichtungen verstärkt (Beamforming). Eine Kombination beider Methoden ist ebenfalls machbar. Die Antennen-Arrays bestehen typischerweise aus vier bis sieben Antennenelementen. Je mehr Elemente, umso mehr Störsignale können gleichzeitig unterdrückt werden.

Für Tests an GNSS-Empfängern, die CRPA nutzen, bietet Rohde & Schwarz ein Testsystem an. Dieses fungiert zum einen als mehrkanaliger GNSS-Simulator und berücksichtigt dabei alle Aspekte eines Satellitennavigationssystems. Hierbei müssen die Signale aller gängigen Satellitensysteme in allen GNSS-Frequenzbändern erzeugt werden, unter Berücksichtigung von korrekten Satellitenorbits, der Signalausbreitungseigenschaften sowie einer realistischen Modellierung der sich dynamisch ändernden Empfangsumgebung. Des Weiteren ist die Konfiguration des Antennen-Arrays hinsichtlich Geometrie und Empfangseigenschaften der Einzelantennen einzubeziehen.

Zudem kann die Lösung gleichzeitig störende Jamming- oder Spoofing-Signale generieren, um die Störunterdrückungsfunktionen des DUTs prüfen zu können. Zur freien Konfiguration von Störern mit sehr großer Sendeleistung ist ein zweites, identisches Testsystem notwendig. Dabei hilft die R&S Pulse Sequencer Software bei der Definition von komplexen Störszenarien. Die Szenarien decken Anforderungen wie lange Simulationszeiten, bewegte Störer und GNSS-Empfänger, benutzerdefinierte Antennendiagramme sowie Antennenscans ab. Darüber hinaus berechnet die Software die korrekte Amplitude, Phasenlage und Laufzeit der Signale in Abhängigkeit von Signalfrequenz, Antennenanordnung und Position von Sendern und Empfängern im dreidimensionalen Raum für jedes einzelne Antennenelement. Die Signalerzeugung übernimmt dabei der High-end-Vektorsignalgenerator R&S SMW200A.

Für die Tests müssen für jeden Antenneneingang des GNSS-Empfängers sowohl das gewollte GNSS-Signal als auch die ungewollten Signale der Störer erzeugt werden. Zum Testen eines CRPA-Empfängers mit vier Antenneneingängen werden somit vier Signalquellen für die Erzeugung der GNSS-Signale und vier weitere Signalquellen zur Generierung der Jammer-Signale benötigt. Bild 2 zeigt zwei Testsysteme, mit denen man sowohl gekoppelte GNSS-Signale als auch Jammer-Signale für einen vierkanaligen CRPA-Empfänger erzeugen kann.

Um die Einfallsrichtung der Satelliten- und Störsignale korrekt zu simulieren, müssen die Testsysteme an der HF-Schnittstelle zum DUT in Bezug auf Amplitude, Phase und Laufzeit kalibriert sein. Das heißt Amplituden-, Phasen- und Laufzeitunterschiede zwischen den einzelnen HF-Pfaden, die sich beispielsweise durch Kabel oder HF-Komponenten ergeben, werden kompensiert. Durch geeignete Synchronisation werden die Vektorsignalgeneratoren jedes Systems phasenkohärent gekoppelt. Ein analoger High-End-HF-Signalgenerator R&S SMA100B liefert jeweils das gemeinsame LO-Signal.

Mithilfe der R&S RF Ports Alignment Software lässt sich das komplette System an einer frei wählbaren Referenzebene in Bezug auf Amplitude, Phase und Laufzeit kalibrieren, sodass die Eigenschaften des Testsystems nicht die simulierten Signalunterschiede zwischen den einzelnen Antennen verfälschen. Die notwendigen Messungen werden mit einem Vektor-Netzwerkanalysator durchgeführt.

Die beiden Testsysteme müssen nicht relativ zueinander kalibriert werden. Für die Simulation realistischer Szenarien ist es ausreichend GNSS- und Störersimulation zeitgleich zu starten, da auch in der Realität in der Regel kein Bezug zwischen GNSS-Satelliten und Störquellen besteht.

Das GNSS-Testsystem lässt sich zudem in eine HiL-Umgebung einbetten. Dabei streamt ein Rechner mit hoher Datenrate das Bewegungsprofil des zu testenden GNSS-Empfängers mit Position, Geschwindigkeit, Beschleunigung und Fahrzeuglageinformationen an das Testsystem. Dieses generiert dazu in Echtzeit das entsprechende Satellitennavigationssignal. Das erfordert sehr hohe Update-Raten und geringe Latenzen.

Mehrkanalige GNSS-CRPA-Empfänger verbessern die Navigation von Land- und Luftfahrzeugen jeglicher Art erheblich. Mit dem neuen Testsystem von Rohde & Schwarz lassen sich Testsignale sowohl für die GNSS- als auch die Störersimulation mehrkanalig und realistisch erzeugen. Für Tests in einer HIL-Umgebung ist es auch möglich, Bewegungsdaten an das GNSS-Testsystem zu streamen. (eck)

<a href="http://www.rohde-schwarz.com">www.rohde-schwarz.com</a>

Sebastian Kehl-Waas ist Applikationsingenieur für Signalgeneratoren bei Rohde & Schwarz. Dr. Markus Irsigler ist Produktmanager GNSS bei Rohde & Schwarz.

Bild 1a: Diese GNSS-Empfangsantenne hat nur ein Element, ihre Charakteristik lässt sich also nicht modifizieren. Ein Störsignal ausreichender Stärke kann dazu führen, dass der Empfänger die Signale nicht mehr verarbeitet und satellitenbasiertes Navigieren nicht mehr möglich ist.

Bild 1b: Im Gegensatz zur Einzelantenne lässt sich die Charakteristik von Antennen-Arrays durch Kombination und Gewichtung der Empfangssignale anpassen. Das Störsignal wird in der Einfallsrichtung unterdrückt, und die GNSS-Signale können empfangen werden. Nachteil: GNSS-Signale aus der Richtung des Störsignals werden ebenfalls unterdrückt. 

Bild 2: Vierkanaliges GNSS-Testsystem aus zwei Vektorsignalgeneratoren R&S SMW200A und einem Analogsignalgenerator R&S SMA100B für das LO-Signal (links). Das Testsystem zur Erzeugung der Störsignale (rechts) besteht ebenfalls aus zwei Vektorsignalgeneratoren R&S SMW200A und einem Analogsignalgenerator R&S SMA100B für das LO-Signal.

Dr. Markus Irsigler ist Produktmanager GNSS bei Rohde & Schwarz.

Sebastian Kehl-Waas ist Applikationsingenieur für Signalgeneratoren bei Rohde & Schwarz. 

Rohde & Schwarz

Ist eine C-V2X-Zertifizierung notwendig oder nur „nice to have“?

Mehr Sicherheit im Straßenverkehr ist einer der Gründe für automatisiertes Fahren. Dafür spielte es eine wichtige Rolle, dass ein Fahrzeug weiß, was einen Kilometer vor ihm passiert, um präventive Maßnahmen ergreifen zu können.

Mehr Sicherheit im Straßenverkehr ist einer der Gründe für automatisiertes  Fahren. Dafür spielte es eine wichtige Rolle, dass ein Fahrzeug weiß, was einen Kilometer vor ihm passiert, um präventive Maßnahmen ergreifen zu können. C-V2X wird hier die Voraussetzungen schaffen. Aber wie steht es um die Zertifizierung der C-V2X-Systeme?

Auf dem OmniAir Global Plugfest im September 2020 begann Lars Reger, CTO von NXP Semiconductors, seine Keynote mit der Frage: „Wäre es nicht toll, wenn Sie in Echtzeit wissen könnten, was außerhalb Ihrer direkten Blickrichtung passiert? Wenn Sie wissen würden, dass ein Auto auf eine Kreuzung zufährt, lange bevor Sie es sehen können?“ Das ermöglicht Cellular Vehicle-to-Everything (C-V2X). C-V2X realisiert eine 360-Grad-Erfassung ohne Sichtkontakt (Non-Line-of-Sight, NLOS) sowohl bei guten als auch bei schlechten Wetterbedingungen, um die Funktionalität und Sicherheit des automatisierten Fahrens zu verbessern (Bild 1). C-V2X ergänzt Line-of-Sight-Sensoren (LoS-Sensoren) wie Radar, Lidar und Kamera mit Informationen, die außerhalb deren Erfassungsbereiches liegen, und ermöglicht es dem Fahrzeug, fundierte und besser koordinierte Entscheidungen zu treffen. Während LoS-Sensoren die Intention des Fahrzeugs oder des Fahrers nicht mitteilen können, vermittelt C-V2X die Intention durch die gemeinsame Nutzung von Sensordaten. Das führt zu einem höheren Maß an Vorhersehbarkeit in Verkehrssituationen wie Spurwechsel, wechselnde Geschwindigkeiten oder Straßengefahren.

Die 5G Automotive Association (5GAA) war maßgeblich an der Identifizierung von Anwendungsfällen für C-V2X beteiligt und hat diese in die folgenden Kategorien eingeteilt:

<ul><li>Sicherheit: Notbremsung, Kreuzungsmanagement-Assistent und Kollisionswarnung sind Beispiele für Sicherheitsanwendungsfälle. Die meisten Anwendungsfälle gelten gleichermaßen für automatisierte Fahrzeuge und menschliche Fahrer, mit einigen wenigen Ausnahmen.</li><li>Fahrzeugbetriebs-Management: Zu den Anwendungsfällen in dieser Gruppe gehören die Überwachung von Sensoren, Software-Updates und Remote-Support; sie werden von Automobilherstellern zur Wartung und Überwachung von Fahrzeugen bereitgestellt.</li><li>Komfort: Zu den Anwendungsfällen in dieser Gruppe gehören assistierte und kooperative Navigation, autonomes Parken und Infotainment.</li><li>Vollautomatisiertes und autonomes Fahren: Diese Gruppe umfasst Anwendungsfälle für die Automatisierungs-Level 4 und 5, Teleoperation, Herunterladen von Karten und kooperative Interaktion zwischen Fahrzeugen, um effizient und sicher zu sein.</li><li>Platooning: Diese Anwendungsfälle sind für Transportunternehmen von Interesse und betreffen Anwendungen wie die Bildung und Auflösung eines Nutzfahrzeugzuges, die Positionsbestimmung und das Abstandsmanagement in einer Kolonne sowie die Steuerung des Zuges im stationären Zustand.</li><li>Verkehrseffizienz und Umweltfreundlichkeit: Beispiele für Anwendungsfälle sind Green Light Optimal Speed Advisory (Glosa), Stauinformationen und Routenberatung.</li><li>Gesellschaft und Gemeinschaft: Zu den Anwendungsfällen gehören herannahende Einsatzfahrzeuge, Ampelvorrang und Unfallberichte, die für Einsatzfahrzeuge und -dienste sowie für den Schutz gefährdeter Verkehrsteilnehmer von Bedeutung sind.</li></ul>

Zu den ersten Anwendungsfällen gehören Sicherheitsfunktionen wie elektronisches Notbremslicht und Kollisionswarner, Überholverbotswarnung, Warnung vor dem toten Winkel und Spurwechsel, Warnung vor gefährdeten Verkehrsteilnehmern, Baustellenwarnung und Kreuzungsassistenz.

Zu den Anwendungsfällen des zweiten Schritts gehören Funktionen für automatisiertes Fahren wie die gemeinsame Nutzung von Sensoren in der Cloud und die Vorhersage der Netzverfügbarkeit.

Die C-V2X-Tests umfassen vordefinierte, ausführbare Tests für Anwendungsfälle des ersten und zweiten Schritts sowie Funktionstests von On-Board-Units (OBUs) in verschiedenen Szenarien. Ferner werden die verschiedenen Software-Stacks für die verschiedenen Regionen getestet.

Wie wichtig ist eine Zertifizierung für C-V2X?

C-V2X ist eine relativ neue Technologie im Automobilbereich, und die Vorschriften und Normen für ihren Betrieb und ihre Einhaltung stecken noch in den Kinderschuhen. Daher ist die Zertifizierung von entscheidender Bedeutung, um eine korrekte Implementierung und Interoperabilität zu gewährleisten, weil die Norm Lücken aufweisen kann, die zu unterschiedlichen Auslegungen der Norm durch verschiedene Anbieter führen können. Die Einhaltung der einschlägigen Normen und Spezifikationen gewährleistet eine genaue und zuverlässige Kommunikation zwischen C-V2X und anderen vernetzten Fahrzeug- und Fahrerinformationssystemen sowie anderen Anwendungen. Hersteller, die eine Zertifizierung erhalten, können zugelassene Produkte schnell auf den Markt bringen und ihren Ruf auf dem Markt verbessern.

Speziell bei C-V2X besteht eine der größten Herausforderungen darin, mit den neuen Standards Schritt zu halten. Die Lösungen müssen mit der aktuellen Entwicklung der C-V2X-Anforderungen Schritt halten – einschließlich der Releases für 5G New Radio. Testlösungen müssen einen umfassenden und ganzheitlichen Ansatz zum Testen der HF-, Protokoll- und Anwendungsschichten bieten, um die Qualitäts-, Leistungs- und Sicherheitsziele zu erfüllen. Daher ist eine Zertifizierung wichtig.

 Das US-amerikanische OmniAir Consortium ist ein Industrieverband, der 2004 mit dem Ziel gegründet wurde, die Zertifizierung von intelligenten Verkehrssystemen zu fördern. Die Zertifizierung hat zwei Komponenten:

<ul><li>Konformität</li><li>Interoperabilität</li></ul>

Die Konformität stellt sicher, dass die Technologie den Spezifikationen entspricht und ordnungsgemäß implementiert wurde, während die Interoperabilität gewährleistet, dass sie mit anderen Lösungen zusammenarbeitet und korrekt funktioniert. OmniAir und seine Mitglieder arbeiten gemeinsam mit Interessenvertretern des Transportsektors an der Entwicklung von Anforderungen und Spezifikationen für Technologien, die Radio-Frequency-Identification- bis zu Dedicated-Short-Range-Communication-basierter Konnektivität reichen. OmniAir hat das C-V2X-Gerätezertifizierungsprogramm zusammen mit Unternehmen aus der Automobilindustrie geleitet und entwickelt.

Zu den Mitgliedern von OmniAir gehören öffentliche Einrichtungen, Privatunternehmen, Forschungsinstitute und Testlabors. Sie nehmen an Arbeitsgruppen und Ausschüssen teil, die Anforderungen und Spezifikationen in verschiedenen Bereichen des Verkehrs entwickeln. Die Zertifizierung durch Organisationen wie OmniAir bietet die Gewähr, dass die Geräte Mindestanforderungen an Leistung und Interoperabilität erfüllen.

Für die Bitübertragungsschicht (PHY) umfassen die Testspezifikationen typische Wireless-Sendeparameter wie Ausgangsleistung, Error Vector Magnitude (EVM)-Pegel und In-Band-Emissionen sowie Empfangsparameter wie Empfängerempfindlichkeit und Durchsatz. Die Protokolltests umfassen Testfälle für die grundlegenden Sicherheitsnachrichten von C-V2X, das Wave-Kurznachrichtenprotokoll sowie das semi-persistente Scheduling – den Algorithmus zur Kollisionsvermeidung bei Wireless-Überlastungen.

Beim Testen der HF-, Protokoll-, Nachrichten- und Anwendungsschichten von C-V2X ist ein ganzheitlicher Ansatz wichtig. Einige der wesentlichen Elemente, die zu einer Beschleunigung der Tests beitragen, sind:

<ul><li>Eine intuitive Benutzeroberfläche zur Vereinfachung von C-V2X-Messungen</li><li>Ein Emulator für das globale Satellitennavigationssystem (GNSS) zur Erzeugung von Signalen für realistische GNSS</li><li>Eine 5G-Messplattform zum Schutz der Anfangsinvestitionen und zur Beschleunigung der Einrichtung von 5G NR, das erweiterte Sicherheitsfunktionen ermöglichen wird.</li></ul>

Die Tests der HF-, Protokoll-, Nachrichten- und Anwendungsschicht sollten beide Schnittstellen abdecken: User-to-UTRAN (Uu) sowie direkte Kommunikation PHY sidelink (PC5), wie in Bild 2 dargestellt. Die Tests können im Labor für Entwicklungs- und Interoperabilitätstests, im Feld zur Überwachung der Teststrecke und Aufzeichnung und im Fahrzeug für die Überwachung, Aufzeichnung und Protokollierung durchgeführt werden.

OmniAir hat die C-V2X-Testlösung von Keysight (Bild 3) für PHY- und Protokollkonformität auf der Grundlage der LTE-V2X-basierten Testverfahren 761, 762 und 765 des Konsortiums zertifiziert. Das ermöglicht es einem von OmniAir autorisierten Testlabor mit Keysight-Geräten, eine Kombination aus manuellen und automatisierten Testfällen durchzuführen, die anhand von Industriestandards entwickelt wurden.

Auf dem zu Beginn des Artikels erwähnten Plugfest betonte Lars Reger weithin anschaulich die Wichtigkeit von Cellular-Vehicle-to-Everything: „Wäre es nicht toll zu wissen, dass ein Fahrzeug kurz vor Ihnen eine Vollbremsung macht, obwohl Sie es nicht sehen können, weil sich ein Lkw zwischen Ihnen und dem anderen Auto befindet? Wäre es nicht toll, zu wissen, wann die Ampel auf Grün oder Rot umschaltet? Wäre es nicht toll zu wissen, dass sich direkt vor Ihnen eine vereiste und rutschige Straße befindet?“

Die Diskussionsteilnehmer und Referenten auf der Veranstaltung waren sich einig und plädierten dafür, dass C-V2X bald im Straßenverkehr zum Einsatz kommt. Die NLoS-Sensorfähigkeit wird zukünftig obligatorisch und C-V2X mehr als ein Nice-to-have sein. Um sicherzustellen, dass diese NLoS-Sensoren und C-V2X in allen Fahr- und Verkehrsszenarien korrekt funktionieren, wird die OmniAir-Zertifizierung entscheidend sein. (eck)

<a href="http://www.keysight.com">www.keysight.com</a>

Cheryl Ajluni ist Director of Solutions Marketing bei Keysight Technologies.

 Bild 1: Typische Cellular-V2X-Anwendungen 

Bild 3: Das C-V2X-Testsystem von Keysight Technologies hat den Status „OmniAir Qualified Test Equipment“ für C-V2X-Gerätetests erhalten. 

 Cheryl Ajluni ist Director of Solutions Marketing bei Keysight Technologies.

Keysight

Connectivity (Bussysteme, Telekommunikation, 4G / 5G, WLAN)

Vom Wettlauf der Sensortechnologien zur Harmonie der Systeme

Um automatisiertes Fahren zu ermöglichen, müssen die Fahrzeuge ihr Umfeld rundum erkennen. Eine wichtige Voraussetzung hierfür sind Sensoren, wie   Kameras, Radare oder Lidare. Diese sorgen nur im Zusammenspiel für die notwendige Sicherheit eines automatisierten Fahrzeugs.

Um automatisiertes Fahren zu ermöglichen, müssen die Fahrzeuge ihr Umfeld rundum erkennen. Eine wichtige Voraussetzung hierfür sind Sensoren, wie Kameras, Radare oder Lidare.

Die Nachfrage nach automatisierten Fahrsystemen wächst mit den technischen Möglichkeiten. Was heute längst zum erweiterten Kompaktklassenstandard gehört – etwa Spurhalteassistenten oder Auffahrwarnsysteme –, waren noch vor wenigen Jahren die Messehighlights der Oberklasse. Dabei steht auf dem Weg zum vollautomatisierten und später autonomen Fahrerlebnis nicht nur der Komfort im Fahrzeug durch eine Entlastung der Fahrer:innen im Vordergrund, sondern vor allen Dingen eine Steigerung der Sicherheit. Doch gerade in diesem Punkt wird die öffentliche Diskussion häufig emotional. Die Funktionsfähigkeit von Sensoren und die Algorithmen-basierte Verarbeitung der generierten Daten über das Wohlergehen von Menschen entscheiden zu lassen, fällt vielfach schwer. Vor allen Dingen dann, wenn man erkennt, dass jede Sensortechnologie in den hochkomplexen verschiedenen Situationen im täglichen Straßenverkehr irgendwann an ihre Grenzen stößt. Dogmatische Diskussionen über die Überlegenheit bestimmter Systeme und der entsprechend kategorische Verzicht auf andere sorgen zwar für Hersteller-Publicity, verkennen jedoch die Tatsache, dass die verschiedenen Technologien, zum Beispiel Kamerasysteme, Radar- oder Lidar-Sensoren, nur in ihrer Kombination wirklich für die Sicherheit sorgen, die in der Alltagsmobilität benötigt wird. Doch wo liegen eigentlich die Vor- und Nachteile der jeweiligen Sensorgattungen? Wo ergänzen sie sich oder stoßen an ihre Grenzen? Welche Herausforderungen gibt es dabei, die Daten der unterschiedlichen Sensoren miteinander in Einklang zu bringen und in entsprechende Fahrzeugsteuerungen umzuwandeln? Und wie können Solid-State-Lidar-Sensoren wie der ibeoNext (Bild 1) das automatisierte Fahren disruptieren?

Wer sich als Fahrzeughersteller heute ernsthaft mit dem Thema Level-3-Zulassung beschäftigt – also dem hochautomatisierten Fahren, bei dem die Fahrer:innen zumindest vorübergehend in bestimmten Situationen Fahraufgaben und Verkehr der Technik überlassen dürfen –, muss sich gleich mehreren Herausforderungen stellen. Zum einen suggerieren bisweilen etwas zu selbstbewusste Ankündigungen einzelner Automobilhersteller, entsprechende Fahrzeuge müssten doch eigentlich schon längst serienfertig zur Verfügung stehen. Zum anderen sorgen neue Regulatorien oder angepasste Crashtest-Anforderungen zu Recht dafür, dass der Wettstreit um die begehrten Level-3-Zulassungen nicht zulasten der Sicherheit geht. Denn – abgesehen vom persönlichen Leid eines jeden Unfalls – ein Unfall durch eine technische Fehlfunktion während eines automatisierten Fahrvorgangs wäre für die Fahrzeughersteller ein Super-GAU und würde schwere Image-Schäden nach sich ziehen. Während sich etwa Tesla-Chef Elon Musk dabei noch verschiedenen Sensortechnologien verschließt und primär auf Kamerasysteme setzt, kombinieren die Entwicklungsabteilungen fast aller anderen Hersteller mittlerweile eine Vielzahl verschiedener Sensormodalitäten, namentlich Kamera-, Radar- und Lidar-Sensoren. Dabei werden nicht nur die jeweiligen Kernkompetenzen der Technologien genutzt, um die jeweils beste Leistung in einem abgrenzbaren Anwendungsbereich zu gewährleisten. Es geht darum, Redundanzen herzustellen, um bei Störungen der einzelnen Technologien für mehr Sicherheit zu sorgen. Also das Bestreben, so viele verschiedene Sensoren wie möglich mit ihren unterschiedlichen Stärken und Schwächen zu fusionieren, um letztendlich ein stets zuverlässiges Gesamtsystem abzubilden.

Bei Kamera-, Radar- und Lidar-Systemen ist die Abdeckung großer Sichtfelder möglich – mit jeweils unterschiedlichen Kernkompetenzen: So haben etwa Kamerasysteme eine vergleichsweise hohe Auflösung und können Farben gut wahrnehmen, zum Beispiel Ampeln oder Verkehrsschilder. Es ist heutzutage verhältnismäßig einfach, kamerabasiert Objekte zu identifizieren. Kameras sind außerdem vergleichsweise günstig und durch ihre kompakte Größe einfach integrierbar. Allerdings sehen Kameras eben genau dann schlecht, wenn auch das menschliche Auge an seine Grenzen stößt – bei Dunkelheit oder generell schlechten Sichtverhältnissen. Sie können nur mit großem Aufwand Entfernungen einschätzen und Personennachbildungen, zum Beispiel im Rahmen von Werbeaufdrucken auf Lkw, häufig nicht von realen Menschen unterscheiden.

Lidar- und Radarsensoren erweisen sich dagegen auch bei schlechten Sichtverhältnissen als verlässlichere Quellen. So ist Radar gut für die Detektion von metallischen Objekten (Autos) und relativ robust gegen Wettereinflüsse. Während Radar dabei Radiowellen nutzt, verwenden Lidar-Sensoren Laserlicht im nicht sichtbaren Infrarotbereich. Allerdings streut das im Vergleich zum Radar kurzwelligere Laserlicht beispielsweise stärker an Nebeltröpfchen, wodurch die Performance gemindert werden kann. Da Radiowellen um ein Vielfaches größer sind, genaugenommen im Millimeterbereich, während sich Lidar im Mikrometerbereich befindet, erfolgt bei Radarsensoren kaum eine Streuung an kleinen Teilchen. Deshalb werden sie nur unwesentlich von Nebel oder Staub beeinträchtigt. Der Nachteil der größeren Wellenlänge bei Radar im Vergleich zum Lidar-Sensor ist die ungenauere Winkelauflösung. So können zum Beispiel zwei Objekte, die in ähnlicher Entfernung dicht beieinanderstehen, als ein Objekt dargestellt werden, während Lidar-Sensoren mit „Punktwolken“-Strukturen im Stande sind, Objekte bis ins kleinste Detail darzustellen.

Lidar-Sensoren können mit einer hohen Winkel- und Distanzauflösung Entfernungen bestimmen und sind so in der Lage, die Schwächen von Radar und Kamera zu kompensieren. Noch sind konventionelle Lidare allerdings um ein Vielfaches kostenintensiver als Kameras oder Radare. Der Grund liegt in der Bauart: Die rotierenden Teile in herkömmlichen Lidar-Systemen sind ein zusätzliches Bauteil in der Bill of Material (BOM) und wegen des mechanischen Aufbaus, der wartungsfrei über die gesamte Lebensdauer des Autos funktionieren muss, in der Regel teurer als rein elektronisch angesteuerte Systeme.

Wesentlich günstiger, kompakter und zuverlässiger sind dagegen Solid-State-Lidar-Sensoren, die das gesamte Blickfeld (Field of View, FOV) ohne rotierende Spiegel abdecken: Sie benötigen keine beweglichen Teile und sind bei einer entsprechenden Konstruktion kleiner, einfacher im Design und nahezu verschleißfrei.

Datengenerierung über Solid-State-Lidar-Systeme

Aktuell gibt es verschiedene Konstruktionsweisen für Solid-State-Lidare. Der Lidar-Spezialist Ibeo hat sich beim ibeoNext für eine Version des Sequential Flash Lidar entschieden. Hier wird das Licht dahin ausgesendet, wo auch die Detektoren hinschauen, anstatt, wie sonst beim Flash-Lidar üblich, das gesamte Sichtfeld mit Licht zu fluten (Bild 2). Obwohl das Sensormodul dabei so klein ist, dass es auf eine Kreditkarte passt, ist es leistungsfähig und erzeugt eine hochauflösende dreidimensionale Punktwolke.

Durch das Time-Correlated-Single-Photon-Counting-Messverfahren (TCSPC) können die empfangenen Daten umfangreich digital verarbeitet und mehr Informationen erfasst werden als mit herkömmlichen Lidar-Systemen. Das betrifft nicht nur die Distanz, sondern beispielsweise auch bestimmte Objekteigenschaften und Wetterbedingungen. Und: Der Solid-State-Lidar-Sensor von Ibeo wurde bereits ausgiebig getestet, die Serieneinführung ist für 2022 geplant. Ein weiterer großer Schritt in Richtung automatisiertes Fahren.

Zusammenspiel der verschiedenen Sensorsysteme danke Software

Für die Umwandlung der sensorgenerierten Informationen sorgt die entsprechende Ibeo-Perception-Software. Dafür erhält sie von den Lidar-Sensoren die Punktwolke sowie das sogenannte Intensitätsbild. Jeder Punkt der Punktwolke beinhaltet dabei Detailinformationen zu Distanz, Winkel und Intensität der Reflexion. Daraus lässt sich dann nicht nur die Position, sondern auch die Beschaffenheit der Umgebungsobjekte ableiten. Die Perception-Software erstellt so ein detailliertes Umgebungsmodell, das weit über räumliche Punktwolkendaten hinausgeht und somit verschiedene Fahranwendungen sicher ermöglicht. Sie lokalisiert dafür die Objekte und erkennt, ob es sich etwa um Pkw, Lkw, Fußgänger:innen oder aber um (unbewegliche) Infrastruktur handelt. Über die Intensitätsinformationen lassen sich zudem auch Fahrspuren erkennen. Des Weiteren erfasst die Perception-Software „Free Space“, also Räume, in denen sich keine Objekte befinden. Dieses Umgebungsmodell wird dann an die Steuerung der Fahrfunktionen weitergegeben, die entscheidet, welche Schlüsse daraus für das Fahrzeug zu ziehen sind, und letztendlich entsprechende Befehle an die vom OEM gestalteten Aktuatorik-Systeme des Fahrzeugs gibt.

So stark die unterschiedlichen Sensorsysteme in ihren jeweiligen Disziplinen auch sind, ohne eine entsprechende Fusionierung bleiben sie Einzelkämpfer. Für eine Harmonie und etwa bei Sensorausfällen wichtige Systemredundanz in der Datenerhebung sorgen erst spezielle Schnittstellen, zum Beispiel Unsicherheitsabschätzungen für die Fusion aller Sensorsysteme. Doch damit das funktioniert, müssen die Hersteller der Sensoren diese undogmatisch mit offenen Schnittstellen versehen, damit die Daten zentral prozessiert und verschiedene Befehle – zum Beispiel lenken, bremsen oder beschleunigen – an die entsprechenden Systeme des Fahrzeugs weitergeleitet werden können.

Kamera-, Lidar- und Radarsensoren generieren hierfür unterschiedliche Daten, die für eine Fusion in ein gemeinsames Raster, ein gemeinsames Koordinatensystem, gebracht werden müssen. Ein verbreiteter Ansatz hierbei ist es, mit „Confidencen“ zu arbeiten. Jeder Sensor gibt dabei zusätzlich zu seinen Daten auch eine Wahrscheinlichkeit dafür an, wie sicher die jeweiligen Datenerhebungen sind. Wenn alle drei verschiedenen Sensormodalitäten das tun, kann man diese Wahrscheinlichkeitsaussagen im Rahmen eines Gesamtsystems kombinieren und fusionieren.

Nur so kann es eine echte integrative Zusammenarbeit der verschiedenen Sensoren geben. Auf dem Weg zu einem wirklich sicheren weitgehend automatisierten Fahren der Stufen 3 oder sogar 4 stehen also die Integrationsfähigkeit der Einzelsysteme und deren Fusion als eine der Kernherausforderungen im Aufgabenheft der Entwicklungsabteilungen. Aus Herstellersicht wünschenswert ist eine Sensorfusion auf möglichst niedrigem Level, d. h. bereits bei den Rohdaten von Kamera, Radar und Lidar. Aufgrund der großen Datenmengen ist es aktuell jedoch technisch kaum möglich, eine Rohdatenfusion auf einer zentralen Recheneinheit im Auto in Echtzeit zu realisieren.

Ein Kompromiss liegt in der Abstraktion: Die Daten von Lidar, Kamera und Radar werden getrennt zu Objekten verarbeitet und anschließend miteinander fusioniert. Hierbei gehen zwar Informationen verloren, doch auch eine Fusion auf Objektebene bedeutet bereits heute eine erhebliche Erweiterung des Technologiepotenzials – mit einem Plus an Komfort, vor allen Dingen aber auch mit erheblichen Steigerungen der Sicherheit im Verhältnis zu einer weitgehend menschlichen Fahrzeugsteuerung. Doch mit Blick auf die rasant wachsenden Übertragungs- und Rechengeschwindigkeiten wird eine Sensorfusion im Fahrzeug bald auch mit weitaus detaillierteren Daten möglich sein. (eck)

Hanno Holzhüter arbeitet als Research Project Manager bei Ibeo Automotive Systems und ist gleichzeitig Doktorand mit Schwerpunkt digitale Signalverarbeitung in Lidar-Sensoren an der Leibniz Universität Hannover und bei Ibeo AS.

Hanno Holzhüter arbeitet als Research Project Manager bei Ibeo Automotive Systems und ist gleichzeitig Doktorand mit Schwerpunkt digitale Signalverarbeitung in Lidar-Sensoren an der Leibniz Universität Hannover und bei Ibeo AS.

Bild 1: Der Solid-State-Lidar-Sensor ibeoNext kommt ohne bewegliche Teile aus und soll bereits Ende 2022 serienreif sein.

Bild 2: Der IbeoNext sendet als Sequential-Flash-Lidar-Variante das Licht dorthin, wo auch die Detektoren hinschauen.

ibeo

Sensoren / Aktoren

Hürden bei der Skalierung der Lidar-Produktion

Lidar gilt als Schlüsseltechnologie für das automatisierte Fahren – ohne Lidar sind Experten überzeugt, lässt sich Level 3 nicht umsetzten.

Lidar gilt als Schlüsseltechnologie für das automatisierte Fahren – ohne Lidar  sind Experten überzeugt, lässt sich Level 3 nicht umsetzten. Doch auf dem Weg von der Prototypenphase zur Massenfertigung muss die Lidar-Industrie noch große Herausforderungen bewältigen.

Die Lidar-Industrie ist noch jung und steht momentan an einem spannenden Wendepunkt: Immer mehr Lidar-Hersteller verkünden Serien-Aufträge von OEMs. Einige sind bereits dabei den Massenproduktionsprozess einzuläuten. Zu den Herstellern, die ihre Produktionskapazitäten skalieren, gehört auch Cepton. Der Lidar-Produzent aus dem Silicon Valley hat einen Großauftrag von General Motors für den Einsatz von Lidar-Systemen in zahlreichen Fahrzeugklassen erhalten. Doch auf dem Weg von der Prototypenphase zur Massenfertigung ist die Lidar-Industrie noch mit großen Herausforderungen konfrontiert.

Der Übergang in die Massenfertigung ist mit vielen Unwägbarkeiten und einer steilen Lernkurve verbunden. Es gibt jedoch einige grundlegende Fragen, mit denen sich zunächst alle Lidar-Hersteller auseinandersetzen müssen. Dazu gehört die Entscheidung, ob sich ein Lidar-Produzent mit einem Tier-1-Zulieferer zusammenschließt oder die Produktion selbst verantwortet. Weitere Bausteine sind die Produktionsanlagen und das Know-how der Belegschaft: Neben Rohstoffen und Chips ist auch qualifiziertes Personal eine knappe Ressource. Eine besondere Gratwanderung ist darüber hinaus die Senkung der Kosten, ohne die Zuverlässigkeit und Qualität des Sensors zu beeinträchtigen.

 Die Qualitätsanforderungen in der Automobilbranche sind hoch, was die Produktion von Lidar-Sensoren aufwendig macht. Die Hersteller müssen eine Vielzahl von Standards einhalten und den strengen Qualitätskontrollen der Autobauer und Tier-1-Zulieferer entsprechen. Standards wie AEC-Q100 oder AEC-Q102 für optoelektronische Bauelemente prüfen zum Beispiel die Funktion der Bauteile in bestimmten Temperaturbereichen und wechselnden Klimabedingungen. Eine weitere wichtige Norm ist die ISO 16750, die Versuche und Testverfahren unter verschiedenen Umweltbedingungen definiert. Dazu zählen Umweltfaktoren, mechanische und elektrische Belastungen, der Fahrzeugtyp, Betriebsarten des Fahrzeugs und die Integration im Fahrzeug. Darüber hinaus klassifizieren die Automotive Safety Integrity Level auf Basis der ISO 26262, inwieweit der Ausfall von Bauteilen funktionale Sicherheitsrisiken birgt. Neben den etablierten Standards gilt es auch die eigens entwickelten Normen der Automobilbauer zu erfüllen. Autobauer wie BMW, Audi oder VW entwickelten beispielsweise die Norm LV 124, die Anforderungen und Tests für elektrische, elektronische sowie mechatronische Komponenten für den Einsatz in Fahrzeugen bis 3,5 t spezifiziert. Ergänzend zu den strengen Anforderungen an die Hardware wird auch der Software-Code einer eingehenden Prüfung unterzogen. Ein solcher Software-Audit ist ein langwieriger Prozess, der zum Teil auch an externe Dienstleister ausgelagert wird.

Außerdem findet ein gründlicher Audit-Prozess entlang der Lieferkette statt. Dieser umfasst beispielsweise die Freigabeprüfung der Produktionsanlagen sowie deren Kalibrierung. Daneben gibt es auch Audit-Prozesse, die die eigentliche Produktion auf den Prüfstand stellen. Zum Beispiel Run@Rate Audits, in denen untersucht wird, ob die vertraglich geforderten Stückzahlen problemlos produziert werden können. Eng damit verbunden ist das PPAP-Verfahren (Part Production Approval Process), das vorranging die Qualität der Bauteile überprüft und ein Rahmenwerk für die Beurteilung durch den Abnehmer bereitstellt. Um diese Vorgaben zu erfüllen, müssen die Sensoren bereits in den frühen Phasen der Prototypentwicklung entsprechend ausgelegt werden.

Spätestens bei der Vorstellung der A- und B-Muster spielen Konzepte wie Design for Manufacturing and Assembly (DFMA) eine zentrale Rolle bei der Konstruktion, da es sich beim Produktdesign um einen wichtigen Kostenfaktor handelt: Das Design definiert 70 bis 80 Prozent der Produktkosten. Die fertigungs- und montagegerechte Gestaltung eines Sensors reduziert unter anderem systematisch Bauteile, Schnittstellen und jegliche Fehlermöglichkeiten im Herstellungsprozess. DFMA ist aber nicht das einzige Prinzip, das im Rahmen der Optimierung der Produktion zum Einsatz kommt. Ergänzend finden zum Beispiel Lean-Management-Konzepte oder die TRIZ-Methode Anwendung. Das Sensor-Design kann sich durch diesen Optimierungsprozess von Grund auf verändern.

Ob ein Lidar-Sensor für die Produktion in hohen Stückzahlen geeignet ist, hängt zunächst von der Sensor-Technologie ab. Die variierenden Technologieansätze, wie Solid-State-Sensoren oder Sensoren mit rotierenden Spiegeln, eignen sich unterschiedlich gut für höhere Produktionsvolumen. Hier ist es jedoch schwierig eine pauschale Aussage zu treffen. Zweckmäßiger sind aber auf jeden Fall Technologien, die auf kostengünstigen Komponenten mit einem hohen Reifegrad und einer möglichst sicheren Lieferkette basieren. Komplexe Designs lassen sich nur schwer oder überhaupt nicht skalieren. Bei Ceptons Technologie kommen daher Edge-Emitting Laserdioden (EEL) und Avalanche-Photodioden (APD) zum Einsatz. Gleichzeitig kommt die Micro Motion Technologie (MMT) ohne Spiegel, rotierende oder reibungserzeugende Elemente aus (Bild 1), was die Zuverlässigkeit der Sensoren verbessert und den Produktionsaufwand minimiert. Trotzdem musste auch Cepton in Vorbereitung auf die Massenproduktion Änderungen an den Bauteilen vornehmen: Beispielsweise wurden das Aluminium-Gehäuse oder 3D-gedruckte Bauteile durch Komponenten ersetzt, die im Spritzgussverfahren gefertigt werden.

Eine besondere Herausforderung bei der Lidar-Produktion stellt die Kalibrierung der Sensoren dar, die bei optischen Sensoren anspruchsvoll ist. Bereits kleine Abweichungen im optischen Pfad können zu einem veränderten Detektionsergebnis führen. Lidar-Sensoren werden deshalb sowohl intrinsisch wie auch extrinsisch kalibriert. Für die intrinsische Kalibrierung ist der Lidar-Hersteller und/oder der beteiligte Tier-1-Zulieferer zuständig. Dabei wird unter anderem eine geometrische Kalibrierung vorgenommen, die systematische Fehler aus der 3D-Punktewolke eliminiert. Außerdem überprüft der Hersteller im Rahmen der intrinsischen Kalibrierung die Erkennung verschiedener Intensitäten. Lidar-Sensoren müssen je nach Reflektivität einer Oberfläche zuverlässig unterschiedliche Intensitäten darstellen können. Weiße Flächen erscheinen so in einer anderen Farbe als zum Beispiel schwarze Abschnitte. Auch die Reichweitenmessung muss für jeden Sensor, der vom Band läuft, zuverlässig funktionieren.

Die extrinsische Kalibrierung fällt in den Verantwortungsbereich der Automobilhersteller. Am Ende der Montage wird der Sensor auf einen Referenzpunkt im Fahrzeug kalibriert. So ist sichergestellt, dass alle im Fahrzeug verbauten Sensoren, egal ob Lidar, Radar oder Kamera, dasselbe Koordinatensystem verwenden – das ist für die Sensorfusion essenziell. Als Referenzpunkt dient meist der Mittelpunkt der Hinterachse. Wichtig ist im Rahmen der extrinsischen Kalibrierung auch eine Echtzeit-Erkennung der Sensor-Ausrichtung: Das Fahrzeug muss auch nach kleineren Unfällen erkennen, ob sich die Position oder Ausrichtung des Sensors verändert hat. Eine durchdachte Sensor-Platzierung kann dabei unterstützen, dass solche Szenarien eher die Ausnahme bleiben.

 An welcher Stelle der Sensor platziert ist, hat einen großen Einfluss auf die Komplexität und die Abmessungen eines Lidar-Sensors. Idealerweise sind Lidar-Sensoren so geschützt und hoch wie möglich verbaut. Zum einen lässt sich somit ein viel umfänglicheres Bild der Umgebung erzeugen, zum anderen ist eine geringere IP-Schutzart vonnöten. Ein Sensor hinter der Windschutzscheibe muss offensichtlich weniger gut gegen Wasser, Fremdkörper oder Berührungen geschützt sein als ein Sensor, der im Kühlergrill oder in die Karosserie des Fahrzeugs integriert wurde. Hier ist der Entwicklungsaufwand ungleich höher.

Trotz der offenkundigen Vorteile einer Platzierung hinter der Frontscheibe ist die Platzierung der Sensoren stets getrieben vom jeweiligen Anwendungsfall (Bild 2). Für vorwärts gerichtete Systeme wie Spurhalte- und Notbremsassistenten und viele andere Anwendungen in Fahrerassistenzsystemen eignet sich tatsächlich eine möglichst hohe Montierung. So können die Sensoren weit im Voraus Informationen zum Streckenverlauf sammeln und werden nicht durch Hindernisse wie Mauern oder andere Verkehrsteilnehmer blockiert. Auch für die Lokalisierung des Fahrzeugs mithilfe von hochauflösendem Kartenmaterial ist eine möglichst große Rundumsicht auf Wegmarken wie Brücken oder Kreuzungen nötig. Für eine Abstandserkennung hingegen würde sich auch eine Anbringung im Grill – oder im Falle eines Elektrofahrzeugs hinter den vorderen Blenden – eignen. Der Fortschritt beim Automated Valet Parking treibt auch die Nachfrage nach Kurzstrecken-Lidar-Sensoren voran: Solche kompakten Lidar-Sensoren, wie der Nova von Cepton (Bild 3), können wie ein Sicherheitsgürtel um das Fahrzeug herum angebracht werden.

Aufgrund der zahlreichen unterschiedlichen Platzierungsoptionen müssen Lidar-Hersteller zwangsläufig flexibel bleiben. Nicht jeder Autobauer hat die Möglichkeit, den Lidar-Sensor optimal zu integrieren, und auch die Abmessungen des Sensors müssen häufig individuell angepasst werden. Die wechselnden Anforderungen für verschiedene Modell-Derivate erfordern eine flexible Architektur der Sensoren – das ist absolut ausschlaggebend für eine erfolgreiche Massenproduktion.

Zusammengefasst steht und fällt die erfolgreiche Skalierung der Lidar-Produktion mit einer geeigneten Sensor-Technologie und Architektur. Zunächst sollten die Sensoren natürlich die vorgegebenen KPIs der Automobilhersteller in Hinsicht auf Field of View (FoV), Reichweite, Auflösung und Frame-Rate erfüllen. Vor allem aber muss sich die zugrundeliegende Technologie auch für die Produktion im großen Maßstab eignen. Das bedeutet, die Sensoren sollten auf zuverlässigen, ausgereiften und kostengünstigen Bauteilen basieren – hier wird die Zeit zeigen, welche Hersteller auf die richtige Technologie gesetzt haben.  (eck)

<a href="http://www.cepton.com">www.cepton.com</a>

Henri Häfner ist Director Product Management & Marketing bei Cepton.

Bild 1: Die MMT-Technologie ist ein 3D-Bildgebungsverfahren ohne Spiegel, Rotation oder reibungserzeugende Elemente. 

Bild 2: Mögliche Platzierungsorte für gerichtete Lidar-Sensoren, z. B. am Kühlergrill, an den Seitenspiegeln, an der Heckklappe und an der hinteren Stoßstange.  

Bild 3: Beispiele für Lang- und Kurzstrecken-Sensoren von Cepton. Rechts ist der Nova-Sensor zu sehen. 

Henri Häfner ist Director  Product Management & Marketing bei Cepton. 

Cepton

Automatisiertes Fahren durch Drohnenaufzeichnung und Simulation absichern

Um automatisierte Fahrfunktionen mithilfe des szenariobasierten Testens entwickeln und absichern zu können, spielt das Verständnis über das Verhalten der Verkehrsteilnehmer eine grundlegende Rolle. Reale Verkehrssituationen durch Drohnen aufzuzeichnen hilft, große Mengen verwertbarer Daten zu gewinnen.

Um automatisierte Fahrfunktionen mithilfe des szenariobasierten Testens entwickeln und absichern zu können, spielt das Verständnis über das Verhalten der Verkehrsteilnehmer eine grundlegende Rolle.

Dr. Raphael Pfeffer und Dr. Paul Spannaus

Zur integralen und funktionalen Absicherung automatisierter Fahrfunktionen, also Level 2 und 3+, bietet sich ein szenariobasiertes Vorgehen an, das sich an Normen wie ISO 26262 oder SOTIF orientiert. Dabei gilt es, kritische Situationen – sowohl bekannte als auch unbekannte – zu identifizieren und das fehlerfreie Verhalten der Fahrfunktion abzusichern. Hierfür ist nicht nur ein Verständnis über das Verhalten der Verkehrsteilnehmer notwendig, es muss auch die statistische Relevanz von Szenarien berücksichtigt werden. Mit skalierbar erzeugten Top-View-Drohnenbeobachtungen – integriert in eine physikalische Simulation – sowie einer vollständigen Situationsrekonstruktion lässt sich eine umfangreiche Fahrzeug-Sensordatenbasis generieren. Die von den Umfeldsensoren gesammelten Daten reichen von logischen Objektlisten über physikalische, virtuelle Sensorinformationen wie Lidar und Radar bis hin zu Eigenbewegungen wie Beschleunigungen, Lenkwinkel, Nicken und Wanken. Damit liegt für die Entwicklung und Absicherung automatisierter Fahrfunktionen eine belastbare und skalierbare Ground Truth vor.

 Eine automatisierte Fahrfunktion muss dazu in der Lage sein, die Längs- und/oder Querführung eines Fahrzeugs in allen vorstellbaren realen Verkehrssituationen fehlerfrei übernehmen zu können. Viele Situationen lassen sich dabei aus der Definition der Fahrfunktion funktional erschließen. Beispielhafte kritische Situationen sind zwischen parkenden Fahrzeugen hervorlaufende Kinder oder Einschervorgänge auf der Autobahn, die mit zu geringem Abstand durchgeführt werden. Viele dieser Situationen sind vorab bekannt und in entsprechenden Testkatalogen im Software-Entwicklungsprozess des Fahrzeugs nutzbar.

Sogenannte blinde Flecke, hervorgerufen beispielsweise durch unvorhersehbare Verhaltensweisen, sind hingegen nicht bekannt. Es ist unklar, wie viele mögliche kritische Situationen für eine konkrete Fahraufgabe sowie deren Software-Umsetzung existieren und wie wahrscheinlich deren Auftreten ist. So entsteht in der Fahrzeugentwicklung die Notwendigkeit zur Etablierung eines Ablaufs, der systematisch alle kritischen Situationen identifiziert und in nutzbare Situationsbeschreibungen überführt, ohne dabei Verkehrsteilnehmer zu gefährden.

So vielfältig Situationen im Straßenverkehr sein können, so unterschiedlich sind auch die Reaktionsmuster auf eine konkrete Situation. Eine Bestimmung ihrer Auftretenswahrscheinlichkeit ist deshalb nur mit einer umfangreichen, den Verkehr nicht beeinflussenden Situationsbeobachtung möglich. Die daraus gewonnenen Situationen und Erkenntnisse bilden synthetisiert die Basis für die Software- und Funktionsgestaltung des automatisierten Fahrens.

Prozessual verzahnen sich bei der virtuellen Entwicklung des digitalen Zwillings mehrere Elemente: das V-Modell aus der Fahrzeugentwicklung, die durch Anwendungsfälle beschriebenen Anforderungen an das Soll-System, die in diesem System möglicherweise auftretenden Fehler (ISO 26262) sowie die Sicherheitsansprüche der Sollfunktion (SOTIF) inklusive systematischer Schwachstellenreduktion und szenarienbasierter Absicherung. Mit dem digitalen Zwilling liegt eine Abbildung der Wirklichkeit vor, an die Entwickler konkrete Anfragen stellen können. Exemplarisch könnte das die systematische Suche nach kritischen Situationen sein, in denen hochskalierte Cluster-Simulationen und Optimierungsverfahren zum Einsatz kommen können. Auch die szenarienbasierte Absicherung des neu generierten Software-Flash-Containers im Daily-Build-Prozess oder die Suche kritischer Testfälle für Safety- und Security-Fragestellungen sind denkbar.

Die Bundesregierung legt mit der „Verordnung zur Regelung des Betriebs von Kraftfahrzeugen mit automatisierter und autonomer Fahrfunktion und zur Änderung straßenverkehrsrechtlicher Vorschriften“ fest, dass bei entsprechenden Fahrzeugen – neben der Pflicht der Hersteller zum Nachweis systematischer Methoden zur Fehlverhalten-Minimierung – auch der Fahrzeughalter zu einer quartalsmäßigen Systemprüfung verpflichtet wird. Damit der digitale Zwilling der realen Umgebung (Bild 1) belastbar ist, gilt es, ihn mit Beobachtungen aus der realen Welt anzureichern – insbesondere bei der Szenarienerfassung. Dazu lassen sich unter anderem rund um die Uhr Beobachtungen basierend auf Datenquellen vorhandener Infrastruktur realisieren. Systembedingt sind hier die perspektivische Verzerrung und Objektüberdeckung zu berücksichtigen. Aus der Fahrzeug-Egoposition ist die Wahrnehmung per Sensorik in Hinsicht auf Qualität und Sichtbarkeit limitiert. Eine mit Drohnen aufgezeichnete Top-View-Perspektive erlaubt die Beobachtung der tatsächlichen Situation mit allen Verkehrsteilnehmern einschließlich deren Bewegungen. Nur die Drohnenflughöhe und die Kameraauflösung limitieren den Beobachtungsraum der Verkehrsteilnehmer.

Mit dem Open Automatum Dataset liegt ein kommerziell nutzbarer, freier Datensatz deutscher Autobahnabschnitte mit unterschiedlichen Kurvenradien vor, der eine 30 Stunden umfassende Aufnahme des Freiflussverkehrs auf einer Streckenlänge von ca. 250 m samt Python Utility bereithält. Die Aufnahme enthält zudem Trajektorien der Objekte, Relativbeziehungen der Referenzobjekte auf ein beliebiges Egofahrzeug und die Beschreibung der statischen Welt. Dieser Datensatz zeigt, dass aus Drohnenaufzeichnungen Ground-Truth-Informationen der Szenarien entstehen, indem über lange Zeiträume hinweg mit Algorithmen komplexe Situationen mitsamt den Koordinaten aller Verkehrsteilnehmer bestimmt werden. Die Vogelperspektive ermöglicht dabei die Bestimmung der Fahrbahnbegrenzung und der absoluten Objektbewegungen im Verkehrsraum. Damit sich nahezu unbegrenzt viele abgeleitete Szenarien generieren lassen, hat Automatum Data eine skalierbare Datenverarbeitungs-Pipeline entwickelt. Diese erlaubt es, Optimierungen der einzelnen Verarbeitungsschritte auf sämtliche assoziierten Daten anzuwenden oder umfangreiche Neudatenverarbeitungen durchzuführen.

Aus Sicht des Anwenders ergibt sich damit beispielhaft die Möglichkeit, Fragen zum Verkehrsverhalten datengetrieben und damit belastbar zu beantworten sowie konkrete aufgezeichnete Szenarien zur Verifikation der Software oder der Funktion zu identifizieren. Exemplarisch könnten etwa alle Szenarien ausgegeben werden, bei denen die laterale Relativgeschwindigkeit einscherender Fahrzeuge bei einer Autobahnfahrt bei hoher Verkehrsdichte im Stau weniger als 60 km/h beträgt. Grundlage für die konkreten Ergebnisse in Form von Szenarien ist das Durchsuchen der in der Datenbank verfügbaren Top-View-Datensätze. Je nach Funktion und Anforderungen kann zudem die Aufzeichnung des Verkehrs an den zu beobachtenden Fahrbahnstellen explizit beauftragt oder eigenständig mit Drohnen umgesetzt werden.

Die aufgezeichneten Verkehrsbeobachtungen werden initial im Datenspeicher deepSpace abgelegt. Sie werden je nach Prozessierungsschritt – KI-Objekterkennung, Trajektorien-Fitting, Perspektivenkorrektur, KPI-Ermittlung, automatisierte Fehlerkorrektur – in Containern auf GPU-oder CPU-Cluster-Einheiten verarbeitet. Die daraus resultierenden Ergebnisse werden in den Datenspeicher zurückgespielt. Der Anwender erhält auf dieser Grundlage konkrete und für die Fragestellung passende Szenarien mit dem extrahierten Wissen (Bild 2) der statischen und dynamischen Welt, beispielsweise im OpenDRIVE-Standard.

Verknüpfung der Daten  mit der Simulation

Das referenzierte Open Automatum Dataset erweitert die bei Nutzern gegebenenfalls auf anderen Messmethoden beruhenden Datensätze, die es ermöglichen, individuellen Anforderungen gerecht zu werden. Die Anbindung an die Open.Automatum.Utilities ist für sämtliche Einsatzmöglichkeiten identisch, damit Optimierungen der Pipeline für alle Nutzer bereitstehen.

Die Grundlage für die Simulation bildet die 2D-Beschreibung der Automatum Data Pipeline in Form von Objektbewegungen in der x-/y-Ebene, die durch eine statische Beschreibung der Welt angereichert werden. Der voll automatisierte Übertrag in die Integrations- und Testplattform CarMaker erlaubt dann eine 3D-Betrachtung. So wird die Top-View-Beobachtung für anschließende Variationen und Analysen nutzbar.

Aus den von Drohnen beobachteten Szenarien mit statischen Elementen – etwa der Straße und den dazugehörigen Markierungen – sowie dynamischen Elementen, also alle bewegten Objekte mitsamt ihren Trajektorien, resultieren Szenarien für die Simulation (Bild 3). Diese lassen sich durch andere dynamische Elemente anreichern. So ist eine nennenswerte Skalierung der möglichen Ergebnisse erzielbar.

An dieser Stelle findet die Toolbox ScenarioRRR von IPG Automotive Anwendung und etabliert folgenden Ablauf:

<ul><li>Recording – Aufnahme einer validen Umgebung aus der Vogelperspektive,</li><li>Replay – Wiedergabe der Simulation in CarMaker und</li><li>Rearrange – Variation der Szenarien und Ableitung weiterer Szenen.</li></ul>

In der hier vorgestellten Anwendung stützt sich die Toolbox auf die von Automatum aufgenommenen Daten. Der Einsatz von standardisierten Formaten vereinfacht dabei den Datenaustausch. Die statischen Informationen zu Straße, Straßenmarkierungen und Verkehrszeichen können in der Simulation über das OpenDRIVE- oder ROAD5-Format direkt als Repräsentation der statischen Welt genutzt werden. Mit dem JSON-Format lässt sich das Verhalten der nun simulierten Objekte über die Zeit beschreiben.

Im ersten Schritt werden alle Objekte mitsamt ihren Trajektorien aus dem Datensatz im Open-Loop-Verfahren in der Simulation abgebildet. Wahlweise kann anschließend jedes Objekt dabei auch aus der Ego-Perspektive betrachtet werden. Die Objekte fahren dann im Closed-Loop-Verfahren die ursprünglichen Geschwindigkeitsprofile nach. Dabei wird ein fahrdynamisch plausibles Verhalten augmentiert und zusätzliche Funktionen wie die Fahrzeugeigenbewegung mit allen korrespondierenden Sensorinformationen bereitgestellt. Die physikalischen Modelle der Umwelt runden die Simulation bei der Datenanreicherung von der 2D-Perspektive in eine vollständige 3D-Welt ab. Die Betrachtung der so erzeugten Szenarien mit verschiedenen virtuellen Sensorinstanzen, wie Lidar, Radar oder Kamera, generiert zusätzlich für die real beobachtete Situation eine virtuelle, aber belastbare Wirklichkeit.

Entsprechend basiert der digitale Zwilling auf realen Situationen. Über Variationen des direkten oder assoziierten Replays lassen sich verschiedene Fragestellungen an die umgesetzte Fahrfunktion, dem System-under-Test (SUT) und seiner gesamten Wirkkette, beantworten. Eine mögliche Fragestellung könnte sein, ob sich die Time-to-Collision unter einem definierten Schwellenwert befindet oder gleichzeitig sehr hohe Beschleunigungen bei einem anderen Verkehrsteilnehmer auslöst. Die resultierenden Werte können auf spezifische Corner Cases für bestimmte Fahrfunktionen hinweisen.

Der dargestellte Ansatz ermöglicht es, durch eine Kombination verschiedener Verfahren kritische Situationen gezielt herbeizuführen. Das ermöglicht die Erzeugung relevanter, jedoch in der Realität selten auftretender Szenarien auf Basis einer realen Datengrundlage. Diese Vorgehensweise ermöglicht eine effiziente Absicherung automatisierter Fahrfunktionen. (eck)

<a href="http://www.ipg-automotive.com">www.ipg-automotive.com</a>

Dr. Raphael Pfeffer ist Manager Innovation bei IPG Automotive. Dr. Paul Spannaus arbeitet bei Automatum Data in Kronach.

Bild 1: Abbildung der realen Welt durch den Digitalen Zwilling

Bild 2: Workflow zur Wissensextraktion aus Drohnendaten  

Bild 3: Automatisierte Verwendung von realen Daten in der Simulation

Dr. Raphael Pfeffer ist Manager  Innovation bei IPG Automotive. 

Dr. Paul Spannaus arbeitet  bei Automatum Data in Kronach. 

IPG Automotive

Intelligente Batteriesensorik für optimale Bordnetzfunktionen

Für optimale Bordnetzfunktionen ist eine intelligente Batteriesensorik notwendig. Der Beitrag erläutert am Beispiel des PSoC4 HV PA von Infineon, welche Anforderungen diese Sensorik erfüllen muss.

Für optimale Bordnetzfunktionen ist eine intelligente Batteriesensorik notwendig. Der nachfolgende Beitrag erläutert am Beispiel des neu entwickelten PSoC4 HV PA von Infineon, welche Anforderungen diese Sensorik erfüllen muss.

Durch die Entwicklung von Fahrerassistenzsystemen und dem Trend des automatisierten Fahrens sind Teilbordnetze für die sichere Versorgung kritischer Verbraucher entstanden. Dazu gehört ein Energiemanagement mit elektronischen Sensoren, Schaltern und Sicherungen. Eine kritische Aufgabe hierbei ist die Überwachung der Batterie: Denn nur der Betrieb in der „Komfortzone“ zwischen Über- und Tiefentladung und ohne Überlastung garantiert eine möglichst lange Lebensdauer und sichere Versorgung der angeschlossenen Verbraucher. Diese Überwachungsaufgabe übernimmt eine Strom-/Spannungssensorik an der Batterie, der intelligente Batteriesensor. Hier kommt der neu entwickelte PSoC4 HV PA von Infineon zum Einsatz. Die Programmable Systems on Chip (PSoC) des Herstellers sind nicht nur per Software programmierbar. Zusätzlich können ihre konfigurierbaren Hardware-Peripherals auch flexibel miteinander verschaltet werden. Die neuen PSoC4 HV PA (High-Voltage Precision Analog) integrieren zusätzlich Spannungsregler, LIN-Transceiver und ein Analog Front End (AFE). Das erste Derivat adressiert die Applikation intelligenter Batteriesensor.

Die Stärken der PSoC erwachsen unter anderem aus ihren Peripherals. Über mehrere Bauteilgenerationen hinweg gesammelte Erfahrung fließt in die analogen Funktionsblöcke, speziell in die für das Sensieren kleiner Kapazitäten und deren Änderung (Capacitive Sensing). Durch Capacitive Sensing eignen sich die Komponenten insbesondere für Berührsteuerungen im Fahrzeug.

Zu den Analog-Blöcken gehören beispielsweise Operationsverstärker, Komparatoren, Sigma-Delta-ADC (Analog/Digital-Converter nach dem Sigma/Delta-Verfahren), IDAC (programmierbare Stromquelle) und SARADC (Analog/Digital-Converter nach dem Verfahren der sukzessiven Approximation). Die Bauteile eignen sich aber auch für viele andere Applikationen, bei denen Signale analoger Sensoren verarbeitet werden.

Integrierte Application Specific Standard Products (ASSP) für den Direktanschluss an das Bordnetz mit 12 V sind bereits im Infineon-Portfolio verfügbar. Dabei handelt es sich um die integrierten Motor-Control-Bausteine, wie TLE984x/5x/6x/7x. Inzwischen sind sie als Motix MCU gelistet und eignen sich für die Ansteuerung von Relais, DC- und BLDC-Motoren. Sie beinhalten einen Mikrocontroller mit Kern von ARM, LDO-Spannungsregler, LIN-Transceiver, Current Sense Amplifier und die Gate-Treiber für die MOSFET der Leistungsstufe. Damit zielen sie auf Power-Applikationen mit magnetischer Aktorik.

Aus der Cypress-Schiene von Infineon kommen nun die PSoC4 HV und komplementieren Infineons bestehendes Portfolio an Motix MCU, denn sie zielen mit ihrem Analog-Front End insbesondere auf Sensor-Applikationen im Fahrzeug. Auch sie enthalten einen Mikrocontroller mit Kern von ARM. Die Zielapplikation der PSoC4 HV PA ist der intelligente Batteriesensor 12 V, wobei der Baustein die Messgrößen Temperatur, Batteriespannung und Batteriestrom misst und überwacht (Bild 1). Durch vom Anwender programmierte Rechenalgorithmen kann der integrierte Rechenkern vom Typ ARM Cortex M0+ daraus zum Beispiel den Ladezustand (State of Charge, SOC), den Allgemeinzustand (State of Health, SOH) oder die geflossene Energie ermitteln.