Zentralcomputer im Fokus

Herr Schupfner, wie laufen die Geschäfte?

Markus Schupfner: Visteons Geschäfte laufen sehr gut, und wir sehen extrem viele Auftragseingänge in 2017. Allein im Jahr 2017 hatten wir sieben Milliarden US-Dollar an neuen Geschäftsaufträgen. In China wachsen wir beispielsweise gut 21 Prozent mehr als im Jahr 2016. Wenn man bedenkt, dass global etwa drei Prozent Zuwachs im Fahrzeugverkauf 2017 weltweit erfolgte, dann ist die Zunahme in China wirklich fantastisch. In China haben wir vier Joint-Ventures, von denen Yanfeng Visteon das Größte ist.

Markus Schupfner: „Die OEMs wollen eine Lösung möglichst vom Entry-Level, dem Kleinwagen, bis zum Premium-Modell nutzen, um nicht für jede Modellreihe ein komplett eigenes System entwickeln zu müssen.“ Alfred Vollmer

Wie wirkt sich der hohe China-Anteil sonst noch aus?

Markus Schupfner: Wenn wir mit chinesischen Kunden über ein neues Projekt reden, dann sagen sie uns, dass sie bereits zwei Jahre später damit in Produktion gehen wollen. Früher hatten wir für Entwicklungen mindestens drei Jahre zur Verfügung. Die Entwicklungsgeschwindigkeit hat sich somit wesentlich erhöht. Weil viele der neuen chinesischen OEMs so gut wie keine Altlasten – beispielsweise Verbrennungsmotoren – haben, können sie komplett neue Fahrzeugarchitekturen viel leichter generieren und einführen.

Wie reagieren die anderen OEMs?

Markus Schupfner: Wenn es um neue elektrische Plattformen geht, dann legen auch die deutschen OEMs jetzt ein noch nie gekanntes Entwicklungstempo an den Tag. Wir sehen das zum Beispiel bei den Änderungen für elektrische Fahrzeuge, wo Konzerne die kompletten E/E-Architekturen neu aufstellen und dabei auch eher über Ethernet als über MOST oder CAN sprechen. Aufgrund der höheren Bandbreite, die dann zur Verfügung steht, lassen sich mehr Informationen im Fahrzeug zentral verarbeiten. Diese Zentralisierung ist eines unserer Hauptthemen sowohl für den Cockpitbereich als auch für autonomes Fahren.

Die höhere Geschwindigkeit drückt sich in zwei Aspekten aus. Der eine Aspekt ist die Geschwindigkeit selbst, mit der die Produkte bei erheblich kürzerer Entwicklungszeit marktreif werden. So etwas funktioniert nur mit dem konsequenten Einsatz von Plattformen. Wir als Tier-1 müssen derartige Plattformen generieren und quasi zum richtigen Zeitpunkt schon in der Schublade bereithalten, um sie dann an die Bedürfnisse des OEMs zeitnah anzupassen.

Der zweite Aspekt ist die Skalierbarkeit, denn die OEMs wollen eine Lösung möglichst vom Entry-Level, dem Kleinwagen, bis zum Premium-Modell nutzen, um nicht für jede Modellreihe ein komplett eigenes System entwickeln zu müssen. Dabei stellt sich die Frage, wie sich CPU- oder GPU-Power auf den Systemen skalieren lässt, ohne dabei das gesamte Steuergerät neu entwickeln zu müssen. Diese Skalierbarkeit beschäftigt uns bei allen neuen Entwicklungskonzepten in den Bereichen Cockpitcomputer und zentralisiertes Computing für das automatisierte Fahren.

Wie sieht denn das neue Geschäft von Visteon aus?

Markus Schupfner (mit Drivecore-Exponaten für Level 2 bis Level 5): „Wir haben unsere Plattform bewusst so entwickelt, dass die OEMs und Drittanbieter ihre Algorithmen integrieren können.“ Alfred Vollmer

Markus Schupfner: Visteons Vision ist die Verwandlung in ein Technologieunternehmen. Früher gehörten wir mit unserem klassischen Produktportfolio eher zur Kategorie Me-Too, aber das hat sich radikal geändert, denn bei uns heißt es unter unserem CEO Sachin Lawande ganz klar: „Changing over to a High-Technology Company“. Das Ziel ist es, Visteon mit hoher Geschwindigkeit in eine Hochtechnologiefirma zu überführen, und ich denke, wir sind mit unseren neuen Technologien bereits auf einem guten Weg dazu.

Das merkt man auch bei unserem aufstrebenden Geschäftsvolumen mit den Cockpit-Computern, wo Visteon dieses Jahr erstmalig mit einem deutschen OEM auf den Markt kommt. Bei diesen Cockpit-Computern erfolgt die Berechnung zum Beispiel für das Head-Up-Display, das Cockpit-Cluster und das Infotainment auf einem zentralisierten Chipset und damit nur noch in einer anstatt bisher drei verschiedenen ECUs. Unsere Entwicklung, bei der wir beispielsweise mit SoCs von Nvidia,  Renesas oder Qualcomm arbeiten, haben wir vor über vier Jahren gestartet. Damals gab es auf dem Markt noch keine passende Lösung zur Virtualisierung, mit der wir auf einem zentralen Rechner mehrere Betriebssysteme betreiben konnten. Deshalb haben wir unseren eigenen hardwarenahen Typ-1-Hypervisor entwickelt. So können wir auf einem Prozessorsystem sowohl ein Betriebssystem laufen lassen, das die Anforderungen an funktionale Sicherheit gemäß ASIL-B erfüllt, als auch ein Betriebssystem für das Infotainment auf QM-Level.

Parallel dazu haben wir ein zentrales Clustersystem entwickelt, das die gesamte grafische Rechenleistung erbringt, sodass lediglich ein simples Display erforderlich ist. Wir virtualisieren somit die Displays, um so die Hardware-Abhängigkeit zum Display zu verringern. Wir wollen die Grafikleistung und das Grafik-Setup unabhängig von den verschiedenen Auflösungen und Skalierungen umsetzen, um dann mit der gleichen zentralen Lösung sowohl ein kleineres Display in den unteren Marktsegmenten als auch beispielsweise ein 12-Zoll-Cluster in Premium-Fahrzeugen anzusteuern. Mit diesem Konzept können wir auch Applikationen über verschiedene Displays verteilen, ohne die Berechnung oder Datenbasis auf die Anzeigegeräte verschieben zu müssen.

Welche generellen Trends sind für Visteon besonders wichtig?

Markus Schupfner: „Wir virtualisieren die Displays, um so die Hardware-Abhängigkeit zum Display zu verringern.“ Alfred Vollmer

Markus Schupfner: Generell sehen wir einen Trend startend vom 100 Prozent digitalen Cockpit hin zu Cockpitfunktionalität für teil- und voll-automatisiertes Fahren. Dies beinhaltet einen Trend zur verstärkten Zentralisierung von Funktionen auf einem Zentralrechner. Dies beginnt durch die zentrale Steuerung aller Anzeigesysteme inklusive Infotainment-System bis hin zur Integration von Driver- und Passenger-Monitoring, das für autonomes Fahren ab Level-3-Fahrten unbedingt erforderlich ist. Auch Augmented-Reality-Anzeigen liegen im Trend, um das wahrgenommene Fahrzeugumfeld für Fahrer und Beifahrer darzustellen und den Sicherheitskomfort zu steigern. Im Zuge der kompletten Digitalisierung sehen wir zudem den Trend Richtung E-Mirror, also zu elektronischen Spiegeln. Auch diese Anzeige muss das zentrale Steuergerät in Zukunft berechnen.

Wie geht Visteon in diesem Bereich vor?

Markus Schupfner: Um alle Features sinnvoll umzusetzen, ist ein hochgradig skalierbares System erforderlich, das gleichzeitig noch entsprechend kostengünstig ist. Daher beschäftigen wir uns intensiv mit dem Thema skalierbare Plattformen – sowohl im Bereich Cockpit als auch für das autonome Fahren. Mit Visteons neuem skalierbaren Baukasten ist es möglich, ein Basissystem, ein Mid-System und ein High-System gleichzeitig zu realisieren; für das Cockpit heißt unser Baukasten Smartcore, für das automatisierte Fahren Drivecore. Die Software-Anwendungen laufen auf Smartcore beziehungsweise Drivecore je nach Art der eingesetzten Prozessoren und SoCs unterschiedlich schnell.

Wir produzieren jeweils ein Basisboard, auf das dann je nach Zusatzfunktionalität, Art der zusätzlichen Sensoranbindungen, funktionaler Sicherheitsanforderung und Performance-Anforderung ein oder mehrere Zusatzboards, sogenannte Computing- Carrrier, aufgesteckt werden. Wenn die Performance zum Beispiel von 500 GFLOPS auf 2 TFLOPS steigen soll, dann sind aktuell vier Zusatzboards erforderlich. Mit unserem aktuellen Ansatz erzielen wir eine Verarbeitungsleistung von bis zu 20 TFLOPS. Aufgrund des hohen Energiebedarfs dieser Hochleistungs-Chips verfügen die Mid-Systeme über eine aktive Lüfterkühlung, während die Topsysteme aktuell auf Wasserkühlung ausgelegt sind. Bezüglich der SoCs, die wir verwenden, sind wir ziemlich neutral und versuchen, die effizientesten Lösungen, ausgerichtet nach den Wünschen unserer Kunden, zu finden. Hier sind wir bestens gerüstet für die neuen Grafikprozessoren und SoCs von Unternehmen wie Nvidia, Renesas, Qualcomm, Intel oder anderen Chipherstellern.

Auf der nächsten Seite sind zentrale Steuerungen Thema.

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?

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?

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.

Welche Bedeutung hat Security für Visteon?

Markus Schupfner: Vor rund drei Jahren haben wir unsere Cyber-Security Aktivitäten durch Rekrutierung von Spezialisten aus den Bereichen Spielautomaten und Mobiltelefone verstärkt. Cyber-Security spielt eine wichtige Rolle in allen Projekten im Zusammenhang mit verbundenen Systemen, da Bedrohungen jeden Tag zunehmen. Insbesondere in Bezug auf Connectivity, autonomes Fahren und SOTA (Software-Updates Over The Air) ist Cyber-Sicherheit ein zentrales Thema.

Wir konzentrieren uns auf Cybersecurity Ende-zu-Ende „Von Prozess zu Lösungen.“ Wir beginnen mit Secure Hardware und wählen die richtigen SoCs/Chipsätze mit HSM (Hardware Security Module) und SHE (Secure Hardware Extension) aus. Als nächstes schützen wir die verschiedenen Schichten wie Hypervisor, Betriebssysteme mit Secure Boot mit digitalen Signaturen. Softwaresysteme und Anwendungen enthalten bestimmte digitale Signaturen, die beim Start überprüft werden. Auch während der Laufzeit überprüft das System ständig, ob es den Anwendungen immer noch vertrauen kann, um zu erkennen, ob eine Anwendung innerhalb der vorgegebenen Grenzen fehlerhaft arbeitet oder sogar extern gesteuert wird. Auch Nachrichten, die wir im Rahmen der Nachrichtenbehandlung prüfen, werden ständig kontrolliert, um sicherzustellen, dass nur autorisierte Teilnehmer Nachrichten austauschen können. Wir können auch die Schlüsselbehandlung verwenden, um festzustellen, ob eine Version eines Programms tatsächlich mit einer bestimmten Version einer anderen Anwendung arbeiten kann. Die Implementierung einer angemessenen Cyber-Sicherheit ist bei uns Standard. Wir ergänzen unsere starken Sicherheitslösungen mit robusten Sicherheitsprozessen. Wir haben den Cybersecurity-Prozess J3061 in unseren Produktentwicklungsprozess integriert.

In unserem Haus ist das Thema White-Hacking noch ziemlich neu. White-Hacking-Teams sind Visteon-Teams, die versuchen, in unsere eigenen Systeme einzubrechen. Wir führen diese Prüfung auch dann durch, wenn die Kunden nicht danach fragen, weil es uns einfach wichtig ist, zu erfahren, wie gut wir unsere Systeme schützen können. Neu im Zuge der Cyber-Security ist nun auch die Verifizierung von Sicherheit und Authentizität von Sensorsignalen, damit das Auto sich auf die Sensorsignale verlassen kann. Ergänzt um adäquate Plausibilitäts-Checks wird dann auch klar erkennbar, ob beispielsweise ein Laserpointer den Lidar-Sensor blendet.

Was tut sich im Bereich Augmented Reality im Auto?

Markus Schupfner: Mit Augmented Reality können wir dem Fahrer wesentliche sicherheitsrelevante Informationen über das Fahrzeugumfeld darstellen aber auch im Hinblick auf halbautomatisiertes Fahren die Insassen auf die nächsten Aktionen des Fahrzeugs vorbereiten. Für mich ist Augmented Reality (AR, die Redaktion) ein Schlüsselfaktor für die Akzeptanz des automatisierten Fahrens. Bei den AR-Head-Up-Systemen sollte das virtuelle Bild mindestens 7 m, besser 10 m vor dem Fahrer liegen und dabei auch eine genügend weite horizontale und vertikale Projektion ermöglichen.

Mit dem, was derzeit absehbare AR-HUDs leisten, sehe ich den Mehrwert vor allem im Assisted Driving, denn der immer noch limitierte Projektionsbereich bietet primär die Möglichkeit, die Fahrsicherheit durch kontaktanaloge Projektion in das Sichtfeld des Fahrers zu erhöhen und sein Fahrverhalten zu coachen.

Für delegiertes oder autonomes Fahren liegt die wesentliche Aufgabe in der Passagierinformation. Wir gehen jedoch davon aus, dass der Durchbruch dieser Technologie dazu erst vollständig kommt, wenn wir zum Beispiel Laser-Projektionstechnik zur Serienreife bringen. Diese wird es ermöglichen, Informationen auch großflächig für alle Passagiere zu projizieren, und sie bietet die Grundlage für AR-basierte Mehrwertdienste über die Fahrsicherheit hinaus.

Zur Umsetzung von AR sind Objekterkennung und Sensorfusion erforderlich, um ein 3D-Umfeldmodell zu erzeugen, das statische und dynamische Objekte zentimetergenau erfasst. Über das Driver-Monitoring-System wissen wir dann, wo der Fahrer hinschaut. Über die Fahrprojektion und das Umgebungsmodell können wir nun in Echtzeit eine Gefährdungslage errechnen. Wir blenden dann in Echtzeit die passenden Inhalte ins AR-Head-Up-System ein, so unter anderem die Markierung von eventuell für den Fahrweg gefährlichen Objekten. Für diese Darstellung in Echtzeit benötigt der Cockpit-Computer viel Rechenleistung, und zudem müssen derartige Systeme in Zukunft ASIL-B-Anforderungen erfüllen. Mit unseren AR-HUD-Aktivitäten zielen wir genau auf die Anfragen der OEMs, die bei allen Ausschreibungen ab Level 2+ gleichzeitig auch ein AR-HUD mit anfragen. Die entsprechenden Vorentwicklungen laufen.