Experten, die sowohl etwas von Safety als auch von Security verstehen, sind absolute Mangelware. Das belegt auch eine Blitzumfrage, die ein Referent anlässlich seines Vortrags auf der Sicherheitskonferenz escar 2019 durchführte.

Experten, die sowohl etwas von Safety als auch von Security verstehen, sind absolute Mangelware. Das belegt auch eine Blitzumfrage, die ein Referent anlässlich seines Vortrags auf der Sicherheitskonferenz escar 2019 durchführte. Gerade einmal eine Handvoll der etwa 300 Teilnehmer sehen sich als Spezialisten, die auf beiden Gebieten gleichermaßen heimisch sind.

Gleichzeitig zeigten die Vorträge, dass es beim Thema Cybersecurity noch deutlichen Nachholbedarf gibt. Die Defizite dürften sich für die Automobilindustrie noch zu einem beachtlichen Problem auswachsen. Schließlich ist Funktionale Sicherheit nicht ohne Datensicherheit zu erreichen.

Das übliche Vorgehen, ein Fahrzeug nach erfolgreicher Safety-Zertifizierung nicht mehr anzutasten, ist ein Auslaufmodell. Zur Gewährleistung der Cybersecurity müssen Fahrzeugsysteme auch während des Betriebs nach- und aufgerüstet werden. Diese Maßnahmen können sich aber auf die Funktionale Sicherheit des betroffenen Fahrzeugs auswirken und erfordern daher eine Safety-Neubewertung.

Es ist also unumgänglich, dass sich Safety-Experten zukünftig auf eine iterative Arbeitsweise einstellen und sich deutlich stärker und auf Augenhöhe mit den Cybersecurity-Fachleuten austauschen. Dafür sollten OEMs und Zulieferer schnellstens die organisatorischen, technischen, personellen und mentalen Grundlagen schaffen, damit die Folgen der unvermeidlichen Cyber-Attacken für Hersteller und Betreiber minimal bleiben und vielversprechende Geschäftsmodelle nicht schon im Keim ersticken.

Franz Roßmann ist Korrespondent der HANSER automotive

Editorial Rossmann

Das ganze Team der HANSER automotive wünscht Ihnen eine friedvolle Weihnachtszeit und einen guten Start ins neue Jahr. Wir freuen uns darauf, Sie auch 2020 mit vielen interessanten Fachbeiträgen und spannenden Nachrichten bei Ihrer Arbeit zu unterstützen. Herzlichen Dank an die treue Leserschaft!

Ultra-Wideband-Vernetzungstechnik im Fahrzeug

Sehr präzise Lokalisierung und Distanzbestimmung bei einem Höchstmaß  an Cybersicherheit sind die wesentlichen Eigenschaften von UWB (Ultra Wideband). Für Autohersteller eröffnen sich damit neue Komfortfunktionen und verbesserter Diebstahlschutz, wie Volkswagen kürzlich in einem Demonstrationsfahrzeug gezeigt hat.

Sehr präzise Lokalisierung und Distanzbestimmung bei einem Höchstmaß an Cybersicherheit sind die wesentlichen Eigenschaften von UWB (Ultra Wideband). Für Autohersteller eröffnen sich damit neue Komfortfunktionen und verbesserter Diebstahlschutz.

Während Bluetooth Low Energy (BLE) und Wi-Fi heute schon von einer sehr breiten Marktakzeptanz profitieren, mangelt es ihnen aber an Genauigkeit bei der Standortbestimmung und sie bieten im Vergleich zu Ultra-Wideband (UWB) relativ wenig bis gar keine Sicherheit auf HF-Ebene für den geschützten Austausch von Positionsdaten. Anders bei UWB: Durch die Echtzeitgenauigkeit der Messungen kann ein UWB-fähiges System den genauen Standort eines Geräts mit sehr hoher Präzision erkennen und weiß, ob das Objekt stationär bleibt oder sich auf ein anderes zu- oder von diesem wegbewegt. Aufgrund der hohen Präzision der UWB-Standortbestimmung lässt sich der Reaktionsbereich dem Anwendungsszenario entsprechend definieren und Falschauslösungen oder Manipulationen werden vermieden.

Sobald ein mit einem UWB-Funkteil ausgestattetes Gerät wie z. B. ein Smartphone, ein Armband oder ein intelligenter Schlüssel in Reichweite eines anderen UWB-Geräts gelangt, beginnen die Geräte miteinander zu kommunizieren (Bild 1). Die Lokalisierung erfolgt mithilfe von Laufzeitmessungen (Time of Flight, ToF) zwischen den Geräten. Die ToF wird berechnet, indem die Roundtrip-Zeit von sogenannten Challenge/Response-Paketen gemessen wird. Abhängig von der Art der Anwendung berechnet entweder das mobile oder das feste UWB-Gerät den genauen Standort des Geräts. Soll das Gerät einen Indoor-Navigationsdienst ausführen, so muss sein relativer Standort zu den festen UWB-Ankerpunkten bekannt sein und seine Position auf der Karte des jeweiligen Areals berechnet werden.

UWB baut auf eine Kanalbandbreite von 500 MHz mit kurzen Impulsen von jeweils etwa 2 ns auf. Damit lässt sich eine Genauigkeit im Zentimeterbereich erreichen. Die Standortbestimmung erfolgt bei UWB adhoc, wodurch die Bewegungen des Mobilgeräts in Echtzeit sehr genau verfolgt werden können. UWB wartet mit einer Reichweite von bis zu 200 Metern auf. Im Gegensatz zu Schmalband-Funktechnologien bietet UWB durch die Nutzung einer hohen Bandbreite eine stabile Konnektivität mit wenig bis gar keinen Störungen und ermöglicht eine präzise Lokalisierung – selbst in stark frequentierten Umgebungen mit Mehrwegeffekten.

Aktuelle Lokalisierungstechnologien stützen sich in erster Linie auf die Signalstärke, um Entfernung und Standort zu bestimmen. Sie messen die Signalstärke eines Geräts und treffen die Annahme, dass ein starkes Signal bedeutet, dass das Gerät in der Nähe ist. Angreifer haben einen Weg gefunden, diese Systeme mithilfe einer sogenannten Relay Box auszutricksen. Bei dieser Art von Angriff werden die legitimen Funksignale, die zum Entriegeln einer Tür verwendet werden, abgefangen und verstärkt, sodass sich die Tür öffnen lässt, obwohl der Schlüssel gar nicht in der Nähe ist.

Was jedoch bei diesen Techniken fehlt, ist die genaue Berechnung der tatsächlichen physikalischen Entfernung, und genau das bringt UWB ins Spiel. Jeder Versuch, ein UWB-Signal mithilfe einer Relaisattacke abzufangen und zu verstärken, verzögert lediglich den Empfang des Bestätigungssignals des antwortenden Geräts, und dadurch wird offensichtlich, dass das antwortende Gerät tatsächlich weiter entfernt und nicht näher ist. Ein UWB-Signal, welches Angreifer erfolgreich abgreifen und verstärken können, führt nicht dazu, dass ein mit UWB ausgestattetes Schloss sich öffnet. Darüber hinaus bietet die Erweiterung von IEEE 802.15.4z einen Schutz auf PHY-Ebene gegen alle bekannten Angriffe auf ältere UWB-Funkstrecken.

 In einem Volkswagen Concept Car demonstrierten Volkswagen und NXP Semiconductors das Potenzial von UWB für mehr Sicherheit und Komfort der Fahrzeuginsassen. Lars Reger, Chief Technology Officer bei NXP Semiconductors, und Maik Rohde, Leiter Karosserie, Elektronik, Komponenten bei Volkswagen, erläuterten ihre enge Zusammenarbeit in Forschung und Entwicklung vor dem Hintergrund der breiten, branchenübergreifenden Initiative FiRA, die sich gebildet hat, um die Fähigkeiten von UWB optimal auszuschöpfen. Neue Anwendungen sind zum Beispiel die Erkennung von Lebewesen im Fahrzeug, automatisiertes Valet-Parking, eine automatische Aktivierung der Anhängerkupplung (Bild 2) oder einen mühelosen Zugang zu Parkplätzen und ihre automatische Bezahlung bei der Durchfahrt. Eine weitere interessante Einsatzmöglichkeit ist die Erkennung des Bewegungsmusters von Personen für den personalisierten, anlernbaren Zugang zum Auto: So nutzt der der vorgestellte Volkswagen UWB Autoschlüssel neben der Sensortechnologie auch künstliche Intelligenz, um die Bewegungsmuster und Gesten von Nutzern zu erlernen (Bild 3).

Verschiedene Konnektivitätslösungen wie Bluetooth oder Wi-Fi sind derzeit im Einsatz, und jede hat ihre eigenen Stärken in bestimmten Einsatzszenarien. Bei der genauen Positionsbestimmung zeichnet sich UWB durch die Fähigkeit aus, Geräte und Objekte bis auf weniger als 10 cm genau zu lokalisieren. Darüber hinaus bietet es durch seine Immunität gegen Hochfrequenzstörungen eine sehr robuste Technologieoption.

<a href="http://www.firaconsortium.org">www.firaconsortium.org</a>

<a href="http://www.nxp.com/applications/solutions/ultra-wideband">www.nxp.com/applications/solutions/ultra-wideband</a>:UWB

Bild 1: Die Lokalisierung erfolgt mithilfe von Laufzeitmessungen (Time of Flight, ToF) zwischen den UWB-Geräten.

Bild 2: Anwendungsszenario Automatisierte Anhängerkupplung: Auto und Anhänger verbinden sich automatisiert.

Bild 3: Mit einer Kombination aus präziser Sensorik und künstlicher Intelligenz können UWB-Systeme personalisierte Gesten erlernen, um die Fahrzeugtüren schnell und einfach zu öffnen.

UWB hilft, Autodiebstähle zu verhindern, die darauf basieren, die Kommunikation zwischen Schlüssel und Fahrzeug abzuhören.

16:9

Hauptartikel

Klaus Oertel ist Chefredakteur der  HANSER automotive.

Die ASSA ABLOY Gruppe, Bosch, HID Global, NXP Semiconductors und Samsung Electronics arbeiten beim Ausbau und der Verbreitung des Ultra-Wideband (UWB)-Ökosystems zusammen und haben zu diesem Zweck das FiRa-Konsortium gegründet. Der Name FiRa steht für „Fine Ranging“ und hebt die Eigenschaften der UWB-Technologie hervor, wie die Genauigkeit bei der Entfernungsmessung oder bei der Bestimmung der relativen Position eines Gerätes oder Objekts zu einem anderen. Ziel des Zusammenschlusses ist es, einen Standard für UWB zu definieren. Als erste Mitglieder traten die Sony Imaging Products & Solutions Inc., LitePoint und die Telecommunications Technology Association (TTA) der neu gegründeten Organisation bei.

»Wir sehen Riesenpotenzial in UWB. Eine mögliche Anwendung,  die mich persönlich sehr beeindruckt:  UWB könnte den Schlüsselbund ersetzen für Zuhause, im Büro und unterwegs.

Lars Reger, Chief Technology Officer bei NXP Semiconductors.

Diagnose als Teil eines E/E-Entwicklungsprozesses

Diagnosedaten effizient  erfassen, spezifizieren und  in Software umsetzen

In gängigen Entwicklungsprozessen werden Diagnosebeschreibungen und deren Software-Umsetzung nicht nur durch unterschiedliche Personen und Rollen in Unternehmen bearbeitet, sondern auch durch verschiedene Autorenwerkzeuge unterstützt. Die Konsistenz zwischen beidem muss manuell gewährleistet werden und ist damit aufwendig und fehleranfällig. Durch einen modellgetriebenen Entwicklungsansatz wird es möglich, die Diagnose gemeinsam mit dem gesamten E/E-System eines Fahrzeugs zu beschreiben.

In gängigen Entwicklungsprozessen werden Diagnosebeschreibungen und deren Software-Umsetzung nicht nur durch unterschiedliche Personen und Rollen in Unternehmen bearbeitet, sondern auch durch verschiedene Autorenwerkzeuge unterstützt.

In Projekten rund um die Fahrzeugdiagnose lässt sich regelmäßig beobachten, dass die Diagnosespezifikation und die Software-Entwicklung weitgehend entkoppelt sind. Die Zuständigkeiten für die Diagnosespezifikation und Applikationssoftware-Entwicklung sind heute oft auf verschiedene Personen, Rollen und Abteilungen verteilt. Die Mitarbeiter erfüllen die notwendigen Aufgaben mit unterschiedlichen Werkzeugen und verwalten die Arbeitsergebnisse isoliert voneinander, es besteht keine gemeinsame Datenbasis. Notwendige Abstimmungen erfolgen oft nur ad hoc und ohne einen standardisierten Datenaustausch. Der Informationsaustausch zwischen den verschiedenen Bereichen erfolgt damit informell über E-Mails oder den Austausch von Dokumenten. Die eigentlichen Daten müssen manuell in die verschiedenen Werkzeuge eingepflegt werden.

Diese Beobachtungen überraschen wenig, wenn man bedenkt, wie sehr die Aufgabenfelder der Diagnose- und der Software-Entwicklung in der Praxis auseinanderfallen. Ein erfolgreiches Diagnosedesign muss den gesamten Systemlebenszyklus berücksichtigen. Außerhalb der eigentlichen Systementwicklung muss die Diagnoselösung auch die Anwendungsfälle der Fahrzeugproduktion und des Kundendienstes unterstützen. Experten aus diesen Bereichen betrachten die Fahrzeugdiagnose aus unterschiedlichen Blickwinkeln. Für Produktions- und Kundendienstexperten liegt ein wesentlicher Fokus auf Protokolldetails für die Parametrierung der unterschiedlichen Tester in Produktion und Kundendienst. Für Systementwickler steht hingegen die innere Ausgestaltung und Funktionsweise der Fahrzeug-Software im Mittelpunkt des Interesses. Beides ist für die Arbeit der jeweils anderen Seite weitestgehend irrelevant.

Abhängigkeiten zwischen der Diagnose und Software bestehen aber! Es können Inkonsistenzen entstehen, wenn beispielsweise die Datentypdetails der Diagnosespezifikation nicht zur umgesetzten Applikationssoftware passen. Diese werden bestenfalls bereits bei der Konfiguration der in AUTOSAR definierten Basissoftware-Komponenten wie Diagnostic Event Manager (DEM) und Diagnostic Communication Manager (DCM) erkannt, im schlechteren Fall aber erst bei der Inbetriebnahme des Steuergeräts oder sogar erst im Feld. Hier greift die alte Regel: Je später ein Fehler erkannt wird, desto teurer und aufwendiger ist seine Behebung. Wenn es gelingt, die Beschreibung der Applikationssoftware zusammen mit den Diagnoseinhalten in einem Werkzeug zu erstellen, dann können die genannten Inkonsistenzen und die damit verbundenen Folgeprobleme vermieden werden. Eine effiziente Methode zum Meistern der beschriebenen Herausforderungen bietet die enge Verzahnung zweier Werkzeuge aus dem Produktportfolio von Vector: das modell- und datenbankbasierte Werkzeug PREEvision lässt sich für die Diagnose- und Software-Entwicklung einsetzen und tauscht alle relevanten Daten mit CANdelaStudio aus, dem Vector-Werkzeug zum Erstellen und Bearbeiten formaler Diagnosespezifikationen.

In der Elektrik-/Elektronikentwicklung (E/E) vieler Automobilhersteller werden die Vorteile des modellbasierten Werkzeugs PREEvision immer intensiver genutzt. Ein übergreifendes E/E-Datenmodell ermöglicht Herstellern, die fachliche Durchgängigkeit zwischen Systemanforderungen, Architektur- und Designebene für Software, Netzwerk und Komponenten der Hardware sowie Leitungssatz und Geometrie zu gewährleisten. Sie können das gesamte Beziehungswissen zwischen den fachlichen Ebenen und Elementen in diesem gemeinsamen Datenmodell beschreiben (Bild 1). Betrifft eine fachliche Änderung mehrere Ebenen, so wird die Änderung für alle betroffenen Entwickler unmittelbar ersichtlich und der einzelne Anwender wird automatisiert darauf hingewiesen. Dadurch werden mögliche Konflikte frühzeitig erkannt und ausgeräumt. Der Anwender kann zeitliche Abfolgen und Zusammenhänge durch die Nutzung von Versionierungsmechanismen zuverlässig nachverfolgen. Darüber hinaus steht eine umfangreiche Unterstützung für das Management von Varianten zur Verfügung. Das ermöglicht dem Anwender, die Gleichteile aber auch Unterschiede von verschiedenen Varianten in einer gemeinsamen Datenbasis zu beschreiben. In der Modellansicht oder für den Datenexport können dann einzelne Varianten aktiviert werden.

Abhängigkeiten zwischen Diagnose- und Softwaremodellierung

Welche Abhängigkeiten ergeben sich überhaupt zwischen der Steuergeräte-Software und der Diagnosebeschreibung? In vielen Autorenwerkzeugen für die Diagnose werden Diagnosefunktionen eines Steuergeräts aus dem Blickwinkel eines Diagnosetesters beschrieben. Der Fokus einer solchen Beschreibung liegt dabei auf den Diagnosefunktionen, die ein externes Testwerkzeug über die Diagnoseschnittstelle des Fahrzeugs nutzen kann. Dazu gehören zum Beispiel Informationen darüber, welche Diagnostic Trouble Codes (DTC) ein Tester aus dem Fehlerspeicher eines Steuergeräts auslesen kann oder welche Data Identifiers (DID) ein Steuergerät zum Lesen und Schreiben von Daten zur Verfügung stellt. Darüber hinaus werden aber auch Detailinformationen beschrieben, die für die Anzeige im Testgerät von großer Bedeutung sind, zum Beispiel Datentypen, Umrechnungen und physikalische Einheiten der einzelnen Datenobjekte von DIDs und Routinen.

In der Applikationssoftware muss es nun eine Realisierung durch einen Diagnoseport, also die konkrete Ausprägung eines Softwareports, geben. Für ein Datenobjekt eines DIDs ist das ein einzelnes Datenelement eines Diagnoseports. Auch dieses Datenelement wird konkretisiert durch einen Datentyp mit Umrechnung und physikalischer Einheit. Allerdings werden in der Software diese Details durch die AUTOSAR-konforme Modellierung auf mehrere Objekte verteilt, wohingegen sie in vielen gängigen Diagnosebeschreibungsformaten durch ein einzelnes Objekt beschrieben werden. Trotz der unterschiedlichen Granularität und Beschreibungsarten müssen die enthaltenen Informationen aber konsistent sein. Wenn die Diagnose gemeinsam mit der Software in einem Werkzeug definiert wird, ist es möglich Software und Diagnose redundanzfrei zu beschreiben. Die Datentypen werden dann wie gehabt in der Software beschrieben. Die Diagnosebeschreibung referenziert diese Datentypen, verwendet also dieselben Objekte wieder. Alternativ ist es auch möglich, zuerst die Diagnoseinhalte zu beschrieben und die gemeinsamen Detailinformationen für die Software-Umsetzung zu nutzen.

Neben der Notwendigkeit, gemeinsame Datenbeschreibungen konsistent zu halten, ergeben sich aus den Diagnosespezifikationen auch Anforderungen an die Applikationssoftware selbst. Definiert die Diagnosespezifikation beispielsweise eine Routine, so muss es in der Applikation eine Softwarekomponente geben, die diese Routine implementiert. Definiert die Diagnosespezifikation einen DTC, so muss die Applikation eine Monitorfunktionalität aufweisen, die das Auftreten des damit verbundenen Fehlerereignisses feststellen kann. AUTOSAR stellt dabei spezifische, strukturelle Anforderungen an die realisierenden Softwarekomponenten. Ein I/O-Control erfordert beispielsweise die Abbildung der kontrollierbaren Daten durch einen Record-Typ. Eine Routine wiederum erfordert ein Client/Server-Interface mit Start-, Stop- und RequestResult-Operations. Auch hier hilft es, die Strukturen nur einmal zu definieren und gleichermaßen für die Software und Diagnose zu nutzen.

Konkrete Umsetzung in einer Werkzeugkette

Um den beschriebenen Problemen zu begegnen, wurde PREEvision um eine eigene Modellierungsebene für die Diagnose erweitert. Diese Diagnoseebene ermöglicht es, Diagnoseobjekte systemweit zu beschreiben und an die Applikationssoftware anzubinden. Der Anwender kann hier DIDs mit ihren Datenobjekten, I/O-Controls und Routinen definieren. Für diese Objekte können auch einige ergänzende Eigenschaften, wie Identifier oder die verwendeten Diagnosedienste, beschrieben werden. Des Weiteren können auch relevante Teile des Eventhandlings gemäß AUTOSAR modelliert werden. Dazu gehören Objekte wie DTCs, DiagnosticEvents und DiagnosticOperationCycles, um nur einige zu nennen. Für die Konkretisierung der Diagnosebeschreibung sind nach wie vor Autorenwerkzeuge wie CANdelaStudio unerlässlich.

Eine Toolkette aus PREEvision und CANdelaStudio bietet deswegen einen bidirektionalen Datenaustausch (Bild 2) und unterstützt verschiedene Zusammenarbeitsmodelle. Auch ein Datenrückfluss nach PREEvision ist möglich. Dadurch kann der Anwender einfach Bestandsdaten aus der Diagnose übernehmen und als Startpunkt für seine Software-Realisierung nutzen. Für den Datenaustausch wurde ein dateibasierter Ansatz gewählt, was einen Austausch über Organisationsgrenzen hinweg ermöglicht. Die Import- und Exportmöglichkeiten in CANdelaStudio erschließen ein breites Spektrum in der Zusammenarbeit mit Zulieferern und in der Ankopplung an verschiedene Toolketten. Die Austauschdatei enthält sowohl die eigentlichen Diagnoseobjekte, aber auch die zugehörigen Details, die aus der referenzierten Software abgeleitet sind.

Obwohl die Modellierung der Diagnoseobjekte systemweit durchgeführt wird, finden sich in der Austauschdatei nur die Informationen für ein einzelnes Steuergerät. Abhängig von der Software- und Hardwaremodellierung wird ermittelt, welche Diagnoseports auf einem Steuergerät überhaupt zur Verfügung stehen. Diese Information ist die Basis für die Zusammenstellung der Diagnoseobjekte für den Datenaustausch (Bild 3). Es gibt noch einen weiteren Aspekt, der für den nachgelagerten Prozess hilfreich ist: Die Information über die Zuweisung des Diagnoseobjekts zum Diagnoseport in der Applikationssoftware wird im Datenaustausch mittels einer Referenz transportiert. In einem Konfigurationswerkzeug für Basissoftware muss der Integrator nun nicht die Verbindungen zwischen den Ports der Basissoftware und denen der Applikationssoftware ziehen. Die Verbindungen können anhand der Referenzen automatisch ermittelt werden, womit die Fehleranfälligkeit bei gleichzeitiger Zeitersparnis erheblich sinkt.

Diagnosekonformität in der Software sicherstellen

Im AUTOSAR-Standard ist festgelegt, wie Softwarekomponenten für die Diagnose zu beschreiben sind. Wird beispielsweise ein Diagnoseport erzeugt, muss dieser AUTOSAR-konform modelliert sein. Allerdings ist der AUTOSAR-Standard umfangreich, komplex und nicht immer einfach zu verinnerlichen. Häufiges Nachschlagen in den Regelwerken ist gängige Praxis und das Umsetzen des Standards zeitaufwendig und anfällig für Fehler. Dank Toolunterstützung lassen sich diese Daten effizienter und in deutlich höherer Qualität erstellen: Erzeugt man einen Diagnoseport direkt aus dem eigentlichen Diagnoseobjekt, wird dieser Port toolgestützt korrekt und AUTOSAR-konform erzeugt. Führt der Anwender nachträglich Änderungen am Diagnoseport durch, die zu einer Abweichung vom Standard führen, wird er vom Werkzeug direkt darauf hingewiesen.

In PREEvision lassen sich in einem Modell zusätzlich zu Software, Hardware und Kommunikation auch Diagnoseinformationen für ein E/E-System beschreiben. Der Anwender verwaltet alle Daten zentral, auch die Diagnose wird systemweit betrachtet. Aus der Beschreibung von Software-, Hardware- und Kommunikation ergibt sich die Systembeschreibung nach AUTOSAR (Bild 4). Aus demselben Modell werden die Diagnoseinhalte für CANdelaStudio exportiert und dort in der Diagnosespezifikation weiter verfeinert und ergänzt. Ein manueller Abgleich der Diagnosedaten mit der Software ist nicht mehr nötig: In CANdelaStudio durchgeführte Änderungen werden via Datenaustausch in PREEvision zurückgeschrieben, die Software aktualisiert sich damit automatisch. In CANdelaStudio entsteht der Diagnostic Extract (DEXT) und die ODX-Beschreibung. Zum Konfigurieren der AUTOSAR-Basissoftware werden schließlich Systembeschreibung und DEXT in Werkzeuge wie Vectors DaVinci Configurator eingelesen. Hier ergeben sich mehrere Vorteile:

<ul><li>Die Diagnoseobjekte müssen nicht manuell mit den Diagnoseports zusammengeführt werden. Über die gesamte Toolkette übertragene Referenzen ermöglichen eine automatische Zuordnung.</li><li> Die Diagnoseports sind bereits AUTOSAR-konform modelliert und benötigen keine Nacharbeit.</li><li> Die Eigenschaften der Diagnoseports passen zu den Eigenschaften der Diagnoseobjekte, es müssen keine Konflikte bezüglich Datentypen oder Software-Strukturen aufgelöst werden.</li></ul>

Über den gesamten Designprozess ergibt sich damit ein geringerer Abstimmungsaufwand, weniger manueller Aufwand und die Reduktion von Fehlerquellen. Die Vorteile beschränken sich aber natürlich nicht auf die Verknüpfung der Diagnose mit der Applikationssoftware: So ließen sich künftig auch aus anderen Modellebenen in PREEvision automatisiert Diagnosedaten oder -abläufe ableiten, wie beispielsweise Prüfabläufe für einen Kabelbruch direkt aus der Beschreibung des Kabelbaums. Der modellbasierte Ansatz von PREEvision bietet hier erhebliches Potenzial für die Zukunft, um Arbeitsaufwände und Fehlerquellen noch weiter zu verringern. (oe)

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

Bild 1: Die Multiuser-Umgebung von PREEvision erlaubt einen systemweiten Blick, wohingegen die nachgelagerte Toolkette jeweils den Fokus auf ein einzelnes Steuergerät legt.

Bild 3: Die Zusammenhänge zwischen Software-, Hardware- und Diagnose-Design und wie daraus die Informationen für den Diagnoseautausch abgeleitet werden  (M = Mapping).

Bild 4: Übersicht der beschriebenen Vector Toolkette für Diagnose (M = Mapping). 

Armin Cont ist Produktmanager CANdelaStudio bei Vector Informatik.

Claudia Gettkandt ist Produktmanagerin PREEvision bei Vector Informatik. Armin Cont ist Produktmanager CANdelaStudio bei Vector Informatik.

»Bei Lithium-Ionen-Batterien gibt es noch viel Potenzial!«

Auf Basis existierender und selbst entwickelter Techniken hat Dr. Akira Yoshino 1985 die Lithium-Ionen-Batterie zur Marktreife geführt. Im Gespräch mit HANSER automotive erläutert der diesjährige Chemienobelpreisträger, der heute bei Asahi Kasei das Lithium Ion Battery Technology and Evaluation Center leitet und Honorary Fellow des Unternehmens ist, welches Potenzial noch in der Batterietechnik schlummert und wann alternative Batterietechniken in Batterieelektrischen Fahrzeugen (BEVs) Einzug halten werden.

 Im Gespräch mit HANSER automotive erläutert der Chemienobelpreisträger Dr. Akira Yoshino, welches Potenzial in der Batterietechnik schlummert und wann alternative Batterietechniken in BEVs Einzug halten werden.

 In welchen Bereichen bieten für den Einsatz in BEVs gedachte Lithium-Batterien (LIB) noch Optimierungspotenziale und was muss getan werden, um diese nutzen zu können?

Dr. Akira Yoshino: Ich bin der Meinung, dass es noch viel Potenzial gibt. Das gilt vor allem in Bezug auf die positive Elektrode und die Verwendung einer ternären Nickel-Kobalt-Mangan-Materialmischung wie NCM-811. Zusätzlich bietet bei der negativen Elektrode der Einsatz einer Graphit-Silizium-Anode mit einem Siliziumgehalt von etwa fünf Prozent weiteres Potenzial. Darüber hinaus birgt die Nutzung eines Elektrolyten mit hoher Ionenleitfähigkeit zusätzliche Entwicklungsmöglichkeiten.

Wie hoch schätzen Sie jeweils das verbleibende Optimierungspotenzial in Hinblick auf Größen wie Ladezyklen und Kapazität, durch verbesserte Katoden-/Anoden-Materialen, Separatoren und Elektrolyt-Zusammensetzungen ein?

Das Verbesserungspotenzial durch den Einsatz verschiedener Materialien habe ich bereits erwähnt. Ich bin auch davon überzeugt, dass eine Optimierung der Ladezyklen durch gezielte Weiterentwicklung des Elektrolyten möglich ist.

Wie beurteilen Sie die CO2-Bilanz aktueller LIB-Module? An welcher Stelle muss/kann angesetzt werden, um die Bilanz spürbar zu verbessern? Können der Einsatz von Strom aus erneuerbaren Quellen bei der Zellenproduktion sowie das Recycling der Batterien dabei einen wichtigen Beitrag leisten?

Sicherlich kann die CO2-Bilanz im Produktionsprozess durch die Nutzung erneuerbarer Energiequellen und Recycling verbessert werden. Meiner Meinung nach würde jedoch die Mehrfachnutzung von Lithium-Ionen-Batterien den größten Beitrag leisten. Beispielsweise die Verwendung einer LIB, die zunächst in einem Elektrofahrzeug montiert war und danach in einem Energiespeichersystem zum Einsatz kommt.

Wie gut können die Auswirkungen der unterschiedlichen Elektrolytzusammensetzungen in Hinblick auf die Lebensdauer und den Alterungsprozess sowie auf das Crash-Verhalten effizient bewertet oder abgeschätzt werden?

Es kann mit Sicherheit gesagt werden, dass die Verbesserung des Elektrolyten zur Lebensdauer, zum Alterungsprozess und zum Crash-Verhalten der LIB beitragen kann. Es ist jedoch sehr schwer zu beurteilen, in welchem Maße.

Müssen Feuerwehrleute und Mitarbeiter von Werkstätten zukünftig unterschiedliche Sicherheitshinweise je nach verwendeter Elektrolytzusammensetzung, Katoden-/Anoden-Materialen und Separatoren berücksichtigen?

Solange wir LIBs mit einem flüssigen Elektrolyten haben, ändern sich die Sicherheitshinweise nicht. Bei einem Festelektrolyten besteht jedoch die Möglichkeit, dass die Handhabung der LIB sicherer wird.

Wird die Verfügbarkeit und Preisentwicklung von Rohstoffen wie Lithium und Kobalt die Verbreitung der eMobility gefährden oder ausbremsen?

Was die Nutzung für die E-Mobilität betrifft, so ist Recycling eine Voraussetzung. Daher sehe ich hier keine grundlegenden Risiken. Spekulative Preisschwankungen sind jedoch ein Grund zur Sorge.

Ist die Reichweite der entscheidende Faktor für den Erfolg der BEVs?

Die Reichweite der gängigen Elektrofahrzeuge liegt heute bei rund 400 Kilometern. Das wird bis 2025 so bleiben. Nach 2025 kommt es zu einem Wandel, insbesondere in enger Verbindung mit den Megatrends im Rahmen des Konzepts Connected, Autonomous, Shared, Electric. Dies wird zu einer neuen Automobilgesellschaft beitragen. Dann spielt die Reichweite keine Rolle mehr.

Wie beurteilen Sie Europas Einstieg in die Zellfertigung?

Wenn man weiterhin Autos in Europa produzieren will, ist es nur logisch, LIBs in Europa herzustellen.

Es ist viel von Feststoffbatterien zu lesen, aber den Ankündigungen ist bisher wenig Konkretes gefolgt. Wie schätzen Sie den Stand der Forschung ein und wann können wir mit kommerziell verfügbaren Lösungen rechnen?

Das japanische Unternehmen TDK vermarktet die Festkörperbatterie bereits unter dem Markennamen „CeraCharge“. Ich denke, dass es in Kürze weitere Pressemitteilungen zur Kommerzialisierung durch andere japanische Unternehmen wie Kyocera oder Murata Manufacturing geben wird. In all diesen Fällen sprechen wir aber von kleinen Festkörperbatterien, vor allem für den Einsatz in Sensoren für das Internet of Things. Die Frage ist, wann große Festkörperbatterien für den Einsatz in BEVs kommerziell vermarktet werden. Dies wird noch etwas Zeit in Anspruch nehmen, vielleicht etwa zehn Jahre. Asahi Kasei forscht auch auf diesem Gebiet.

Das Gespräch führte Franz Joachim Roßmann, Korrespondent der HANSER automotive.

Der Erfindergeist von Chemienobelpreisträger Dr. Yoshino hat es möglich gemacht: Batterieelektrische Autos wie das Konzeptfahrzeug AKXY.

Honorary Fellow Akira Yoshino auf der Pressekonferenz des japanischen Technologiekonzerns Asahi Kasei zur Preisverleihung des Nobelpreises für Chemie 2019.

Akira Yoshino hatte 1985 die Idee, das hochreaktive Lithium durch Lithium-Ionen zu ersetzen und schuf so die Grundlage für die heute noch verwendeten Lithium-Ionen-Batterien.  © Asahi Kasei

Moderne Sicherheitssoftwareplattform für hochkomplexe Automotive-Anwendungen

Traditionelle Entwicklungsprozesse der Automobilindustrie stoßen bei hochkomplexen Anwendungen wie Fahrerassistenzsysteme und Systeme für das Autonome Fahren an ihre Grenzen. An die IT-Welt angelehnte neue Entwicklungsprozesse und eine damit eng gekoppelte Softwareplattform, die eingebettet auf dem Steuergerät läuft, können helfen, diese Grenzen zu überwinden. Die Softwareplattform sorgt dabei dafür, dass neuentwickelte Fahrassistenzfunktionen schnell und sicher auf dem Steuergerät ausgeführt werden können.

Die MotionWise-Sicherheitssoftwareplattform, die eingebettet auf dem Steuergerät läuft, sorgt dafür, dass neuentwickelte Fahrassistenzfunktionen schnell und sicher auf dem Steuergerät ausgeführt werden können.

Das Angebot an Fahrassistenzfunktionen ist für immer mehr Verbraucher das wichtigste Ausstattungsmerkmal. Etwa 43 Prozent der Kunden im Premiumsegment orientieren sich laut einer aktuellen Studie beim Kauf eines Neuwagens an der Ausstattung mit Assistenzsystemen, wobei sie auch nicht vor einem Markenwechsel zurückschrecken. In China liegt der Prozentsatz laut der Studie sogar bei 70 Prozent der Autokäufer. Auch bei der Bewertung der Fahrzeugsicherheit spielen Fahrerassistenzsysteme eine zentrale Rolle. Ohne sie lassen sich zukünftig keine hohen NCAP-Ratings erreichen. Die effiziente Entwicklung von Fahrassistenzfunktionen und in weiterer Folge die Entwicklung von (teil-)automatisierten Fahrfunktionen entscheidet daher zunehmend über den wirtschaftlichen Erfolg eines Fahrzeugherstellers.

Limitierender Faktor:  Die steigende Komplexität der Systeme

Die hohe Komplexität dieser Funktionen, die eingeschränkte Wiederverwendbarkeit der Software und der Validierungsartefakte sowie der hohe Aufwand für die Gewährleistung der Funktionalen Sicherheit stellen traditionelle Softwareentwicklungsprozesse allerdings vor kaum überwindbare Hürden. Fortschrittliche Chips sind maßgeblich für das Hochschnellen der Funktionskomplexität verantwortlich. Allen voran sind hier Hardwarebeschleuniger für Lösungen für KI-Anwendungen wie neuronale Netzwerke für maschinelles Lernen zu nennen. Da bei Automotive-Anwendungen die Mehrzahl der Funktionen sicherheitsrelevanten Charakter hat, ist die Validierung der Software ein wesentlicher Kostentreiber in der Entwicklung. Neuartige Entwicklungsprozesse und maßgeschneiderte Softwareplattformen helfen, den Entwicklungsaufwand und damit die Kosten spürbar zu reduzieren. Sie sorgen zum einen dafür, dass sich einmal entwickelte Softwarefunktionen fortschreiben und verbessern lassen. Dabei muss sichergestellt sein, dass sich die Software der Bestandsfahrzeuge aktualisieren lässt, ohne einen kompletten Validierungsprozess auszulösen. Zum anderen stellen sie sicher, dass die Softwarefunktionen wiederverwendet werden können – zum Beispiel auf anderen Fahrzeugtypen mit anderen Rechnerarchitekturen.

Der Hebel zur Bewältigung: Entkopplung von Hard- und Software

Eine Wiederverwendung der Software setzt voraus, dass die Software hardwareunabhängig entwickelt wurde. Das setzt eine ausreichende Abstraktion der Hardware voraus. Dann kann die Software von den Leistungssteigerungen zukünftiger Hardwaregenerationen profitieren oder bei Bedarf schon während der Entwicklung – auch zu einem späten Zeitpunkt – auf eine leistungsfähigere Hardware, z. B. eine System-on-Chip-Lösung, umgestiegen werden.

Um Softwarefunktionen mit einer derart hohen Komplexität funktional sicher zu entwickeln, ist aber nicht nur die Entkopplung der Software von der Hardware zielführend, sondern es müssen die Funktionen selbst ebenfalls gekapselt werden. Die Interaktion zwischen Funktionen muss durch klar definierte Schnittstellen festgelegt sein, um ungewollte Wechselwirkungen zwischen Softwarefunktionen zu vermeiden. Diese Kapselung und eine kontrollierte Interaktion hat sich bereits in anderen sicherheitsrelevanten Anwendungen, wie in der zivilen Luftfahrt oder beim Cloud-Computing, als geeignetes Mittel zur Beherrschung der Komplexität bewährt. Allerdings fehlt aus der IT und dem Cloud-Computing kommenden Ansätzen der Aspekt, dass Echtzeitverhalten und Funktionale Sicherheit garantiert werden müssen.

Die Lösung: Die MotionWise Sicherheitssoftwareplattform

Die Embedded-Softwareplattform MotionWise von TTTech Auto ermöglicht einen Entwicklungsprozess, ohne die beschriebenen Probleme. Die Plattform ist bereits Bestandteil von Level-2+-Fahrassistenzsystemen in mehr als einer Million ausgelieferter Fahrzeuge. Dabei hat sich MotionWise als Sicherheitssoftwareplattform bewährt, mit der sich hochkomplexe Softwarefunktionen unterschiedlichster Herkunft interferenzfrei integrieren und dabei hohe Anforderungen in puncto Funktionaler Sicherheit und Echtzeitverhalten erfüllen lassen. MotionWise ist dabei so skalierbar, dass sich die Plattform auch bei zukünftigen Systemen mit höheren Automatisierungs-Leveln nutzen lässt.

MotionWise ist eine echtzeitfähige Sicherheitssoftwareplattform, die auf einem oder mehreren komplexen SoC-Mikrocontrollern (System-on-Chip) und Mikroprozessoren eine sichere Ablaufumgebung zur Verfügung stellt. Dabei unterstützt die Plattform die in der Automobilindustrie gängigen SoCs. Die Software stellt spezielle Synchronisations- und Scheduling-Mechanismen zur Verfügung. Diese Mechanismen ermöglichen die zeitlich enge Kopplung einer Vielzahl an Funktionen, die auch auf unterschiedlichen Prozessoren sowie unterschiedlichen Betriebssystemen ausgeführt werden können. Damit können End-to-End-Wirkketten, die mehrere (verteilte) Funktionen umfassen, effizient mit garantierter Ausführungszeit der gesamten Wirkkette umgesetzt werden. Eine Wirkkette könnte zum Beispiel folgende Sequenz umfassen: das Einlesen und die Vorverarbeitung von Sensorwerten, die Sensordatenfusion, die Trajektorienplanung, gefolgt von der Berechnung der Stellgrößen und schlussendlich von der Ansteuerung von Aktuatoren. MotionWise unterstützt dabei sowohl AUTOSAR- als auch POSIX-kompatible Betriebssysteme. Funktionsentwickler können als Hardwareabstraktion und zur Funktionskapselung die weitverbreiteten AUTOSAR- sowie ara::com-Schnittstellen verwenden. MotionWise 2.0 unterstützt darüber hinaus auch servicebasierte Kommunikationsmodelle.

Typischer Anwendungsfall: Steuergeräte mit Multi-Core, Multi-OS-Konstellation

Ein typischer Anwendungsfall von MotionWise ist ein Steuergerät, das mehrere Multi-Core-Prozessoren mit unterschiedlichen Betriebssystemen einschließt, wobei sowohl die Prozessoren als auch die Betriebssysteme unterschiedliche Automotive Safety Integrity Level (ASIL) haben können. Dieser Anwendungsfall ist für Level 2+-Systeme typisch, da hier ein Mix aus Safety-Mikrocontrollern, spezialisierten Prozessoren für die Bilderarbeitung mit DNN-Beschleunigern und leistungsfähigen Multi-Core-CPUs im Zusammenspiel verwendet werden.

In einem solchen Anwendungsfall kann MotionWise jeweils als Instanz auf den Betriebssystemen integriert werden und damit die Ausführung der einzelnen Softwarekomponenten zeitlich koordinieren und kontrollieren, sowie den Informationsaustausch zwischen den Softwarekomponenten steuern und überwachen. Für die Kommunikation zwischen Prozessoren unterstützt MotionWise Ethernet- sowie PCIe- Verbindungen und kann spezielle deterministische Kommunikationsmechanismen, die diese Verbindungen anbieten, auch nutzen (zum Beispiel IEEE 802.1 Time-Sensitive Networking).

Schlüssel zum Erfolg: Vorabplanung der Rechenzeitzuteilung

Zur Synchronisation der individuellen Instanzen der MotionWise-Sicherheitssoftwareplattform auf den unterschiedlichen Prozessoren kommen standardisierte Netzwerkprotokolle zum Einsatz. Die enge zeitliche Kopplung wird schlussendlich durch eine intelligente Planung der Ausführungszeitpunkte der Funktionen sowie deren Informationsaustausch bewerkstelligt. Diese intelligente Planung ist Teil des Entwicklungsprozesses und erzeugt für kritische Funktionen bereits während der Entwicklung der Funktionen einen zeitlichen Ausführungsplan und auch einen optimierten Softwarecode für die Kommunikation. Zur Laufzeit der Funktionen im Fahrzeug werden daher keine dynamischen Entscheidungen getroffen, sondern die Funktionen einfach entsprechend dem bestehenden Plan ausgeführt. Funktionen, die nicht zeitkritisch sind, können auch ohne Planung mit niedrigerer Priorität ausgeführt werden (somit ist sichergestellt, dass die kritischen Funktionen rechtzeitig die notwendige Rechenleistung bekommen).

Der Ausführungsplan reduziert damit den Rechenaufwand für das Gesamtsystem und die Komplexität, was sowohl den Validierungsaufwand verringert als auch positiv auf den funktionalen Sicherheitsnachweis wirkt. Darüberhinausgehend ermöglicht dieser Ansatz eine beschleunigte Funktionsentwicklung: Da der Ausführungsplan das zeitliche Verhalten der Funktionen spezifiziert, können bereits frühzeitig in der Entwicklung Integrationstests durchgeführt werden. Dabei können Funktionen auf unterschiedlichen Entwicklungsständen miteinander integriert, evaluiert und getestet werden, zum Beispiel eine Funktion als Modell auf einem Entwicklungscomputer gemeinsam mit einer bereits integrierten Funktion auf dem Steuergerät. Das MotionWise-SDK stellt die entsprechenden Services bereit.

Die MotionWise-Sicherheitssoftwareplattform wird kontinuierlich weiterentwickelt und kommt mittlerweile schon bei einer Reihe von Serienentwicklungsprojekten unterschiedlicher Fahrzeughersteller zum Einsatz. Damit einher geht die laufende Erweiterung der Betriebssystem- und Prozessorunterstützung. Gleichzeitig wird die intelligente Planung immer effizienter und beherrscht immer größere und komplexere Systeme. Außerdem wird zurzeit die Anwendung von MotionWise in virtualisierten Umgebungen umgesetzt und kann daher zukünftig gemeinsam mit Hypervisor-Lösungen eingesetzt werden. Damit unterstützt MotionWise die Fahrzeughersteller beim Re-Use von komplexen Fahrassistenzfunktionen und ermöglicht eine deutlich höhere Innovationsgeschwindigkeit bei geringeren Kosten. (jr)

<a href="http://www.tttech-auto.com">www.tttech-auto.com</a>

MotionWise besteht aus Kernfunktionen, optionalen Diensten und Tools.

Dr. Stefan Poledna ist Vorstand und Mitgründer der TTTech Computertechnik AG sowie CTO bei TTTech Auto.

Dr. Wilfried Steiner, ist Leiter TTTech Labs der TTTech Computertechnik AG. Dr. Stefan Poledna ist Vorstand und Mitgründer der TTTech Computertechnik AG sowie CTO bei TTTech Auto.

Prototyping und Data Logging  für das Autonome Fahren

dSpace hat auf seiner World Conference mit der Autera-Produktfamilie ein neues Prototyping- und Data-Logging-System für die Funktionsentwicklung für Autonomes Fahren vorgestellt. Unterstützt werden alle relevanten Sensor-Interfaces, Busse und Netzwerke.

dSpace hat auf seiner World Conference mit der Autera-Produktfamilie ein neues Prototyping- und Data-Logging-System für die Funktionsentwicklung für Autonomes Fahren vorgestellt.

Videokameras, Lidar- und Radarsensoren erzeugen Datenmengen von mehreren Terabyte pro Stunde und stellen daher höchste Anforderungen an die Verarbeitung in Bezug auf Bandbreite, Rechenleistung und Speichertechnologie. Mit der AUTERA-Produktfamilie gibt dSpace Entwicklern und Testfahrern nun ein komplettes Portfolio für die Entwicklung von Funktionen für Autonomes Fahren an die Hand: Typische Einsatzbereiche sind die Aufzeichnung umfangreicher Datenmengen bei Testfahrten, zum Beispiel während der Entwicklung oder auch für die Homologation, sowie die Wiedergabe der aufgezeichneten Daten im Labor oder das Prototyping von Sensorfusions- oder Perzeptionsalgorithmen im Fahrzeug.

Dazu bietet die AUTERA AutoBox in Kombination mit einer großvolumigen Solid State Disk mehrere Terabyte Speicherplatz und eine Speicherbandbreite von bis zu 50 Gbit/s . Um rechenintensive Aufgaben wie die Entwicklung, Validierung oder Optimierung von KI-Algorithmen zu erledigen, kann sie mit Hardware-Beschleunigern wie GPUs oder FPGAs ausgestattet werden. Diese können während des Data Loggings auch dazu verwendet werden, bereits bei der Testfahrt eine intelligente Datenfilterung und -vorverarbeitung durchzuführen.

 Um die Daten aus den verschiedenen Sensoren synchron verarbeiten zu können, nimmt die AUTERA AutoBox exakte Zeitstempel und unterstützt Kameraschnittstellen wie GMSL II, FPD Link III oder CSI II für verschiedene Kamerahersteller. Damit die protokollierten Daten so schnell und einfach wie möglich in eine bestehende Server- oder Cloud-Infrastruktur hochgeladen werden können, steht eine dedizierte AUTERA-Upload-Station zur Verfügung. Diese lädt die aufgenommenen Daten mit 100 Gbit/s Ethernet in das Rechenzentrum. Die AUTERA AutoBox wird mit einem Setup auf Basis von RTMaps ausgeliefert. Mit der komponentenbasierten Software-Entwicklungs- und Laufzeitumgebung können Anwender Daten von unterschiedlichen Sensoren und Fahrzeugbussen erfassen, zeitstempeln, synchronisieren und wiedergeben. Zukünftig wird darüber hinaus auch eine Lösung für das Flottenmanagement verfügbar sein, mit der die AUTERA-Systeme im Flotteneinsatz einfach verwaltet und überwacht werden können.

Die MicroAutoBox III, die dSpace ebenfalls auf seiner Konferenz vorstellte, ist jetzt mit einem Quad-Core ARM-Prozessor ausgestattet, der im Vergleich zur MicroAutoBox II bis zu 16-mal mehr Rechenleistung bietet, und das pro Kern. Zur Ausführung großer Modelle stehen außerdem deutlich mehr Flash- und DDR4-Speicher zur Verfügung.

Die MicroAutoBox III ist in den bekannten I/O-Varianten verfügbar Das macht die Migration auf das neue System besonders einfach, da vorhandene Kabelbäume einfach wiederverwendet werden können. In Zukunft wird es neben einer WiFi-Option für den drahtlosen Zugriff auch eine weitere neue Variante DS1521 der MicroAutoBox III geben,

Zudem kommt für die MicroAutoBox II ein eigener Embedded PC mit Intel-Xeon-Prozessor und 10-Gbit-Ethernet-Schnittstellen. (oe)

<a href="http://www.dspace.de">www.dspace.de</a>

Das AUTERA-System bietet umfassende Bus- und Netzwerkunterstützung basierend auf den neusten Standards wie AUTOSAR und FIBEX.

Hauptartiklel

Nach Unterlagen der dSpace GmbH,  33102 Paderborn.

Jetzt Aufgaben auslagern,  bevor die CPU stirbt!

KI wird immer mehr als eine der grundlegendsten Transformationen des Computings seit Erfindung der CPU angesehen. Für viele besteht der nächste Schritt darin, den CPU- bzw. GPU-Clustern Hardwarebeschleunigern für Neuronale Netzwerke (NN) zur Seite zu stellen. Das könnte jedoch die Leistung von SoCs einschränken und nicht annähernd die erwartete Leistungs- oder Effizienzsteigerung bringen.

KI wird immer mehr als eine der grundlegendsten Transformationen des Computings seit Erfindung der CPU angesehen. Für viele besteht der nächste Schritt darin, den CPU- bzw. GPU-Clustern Hardwarebeschleunigern für Neuronale Netzwerke (NN) zur Seite zu stellen.

Mit dem Aufkommen der Smartphones wurden enorme technische Fortschritte erreicht, insbesondere im Bereich der Computerhardware. Die hohen Leistungsanforderungen bei niedriger Stromaufnahme und geringer Wärmeentwicklung führten zu Fortschritten bei der Entwicklung von Hochleistungssystemen auf einem einzigen Chip (System on Chip, SoC), die mit einer Leistungsaufnahme von ein paar Watt auskommen und trotzdem so leistungsfähig sind wie ein Desktop-Computer.

Den Entwurf derartiger moderner SoCs beherrschen wir nun, da ist es sicherlich ein logischer Schritt, zusätzlich NN-Beschleuniger zu integrieren? Für einige hundert GOPS ist das wahrscheinlich eine großartige Idee. Bei Systemen für Autonomes Fahren, die Rechenleistungen von 50 bis 100 TOPs und mehr erfordern, ist das viel schwieriger. Einfach nur Taktfrequenz und Leistung zu erhöhen, ist einfacher gesagt als getan.

Die erhöhte Rechenleistung von SoCs bringt praktisch nichts, wenn nicht jeder Prozessor die Daten vorliegen hat, wenn er sie für die Erledigung einer Aufgabe benötigt. Deshalb haben die heutigen SoCs für Smartphones moderne On-Chip-Speicher-Caches und hochmoderne On-Chip-Netzwerke mit hoher Bandbreite (Network on Chip, NoCs), um die verschiedenen Prozessoren und Beschleuniger mit Speicher, Peripheriegeräten und untereinander zu verbinden. Bei jeder Datenbewegung muss entschieden werden, was Priorität hat. Das ist letztendlich eine ziemlich komplexe Aufgabe und wird mit zunehmender Taktfrequenz umso schwieriger. Jeder Zyklus, der für Priorisierungsentscheidungen benötigt wird, und jeder Block, der auf den NoC-Zugriff wartet, ist ein Effizienzverlust.

Mit jeder neuen Siliziumprozessgeneration lässt sich deutlich mehr Speicher auf einem Chip unterbringen, in der Regel in Form von SRAM. Je näher der Speicher an dem Funktionsblock liegt, der ihn benötigt, desto schneller ist er und desto weniger Energie benötigt er zum Lesen oder Schreiben von Daten. Da jedoch immer mehr Speicher auf dem Chip untergebracht wird, gibt es immer öfter Situationen, in denen Daten zwischen diesen SRAM-Blöcken ausgetauscht werden müssen. Dies führt zu einer erheblichen Belastung der On-Chip-Netzwerke.

SoCs müssen externe Speicheranforderungen aus vielen Quellen verwalten: CPU-Anwendungen, GPU-Aufgaben sowie Ein- und Ausgangssignale von Sensoren und anderen Peripheriegeräten. Es ist keine einfache Aufgabe, diese Anfragen richtig zu priorisieren. Außerdem kann auf das in externen Speichern verwendete DRAM nur in Blöcken effizient zugegriffen werden: Wenn Datenanforderungen an und von DRAM nicht optimiert werden, gehen leicht 50 oder mehr Prozent der externen Speicherbandbreite verloren. Dazu kommt noch, dass der Zugriff auf externen Speicher viel mehr Energie benötigt als das Lesen aus dem SRAM.

Da der zentrale Prozessor das Herzstück der meisten SoCs ist, ist die Verwaltung der Speicherbandbreite eine große Herausforderung. Im ungünstigsten Fall blockieren sich CPUs und GPUs, und ein Großteil der theoretischen Rechenleistung verpufft. Im Automobilbereich ist so etwas nicht akzeptabel.

Warum ist die NN-Verarbeitung so anspruchsvoll?

Bei der NN-Verarbeitung müssen zahlreiche Rechenaufgaben parallel ausgeführt werden. Bis vor kurzem war es praktisch noch nicht möglich, einen signifikanten NN-Beschleuniger auf dem Chip unterzubringen, da die Siliziumtechnologie nicht in der Lage war, die Vielzahl der benötigten Berechnungselemente zu integrieren.

Es wurde jedoch erkannt, dass die NN-Berechnung ein Problem der Datenverarbeitung ist. Die Leistung jedes NN-Beschleunigers hängt davon ab, wie die Daten zwischen Tausenden von Rechen-Engines ausgetauscht werden. Da dieser Prozess datenintensiv ist, wird die Abwägung bezüglich der Verwendung von On-Chip- versus Off-Chip-Speicher zu einer entscheidenden Architekturfrage. Eines ist dabei klar: Bei der Verarbeitung mehrerer HD-Sensoreingänge in Echtzeit ist das Datenvolumen, das ständig im System verarbeitet werden muss, mit Sicherheit enorm.

Zudem werden NNs immer umfangreicher und tiefer, da die Algorithmik fortschreitet. Dies bereitete AImotive einiges Kopfzerbrechen, da einige Anwendungen den Einsatz mehrere HD-Kameras erfordern, sodass die NNs in der Lage sein müssen, acht und und mehr Kameraeingänge mit 3 x 1920 x 1024 Pixeln und mindestens 30 fps zu verarbeiten. Das sind fast 200 MB/s pro Kamera oder fast 1,6 GB/s insgesamt.

Die ersten Layer des Neuronalen Netzwerks (NN), die mehrere Faltungen durchführen, werden ähnlich große Mengen an Ausgabedaten abspeichern, und das wahrscheinlich sogar mehrere Male, bevor die anschließenden Operationen mit kleineren Datenmengen gefüttert werden. So summiert sich die erforderliche Bandbreite schnell zu 10 GB/s. Aus diesem Grund sind die Fachleute von AImotive der Ansicht, dass die NN-Berechnungsplattform im Zusammenhang mit der Gesamtsystemarchitektur sorgfältig betrachtet werden muss, um die extremen Bandbreiten für ein System mit mehreren Kameras (oder jedes andere Lidar-, Radar- oder Sensor-Fusion-System) realisieren zu können.

Nach einer umfassenden Analyse vieler NN-Workloads kamen die Ingenieure von AImotive zu dem Schluss, dass die Rechenleistung ausschließlich von der Datenbewegung abhängt: davon, wie schnell jedes Zwischenergebnis durch den Beschleuniger von einer Berechnung zur nächsten übergeben wird. Dabei zeigte sich, dass die Verarbeitung umso effizienter war, je mehr Gewichtungen und Zwischenergebnisse so nah wie möglich an den jeweiligen Ausführungseinheiten gespeichert wurden. Das heißt, dass es für eine Leistungssteigerung entscheidend ist, bei der Berechnung auf die Nutzung von Zwischenspeichern oder eines gemeinsamen zentralen Speichers zu verzichten.

aiWare wurde entwickelt, um dieses umfassende Wissen über Workload-basierte Datenflüsse in eine Hardware-Engine umzusetzen, die weitaus effizienter ist als herkömmliche Konzepte. Ziel war die Entwicklung einer Engine, die eine fortwährende, hocheffiziente NN-Berechnung ermöglicht und gleichzeitig die Datenbandbreiten sowohl innerhalb des Beschleunigers als auch zwischen dem NN-Beschleuniger und anderen Teilen der Hardwareplattform, speziell von CPU-basierten SoCs, verwaltet.

Viele aktuelle Implementierungen von NN-Beschleunigern bestätigten die Feststellungen des aiWare-Teams, dass ihr Design davon abhängt, wie viel lokaler Speicher verwendet wird. Bei aiWare sind etwa 80 bis 85 Prozent der Gesamtfläche durch lokale SRAM-Blöcke belegt. Entscheidend ist dabei die Speichernutzung und wie der Datenfluss vom und zum Speicher gestaltet wird. Deshalb dreht sich bei den aiWare-Hauptpatenten von AImotive alles um den Datenfluss und nicht um die Berechnung.

Viele Branchenvertreter glauben, dass zukünftige autonome Fahrzeuge eine leistungsfähige zentrale CPU brauchen werden. Tatsächlich sehen immer mehr Automobilelektroniker zukünftige Fahrzeuge als „Rechenzentren auf Rädern“. Das ist sicherlich sinnvoll: Dank der Flexibilität eines Konzepts mit zentralem Prozessor benötigen wir beim Aufbau unserer Prozessor-Hardware-Plattform noch nicht alle Anforderungsdetails.

Die Herausforderung besteht darin, dass ein Rechenzentrum nicht als Echtzeitsystem konzipiert ist. Es kann stoppen und sich selbst neu konfigurieren, Prozessoren neu starten und Rechenlasten an andere verschieben sowie seine Auslastung ändern. Es benötigt auch viel Energie, um diese Flexibilität zu erreichen. Klingt das nach dem idealen Konzept für ein Auto?

Dieses Konzept dürfte für viele unkritische Funktionen in zukünftigen Fahrzeugen eingesetzt werden. Für kritische Echtzeitfunktionen, von denen Leib und Leben abhängen, beispielsweise für die Hauptsteuerungssysteme hochautomatisierter Fahrzeuge, muss jedoch die Flexibilität eines zentralen Konzepts gegen Zuverlässigkeit und Robustheit in allen Situationen sowie Einschränkungen durch Leistung, Wärme und elektrische Störungen abgewogen werden.

 Tatsächlich könnten die Hardwar-Plattformen, die OEMs und Tier1-Anbieter zur Implementierung ihrer autonomen Systeme wählen, in den kommenden Jahren zu einem wichtigen Differenzierungsmerkmal am Markt werden.

Ein Schlüsselfaktor ist die Verwaltung der Systembandbreiten. Jede Kamera erzeugt Datenströme mit hoher Bandbreite. Die NN-Berechnung für die Eingabeschicht (front-end perception) und -Klassifizierung muss extrem schnell und zuverlässig sein. Mit der aiWare-Speicherarchitektur können Systemdesigner deshalb vorverarbeitete Daten von Kameras (oder anderen HD-Sensoren) direkt in den externen aiWare-Speicher streamen. Damit eröffnet sich die Möglichkeit, die SoCs des Host-Prozessors von der gesamten für die Erfassung und Vorverarbeitung von Sensordaten benötigten Bandbreite zu entlasten. Beim aiWare-Subsystem reduzieren sich so die anfallenden Datenmengen, die an den zentralen Prozessor für anschließende Funktionen wie Trajektorienplanung und -steuerung geschickt werden müssen.

Dieser Ansatz ermöglicht eine wesentlich bessere Skalierbarkeit, da es einfacher ist, ein skalierbares, dediziertes Sensor-Fusion-Frontend-System mit Low-Level-Hardware zu entwerfen, als komplexe Prozessoren zu skalieren. Dadurch kann die Flexibilität des zentralen Prozessors auch viel besser für Aufgaben genutzt werden, für die er optimal geeignet ist: Die Verarbeitung flexibler, komplexer Heuristiken und Verwaltung vielfältiger Anwendungen.

Durch eine moderate NN-Beschleunigung innerhalb des zentralen Prozessors sowie eine leistungsstarke, dedizierte, externe NN-Verarbeitung kann so der ideale Mix aus skalierbarer Leistung bei geringstmöglichem Stromverbrauch erreicht werden. Durch ein stärker verteiltes Konzept wird es zudem viel einfacher, Redundanzsysteme zu implementieren, die das erforderliche Maß an permanenter Sicherheit bieten.

Die Zukunft mit autonomen Fahrzeugen wird spannend. Damit diese jedoch von Menschen auf der ganzen Welt akzeptiert werden, müssen sie trotz Obergrenzen bei Leistungsaufnahme und Kosten in anspruchsvolle Betriebsumgebungen bisher unerreichte Leistungen erbringen. Einfach wie in der Vergangenheit weiterzumachen, wird keine Option sein.

AImotive entwickelt mit einem ganzheitlichen Ansatz ein umfassendes Portfolio an Technologien zur Lösung dieser Herausforderungen: den aiDrive Software-Stack; aiSim-Simulation und aiWare-Hardware-IP.

Trotz der erstaunlichen Fortschritte, die Hardware-Technologien in den letzten 10 bis 20 Jahren sowohl bei Hochleistungs-Rechenzentren als auch in anspruchsvollen mobilen Umgebungen gemacht haben, ist es falsch anzunehmen, dass Leistungsfähigkeit kaum etwas kosten wird. Der Einsatz in Autos wird immer besonders anspruchsvoll sein: extreme Betriebsbedingungen, hohe Wärmebelastung, stark eingeschränkte Energieversorgung, Kostenzwänge, lange Entwicklungszeiten und noch längere Produktlebenszeiten.

Hardware-Innovationen werden dazu beitragen, diese Herausforderungen nicht nur durch den Einsatz modernster Technologien zu lösen. Innovationen werden auch durch neue Hardwarearchitekturen maximiert, die bestehende, ausgereifte Technologien auf neue Weise nutzen. Durch Kombination dieser beiden Innovationsansätze wird es möglich sein, die zukünftigen Anforderungen dieser neuen Märkte zu erfüllen. (jr)

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

Bild 1: Automatisierte Fahrzeuge werden trotz des Einsatzes smarter Sensoren immer einen zentralen Rechencluster mit CPU, GPU und einigen Funktionen zur Beschleunigung Neuronaler Netze für einen sicheren Betrieb benötigen.

Bild 2: Neuronale Netzwerkbeschleuniger können auf zwei Arten realisiert werden: Als integraler Bestandteil eines SoC oder als externe Beschleunigerkarte. Beide Ansätze haben spezifische Vor- und Nachteile. Nachteil des SoC-Ansatzes sind die Datenbewegungen, die Kosten für die Entwicklung des Chips und die begrenzte Upgrade-Möglichkeiten.

AImotive unterhält weltweit eigene Testflotten zum Sammeln von Daten und Testen der Software. In Ungarn waren es im Frühjahr 2019 schon acht Fahrzeuge – meist Hybride, wegen der großen Batterie.

Tony King-Smith ist Executive Advisor bei AImotive.

Datenhandelsplattform  mittels Blockchain-Technologie

Vernetzte Fahrzeuge erfassen zahlreiche Informationen über ihren Fahrzustand und ihre Umgebung. Diese Daten bergen prinzipiell große Vorteile für Autofahrer, Fahrzeughersteller und Serviceanbieter. Aber wie lassen sich solche Daten rechtskonform, effizient und transparent zum Vorteil für alle Beteiligten in einem verteilten Ökosystem nutzbar machen? Continental entwickelt dafür mit HPE eine dezentrale Handelsplattform. Unterstützt werden die Partner durch den Technologieanbieter Crossbar.io.

Continental entwickelt mit HPE eine dezentrale Handelsplattform. Unterstützt werden die Partner durch den Technologieanbieter Crossbar.io.

Es ist nachvollziehbar, dass ein Autofahrer für seine grundlegende Bereitschaft, Daten zur Verfügung zu stellen, eine Gegenleistung erwartet. Ein Teil dieser Leistung kann ein verbesserter Service sein, der durch die von möglichst vielen Fahrzeugen bereitgestellten Informationen besonders aktuell und detailliert ist. Aber auch eine Vergütung der Daten in Form einer geldwerten Prämie wäre für viele Fahrer zweifellos ein Anreiz. Manche Fahrzeughersteller (OEM) haben solche Programme ansatzweise installiert und werten Datenströme von beteiligten Fahrzeugen aus, um auf diesem Weg verbesserte und neue Services anzubieten.

Herausforderungen dabei betreffen sowohl die Abdeckung als auch die Penetration eines Services: Kein einzelner OEM erreicht diese Zielsetzungen derzeit mittels der eigenen Fahrzeugflotte auf globaler Ebene. Zudem gibt es auch außerhalb der Automobilindustrie weitere Unternehmen und ganze Branchen, die fahrzeugbezogene Daten für neue Serviceangebote nutzen möchten, vorausgesetzt es gäbe eine sichere, transparente und für alle faire Handelsmöglichkeit für geeignete Daten.

Für Continental und HPE war das Potenzial von in Echtzeit aus dem Fahrzeug gesendeten Daten – quasi ein Schwarm intelligenter rollender Sensoren – einer der interessanten Ansatzpunkte, um eine dezentrale Datenhandelsplattform zu entwickeln. Ein digitales Zustimmungsmanagement schafft die Grundlage für eine rechtskonforme Datenübertragung an den OEM gemäß EU-Datenschutzgrundverordnung (DSGVO). Erlaubt der Fahrer beispielsweise explizit die Übertragung der GPS-Daten, gekoppelt mit weiteren Informationen aus dem Fahrzeug an den OEM, so darf der OEM diese Daten anonymisiert an Dritt- und Serviceanbieter oder andere OEM weitergeben. Als Gegenleistung könnte der OEM dem Fahrer virtuelle Münzen oder auch eine reale Währung zukommen lassen – diese Entscheidung obliegt dem OEM. Hat ein OEM den Schritt des Zustimmungsmanagements noch nicht selbst installiert, kann er auf die Technologie von Continental und HPE zurückgreifen, um eine Lösung für diesen Teil des Datenhandels zu entwickeln. Der OEM ist dabei als späterer Datenanbieter im dezentralen Datenmarkt der erste Empfänger der Fahrzeug-Datenströme. Er speichert und vorverarbeitet die Daten im eigenen Backend, um sie nutzbar zu machen.

Dezentraler Datenmarkt und Mehrwert der Blockchain-Technologie

Es gibt verschiedene Möglichkeiten zur Monetarisierung von Daten: Einerseits können die Daten in einer zentralen Datenbank eines Drittanbieters gespeichert und über diesen Mittelsmann gehandelt werden. Andererseits können sie in einem verteilten Netzwerk aus gleichberechtigten Datenanbietern und -konsumenten nutzbar gemacht werden. Beide Ansätze sind komplementär und können ineinandergreifen. Die Datenhandelsplattform von Continental und HPE basiert auf letzterem Prinzip. Für die Sicherheit, Transparenz, Autorisierung und Dokumentation der Datenübertragungen zwischen einem Datenanbieter und -konsumenten dient die Blockchain-Technologie, genauer gesagt die Ethereum-Blockchain, weil sie sich besonders für die Entwicklung verteilter Applikationen eignet. Grundlage dafür sind intelligente Verträge („Smart Contracts“), die das Ausführen wichtiger Funktionen des Datenmarktes ermöglichen, wie zum Beispiel die Kopplung zwischen Bezahlmechanismus und Datentransfer. Ermöglicht wird dies durch den Technologiepartner <a href="http://Crossbar.io">Crossbar.io</a> (Bild 1).

Daten- und Geldströme im dezentralen Datenmarkt

Mit der Datenhandelsplattform hat ein teilnehmender OEM die Möglichkeit, seine vom Fahrer autorisierten und im eigenen Backend gespeicherten Daten und Datenströme auch für andere Interessenten gegen Bezahlung nutzbar zu machen. Damit entstehen eine neue Wertschöpfungskette (Bild 2) sowie neue Möglichkeiten zur Serviceentwicklung. Als Voraussetzung zur Teilnahme im dezentralen Datenmarkt müssen sich die beteiligten Datenanbieter und die interessierten Datenkonsumenten am Marktplatz und auf der Blockchain registrieren. Sie erhalten dabei individuelle Schlüssel, die in der Folge dazu dienen, Transaktionen anzustoßen oder selbst durchzuführen. Wollen zwei registrierte Teilnehmer der Handelsplattform Daten übertragen (z. B. vom Datenanbieter zum -konsument), so nutzen sie dafür in der Blockchain hinterlegte Smart Contracts als Grundlage, um einen Kanal für die Zahlung zu öffnen („State-Channel“). Wurde eine Transaktion über den Kanal abgeschlossen, so folgt die eigentliche Übertragung der Datenströme. Diese ist zwischen den beiden Teilnehmern direkt Ende-zu-Ende verschlüsselt. Der Zugriff wird beispielsweise für einen festgelegten Zeitraum gewährt. Ist dieser abgelaufen, kann automatisch ein neuer Schlüssel gekauft werden, um weiterhin Zugriff zu erhalten. Damit der Datenkonsument einschätzen kann, was er mit den Datenströmen praktisch anfangen kann, kann er vorab Musterdatensätze analysieren. Auf diesem Weg lassen sich sehr schnell und gezielt Mikrozahlungen für ausgewählte Datenströme abwickeln. In der Blockchain wird jeweils nur die Summe der erfolgten Transaktionen zwischen zwei Partnern fälschungssicher dokumentiert (Prinzip des Distributed Ledgers). Es ist für andere Teilnehmer der Blockchain nicht nachvollziehbar, wer welche Daten im Einzelnen gekauft hat.

Mit dieser Plattform wird die Fälschungssicherheit und Transparenz der Blockchain gezielt genutzt, um für alle Beteiligten Sicherheit zu schaffen, den benötigten Energieeinsatz in der Blockchain zu minimalisieren und sensible strategische Aktivitäten zu schützen. In der Handelsplattform werden jeweils nur Metadaten der Datenströme und die Bezahlungen registriert, um eine individuelle Abrechnung der Teilnehmer zu gewährleisten. Die eigentliche Datenübertragung findet aus Effizienzgründen außerhalb der Blockchain statt. Sie ist jedoch durch die Verschlüsselung angekoppelt und über die Handelsplattform abgesichert.

Die Automobilbranche steht erst am Anfang der Entwicklung, die mit der Datenhandelsplattform und der Blockchain-Technologie möglich wird. Wenn ein Fahrer beispielsweise zugestimmt hat, neben seiner GPS-Position auch weitere damit verbundene Attribute, wie etwa erkannte freie Parkplätze und aus- oder einparkende Fahrzeuge, zu übertragen, dann fließen diese Informationen an den OEM. Dieser kann seinem Kunden (Fahrer) dafür virtuelle Münzen in dessen virtuelle Geldbörse (Wallet) gutschreiben und selbst die vorverarbeiteten Daten an einen Serviceanbieter weiterverkaufen. Der Serviceanbieter kann solche Daten beispielsweise für einen Parkplatz-Service nutzen.

Mit der schrittweisen Umsetzung der 5G-Technologie werden die Rahmenbedingungen verbessert, um solche neuen Geschäftsmodelle künftig nahezu in Echtzeit abwickeln zu können. Mittelfristig bietet die dezentrale Datenhandelsplattform Potenzial für Datenkonsumenten aus ganz anderen Branchen als dem Automobilbereich, die mit diesen Informationen neue Services und Geschäftsmodelle entwickeln können, u .a. Handel, Landwirtschaft, Produktion und Logistik (Bild 3). Entscheidend ist, dass die Handelsplattform jede Zustimmung und Transaktion nachvollziehbar und sicher macht und alle beteiligten Datenanbieter jederzeit die volle Kontrolle über ihre Daten behalten. (oe)

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

Bild 2: Wertschöpfungskette in der Datenhandelsplattform.

Bild 1: Schematischer Aufbau der Datenhandelsplattform.

Bild 3: Beim Datenhandel sind der Fantasie im Hinblick auf neue Services kaum Grenzen gesetzt.

Dr. Karoline Bader ist Head of  Digital Product Management bei Continental Intelligent Transportation Systems. Dr. Konrad Hilarius ist Experte für Car-to-Cloud Systeme bei Continental Interior Systems & Technologies. Volkmar Knaup ist Director Product & Customer Center Europe bei Continental Intelligent Transportation Systems.

Dr. Konrad Hilarius ist Experte für Car-to-Cloud Systeme bei Continental Interior Systems & Technologies.

Volkmar Knaup ist Director Product & Customer Center Europe bei Continental Intelligent Transportation Systems.

»Wir sind davon überzeugt, dass wir mit unserer Plattform den gordischen Knoten von Datenaustausch und Datenschutz durchschlagen.

Helmut Matschi, Mitglied des Vorstands von Continental  und Leiter der Division Interior.

Faurecia möchte Passagieren den Aufenthalt in künftigen Fahrzeugen so angenehm wie möglich machen. Dafür sollen neue Bedienkonzepte und Komfortfunktionen, künstliche Intelligenz und Kooperationen mit Spezialisten sorgen.

Fahrer und Beifahrer steigen ein, Sensoren analysieren ihren Fitnesszustand und regeln auf dieser Basis Temperatur und Belüftung. Beleuchtungseffekte sowie Audiosysteme schaffen ein raumgreifendes und doch individuelles Wohlfühlambiente. Sobald (teil-)autonome Fahrfunktionen die Fahrzeugführung übernehmen, gleiten die Vordersitze in eine Relax-Position und die Passagiere können entspannen, kommunizieren oder Filme auf einem großflächigen Display anschauen. Andre Wlasak, Vice President Industrial Design bei Faurecia, sieht einen hohen Bedarf an solchen flexiblen Innenraumszenarien und Komfortsystemen schon vor dem Rollout von vollautonomen Fahrzeugen: „Wir sollten schon die in den nächsten Jahren eingeführten Level der höheren Automatisierung nutzen.“