Nicht nur im Cover-Interview der letzten AUTOMOBIL-ELEKTRONIK sondern auch auf der CES 2018 sind zentrale Steuergeräte wie das ZFAS für das automatisierte Fahren ein großes Thema. Wie schätzt Visteon die Lage ein?

smartcore Markus Schupfner: „Mit Visteons neuem skalierbaren Baukasten ist es möglich, ein Basissystem, ein Mid-System und ein High-System gleichzeitig zu realisieren“ visteon

Markus Schupfner: „Mit Visteons neuem skalierbaren Baukasten ist es möglich, ein Basissystem, ein Mid-System und ein High-System gleichzeitig zu realisieren.“ Alfred Vollmer

Markus Schupfner: Diesen Trend, den Audi erstmals mit dem A8 für halbautonomes Fahren gesetzt hat, sehen wir jetzt überall. Wenn wir mit den OEMs weltweit – von Asien über Europa bis Amerika – sprechen, dann ist die Zentralisierung von Steuergeräten stets ein Thema. Dabei bestehen hohe Ansprüche in punkto Redundanz. Es geht hier um Redundanz auf zwei Ebenen: Zum einen sind unabhängige Sensoren erforderlich, sodass die Branche ab Level 3 beim automatisierten Fahren um das Thema Lidar nicht herumkommen wird. Aber auch im zentralen Steuergerät sind Redundanzen erforderlich: Redundanzen in punkto Algorithmik aber auch in punkto Ausfallsicherheit. Ein klassisches Beispiel ist die automatisierte Fahrt auf der Autobahn, bei der das Fahrzeug auch bei einem Ausfall eines zentralen Systems noch sicher zum Halten kommen muss.

Je mehr Künstliche Intelligenz in Form von neuronalen Netzen zum Einsatz kommt, umso wichtiger wird aber auch eine Redundanz der Algorithmik. Beim Einsatz von CNNs (Convolutional Neural Network) trainieren die Ingenieure zwar diese Netze, und sie können auch messen, wie viel die CNNs in welcher Qualität erkennen, aber CNNs lassen sich weder klassischerweise wie geschriebener Code debuggen noch lässt sich das Optimum der Trainingseinheiten und -folgen berechnen. Die Entwickler wissen somit nicht, ob die neuronalen Netze optimal trainiert wurden oder eventuell schon übertrainiert sind. Da stellt sich die Frage, wie sich CNNs  redundant überwachen lassen und welche weitere Redundanzen im Fahrzeug erforderlich sind. Durch einen Crosscheck mit den klassischen Ansätzen aus dem Bereich maschinelles Sehen können wir Unsicherheiten zwar ausgleichen, aber dafür ist auch zusätzliche Rechenleistung erforderlich. Immerhin können wir hier auch aus anderen Bereichen lernen: im Flugzeug sind diese Crosschecks ja bereits seit langer Zeit gang und gäbe.

Welche Vorgehensweise hatten Sie beim Aufbau des Drivecore-Teams?

Markus Schupfner: Um Drivecore zu entwickeln, haben wir ein komplett neues Team mit über 100 Mitarbeitern aufgebaut, die unter anderem zuvor in den Bereichen maschinelles Sehen, Lenkungstechnik oder Künstliche Intelligenz tätig waren – teilweise in den Branchen Luftfahrt- oder Verteidigungssysteme. Diese Mitarbeiter sind zu uns gekommen, weil wir ihnen die Möglichkeit geboten haben, ein komplett neues zentrales System für automatisiertes Fahren von Level 2 bis Level 4 zu erschaffen und die Eingeschränktheit spezialisierter ECU-Funktionen zu verlassen.

Wie bei einem Startup haben wir uns zuerst in völlig neuer Umgebung eingemietet sowie die ersten grundsätzlichen Architekturen und Technologien für zentrales Computing diskutiert. Danach sind wir Stück für Stück mit einer großen Eigenverantwortung jedes neuen Mitarbeiters in die messbare Umsetzung der Funktionalität durch Zuhilfenahme agiler Entwicklungsmethodik gegangen. Auf der Hardwareseite haben wir natürlich unser Know-how und das exzellente Team aus dem Cockpitbereich genutzt, aber das Team speziell für Software und Algorithmik selbst war bei Drivecore komplett neu.

Schon im Mai 2017 hatten wir die erste Shuttle-Fahrt, das heißt autonomes Fahren für eine vordefinierte Strecke. Ende 2017 hatten wir einen Highway-Pilot auf Drivecore-Basis auf Straßen in den USA erstmalig getestet; nun dehnen wir unsere Tests auf Deutschland und China aus. Durch unseren Greenfield-Approach mussten unsere Leute nicht parallel an irgendwelchen Serienentwicklungen arbeiten; sie konnten und können das Thema intensiv und mit einem frischen Ansatzpunkt auf die Neuentwicklung konzentrieren. Das Kernteam sitzt in Karlsruhe, aber weitere Teams in Shanghai/China, Sofia/Bulgarien, Pune/Indien sowie an den US-Standorten Detroit und Silicon Valley arbeiten kräftig mit. Dabei sind wir komplett agil unterwegs: mit Zwei-Wochen-Rhythmen.

Welchen Ansatz verfolgt Visteon?

Visteon drivecore Markus Schupfner (rechts, hier im Gespräch mit AUTOMOBIL-ELEKTRONIK-Chefredakteur Alfred Vollmer): „Für mich ist Augmented-Reality ein Schlüsselfaktor für die Akzeptanz des automatisierten Fahrens.“ smartcore

Markus Schupfner (rechts, hier im Gespräch mit AUTOMOBIL-ELEKTRONIK-Chefredakteur Alfred Vollmer): „Für mich ist Augmented-Reality ein Schlüsselfaktor für die Akzeptanz des automatisierten Fahrens.“ Alfred Vollmer

Markus Schupfner: Viele OEMs wollen beim autonomen Fahren einen höheren Applikations- oder auch Algorithmik-Anteil selbst entwickeln. Wir haben daher unsere Plattform bewusst so entwickelt, dass die OEMs und Drittanbieter ihre Algorithmen integrieren können. Unsere Aufgabe als Tier-1 besteht im Grunde darin, skalierbare Plattformen zur Verfügung zu stellen, die bereits einen bestimmten Anteil an Software-Plattformen mit sich bringen, meist in Form von Hypervisor, Betriebssystemen und einem Teil der Middleware. Solch eine Plattform muss es den OEMs ermöglichen, möglichst schnell und sicher ihre Systeme und Funktionalitäten zu integrieren. In der Regel bringen OEMs ja ihre Applikationen, teilweise sogar per Software realisierte Infotainmentsysteme und HMIs mit.

Um diese Integration möglichst reibungslos umzusetzen, bieten wir für unsere beiden Plattformen sogenannte Studios zur Entwicklungsunterstützung an: Smartcore Studio und Drivecore Studio. Damit lassen sich diese sehr komplexen Plattformen und deren Architektur relativ schnell mithilfe eines PCs konfigurieren und Applikationen, die OEMs mitbringen, integrieren. Gleichzeitig ermöglichen es die Studios, die Performance direkt auf der Zielhardware zu messen. So können die OEMs beispielsweise die Leistungsfähigkeit zweier Algorithmen direkt vergleichen und mit gleichen Parametern simulieren.

In der Entwicklungsphase können die Anwender mit unserem Tooling dann jeden Tag für Testzwecke eine neue Version aufspielen, um so mit der stets aktuellen Version zu arbeiten und die Entwicklungszeit zu verkürzen. Drivecore Studio bietet auch die Möglichkeit, Vorsimulationen am Rechner durchzuführen, um so zusätzliche Zeit zu sparen. Als Inputs akzeptiert das Tool sowohl Live- als auch Simulationsdaten.

Welche Middleware steuert Visteon bei?

Markus Schupfner: Die Middleware fungiert als Schnittstelle und ermöglicht es, Applikationen jeweils in einer Sandbox laufen zu lassen und diese zu überwachen. Wir stellen mit dieser Middleware offene APIs für die Entwicklung zur Verfügung und sorgen dafür, dass die Kommunikationskanäle stets kontrolliert bleiben sowie dass sowohl die Echtzeitkriterien als auch das gewünschte Laufzeitverhalten erfüllt werden. Third-Party-Anbieter sowie unsere Kunden können auf die offenen APIs, die Common-APIs, aufbauen.

Wann kommt die nächste Generation?

Markus Schupfner: Drivecore kommt gerade in der ersten Generation als A-Muster auf den Markt. Anfang 2018 werden wir den ersten SOP des Cockpit Computers in einem Fahrzeug ausrollen. Von Smartcore haben wir auf der CES 2018 bereits mit der Version 2.0 die zweite Generation vorgestellt. Smartcore 2.0 bieten wir jetzt auf Basis unterschiedlicher Chipsets auch als Integrationslösungen an, sodass die OEMs auswählen können, welches die effizienteste Lösung für ihre unterschiedlichen Zielkonfigurationen für das Fahrzeug sind.

Für den Infotainment-Bereich bieten wir drei unterschiedliche Lösungen an. Entweder können unsere Kunden Visteons eigenen, Phoenix genannten Infotainment-Stack nutzen oder sie entscheiden sich für einen Android-Embedded-Infotainment-Stack oder sie haben bereits einen in Eigenregie entwickelten Infotainment-Bereich, den wir dann als Infotainment integrieren.  Generell sehen wir einen großen Trend Richtung Android auf Infotainment-Systemen; etwa 50 Prozent aller OEMs scheinen dafür Interesse zu haben. Der Community-Effekt ist da sehr groß, zumal Google sich massiv zu dieser Plattform bekannt hat und sich der Infotainment-Stack dadurch wesentlich besser pflegen lässt. Da die Entwicklungskosten für einen Infotainment-Stack im High-End-Bereich oftmals einen dreistelligen Millionenbetrag erfordern, ist das ein zugkräftiges Argument.

Außerdem ist die Update-Frequenz bei Android-Stacks um ein Vielfaches höher; wenn es um neue Features und Stabilisierung geht, kommen die Updates deutlich schneller als bei anderen Lösungen. Wir als Tier-1 sehen die Diskussion um Android jedoch neutral, denn wir haben neben Android auch unseren eigenen Infotainment-Stack im Angebot, der gewisse Vorteile bietet, aber wir sind auch offen für OEM-spezifische Integrationen. Auf der CES2018 zeigten wir diese unterschiedlichen Möglichkeiten. Mit der Entwicklung der dritten Generation haben wir gerade begonnen, um einen kompletten und skalierbaren Cockpitcomputer zu ermöglichen. Global betrachtet arbeiten wir jedes Jahr an einer neuen Plattform-Generation.

 

Auf der nächsten Seite geht es um Security und Augmented Reality.

Seite 2 von 3123