Lesen Sie unter anderem in dieser Ausgabe:

<ul><li>Safety & Security: Tielstory „Fahrerlose Angriffsziele“</li><li>Messen-Testen-Diagnose: ADAS/AD-Funktionen sicher validieren</li><li> Fahrerassistenz und automatisiertes Fahren: Zentralisierte Sensorfusion</li><li>Technik und Lieferbeziehungen im Wandel</li></ul>

Ab SAE Level 4 entsteht für autonome Fahrzeuge eine neue Risikolage mit höheren Anforderungen an deren Absicherung vor Cyberattacken, unerlaubten Zugriff und Manipulation. Als „Schutzmacht und Ausfallbürgschaft“ wird Cybersecurity zur fundamentalen Voraussetzung für das autonome Fahren.

Ab SAE Level 4 entsteht für autonome Fahrzeuge eine neue Risikolage mit höheren Anforderungen an deren Absicherung vor Cyberattacken, unerlaubten Zugriff und Manipulation.

Michael Friedrich und Wolfram Gottschlich

Weltweit zeugen Pilotprojekte davon, dass verlässlich funktionssichere autonome Fahrsysteme an der Schwelle zur technologischen Umsetzung stehen. Das Versprechen: Erhöhte Verkehrssicherheit durch Vermeidung menschlicher Fehler und zugleich eine ganz neue Qualität vernetzter Mobilität. Beim vollautomatisierten Fahren ab SAE Level 4 übernehmen verteilte Systeme in der E/E-Architektur – und potenziell auch außerhalb der Fahrzeuge – die Steuerung des Fahrzeugs ohne einen Fahrer in der Kette. Funktionale Sicherheit und Robustheit der Fahrfunktion basieren allein auf Sensorik und deren Verarbeitung in den Fahrzeugsystemen.

Große Angriffsfläche, hohes Schadenspotenzial

Automotive Cybersecurity, der Schutz der Fahrzeuge vor unerlaubtem Zugriff oder Manipulation und die Absicherung der Verfügbarkeit wichtiger Fahrzeugsysteme erlangt vor diesem Hintergrund fundamentale Bedeutung. Autonome Fahrzeuge werden für Angreifer zu einem attraktiven Ziel – aus zweierlei Gründen: Sie bieten eine große, vielgestaltige Angriffsfläche, und sie bergen hohes Schadenspotenzial.

Tatsächlich nimmt die Zahl potenzieller Angriffsvektoren beim vollautomatisierten Fahrzeug ab SAE Level 4 deutlich zu. Denn die Verwirklichung autonomer Fahrfunktionen geht in aller Regel mit permanenter, hochgradiger Vernetzung einher – zum Beispiel durch den Abruf von Kartenmaterial, vernetzte Cloud-Services oder V2X-Kommunikation mit anderen Fahrzeugen und Verkehrsinfrastruktur. Darüber hinaus eröffnet die notwendige umfassende Sensorik neuartige Angriffsmöglichkeiten.

Gleichzeitig steigt beim autonomen Fahren das mögliche Ausmaß des durch einen Cyberangriff verursachten Schadens erheblich. Dass sich einzelne Fahrzeugsysteme und -funktionen über Sicherheitslücken aus der Ferne übernehmen lassen, haben Miller/Valasek bereits 2015 demonstriert [1].Fahrer- assistenzsysteme geben bei Funktionsstörung die Kontrolle an den Fahrer zurück Kompromittierte oder gar gekaperte Fahrzeugsysteme in einem autonomen Fahrzeug hingegen verfügen nicht mehr über die Rückfallebene in Gestalt des korrigierend eingreifenden Fahrers.

Daran zeigt sich: Beim autonomen Fahrzeug bilden die Cybersicherheit (Security) und die funktionale Sicherheit (Safety) der Fahrfunktionen geradezu eine „Schicksalsgemeinschaft“, die es intelligent zu managen gilt. So müssen die Safety-relevanten Systeme nicht nur robust gegen Cyberattacken sein, sondern auch Rückfallebenen im Falle einer Teilkompromittierung bieten. Selbst im Fall eines erfolgreichen Angriffs, sollte die Grundfunktionalität der autonomen Systeme aufrechterhalten bleiben, um die funktionale Sicherheit des Fahrzeugs nicht zu gefährden (Bild 1).

Die Konvergenz von Security und Safety wird zu einem entscheidenden Faktor: So spielen etwa Cloud-Systeme bei der praktischen Umsetzung autonomer Fahrfunktionen häufig eine wichtige Rolle: Sie ermöglichen u.a., das Fahrzeug an einen bestimmten Ort zu rufen oder starten Parkvorgänge. Zugleich sind sie ein mögliches Einfallstor, über das Angreifer Fahrzeuge kapern und zum Beispiel Verkehrschaos stiften könnten. Sind ebendiese Cloud-Services indes Security-seitig gegen unauthorisierten Zugriff abgesichert, können sie über den Fernsteuerungsmechanismus zum wichtigen Bestandteil des Betriebskonzepts der Flotte werden: Sie erlauben einem Operator im Backend, das Fahrzeug aus einer kritischen Situation heraus zu führen – und werden so von einer potenziellen Bedrohung zum möglichen „Rettungsanker“.

Neuartige Herausforderungen für die Cybersicherheit

Dass das Fahrzeug die Fahraufgabe über eine gewisse Zeit, in gewissen Situationen oder vollständig selbst übernimmt, setzt zwingend voraus, dass die autonomen Systeme jederzeit verfügbar und funktionsfähig sind. Im Gegensatz zu Fahrerassistenzsystemen müssen autonome Systeme auch die letzte Rückfallstufe zur sicheren Ausführung der Fahrfunktion darstellen. Ihre Absicherung gegen unerlaubten Zugriff und Manipulation muss das mit einbeziehen – Cybersecurity stellt nicht nur die „Schutzmacht“ der autonomen Systeme dar, sondern auch deren „Ausfallbürgschaft“. Das bringt eine Reihe neuer Herausforderungen mit sich (Bild 2):

<ul><li>Heterogene Rückfallebenen</li><li>Hohe Datenraten</li><li>Adversial Attacks</li><li>Regulatorische Rahmenwerke</li></ul>

Zur Resilienz von autonomen Fahrzeugen gehören einerseits der Schutz von Daten innerhalb des Systems, andererseits die verlässliche Umgebungserkennung mittels der Sensorik als unmittelbare Basis für die Fahrentscheidungen. Daten innerhalb des autonomen Systems lassen sich durch klassische IT-Security-Mechanismen wie Verschlüsselung, Integritätsschutz und Authentifikation schützen. Diese klassischen Mechanismen helfen jedoch nicht gegen Angriffe auf die Algorithmen, die mit maschinellem Lernen die sensorische Umfelderfassung umsetzen. Sowohl die Steuerung der Fahrfunktionen als auch die Umgebungserkennung sollten mithilfe von Redundanzen heterogene Rückfallebenen schaffen. So ist etwa bei einer Teilkompromittierung Safety-relevanter Fahrsysteme sicherzustellen, dass zumindest deren Grundfunktionalität verfügbar und erhalten bleibt. Ebenso muss die Umgebungserkennung, beispielsweise in der Sensorfusion, feststellen können, wenn ein Teil der Sensordaten nicht plausibel ist: Das Fahrzeug kann dann idealerweise weiterhin sicher fahren, solange eine sensorische Umfelderfassung in ausreichendem Maße erfolgt.

Das Defense-in-Depth-Prinzip, die vielschichtige Absicherung mit spezifischen Schutzmechanismen auf relevanten Systemebenen ist hier also wichtiger denn je, muss aber über die Ebenen hinweg die besonderen Implikationen und Notwendigkeiten autonomen Fahrens mit einbeziehen (Bild 3).

Autonome Fahrzeuge werden in Zukunft hohe Datenraten im Gigabit-Bereich in Echtzeit verarbeiten, um Fahrsituationen meistern zu können. Allein bei der Umgebungserkennung durch Kamera, Lidar, Radar oder Ultraschall entstehen Datenmengen, die heutige Automotive-Hardware an ihre Grenzen bringt. Die Frage ist, wie sich ein permanenter Datenaustausch solchen Umfangs Security-seitig effizient begleiten lässt. Selbst mit Maßnahmen zur Steigerung der Leistungsfähigkeit von kryptographischen Operationen, wie der Hardware-Beschleunigung von kryptographischen Algorithmen, lassen sich solche Datenmengen nicht trivialerweise schnell genug verarbeiten. Vielmehr kann durch eine Überarbeitung von Automotive-Hardware-Bausteinen der Overhead, etwa bei der Benutzung der Hardware-Beschleuniger im Hardware-Security-Modul, reduziert werden [2]. Neben der Hardware als solcher, lassen sich Schutzmaßnahmen optimieren, insbesondere durch die Zusammenlegung von Safety und Security zum Beispiel mit kryptographischen Message Authentication Codes (MACs), die auch aus Safety-Sicht qualifiziert sind, Datenintegrität zu liefern [3].

Mit seiner multimodalen Sensorik zur Umgebungserkennung und der Verarbeitung der Sensordaten via künstlicher Intelligenz ermöglicht das autonome Fahrzeug Angriffsparadigmen, die die sensorische Umfelderfassung durch Adversial Attacks gezielt irreführen. Dabei täuschen Angreifer die Wahrnehmung des Fahrzeugs beispielsweise mittels physischer Markierungen oder Aufkleber am Straßenrand. Mögliche Folge: Das autonome Fahrzeug erkennt Objekte, wo keine sind, missinterpretiert Verkehrsschilder oder wird in seiner Bewegungsschätzung beeinträchtigt. Das Fahrzeug kann nicht mehr verlässlich navigieren, und zugleich kann kein Fahrer mehr korrigierend eingreifen. Im Hinblick auf die funktionale Sicherheit wird das Thema im Rahmen der ISO/PAS 21448 „Safety of the intended functionaltity“ (SOTIF) behandelt [4]. Für die nötige Robustheit und Verfügbarkeit von autonomen Fahrzeugen müssen künftig mögliche Adversial Attacks auch seitens der Cybersecurity berücksichtigt werden. Dabei sind Schutzmaßnahmen auf unterschiedlichen Ebenen denkbar: im Sensor selbst, bei der direkten Verarbeitung der Sensordaten oder bei deren Fusion.

Über die letzten Jahre sind regulatorische Rahmenwerke entstanden, die eine risikobasierte, qualitative Bewertung der Angriffsflächen von Fahrzeugen vorsehen, um daraus geeignete Maßnahmen abzuleiten. Mit dem verpflichtenden Nachweis eines Cybersecurity-Management-Systems (CSMS) gemäß UN-R155 auf Organisationsebene und den technischen Leitlinien auf Fahrzeugebene durch die ISO/SAE 21434 ist Security zum integralen Bestandteil der Typgenehmigung geworden [5,6]. Wenngleich diese Regularien sicherstellen, dass Security auf Prozessebene berücksichtigt wird, bieten sie keine spezifischen technischen Lösungen für die Absicherung autonomer Fahrzeuge an. Einen weiteren Ansatzpunkt bildet hier die UN-R157, die die automatische Spurhaltung betrachtet; sie referenziert jedoch im Wesentlichen die UN-R155 bzw. die UN-R156 zum Software-Update-Management. Beachtenswerterweise ist in Deutschland seit Mitte 2021 ein Gesetz zum autonomen Fahren in Kraft. Dieses Gesetz betrachtet Security allerdings nur auf einem sehr hohen Abstraktionsgrad; dazu versteht es sich ausdrücklich als Übergangslösung auf dem Weg hin zu international harmonisierten Vorschriften [7].

Erste grundlegende Schritte hin zu regulatorischen Rahmenwerken fürs autonome Fahren sind also vollzogen. International gültige Regelwerke, die darauf aufbauend einen hinreichenden Schutz vollautomatisierter Fahrzeuge ab SAE Level 4 verbindlich definieren, allerdings stehen noch aus. Es ist jedoch damit zu rechnen, dass Regulierungsbehörden und Standardisierungsorganisationen hier den regulatorischen Rahmen in Inhalt und Umfang weiterentwickeln werden.

Autonomes Fahren: Neue Dimension für Cybersecurity

Zur Verwirklichung des autonomen Fahrens mithilfe verteilter Systeme in und außerhalb des Fahrzeugs ist die Orchestrierung von Cybersecurity-Maßnahmen Voraussetzung. Von der ECU über fahrzeuginterne Kommunikation und E/E-Architektur bis hin zu V2X-Kommunikation und vernetzten Diensten liefern sie proaktiven Cyberschutz und sorgen im Angriffsfall für die nötige Resilienz. Etablierte Automotive-Cybersecurity-Mechanismen stellen das Fundament, um den neuartigen Angriffsvektoren und höchsten Safety-Anforderungen zu begegnen. Dabei müssen Security-Maßnahmen im Sinne eines kontinuierlichen Risikomanagements implementiert und über den gesamten Fahrzeuglebenszyklus hinweg alimentiert werden. (eck)

Michael Friedrich ist Team Lead Professional Security Services mit Fokus Software-defined Vehicle bei Escrypt, einer Marke von ETAS. Wolfram Gottschlich ist Team Lead Professional Security Services mit Fokus Automotive bei Escrypt, einer Marke von ETAS.

[1] Andy Greenberg: Hackers Remotely Kill a Jeep on the Highway – With Me in It. Unter: <a href="https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/" target="_blank">https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/</a>

[2] Suraj Ramachandrappa, Raimund Stampa: Hardwarebasierte Cybersicherheit für die nächste Fahrzeuggeneration. ATZelektronik 3–4/2022.

[3] Dirk Bierbaum, Raimund Stampa: Smarte Synthese aus Cybersecurity und Funktionssicherheit, ATZ Elektronik 6/2021

[4] ISO International Organization for Standardization: ISO 21448:2022 Road vehicles – Safety of the intended functionality. Unter: <a href="https://www.iso.org/standard/77490.html" target="_blank">https://www.iso.org/standard/77490.html</a>

[5] UNECE World Forum for Harmonization of Vehicle Regulations: UN Regulation No. 155 – Uniform provisions concerning the approval of vehicles with regards to cyber security and cyber security management system. Unter: <a href="https://unece.org/sites/default/files/2021" target="_blank">https://unece.org/sites/default/files/2021</a>–03/<a href="http://R155e.pdf" target="_blank">R155e.pdf</a>

[6] ISO International Organization for Standardization: ISO/SAE 21434:2021 Road vehicles – Cybersecurity engineering. Unter: <a href="https://www.iso.org/standard/70918.html" target="_blank">https://www.iso.org/standard/70918.html</a>

[7] BMDV: Gesetz zum autonomen Fahren: <a href="https://www.bmvi.de/SharedDocs/DE/Artikel/DG/gesetz-zum-autonomen-fahren.html" target="_blank">https://www.bmvi.de/SharedDocs/DE/Artikel/DG/gesetz-zum-autonomen-fahren.html</a>

Bild 1: Security-Maßnahmen müssen im autonomen Fahrzeug Rückfallebenen schaffen, über die die Grundfunktionalität (teil-)kompromittierter Safety-relevanter Systeme aufrechterhalten bleiben. 

  Bild 3: Defense in Depth, die vielschichtige Absicherung mit spezifischen Schutzmechanismen auf allen  relevanten Systemebenen, muss die besonderen Implikationen autonomen Fahrens mit einbeziehen.

Bild 2: Automotive Cybersecurity muss für das autonome Fahren ab SAE Level 4 Antworten auf spezifische neuartige Herausforderungen finden. 

16:9

Michael Friedrich ist Team Lead Professional Security Services mit Fokus Software-defined Vehicle bei Escrypt, einer Marke von ETAS.

Wolfram Gottschlich ist Team Lead Professional Security Services mit Fokus Automotive bei Escrypt,  einer Marke von ETAS.

ETAS

Safety / Security

Elektronik

Kfz-Elektronik

Fahrerassistenzsysteme / Automatisiertes Fahren

Verschiedene elektronische Domänen auf einer Plattform zusammenführen

Die zentrale Herausforderung moderner Automobilanwendungen besteht darin, die erforderliche Hard- und Software so zu konsolidieren, dass die Rückwirkungsfreiheit kritischer Funktionen gewährleistet ist und gleichzeitig eine hohe Echtzeitleistung, niedrige Kosten und Design-Flexibilität für zukünftige Anpassungen geboten werden.

Virtualisierungstechnologie ist allgemein bekannt und für High-End-Cores wie den Arm Cortex v8-A verfügbar. Die Unterstützung mehrerer Betriebssysteme, die auf derselben Hardware laufen, bringt Herausforderungen mit sich, wie den Schutz von Ressourcen vor Missbrauch und die Gewährleistung einer entsprechenden Bandbreite für alle. Diese Probleme werden bereits mit Prozessortechniken gelöst, die Hardware-Virtualisierung unterstützen. Kürzlich wurden Hardware-Virtualisierungsfunktionen auch in kleine Mikrocontroller-Kerne wie den Arm Cortex v8-R integriert. Die Isolierung und gemeinsame Nutzung von Ressourcen durch mehrere Betriebssysteme, die auf einem physischen System laufen, sind ebenfalls Bedingungen für einfache und kostengünstige Embedded-Systeme.

Die Wahl der spezifischen Virtualisierungstechniken hängt streng vom Prozessortyp, dem Hersteller und der Prozessor-Hardware ab. Eine flexible Hypervisor-Architektur ist erforderlich, um die in heutigen Mikrocontrollern, wie dem NXP S32Z, S32E und ST Stellar SR6, verfügbaren Hardware-Virtualisierungsfunktionen optimal zu nutzen.

Der folgende Abschnitt behandelt die gängigsten Virtualisierungsfunktionen auf Hardware-Ebene für Arm-Architekturen.

Die Arm v8-Architekturen assoziieren Exception Levels (EL) mit Software-Ausführungsprivilegien und definieren einen Satz von vier Exception Levels – EL0 bis EL3 – wobei EL0 die niedrigste und EL3 die höchste privilegierte Ausführungsebene ist.

Die Armv8-R-Architektur führt Funktionen ein, die es Entwicklern ermöglichen, Hochleistungsanwendungen für sicherheitskritische Umgebungen zu entwerfen und zu implementieren. Dazu gehören:

<ul><li>keine überlappenden Speicherbereiche,</li><li>neues Exceptionmodell, das mit dem Modell Armv8-A kompatibel ist,</li><li>Virtualisierung mit Unterstützung für Gastbetriebssysteme.</li><li>Optional: Unterstützung für Double-Precision Floating-Point und Advanced SIMD.</li></ul>

Außerdem können mehrere Protected-Memory-System-Architecture-Kontexte (PMSA) auf demselben Kern ausgeführt werden, indem sie mit Hilfe von Virtualisierungstechnologie eingegrenzt werden. Moderne Mikrocontroller ermöglichen es, die Echtzeitleistung verschiedener Kontexte einzuschließen, wodurch verhindert wird, dass ein Kontext die Reaktionszeit und den Determinismus eines kritischeren Kontexts beeinträchtigt. Einige verfügen auch über redundante Kopien der Logik- und Komparatorinstanzen für den Dual-Core Lock-Step-Betrieb (DCLS).

Eine MMU ist eine „Speicherverwaltungseinheit“, während eine MPU eine „Speicherschutzeinheit“ ist. Beide sind spezialisierte Hardware, die von der CPU für die Speicherverwaltung verwendet wird. Die MMU wird für viele Funktionen verwendet, darunter in erster Linie für den virtuellen Speicher, also die Übersetzung der virtuellen Adresse in die physische Adresse und den Speicherschutz. Die MPU hingegen wird ausschließlich für den Speicherschutz verwendet. In diesem Sinne kann man sich die MMU als Obermenge einer MPU vorstellen. Je nach Komplexität des Prozessors oder SoCs können MMUs/MPUs an verschiedenen Stellen innerhalb der Architektur platziert werden, beispielsweise in Multi-Core-SoCs lokal für jeden Kern oder auf einer gemeinsamen Ebene.

Ähnlich wie eine MMU steuert eine E/A-Speicherverwaltungseinheit (IOMMU) den Zugriff von E/A-Geräten auf den Hauptspeicher, auch als direkter Speicherzugriff (DMA) bezeichnet, und bietet Adressübersetzungsmechanismen und eine programmatische Schnittstelle zur Festlegung der Adressbereiche, auf die das Gerät zugreifen kann. In modernen Mikrocontrollern mit Virtualisierungsunterstützung wurde eine IOMPU oder Peripherie-MPU hinzugefügt, um den Zugriff auf E/A-Geräte vor den Gastbetriebssystemen zu schützen. Sie ähnelt der IOMMU, wurde aber speziell für die Mikrocontroller-Architektur entwickelt.

Bei der Verwendung von Anwendungsprozessoren wie Arm v8-A bietet die Virtualisierung in Kombination mit einem Separations-Kernel erweiterte Funktionen für Software-Entwickler, die sicherstellen müssen, dass die heterogenen Software-Komponenten frei von Interferenzen sind, der Informationsfluss geschützt ist und das Kommunikationssystem im Hinblick auf Sicherheitsaspekte verstärkt wird.

Ein Separationskernel besteht aus Partitionen oder virtuellen Adressräumen (VAS), die vom Kernel erstellt und über die MMU des Systems implementiert wurden. Innerhalb einer Partition ist die Software-Trennung nicht garantiert: Wenn der Code fehlerhaft ist oder kompromittiert wird, kann er weder etwas außerhalb der Partition beeinflussen noch den Betrieb oder das Verhalten anderer Partitionen oder des Separations-Kernel selbst ändern.

Virtuelle Adressräume sind physisch nicht vorhanden. Stattdessen werden ihre Adressen auf Adressen im Kernel Space abgebildet. Wenn sie ausgeführt werden, werden alle ihre Speicherzugriffe, ob Codeabrufe oder Datenzugriffe, von der MMU in physische Zugriffe übersetzt. In Bild 1 befindet sich der Virtual Machine Monitor (VMM) nicht im privilegierten Modus, sondern wird als Anwendung auf dem Separations-Kernel ausgeführt, von wo aus er das nicht vertrauenswürdige Gastbetriebssystem innerhalb der Partition verwaltet. Der VMM sorgt für den Schutz der Speicherressourcen und die sichere Zugriffskontrolle für E/A und andere Systemobjekte. Zudem verteilt er die Arbeitslasten sicher und effizient auf die Kerne.

Der Gast-Kernel läuft im EL1-Modus und kümmert sich um die Hardware-Initialisierung, seine Gerätetreiber, die Planung von Gastprozessen, Interrupts und die Speicherverwaltung. Aus diesem Grund benötigt der Gast-Kernel Zugriffe im privilegierten Modus, die durch den VMM gemildert werden.

Aufgrund der begrenzten Ressourcen von Mikrocontrollern ist eine leichtgewichtige Virtualisierung erforderlich. Bei dem implementierten Hypervisor handelt es sich in der Regel um einen Typ 1, der grundlegende Operationen wie die Konfiguration des Systems zur Aktivierung der Virtualisierung, das Einschalten und Zurücksetzen der Kerne, die Konfiguration der Taktgeber, die Einrichtung der MPU und das Zurücksetzen des Gastkontexts durchführt. Nach dieser Initialisierung überträgt der Hypervisor die Ausführung in den Gastmodus innerhalb des Gastbetriebssystems. Der Hypervisor befindet sich im Leerlauf und wartet auf Unterbrechungen oder Service- Anfragen von den Gästen.

Wie der Anwendungsprozessor-Hypervisor muss auch der Mikrocontroller-Hypervisor über eine robuste, durch Hardware erzwungene Software-Trennung, Unterstützung mehrerer Betriebssysteme und Echtzeit-Effizienz verfügen, um kritische Arbeitslasten sicher zu konsolidieren. Die meisten Anwendungen benötigen eine effiziente Architektur, die die Störungsfreiheit mehrerer Betriebssysteme, die auf derselben CPU laufen, gewährleistet und flexible Optionen zur vollständigen Nutzung mehrerer Kerne und begrenzter Prozessorressourcen bietet. Bild 2 zeigt ein Blockdiagramm eines Typ-1-Hypervisors mit mehreren verschiedenen Gastbetriebssystemen, die auf einem Mikrocontroller laufen. Diese Art der Virtualisierung lässt sich je nach den Anforderungen der Anwendung auch für High-End-SoCs mit Arm v8-A-Kernen nutzen.

In einem virtualisierten System ist es sehr wichtig zu definieren, welche Gäste Zugriff auf ein bestimmtes Peripheriegerät haben und ob ein Peripheriegerät nur einem Gast zugewiesen oder gemeinsam genutzt werden soll. Der nachfolgende Abschnitt beschreibt verschiedene Techniken beschrieben, die von der I/O-Virtualisierungsunterstützung moderner Prozessoren abhängen.

Der Gast hat vollen Zugriff auf E/A, einschließlich DMA. Das ermöglicht eine maximale Wiederverwendung vorhandener Gastbetriebssystemtreiber ohne Leistungseinbußen. Peripheriegeräte, die auf Speicher zugreifen können, wie DMA, die nicht durch die MPU und MMU eingeschränkt sind, könnten jedoch für den Zugriff auf geschützte Speicherbereiche verwendet werden, wenn diese offenliegen. Eine Kernel-Schwachstelle kann E/A nutzen, um die Hypervisor-Isolierung vollständig zu umgehen und sogar den Hypervisor selbst zu untergraben. Dieses Problem lässt sich mit einer IOMMU und IOMPU – auch bekannt als Peripherie MPU – lösen.

Das Gerät wird emuliert und alle E/A-Zugriffe werden vom Hypervisor verwaltet. Das emulierte Gerät kann sich von dem physischen Gerät unterscheiden. Bei dieser Methode werden emulierte Geräte über vertrauenswürdige Hypervisor-Treiber gemultiplext. Obwohl diese Methode eine sichere gemeinsame Nutzung von Geräten durch Gäste ermöglicht, ist der Leistungsverlust in der Regel sehr hoch, insbesondere bei Low-End-Prozessoren mit begrenzten Ressourcen.

Die Paravirtualisierung bietet speziell definierte „Hooks“, die es dem Gast oder den Gästen ermöglichen, Aufgaben anzufordern und zu bestätigen, die andernfalls in der virtuellen Domäne ausgeführt würden – wo die Ausführungsgeschwindigkeit geringer ist. Eine erfolgreiche paravirtualisierte Plattform kann es ermöglichen, den VMM zu vereinfachen, indem die Ausführung kritischer Aufgaben von der virtuellen Domäne in die Host-Domäne verlagert wird und/oder die allgemeine Leistungsverschlechterung der Maschinenausführung innerhalb des virtuellen Gastes zu verringern. Bei Prozessoren wie Arm v8-A und Arm v8-R ist das die gängigste Technik zur gemeinsamen Nutzung von Geräten zwischen Gästen.

Während viele Entwickler mit der Virtualisierung auf High-End-Cores wie dem Arm Cortex v8-A vertraut sind, ermöglichen Hochleistungs-Multicore-Mikrocontroller wie NXP S32Z, S32E und ST Stellar SR6, die mit dedizierten Virtualisierungs-Hardware-Funktionen ausgestattet sind, eine neue Klasse der Mikrocontroller-Konsolidierung. Um die Wiederverwendung von Software zu fördern und aufgrund der Vielfalt moderner SoCs muss eine Virtualisierungsplattform flexibel und konfigurierbar sein, um den spezifischen Anwendungsanforderungen gerecht zu werden. Man sollte daran denken, dass je nach Anwendung und verwendetem Prozessor verschiedene Virtualisierungstechniken sorgfältig evaluiert und implementiert werden müssen, um die erforderliche Effizienz und Leistung sowie eine sichere Virtualisierung für die Anwendung zu gewährleisten. (eck)

Carmelo Loiacono ist Field Applications Engineer bei Green Hills Software.

Bild 1: Der Separation Microkernel Hosted Hypervisor stellt sicher, dass sich Fehler innerhalb eines Prozesses nicht auf das gesamte System ausbreiten, indem der Prozessspeicher auf einen bestimmten Speicherbereich begrenzt wird.

Bild 2: Ein Typ-1-Hypervisor, wie der µ-visor Hypervisor von Green Hills Software, mit mehreren virtualisierten Betriebssystemen, beispielsweise µ-velOSity RTOS, FreeRTOS und AUTOSAR

Carmelo Loiacono ist Field Applications Engineer  bei Green Hills Software.

Green Hills Software

Software / Betriebssysteme / KI

Die Wahrnehmung der Fahrzeugumgebung verbessern

Fahrerassistenz- und frühe AD-Systeme verlassen sich in der Regel auf drei Sensormodalitäten: Radar, Lidar und Kameras – was jedoch teurer und energieaufwändig ist. Durch künstliche Intelligenz kann die VAI-Radarsoftware von Ambarella eine höhere Auflösung und Leistungsfähigkeit als herkömmliches Fahrzeugradar erzielen.

Durch künstliche Intelligenz kann die VAI-Radarsoftware von Ambarella eine höhere Auflösung und Leistungsfähigkeit als herkömmliches Fahrzeugradar erzielen.

Sicherheit ist einer der Hauptgründe für die zunehmende Technik in Fahrzeugen, die den Fahrer zunächst dabei unterstützt, Gefahren wahrzunehmen und zu vermeiden, und diese Aufgabe schließlich vollständig übernimmt, sodass der Fahrer nur noch als Passagier fungiert. Laut einer Erhebung der National Highway Traffic Safety Administration (NHTSA) gehen über 90 Prozent der Verkehrsunfälle auf den Fahrer zurück. Es wird daher erwartet, dass die Verantwortung für die Sicherheit auf die Technik verlagert wird, um die Sicherheit für alle Verkehrsteilnehmer erheblich zu verbessern.

Um den Fahrer zu unterstützen oder Entscheidungen für ihn zu treffen, muss das Fahrerassistenzsystem (Advanced Driver Assistance System, ADAS) in der Lage sein, die Umgebung des Fahrzeugs – und so weit wie möglich im Voraus – bei allen Licht- und Wetterbedingungen zu erfassen. Aktuell kommen dafür drei wesentliche Techniken zum Einsatz: Radar, Lidar und Kameras/Bildsensoren. Derzeit wird mit Ultraschallsensoren eine vierte Technik ausschließlich zum Parken und Rangieren im Nahbereich eingesetzt.

Jede Technik hat ihre eigenen Stärken und Schwächen (Bild 1, [1]). Kameras eignen sich gut für Winkelmessungen und für das Lesen von Geschwindigkeitsbegrenzungsschildern. Lidar ist eine relativ teure Technik, wird aber von etlichen Automobilherstellern und -Zulieferern für die Messung von größeren Entfernungen und für seine hohe Auflösung geschätzt. Allerdings sind sowohl Kameras als auch Lidar unter realen Bedingungen wie schlechtem Wetter oder verschmutzten Sensoren unzureichend – Bedingungen, die die Leistungsfähigkeit eines Radars nicht beeinträchtigen.

Die Sicherheit im Straßenverkehr wird in Zukunft von den Fähigkeiten der Sensoren abhängen. Um sicherzustellen, dass Fahrzeuge, die über ADAS verfügen, die Umgebung unter allen Bedingungen genau erfassen und alle Arten von Hindernissen erkennen, wird die Sensorfusion genutzt: Sobald die Rohsignale der einzelnen Sensoren verarbeitet sind, werden sie kombiniert, um ein Gesamtbild der Fahrzeugumgebung zu erhalten.

 Eine höhere Verkehrssicherheit wird untrennbar mit verbesserter Sensorik und der anschließenden Verarbeitung der Sensordaten verbunden. Viele gehen davon aus, dass das Fahrzeug-Radar dem Luft- und Raumfahrt-Radar ähnlich ist, doch der Unterschied ist erheblich. Das derzeitige Fahrzeug-Radar ist auf einen günstigen Preis ausgelegt und bietet daher eine deutlich geringere Auflösung und ein begrenztes Sichtfeld, sodass man sich stärker auf andere Sensoren verlassen muss.

Die gängige Meinung ist, dass für ein empfindlicheres Radarsystem viel mehr Antennen erforderlich sind, während die Auflösung in Wirklichkeit tatsächlich von der Höhe der Apertur abhängt. Bisherige Radarkonstruktionen haben stets größere Öffnungen mit mehr Antennen unterstützt. Dieser konventionelle und relativ unausgereifte Ansatz treibt die Kosten, den Formfaktor und den Stromverbrauch – jede Antenne erfordert einen Leistungsverstärker – in die Höhe und erzeugt riesige Datenmengen, die lokal am Systemrand (Edge) verarbeitet werden müssen. Durch Ansätze mit künstlicher Intelligenz (KI) lässt sich nun die Radarempfindlichkeit verbessern, was die herkömmliche Herangehensweise in Frage stellt.

Traditionell verwendet Radar feste Modulationstechniken, die je nach Modulationsschema zu Kompromissen zwischen Entfernungsauflösung, Dopplerauflösung und zu verarbeitenden Daten führen. Durch die intelligente Anwendung von KI verwendet die Virtual-Aperture-Imaging-Software Oculii von Ambarella jedoch eine dynamische Wellenform, die sich an die Umgebung anpasst.

Durch die Unterstützung eines „Sparsified Array“ kann Virtual-Aperture-Imaging (VAI) eine weitaus höhere Winkelauflösung mit viel weniger Antennen erreichen als der herkömmliche Ansatz für Fahrzeugradar (Bild 2). Dadurch erübrigen sich die oben erwähnten Kompromisse, ein genaueres System steht bereit, und die Notwendigkeit einer großflächigen Antenneninstallation verringert sich. Das Ergebnis ist eine bessere Auflösung in einem kleineren Formfaktor, weniger Energieverbrauch und geringere Kosten. VAI leistet einen erheblichen Beitrag zur Sicherheit, weil die geringere Komplexität und die niedrigeren Kosten es Fahrzeugherstellern ermöglichen, Radar in größerem Umfang in den Fahrzeugen einzusetzen. Man kann sogar behaupten, dass der Einsatz von VAI die Notwendigkeit von Lidar in Fahrzeugsensorsystemen überflüssig macht – was die Kosten noch weiter senkt, weil Lidar eine sehr teure Technik ist. Außerdem reduziert die geringere Zahl an Antennen die zu verarbeitende Datenmenge erheblich. Dadurch kann die Verarbeitung zusammen mit den Kameradaten zentral erfolgen, was zahlreiche Vorteile mit sich bringt.

Während Kameradaten in der Regel zentral verarbeitet werden, ist das bei Radar derzeit nicht der Fall, weil die riesigen Datenmengen Gigabytes an Bandbreite erfordern würden. Stattdessen werden Radardaten vor Ort (Edge) verarbeitet und dann über Sensorfusion mit den Kameradaten kombiniert. Leider gehen bei diesem Ansatz mehr als 95 Prozent der wertvollen Rohdaten verloren. Durch die gesteigerte Verarbeitungsleistung zentralisierter Prozessoren und die geringere Datenmenge, die von mehreren Radarsystemen nun durch die KI-basierten dynamischen Wellenformen von Oculii übertragen werden, ist die zentralisierte Datenverarbeitung für die Radarerfassung mittlerweile rentabel geworden.

Ein Beispiel für moderne zentralisierte Prozessoren, die sich als Basis einer Sensorfusionsarchitektur einsetzen lassen, sind die KI-Domänencontroller CV3 von Ambarella. Diese skalierbare, energieeffiziente Serie von System-on-Chip-Bausteinen (SoCs) bietet eine Verarbeitungsleistung von bis zu 500 eTOPS. Basierend auf der eigenen CVflow-KI-Engine und mit bis zu 16 Arm-Cortex-A78AE-CPU-Cores ermöglicht der CV3 auch eine zentralisierte Single-Chip-Verarbeitung für die Multi-Sensor-Erfassung – einschließlich hochauflösender Bildverarbeitung, Radar, Ultraschall und Lidar als Deep-Fusion für mehrere Sensortypen. Dieser Ansatz unterstützt ADAS- und Level-2+- bis Level-4-Systeme für autonomes Fahren mit ausgezeichneter Umgebungswahrnehmung bei allen Lichtverhältnissen, Wetter- und Fahrbedingungen.

Durch die gleichzeitige Unterstützung von bis zu 12 physischen oder 20 virtuellen Kameras kann ein einziger CV3 das gesamte Sensorpaket verarbeiten, das bei typischen L2+-Einsätzen zehn Kameras, fünf Radarmodule und zahlreiche Ultraschallsensoren umfasst.

Zentral verarbeitete, CV3-basierte Perception-Stacks bieten Leistungsfähigkeit und Skalierbarkeit sowie Deep-Fusion auf niedrigem Niveau, indem sie Rohdatenströme von Kameras und Radar verarbeiten. Dadurch lassen sich Daten auf eine viel aussagekräftigere Weise fusionieren. Durch den Wegfall der Edge-Verarbeitung sinken die Kosten für Radarsensormodule erheblich, weil sie nur noch die HF-MMIC- und SerDes-ICs enthalten. Aufgrund der geringeren Kosten können mehr Radarmodule im gesamten Fahrzeug, einschließlich dem Innenraum, zum Einsatz kommen. Ein zusätzlicher Vorteil besteht darin, dass der zentrale Prozessor das Bereitstellen und Verteilen von Over-the-Air-Updates (OTA) erheblich vereinfacht.

Der zentralisierte Ansatz passt das Gleichgewicht zwischen Radar- und Kameraverarbeitung während der Fahrt an, um unabhängig von Wetter, Lichtverhältnissen oder Umgebung die beste Leistungsfähigkeit zu erzielen. So kann bei Regen mehr Gewicht auf die Daten der Radarsensoren gelegt werden, während in einer belebten städtischen Umgebung, in der mehr Struktur in der Ansicht erforderlich ist, die Kameradaten Vorrang haben.

Während Edge-verarbeitende Systeme im Fahrzeug per Definition monolithisch verbaut sind, lässt sich ein zentral gesteuertes System je nach Standort, Straßenverhältnissen und Szenarien bereitstellen. Auf der Autobahn geht es vor allem darum, Daten vor dem Fahrzeug zu sammeln; während in einer Stadt der Blick in die Richtung, in die das Fahrzeug abbiegen wird, wichtiger ist. Eine Bereitstellung auf diese Weise erfordert weniger Prozessorressourcen und einen geringeren Stromverbrauch bei gleichzeitig maximierter Umgebungswahrnehmung und Sicherheit.

Zusätzlich zu den kritischen Komponenten für Sensorik und Deep Fusion gibt es ein weiteres Element, das der Stack für autonomes Fahren (Autonomous Driving, AD) mitbringen muss: die Wegplanung.

Basierend auf der wahrgenommenen Umgebung und dem Szenario unterstützt der CV3 in ADAS-Systemen den Fahrer bei der Entscheidungsfindung (Bild 3), zum Beispiel durch Spurwarnung/-assistent und autonome Notbremsung (Autonomous Emergency Braking, AEB). Mit fortschreitender Technik hin zum autonomen Fahren wird die Entscheidungsfindung immer ausgefeilter, weil das System Hindernisse erkennt und klassifiziert sowie feststellt, ob sie beweglich oder statisch sind. Anhand dieser Informationen kann das System dann einen sicheren Weg durch das Hindernis planen – oder Ausweichmaßnahmen ergreifen, wenn es keinen sicheren Weg gibt. Die Kombination aus VAI und zentraler Verarbeitung erhöht die Sicherheit enorm – aber auch der CV3 ist für die Sicherheit des Gesamtsystems von entscheidender Bedeutung, weil dieses sich in hohem Maße auf ihn verlässt.

Der CV3-SoC (Bild 4) ist ASIL-B-fähig und bietet Lock-Step-Sicherheitsinsel, die das Sicherheitsintegrationslevel auf ASIL-D hebt, wie es für AD-Anwendungen erforderlich ist. Darüber hinaus ermöglicht ein On-Chip-Hardware-Sicherheitsmodul (HSM) die Isolierung verschiedener Domänen und die sichere Software-Bereitstellung über Sicherheitsfunktionen wie Domänenisolierung, TRNG, OTP, DRAM-Scrambling und DRAM-Virtualisierung.

Die heute und in Zukunft in Fahrzeuge eingebaute Technik soll die Verkehrssicherheit erheblich verbessern, indem das Fahrzeug allmählich dem menschlichen Fahrer als größter Risikofaktor die Kontrolle abnimmt. Bisher haben sich ADAS und frühe Systeme für autonomes Fahren auf Radar, Lidar und Kameras verlassen. Das ist jedoch ein teurer und energieaufwendiger Ansatz. Durch den Einsatz von KI kann die VAI-RadarSoftware von Ambarella eine weitaus höhere Auflösung und Leistungsfähigkeit als herkömmliches Fahrzeug-Radar erzielen – ohne dass ein ganzer Wald von Antennen eingesetzt werden muss. Das verbessert die Wahrnehmung der Fahrzeugumgebung, während die Kosten, der Platzbedarf und der Stromverbrauch verringert werden und in vielen Fällen der Einsatz von teurem LiDAR überflüssig wird. Die geringen Datenmengen des VAI-Systems ermöglichen eine zentralisierte Deep-Fusion, bei der sich Radar- und Kamera-Rohdaten für eine bessere Umgebungswahrnehmung kombinieren lassen. Darüber hinaus kann das System die Zuweisung der Sensorverarbeitung im laufenden Betrieb neu konfigurieren, um sie an die Lichtverhältnisse und Wetterbedingungen anzupassen – basierend auf den Stärken der einzelnen Sensortypen. Gleichzeitig lässt sich die Verarbeitungsleistung für jedes Szenario dynamisch an die wichtigsten Bereiche rund um das Fahrzeug zuweisen. (eck)

<a href="http://www.ambarella.com" target="_blank">www.ambarella.com</a>

Dr. Steven Hong ist Vice President und General Manager Radar Technology bei Ambarella in Santa Clara, Kalifornien. Lazaar Louis ist Director Automotive Marketing bei Ambarella, Santa Clara, Kalifornien.

[1] <a href="http://www.researchgate.net/publication/26438589_Automotive_Radar_and_Lidar_Systems_for_Next_Generation_Driver_Assistance_Functions" target="_blank">www.researchgate.net/publication/26438589_Automotive_Radar_and_Lidar_Systems_for_Next_Generation_Driver_Assistance_Functions</a>

Bild 1: Vergleich der verschiedenen ADAS-bezogenen Sensorsysteme

Bild 2: Die Oculii-Software von Ambarella erzielt eine höhere Auflösung mit weniger Antennen. 

Bild 3: Der CV3-SoC von Ambarella bietet Verarbeitung für den gesamten AD-Stack. 

Bild 4: Blockdiagramm des CV3-SoC von Ambarella 

Dr. Steven Hong ist Vice President und General Manager Radar Technology bei Ambarella in Santa Clara, Kalifornien. 

Lazaar Louis ist Director Automotive Marketing bei Ambarella, Santa Clara, Kalifornien. 

Ambarella

Die SAE J3016 definiert Begriffe für straßengebundene Kraftfahrzeuge mit Systemen zum automatisierten Fahren. Dazu gehören Fahrerassistenzsysteme, die zuverlässige Hard- und Software für Erkennungs- und Erfassungssysteme erfordern. Hier kommen die magnetischen Positionssensoren von Allegro zum Einsatz.

Lenk- und Bremssysteme sind von entscheidender Bedeutung für die Automatisierung des Fahrens und die Kontrolle und Sicherheit von Fahrerassistenzsystemen (ADAS). Die Entwicklung elektronischer Technologien führt zu neuen Systemen wie Steer-by-Wire und Brake-by-Wire. Diese beruhen auf Motorsteuerungskonzepten, um die Leistungs- und Sicherheitsanforderungen der Automobilhersteller zu erfüllen und dem Endverbraucher ein optimales Fahrerlebnis zu bieten. Diese sicherheitskritischen Systeme sind mit internen Diagnosemöglichkeiten ausgestattet, einschließlich Redundanz zur Erkennung von internen Fehlern, um einen sicheren Betrieb im Falle eines Systemausfalls zu gewährleisten. Magnetische Sensoren sind aufgrund ihrer Zuverlässigkeit, ihres geringen Platzbedarfs und ihrer Konformität mit dem Automotive Safety Integrity Level (ASIL) gemäß ISO 26262 die beste Wahl für die Positionssteuerung von Motoren.

Mit den Bausteinen A33110 und A33115 hat Allegro Winkelsensoren mit heterogenem magnetischem Tunnelwiderstand (TMR) und vertikaler Hall-Technologie (VHT) eingeführt (Bild 1). Bei diesen TMR- und VHT-Sensor-ICs, die aufgrund ihrer Konstruktion so benannt wurden, dass sie die beiden Technologien, die normalerweise getrennt sind, in einem Gehäuse vereinen, handelt es sich um hochauflösende kontaktlose Winkelsensoren, die Winkelposition, Drehgeschwindigkeit und Richtung über 360 Grad messen können. Beide Sensoren sind ASIL D-konform und befinden sich in einem Gehäuse, das den Platzbedarf und die Anzahl der Komponenten reduziert. Heterogene Redundanz (diverse Redundanz) in einer Systemarchitektur, die funktionale Sicherheit bietet, erfordert redundante Funktionalität aus einer unterschiedlichen Technologie, Konstruktion oder einem Design. Im Hinblick auf die systematische Fehlererkennung ist Diversität effektiver und kann die Wahrscheinlichkeit von abhängigen Fehlern im Vergleich zu homogen-redundanten Lösungen reduzieren.

Der magnetische Erkennungsschaltkreis in den Allegro-Geräten bietet sowohl primäre (TMR) als auch sekundäre (VHT) Sensoren, die unabhängige Signalverarbeitungskanäle verwenden. Der TMR-Kanal bietet eine rauschfreie 14-Bit-Auflösung für die Präzisionskontrolle, während der VHT-Kanal eine rauschfreie 10-Bit-Auflösung bietet, die für Sicherheitsprüfungen geeignet ist, einschließlich Prüfungen wie Low-Field und Erkennung eines fehlenden Magneten. Die sensorinterne Fehlererkennung erfolgt durch On-Chip-Diagnose (interne Sicherheitsmechanismen) und Fehlerflags, die beim Systemdesign mit minimaler Analyse der vom Sensor empfangenen Daten verwendet werden können.

Die zwei unterschiedlichen, unabhängig voneinander arbeitenden Primär- und Sekundärkanäle stellen eine wichtige Sicherheitskomponente in ADAS-Anwendungen dar. Durch den TMR-Kanal eignen sich die Sensoren für den Einsatz in elektronischen Servolenkungen (EPS, Bild 2), Steer-by-Wire, Brake-by-Wire und elektromechanischen Bremssystemen (EMB). Der Einsatz der hochauflösenden TMR-Technologie kann die Motorrückkopplung im Lenksystem reduzieren, um eine sanftere Bewegung des Lenkrads und in der Regel weniger hörbare Motorgeräusche im Innenraum zu ermöglichen. Dieser Vorteil zeigt sich bei elektrifizierten Fahrzeugen (Electric Vehicles, EVs) – weniger hörbare Geräusche tragen zu einer leisen Kabine bei, die EV-Fahrer erwarten.

Bei Bremsanwendungen kommen die Sicherheits- und Leistungsvorteile der TMR- und VHT-Lösungen voll zum Tragen. Die ASIL-D-konformen Komponenten kombinieren die Vorteile eines hohen Sicherheits- und Diagnosedeckungsgrades und heterogener Redundanz. Darüber hinaus bieten die Sensoren eine schnelle Reaktionszeit zur Unterstützung der Hochgeschwindigkeits-Motorpositionssteuerung, die in modernen Bremssystemen benötigt wird. Im Zuge der Integration von ADAS und automatisiertem Fahren in Fahrzeuge und der allgemeinen Weiterentwicklung des Automobils sind Systeme, die den Fahrer in Sekundenbruchteilen schützen, ein zunehmend wichtiger Punkt in der Fahrzeugentwicklung.

Abgesehen von diesen Sicherheitsvorteilen heben sich die Sensoren in mehrfacher Hinsicht von anderen Lösungen ab. Zum einen zeichnet sich die Kombination aus TMR- und Hall-Sensor-Technologie durch heterogene Redundanz, Low-Field- und Missing-Magnet-Erkennung aus.

Die ICs arbeiten außerdem über einen Betriebsspannungsbereich von 3,7 bis 18 V. Das ermöglicht den direkten Anschluss an die Batteriespannung des Fahrzeugs und macht Spannungsregler innerhalb eines Systemdesigns überflüssig. Die Bausteine enthalten einen integrierten Umdrehungszähler mit einer Logik, die die Magnetposition verfolgt und einen Zähler aktualisiert, um den Winkel in 90-Grad-Schritten zu verfolgen. Durch diese inkrementelle Verfolgung wird die Richtungserkennung des Umdrehungszählers beibehalten. Der primäre Windungszähler wird auf der Grundlage des vom primären Kanal gemessenen absoluten Winkels aktualisiert und der sekundäre Windungszähler auf der Grundlage des vom sekundären Kanal gemessenen absoluten Winkels.

Eine wichtige Anforderung an EPS-Systeme ist die Zählung der Abbiegevorgänge bei ausgeschaltetem Fahrzeug, wie es bei der Fahrzeugwartung üblich ist. Traditionell wird diese Key-Off-Anforderung durch eine Kombination relativ komplexer mechanischer und elektronischer Komponenten erreicht. Der A33115 trägt dazu bei, die Komplexität auf Systemebene zu reduzieren und viele Komponenten zu eliminieren, indem er sowohl die absolute Winkelmessung als auch die Verfolgung der Umdrehungszahl durchführt und dabei einen niedrigen Batteriestromverbrauch mit einem typischen Versorgungsstrom von 50 A beibehält. Der A33115 ist der erste zweidimensionale TMR-Winkelsensor der Branche, der diese Fähigkeit bietet.

Beide neuen Sensor-IC-Lösungen von Allegro ermöglichen acht EEPROM-auswählbare Kombinationen von TMR- und VHT-Kanälen, um ABI/UVW-, PWM- oder SPI-Ausgangsprotokolle bereitzustellen, sowie das Auslesen beider Kanäle über SPI. Diese Funktion erleichtert den benutzerdefinierten heterogenen Vergleich der Kanäle und ermöglicht es dem Benutzer, jeden Kanal an seine spezifischen Funktions- und Anwendungsanforderungen anzupassen.

Die Linearisierung ist als EEPROM-Option verfügbar, um Fehler aufgrund von Ausrichtungsfehlern zwischen dem Sensor und dem Zielmagneten zu reduzieren. Sie beseitigt Winkelfehler, die aus mechanischen und magnetischen Ungleichmäßigkeiten resultieren. Die Linearisierungsschaltungen bieten diese Korrektur mit minimaler zusätzlicher Latenzzeit.

Die Automobilindustrie blickt auf die Zukunft ihrer Fahrzeuge – ins- besondere im Hinblick auf die Fortschritte bei der Elektrifizierung und der Fahrersicherheit. Die dafür zum Einsatz kommenden verschiedenen Systeme und Komponenten müssen auf einem hohen Niveau arbeiten. Zulieferer,  Ingenieure und Automobilhersteller müssen ein besonderes Augenmerk auf Sicherheit und Zuverlässigkeit legen und gleichzeitig den Komfort und die Bequemlichkeit der Endnutzer im Auge behalten. (eck)

<a href="http://www.allegromicro.com" target="_blank">www.allegromicro.com</a>

Scott Pavlik ist Strategic Marketing Manager bei Allegro.

Bild 1: Blockdiagramm eines TMR- und VHT-Sensor-ICs.

Bild 2: Durch den TMR-Kanal eignen sich die Sensoren insbesondere für den Einsatz in  elektronischen Servolenkungen.

Scott Pavlik ist Strategic  Marketing Manager bei Allegro. 

Allegro

Weg vom Steuergeräte-Overkill und armdicken Kabelsträngen, hin zu geordneten und leistungsfähigen E/E-Architekturen: die Digitalisierung des Automobils verändert die Bordnetze, wirbelt aber auch die eingespielten Lieferantenbeziehungen durcheinander.

Ein „Weiter so“ mit den bisherigen E/E-Architekturen und ihren manchmal mehr als 100 Steuergeräten führt in die Sackgasse. Ausweg ist die Bündelung der Aufgaben in Domänenrechnern, Zentralrechnern und Zonencontrollern: dies senkt die Anzahl der Steuergeräte und damit Kosten und Systemkomplexität. Den Markt für Hochleistungs-Steuergeräte taxieren Analysten von McKinsey im Jahr 2030 auf ein Volumen von 156 bis 207 Milliarden US-Dollar weltweit (Bild 1) – je nach Marktdynamik von automatisierten und autonomen Fahrfunktionen.

Im Jahr 2025 könnten dann in einem Kleinwagen mit Verbrennungsmotor Controller im Wert von etwa 900 Dollar verbaut sein, bei Premiumfahrzeugen mit Plug-In-Hybridantrieb und Level 3-Fahrfunktionen sogar im Wert von knapp 3.400 US-Dollar. In Robotaxis könnte der Wert bis zu 8.500 US-Dollar betragen. Nach 2025 erwarten die Analysten, dass die Controllerkosten pro Fahrzeug um bis zu zehn Prozent sinken werden hauptsächlich wegen Skaleneffekten bei elektronischen Bauteilen sowie Kosteneinsparungen bei den hochaggregierten Domänen-, Zonen- und Zentralrechnern.

Aktuell führen OEMs sukzessive Domänenstrukturen in ihren E/E-Architekturen ein, vor allem für den Infotainmentbereich, aber auch für das Antriebsmanagement, Karosseriefunktionen, sowie für Fahrerassistenz plus automatisiertes Fahren, und als Gateway Richtung Backend/Cloud (Bild 2). Zudem arbeiten OEMs und Zulieferer bereits an Cross-Domain-Controllern, die Aufgaben mehrerer Fahrzeugdomänen bündeln. „Insbesondere bei Fahrzeugen mit einfacherer Ausstattung wären Cross-Domain-Controller eine sinnvolle, weil kostengünstige Alternative,“ meint Joachim Mathes, CTO Comfort & Driving Assistance Systems von Valeo. Konkretes Beispiel ist der Hochleistungsrechner, den Continental ab 2023 an einen chinesischen OEM liefern wird. Er soll bei einem Elektrofahrzeug als Gateway (unter anderem für Over-the-Air-Updates) fungieren und Aufgaben wie die Zugangs-, Tür- und Fenstersteuerung, sowie das Wärme- und Drehmomentmanagement des Fahrzeugs übernehmen.

Logisches Ende dieser Entwicklung wäre ein mehrkerniger Zentralrechner für alle Fahrzeugfunktionen, wie ihn Tesla für seine Modelle bereits entwickelt hat – inklusive der wesentlichen Hard- und Software-Komponenten. „Wenn aber die Rechenleistung zentralisiert ist, wäre es sinnvoll, das Daten- und Leistungsmanagement in Zonencontrollern zu dezentralisieren,“ gibt Joachim Mathes zu bedenken. „Denn der Anschluss beispielsweise aller Aktuatoren und Sensoren verursacht im Zentralrechner sehr hohe elektrische Leistungen und eine aufwendige Verkabelung.“

Auch das Thema Redundanz lässt sich nach Angaben von Sofiane Amara, Technical Manager Automated Driving/ADAS bei Hitachi Astemo, mit dem zweistufigen Ansatz besser lösen: „Wenn die Software sowohl im Zentralrechner als auch im Zonencontroller implementiert ist, ist eine Safe Operational Performance gegeben.“ Zentralrechner mit oder ohne Zonencontroller sind derzeit vor allem für Start-Ups wie Tesla & Co. eine Option, die keine Rücksicht auf vorhandene Modellreihen und Rückwärtskompatibilität nehmen müssen.

Ob und wann die OEMs Zentralrechner-Architekturen implementieren werden, hängt nach Ansicht der Experten stark von der Fahrzeugklasse, dem Ausstattungsniveau und den Stückzahlen ab. Da man Skaleneffekte heben will, liebäugeln die OEMs mit volumenstarken Plattformlösungen über mehrere Produktreihen und -generationen hinweg sowie mit Built-to-print-Lösungen. Das öffnet beispielsweise Chiplieferanten wie Nvidia, Mobileye, Qualcomm oder NXP die Tür zu Großaufträgen. Da Hochleistungsprozessoren großen Einfluss auf die Controllerarchitektur, die Software-Stacks und die Schnittstellen haben, wächst die Marktmacht der Chiplieferanten, die durch die Halbleiterkrise ohnehin am längeren Hebel sitzen.

Aber nicht nur die Chiplieferanten bauen ihren Einfluss bei Hochleistungsrechnern aus. „Parallel dazu entwickeln sich Datenunternehmen wie Amazon, Microsoft und Google mit ihren Kompetenzen für Software, Big Data, Künstliche Intelligenz und Cloudanwendungen zu weiteren Machtzentren“, kommentiert Dr. Volker Nadenau, bis vor kurzem Senior Vice President in der zentralen Vorentwicklung der Robert Bosch GmbH. „Ihnen fehlt teilweise noch etwas das spezifische Automotive-Know how, weshalb sie derzeit bevorzugt Allianzen mit OEMs und Tier1-Lieferanten eingehen.“ Beispiele sind die Kooperationen von Microsoft mit Bosch und ZF, sowie Amazon mit Continental. Auch Chiplieferanten versuchen mit Kooperationen stärker im Automotive-Controller-Markt Fuß zu fassen. So partnert Nvidia mit Daimler und Jaguar Land Rover, Mobileye mit Geely und Qualcomm mit BMW.„Diesen Trend kann man mit Fug und Recht als Strukturbruch im Automotive-Entwicklungsprozess bezeichnen“, so Volker Nadenau weiter. „Statt wie bisher nur der OEM und der Tier1-Zulieferer nehmen jetzt mit den Chiplieferanten und Datenunternehmen weitere potente Player Verantwortung im Entwicklungsprozess wahr.“ Das kann so weit führen, dass sich ein Chiplieferant wie Nvidia einen hohen Umsatzanteil bei Software-Updates in zukünftigen Daimler-Fahrzeugen sichert.

„Bei zukünftig stärker zentralisierten Architekturen werden OEMs mehr Verantwortung bei der Software-Entwicklung, der Funktionsoptimierung und der Integration übernehmen, ebenso wie bei Entwicklung serviceorientierter Geschäftsmodelle“, blickt Sofiane Amara von Hitachi Astemo voraus. Beispielsweise hat Volkswagen mit Cariad einen eigenen Softwareentwickler gegründet und kooperiert zu diesem Thema eng mit Bosch. Auch andere OEMs bauen massiv Entwicklungskapazitäten für Softwarekomponenten und neue Geschäftsmodelle auf. Allerdings sind ihnen auf diesem Feld große Zulieferer um mehr als eine Nasenlänge voraus und beschäftigen beispielsweise viel mehr Softwareexperten als die OEMs.

„Tier1-Zulieferer werden sich zum Tier 0,5 weiterentwickeln müssen“, glaubt Uwe Class, Vice President Advanced System Development bei ZF. „Sie müssen die E/E-Architektur auf Fahrzeugebene verstehen, müssen in Ökosystemen und verschiedenen Mobilitätsebenen denken lernen, um die funktionale Integration eines Domänen-, Zonen- oder Zentralrechners selbstständig durchführen können. Dies umfasst auch Funktionen von dritten Projektpartnern, die der Tier1 nicht selbst entwickelt.“ Da die OEMs auf vielen anderen Feldern ebefalls Verantwortung übernehmen und eigene Kompetenzen aufbauen wollen, dürften sie nach Ansicht von Uwe Class eine stärkere Rolle der Tier1 bei den Hochleistungsrechnern befürworten. Dem steht die Ansicht anderer Experten entgegen, dass die OEMs versucht sein könnten, durch Aufsplitten von Auftragsumfängen ihre Rolle als Gesamtverantwortlicher zu festigen. „In diesem Fall müssen wir Tier 1 einerseits als Generalist mit Gesamtsystemverständnis auftreten,“ glaubt Joachim Mathes von Valeo. „Andererseits sollten wir in unabhängigen Einheiten organisiert sein, um schnell mit beispielsweise Auftragsfertigern, Softwareentwicklern und Engineeringdienstleistern interagieren zu können.“

Prozessorlieferanten und Datenunternehmen sind potenziell auch in der Lage, Gesamtsystemverantwortung bei der Entwicklung von Hochleistungsrechnern zu übernehmen. „Sie verfügen derzeit vielleicht noch nicht über die Integrationsfähigkeiten und Expertise, die für komplette Zentralrechnerlösungen erforderlich sind,“ glaubt Volker Nadenau. „Diese Fähigkeiten können sie aber mithilfe von Partnern erwerben.“

Tier2-Zulieferer wiederum müssen nach Auffassung von Uwe Class ihre Komponenten künftig so gestalten, dass sie in den Zielarchitekturen flexibel integrierbar sind. „Ein Teil einer Softwarefunktion muss beispielsweise auf einem Aktuator durchgeführt werden können, ein anderer Teil vielleicht auf einer höheren Abstraktionsebene wie einer Domäne oder einer Zone.“

Weniger auskunftsfreudig als bei E/E-Architekturen und Organisationsstrukturen zeigen sich die Tier1-Zulieferer bei Zahlen zur eigenen Marktperformance. Von Continental ist beispielsweise bekannt, dass man einen der beiden Zentralrechner für die Volkswagen-Modelle ID3 und ID4 liefert und Stand 2021 Aufträge im Wert von mehr als vier Milliarden Euro in den Büchern stehen hatte. Bei Bosch soll das Auftragsvolumen im vergangenen Jahr insgesamt „eine mittlere einstellige Milliardensumme“ betragen haben und es sind zweistellige Wachstumsraten geplant. ZF bestätigt für seinen ProAI-Domänenrechner (Bild 3) mit Serienstart ab 2024 Großaufträge von Kunden aus Europa und Asien, sowohl im Pkw- als auch im Nutzfahrzeugbereich. Mit insgesamt siebenstelligen Abrufzahlen sieht man sich unter den Top 5 des Segments.

Daneben sieht sich Valeo „bei Domänenrechnern für ADAS-Anwendungen als führender Marktteilnehmer“, aber auch Hitachi Astemo beansprucht in diesem Segment eine „weltweite Führungsposition“. Weitere namhafte Marktteilnehmer sind etwa Aptiv, Harman oder Visteon. Ein Branchenkenner lenkt den Blick in eine ganz andere Richtung: „Man sollte auch Auftragsfertiger wie Quanta und Flex als Wettbewerber sehen.“ (eck)

Hartmut Hammer ist Automobiljournalist und schreibt seit mehr als zwei Jahrzehnten über Elektronik- und Entwicklungsthemen.

Bild 1: Analysten taxieren im Jahr 2030 den Markt für Hochleistungssteuergeräte auf ein Volumen von 156 bis 207 Milliarden Dollar.

Bild 2: Domänenbasierte Architekturen (rechts) sind der erste Schritt weg von den heutigen komplexen E/E-Architekturen. 

Bild 3: Die ProAI-Plattform von ZF kann als Domänen-, Zonen- oder Zentralrechner dienen.

Hartmut Hammer ist Automobiljournalist und schreibt seit mehr als zwei Jahrzehnten über Elektronik- und Entwicklungsthemen.

HANSER automotive_Domänencontroller

Flüssigkeitskühlung  elektronischer Steuergeräte

In Kooperation mit dem Wuppertaler Unternehmen Aptiv hat die WKW.group  ein Kühlkonzept entwickelt, dass maßgeblich zur Reduzierung von Gewicht und Bauraum bei Fahrzeugen mit Assistenzsystemen beiträgt.

In Kooperation mit Aptiv hat die WKW.group ein Kühlkonzept entwickelt, dass maßgeblich zur Reduzierung von Gewicht und Bauraum bei Fahrzeugen mit Assistenzsystemen beiträgt.

Lothar Löchte, Stefan Hackländer und Frank Adam

Moderne Fahrzeuge verfügen über bis zu 100 Steuergeräte, die wiederum jeweils verschiedene Elektronikkomponenten enthalten. Bereits bei Elektronikbauteilen für heutige Fahrzeuge – beispielsweise für Fahrassistenzsysteme – sind beachtliche Wärmemengen abzuführen.

Mit der zunehmenden Elektrifizierung und zunehmenden autonomen Fahrfunktionen zukünftiger Mobilitätskonzepte wird die benötigte Rechenleistung der zentralen elektronischen Steuereinheiten (Electronic Control Unit, ECU) der Fahrzeuge ansteigen. Die dafür benötigten leistungsfähigeren Prozessoren und Systems-on-a-Chip (SoCs) werden die zukünftig benötigte elektrische Leistung und damit wiederum die produzierte Abwärme deutlich ansteigen lassen, die zum sicheren Betrieb der ECUs aus deren Gehäusen abtransportiert werden muss. Ab einer elektrischen Leistung von ca. 150 W können nur flüssigkeitsgekühlte Systeme eine ausreichende Entwärmungsleistung zur Kühlung der ECU zur Verfügung stellen. Bei zu erwartenden Verlustleistungen künftiger Steuergeräte ist es allerdings auch absehbar, dass aktuelle Flüssigkeitskühlungen und ihre Kühlplatten (Coldplates) die Grenze ihrer Leistungsfähigkeit erreichen werden.

Neben den Prozessoren für autonome Fahrfunktionen hat auch die Leistungselektronik batterielektrischer Fahrzeuge Kühlbedarf. Die Leistungselektronik in Elektro- oder auch Hybridfahrzeugen stellt das zentrale Bindeglied zwischen Elektromotor und Hochvolt-Batterie her. Eine der wesentlichen Aufgaben ist u.a. die Wandlung von Gleich- in Wechselstrom und zurück. Auch diese Kühlaufgabe ist zumeist nur mit Flüssigkeitskühlung zu lösen.

In einer Kooperation zwischen Aptiv und der WKW.group wurde im Rahmen einer Konzeptstudie ein Kühlkonzept am Beispiel einer PCB für ein Fahrzeug mit Assistenzsystemen entwickelt, das nicht nur die erforderlichen Kühlbedingungen erfüllt, sondern auch noch Gewicht und Bauraum der Kühleinheit minimiert.

Die neu entwickelte optimierte Coldplate basiert auf Mehrkanalflachrohren (Micro Multi Port, MMP) aus Aluminium der 3000er Serie (z.B. EN AW 3102). MMPs sind nicht nur für die Komponenten von Klimaanlagen und Verdampfern seit vielen Jahren in der Serienanwendung, sondern auch für Batteriekühlungslösungen von Elektrofahrzeugen. Durch ihre geringen Wandstärken, die Vielzahl äußerst kleiner Kammern und die dadurch sehr hohe innere Oberfläche, sowie die gute Wärmeleitfähigkeit von 160 bis 200 W/mK versus ca. 130 W/mK bei Druckgusswerkstoffen können sie hohe Wärmemengen in kurzer Zeit abtransportieren. Als Medium sind handelsübliche Kühlmittel (Wasser/Glykol) oder auch Kältemittel (R1234yf oder CO2) wählbar und seit geraumer Zeit im Serieneinsatz.

Für einen Prototyp der neuartigen Flüssigkeitskühlung wurde ein MMP (Bild 1) mit den Außenabmessungen 60 mm x 3 mm, einer Wandstärke von 0,35 mm und 29 Kammern verwendet. Diese Geometrie ist gut geeignet für die Nutzung von Wasser/Glykol als Kühlmedium.

Das MMP und die eigentliche Kühlplatte sind durch Löten miteinander verbunden (Bild 2). Der flächige metallische Kontakt stellt die bestmögliche Wärmeleitung sicher. Die Wahl eines geeigneten Lots ermöglicht das Löten an Luft-Atmosphäre. Die Coldplate wiederum ist mit den zu kühlenden Bauelementen auf der Leiterplatte der ECU in gutem thermischem Kontakt. Um Fertigungsstreuungen der elektronischen Bauelemente auszugleichen, wird üblicherweise Wärmeleitpaste zwischen der Kühlplatte und den Bauelementen aufgetragen. Das neue Konzept erlaubte es, die Menge an nötiger Wärmeleitpaste auf ein Minimum zu reduzieren. Das ist äußerst wichtig, weil die Wärmeleitfähigkeit der Wärmeleitpasten um einen Faktor 40 geringer ist, als die der verwendeten Aluminiumlegierungen. Daher stellen diese notwendigen Wärmeleitpasten immer einen thermischen Widerstand im Entwärmungspfad dar, den es zu optimieren gilt. Neben der verbesserten Entwärmungsleistung kann über die Minimierung an Wärmeleitpaste eine Kosteneinsparung erzielt werden.

Die Coldplates des Prototyps werden durch einen externen, fahrzeugseitigen Kühlmittelkreislauf mit Kühlmittel versorgt. Das Kühlmittel wird am Gehäuse der elektronischen Steuereinheit in einen Kühlmittelanschluss gespeist und von dort durch die MMPs zu einem zweiten Kühlmittelanschluss transportiert, um dort das Gehäuse wieder zu verlassen. Das Kühlmittel lässt sich im Anschluss wiederum über einen Chiller herunterkühlen.

 Die Entwärmungsleistung des Prototyps wurde mithilfe thermischer Simulationen charakterisiert. Die Coldplate stellt sicher, dass sich die Bauelemente nicht oberhalb von ihrer spezifizierten Betriebstemperatur erwärmen. Die Kühlleistung ist gegenüber konventionellen Kühlkörpern um bis zu 10 Prozent verbessert. Darüber hinaus können im Vergleich zu herkömmlichen, über Druckguss hergestellten Lösungen rund 35 Prozent Gewicht eingespart werden, was ungefähr einem Kilogramm entspricht. Darüber hinaus bieten sich durch das kompakte Design, insbesondere der MMPs, Möglichkeiten der Minimierung des benötigen Bauraums. Im Vergleich zu Druckgusslösungen werden bei der MMP-basierten Coldplate maximal 10 mm in Z-Richtung benötigt, was einer Einsparung von ca. 50 Prozent entspricht.

Die Coldplate bedient den Bedarf nach Flüssigkeitskühlung elektronischer Steuereinheiten heutiger und zukünftiger Mobilitätskonzepte. Die benötigte Kühlleistung kann bei deutlich reduziertem Gewicht, nämlich ca. 35 Prozent Einsparung, gegenüber einer herkömmlichen Druckgusslösung gewährleistet werden und ermöglicht außerdem Einsparung von Bauraum in Z-Richtung durch das flache Design der verwendeten MMPs. Neben dem für den Prototyp verwendeten Kühlmittel (Wasser/Glykol) eröffnet die Verwendung von MMPs auch die Möglichkeit der Nutzung von Kältemittel aus der Klimaanlage und somit noch einen weiteren deutlichen Sprung in der Entwärmungsleistung. (eck)

Dr.-Ing. Lothar Löchte leitet bei der Erbslöh Aluminium GmbH (WKW.extrusion) den Bereich Produktengineering. Stefan Hackländer betreut als Teil von WKW Engineering (WKW.automotive) Neuentwicklungen und Entwicklungsprojekte. Dipl.-Phys. Frank Adam betreut bei Aptiv Services Deutschland Projekte und numerische Simulationen in der Vorentwicklung Hardware.

Bild 1: Micro Multi Port (MMP) mit der Abmessung 60 mm x 3 mm und 29 Kammern.

Bild 2: Übersichtsaufnahme des Prototyps 

Bild 3: Detailaufnahme der Anschlusstechnik des Prototyps.

Dipl.-Phys. Frank Adam betreut bei Aptiv Services Deutschland Projekte und numerische Simulationen in der Vorentwicklung Hardware.

Stefan Hackländer betreut als Teil von WKW Engineering (WKW.automotive) Neuentwicklungen und Entwicklungsprojekte.

Dr.-Ing. Lothar Löchte leitet bei der Erbslöh Aluminium GmbH (WKW.extrusion) den Bereich  Produktengineering.

WKW.group

Um in Extremsituationen schnellstmöglich angemessen reagieren zu können, benötigen moderne Fahrzeuge mit Fahrerassistenzsystemen die richtige Hardware-Lösung im Hintergrund. Damit Lösungen passgenau entwickelt werden können, bedarf es leistungsstarker Entwicklungs- und Datenerfassungsplattformen.

Manuel Deuter, Janina Jonker und Jürgen Obergfell

Im Straßenverkehr sind Fahrerassistenzsysteme (FAS) heutzutage nicht mehr wegzudenken und erhöhen die Fahrsicherheit, erweitern den Komfort und verbessern das Fahrerlebnis merklich. In Deutschland wird bereits über eine Zulassung für SAE-Level 4 Fahrzeuge im Straßenverkehr diskutiert. Weil jedes neue SAE-Level auch die Menge an Daten, die dafür benötigt wird, auf ein neues Niveau anhebt, wird die Hardware stets aufs Neue auf die Probe gestellt. Eine Herausforderung stellt die zunehmende Anzahl an Lidar-, Radar-, und Kamerasensoren verschiedener Typen im oder am Fahrzeug dar. Diese transportieren über Datenbusse Informationen und kommunizieren mit verschiedenen Steuergeräten. Unter Zuhilfenahme vernetzter Bussysteme werden die Sensordaten schließlich in dynamische, automatisierte Steuerungsaktionen transformiert. Automatisiertes und autonomes Fahren (AD) der Level 3 bis 5 benötigt fortgeschrittene Assistenzsysteme (Advanced Driver Assistance Systems, ADAS). Die Vernetzung von Abstand-Regeltempomat, radarbasierten Abbiegeassistenten, GPS- und optischen Daten aus Infrarotkameras, Stereo-Kameras sowie Radar, Lidar und Ultraschall bilden das sensorische Frontend für automatisierte Fahrsysteme. Entwickler müssen aus diesen vielen unterschiedlichen Daten ein Gesamtbild erzeugen und sämtliche Risiken ihrer Steuerungslösungen minimieren, um eine erfolgreiche Zulassung ihres Systems zu gewährleisten. Zusätzlich darf nicht außer Acht gelassen werden, dass sich auch der Komplexitätsgrad bei jedem SAE-Level noch weiter erhöht und die steigende Anzahl an hochentwickelter Sensorik im Fahrzeug eine Fülle an Daten liefert, die verarbeitet und geloggt werden müssen.

Mit dem aktuellen Wandel von Software-in-the-Loop (SiL) zu Hardware-in-the-Loop (HiL) und von HiL zu Vehicle-in-the-Loop (ViL) sowie der Validierung von ADAS- und AD-Entwicklungen, werden möglichst realitätsnahe Datensätze benötigt (Bild 1). Durch hochauflösende Kameras und Sensoren werden während der Testfahrten aus der Umgebung sehr viele Daten, von Straßenbeschaffenheit, über die Dynamik und Steuereinheit des Testfahrzeugs bis hin zu Straßenschildern, Fahrbahnlinien und Verkehrsteilnehmern geloggt. Diese werden dann über Objektklassifizierung und KI-basierte Modelle miteinbezogen, um reale Verkehrsszenarien zu erfassen. Daraus ergeben sich entsprechend hohe Anforderungen an die Aufnahmequalität der Rohdaten. Neben der hohen Datenschreibrate müssen die Daten vor dem Schreibvorgang noch von einer KI ausgewertet und bei geringer Relevanz komprimiert werden, um die Datenträger nicht mit irrelevanten Daten zu beschreiben. Kommt es während eines Testlaufs zu einer Fehlfunktion oder anderen Auffälligkeiten, greifen die Testfahrer manuell in die Fahrzeugsteuerung ein und setzen einen Time Stamp. Damit die autonome Steuerungs-Software aus solchen Korrekturen »lernen« kann (Deep Learning), müssen sämtliche Datenströme vor und nach einem Fahrfehler präzise erfasst, ausgewertet und anschließend in die Steuerungs-Software eingespeist werden. Das führt somit zu einem noch nie dagewesenen Ausmaß an Sensordaten.

Zahlreiche Kameras und Sensoren sind im Fahrzeug mit dem Logger über Ethernet-Schnittstellen verbunden. In einer beispielhaften Rechnung wurde ein Auto mit SAE-Level 3 und 25 Modulen (Radar, Lidar, Kameras) ausgewählt. Wenn hier eine einzelne Kamera betrachtet wird, die mit 8 MP aufnimmt, kommen schnell 500 MB/s zusammen. Weil in der Regel die Videosensoren die höchsten Rohdatenrate haben, lassen sich die 500 MB/s auf die 25 Module hochrechnen, so dass sich eine reine Schreibrate für Rohdaten von bis zu 12,5 GB/s ergibt. Mit 12,5 GB/s, die hier exemplarisch errechnet wurden, kommt man an einem acht Stunden Arbeitstag auf bis zu 360 TB Rohdaten. Automobilhersteller stehen daher vor der Herausforderung, Messdaten unter realen Fahrbedingungen im Fahrzeug parallel aufzuzeichnen, zu speichern und auszuwerten. In der ADAS/AD-Entwicklung wird folglich ein robustes System benötigt, das enorme Rechenleistung, hohe Schreibraten und Speicherkapazität bereitstellt. Die InoNet Computer GmbH unterstützt Fahrzeugentwickler mit ihrem Automotive Portfolio bei Test- und Validierungsanwendungen. Das Car HPC Produkt MAYFLOWER-B17-LiQuid adressiert die beschriebenen Herausforderungen im ADAS-Bereich.

Das speziell für hohe Schreibraten entwickelte QuickTray (QT), ein robuster Wechsel-Datenträger mit vier NVME SSDs im Raid-0-Verbund, ermöglicht diesen hohen und konstanten Datendurchsatz und das Speichern der immensen Datenmengen. In Verbindung mit einem zusätzlichen Storage-Unit-Aufsatz (mit Platz für 2x QuickTray) kann enorme Speicherkapazität von bis zu 300 TB und eine hohe Schreibgeschwindigkeit von bis zu 26 GB/s, also 208 Gbit/s (in Abhängigkeit des verwendeten SSD-Typs und -Herstellers, real gemessen mit Iometer im „Continuous Write Mode“) bereitgestellt werden.

Hohe Temperaturen durch Komprimierung von Rohdaten  mit KI-Unterstützung

Da bei den fortgeschrittenen Testfahrten in den SAE-Level 3 bis 5 nicht mehr jede einzelne Situation aufgezeichnet werden muss, wird heutzutage vorausgewählt. Die automatische Vorselektierung der richtigen Daten bedarf einer künstlichen Intelligenz (KI) im Hintergrund. Die KI entscheidet hierbei mittels Algorithmen während der Fahrt, welche Szenen benötigt und auf den Datenträgern geloggt werden sollen. Außerdem sollen die gesammelten Daten während der Fahrt mit Funktionen wie dem automatisierten Labeling, Time-Stamping, Komprimierung oder auch Verschlüsselung on-the-fly bearbeitet werden. Selbstverständlich benötigen diese Prozesse extrem hohe Rechenleistung, die hauptsächlich durch eine Bündelung der GPU und CPU zustande kommt. Generell haben Computerkomponenten, wie eine CPU oder eine Grafikkarte sehr hohe Abwärme von knapp 100 Prozent. Das bedeutet, dass nahezu die komplette investierte elektrische Leistung in Form von Watt als Abwärme von den Komponenten wieder abgestrahlt wird. KI-Algorithmen sind sehr leistungsintensiv und beanspruchen oft auch den Großteil der Rechenleistung eines Computers, welche wiederum hohe Temperaturen in Form von Verlustleistung erzeugen. Zusätzlich beeinflussen neben internen Faktoren auch externe Faktoren, wie Wetterbedingungen, die Temperaturen der Geräte. Wenn die produzierte Abwärme nicht richtig abtransportiert wird, führt das automatisch zu einer Überhitzung oder zu einem temperaturbedingten Drosseln (Throttling), was sich nachteilig auf die Performance auswirkt.

Im ADAS-Testbereich müssen die Hardware-Komponenten extremen Temperaturen widerstehen, die weit außerhalb der ursprünglichen Spezifikation liegen. Eigene Testergebnisse ergaben, dass ein großer Server-PC mit der richtigen Kühlung auch bei –20 °C startet und schnell auf Betriebstemperatur kommt.

Aber die Extreme befinden sich nicht nur in den unteren, sondern auch in den höheren Temperaturbereichen. Mit der Herausführung des Radiators der Flüssigkeitskühlung vom Kofferraum in den beispielsweise kühleren Fahrerraum ist es möglich Serverrechner bei + 70 °C ohne Drosselung zu betreiben. Diese Temperaturbereiche eröffnen ganz neue Möglichkeiten für die Automobilbranche, weil hoch performante Messtechnik in der Regel für die benötigten Betriebstemperaturbereiche nicht ausgelegt ist (Bild 2).

Abfuhr der Wärmeleistung durch selbst entwickelte Wasserkühlung

Wofür wird überhaupt eine Wasserkühlung beziehungsweise Flüssigkeitskühlung benötigt? Diese Art des aktiven Kühlens wird verwendet, weil viele Computer im Kofferraum der Fahrzeugprototypen verbaut werden und sich dort die Hitze staut. Mit einer standardisierten Luftkühlung wird die Luft im Kofferraum lediglich verwirbelt, aber kaum Temperatur von den Komponenten abgeführt. Um diese Hitze, die auch durch Umweltfaktoren beeinflusst wird, lokal vom Mainboard abzutransportieren, werden externe Wärmetauscher bis zum Fußraum des Beifahrers verlegt. Durch diese Radiatoren wird die aufgenommene Hitze im Fußraum verteilt und diese in der Regel durch die Klimaanlage des Fahrzeugs heruntergekühlt.

Bei der Mayflower B17 Liquid wurde dieses Konzept noch weiter verfeinert und optimiert. Hier wurde die Flüssigkeitskühlung mit No-Spill-Anschlüssen an die CPU angebunden. Zudem wurden eigene Kühlblöcke für die normalerweise luftgekühlten Grafikkarten entwickelt. Diese Kühlblöcke ermöglichen den Grafikkarten eine Anbindung an die Flüssigkeitskühlung. Die vergleichsweise hohe Wärmekapazität des Beispielkühlmediums Wasser begünstigt die Wärmeaufnahme von kleinflächigen Wärmequellen, wie sie bei einer Grafikkarte oder einer CPU typisch sind. Die Wärmekapazität des Wassers ist viermal höher als die der Luft. Das bedeutet, dass für eine Temperaturdifferenz von 1 °C das 250-fache Volumen an Luft verwendet werden muss als Wasser. Das verschafft der Wasserkühlung einen deutlichen Vorteil im Vergleich zur Luftkühlung.

Da neben der CPU und der GPU auch weitere Komponenten, wie Northbridge, Southbridge, Festplatten, Netzteil oder Arbeitsspeicher gekühlt werden müssen, bedarf es hierfür meist eine zusätzliche Luftkühlung, weshalb in den meisten Fällen bei einer Wasserkühlung von einer Hybridkühlung (Bild 3) gesprochen wird. (eck)

<a href="http://www.inonet.com" target="_blank">www.inonet.com</a>

Manuel Deuter ist Produktmanager bei InoNet und betreut die strategische Ausrichtung des Automotive Portfolios. Janina Jonker ist Marketing Manager bei InoNet und unterstützt bei der strategischen Ausrichtung des Online- und Offline-Marketings. Jürgen Obergfell ist Gruppenleiter im Design Engineering bei InoNet und entwickelt als System Engineer Embedded Computersysteme.

Bild 2: Temperaturtest des wassergekühlten Systems unter Last bei steigender Temperatur