Audi_Thomas_m_müller_zugeschnitten1

(Bild: Audi)

AUTOMOBIL-ELEKTRONIK: Was ändert sich grundlegend an der Architektur der Fahrzeuge?

Dr. Thomas M. Müller: Wir sind dabei, eine neue Architektur zu entwerfen, die demnächst in die Serienentwicklung geht, und beginnen mit den neuen Premium-E-Fahrzeugen im Konzern, sodass zunächst einmal Audi und Porsche betroffen sind. Wir entwickeln eine gemeinsame Architektur, die dann auf der gemeinsamen PPE-Plattform erstmalig zum Einsatz kommen wird, wobei PPE für Premium Platform Electric steht. Porsche und Audi entwickeln PPE gemeinsam quasi als Premium-Pendant zum MEB, dem modularen Elektrifizierungs-Baukasten im Konzern.

Nicht nur das Thema E-Fahrzeuge bringt natürlich neue Herausforderungen mit sich, sondern insbesondere Themen wie autonomes Fahren, Digitalisierung, Update-fähige Security etc. Deshalb ist auch dort ein nächster Architekturhub erforderlich. Und in diesem Architekturhub sollen Security-by-Design und Update-by-Design fest verankert sein, während gleichzeitig die Entkopplung von Hardware und Software deutlich stärker gespielt werden soll, als dies in den Fahrzeugen der Fall ist, die jetzt auf den Straßen unterwegs sind. Audi ist auf dem Markt zwar schon bei der Eigenentwicklung von Software ganz weit vorne unterwegs, ebenso wie bei der Softwareentwicklung in entkoppelten Modellen, zum Beispiel mit e.solutions, unserem Joint Venture mit Elektrobit, in dem wir unsere Infotainment-Software wirklich selber entwickeln, selbst integrieren und auf die Head-Unit aufspielen. Aber wir haben auch immer noch etliche Steuergeräte, die heute im Prinzip nur Lastenheftvergabe sind.

Welche Grundzüge weist die neue Architektur auf?

Audi neu (auch für Inhalt) DSC_0488

Dr. Thomas M. Müller (hier im Interview mit AUTOMOBIL-ELEKTRONIK): „Mittlerweile lautet die Frage weniger, mit welchem First-Tier ich eine Lösung realisiere, sondern eher, welchen SoC-Hersteller ich auswähle. Eigentlich treffen wir auf Tier-2-Ebene eine Entscheidung, und dann suchen wir einen Tier-1, der diese Lösung implementiert.“ Audi

Dr. Thomas M. Müller: Wir müssen nicht nur Hardware und Software stärker trennen, sondern wir müssen uns auch stärker auf das Thema Applikation und damit Software konzentrieren – und zwar im Zusammenspiel mit den benötigten Hardware-Peripherien, die für eine Funktion notwendig sind. Damit wollen wir auch einen Teil der Wertschöpfung stärker kontrollieren. Das heißt allerdings nicht, dass wir das zwingend alles selber machen. Wir werden zwar einen Teil der Software selbst entwickeln, aber wir werden dann auch einen Teil so mit Partnern entwickeln, dass uns dann vielleicht die IP gehört. Zusätzlich werden wir einen Teil als Lizenzen einkaufen. Die Funktion und damit letztendlich die Software steht hier ganz klar im Vordergrund – und nicht mehr so sehr das einzelne Steuergerät.

Wie sieht das konkret aus?

Dr. Thomas M. Müller: Wir werden das Bordnetz in einem Ebenenmodell mit einzelnen Domänen strukturieren. Die oberste Ebene bildet die sogenannte Rechnerebene, die derzeit aus fünf Hochleistungs-Computern für fünf Domänen besteht, aber das können in Zukunft auch weniger Einzelcomputer sein. Auf diesen High-Performance-Computern laufen im Wesentlichen die Logiken und Applikationen. Dieser Domänencontroller fungiert dann sozusagen als Gehirn seiner Domäne. Unterhalb der Rechenebene sind alle möglichen Peripherien angesiedelt – in erster Line Eingabe-/Ausgabesteuergeräte für Sensoren, Bildschirme, Audiosysteme etc.

Derzeit arbeiten wir daran, die Logik möglichst aus den Peripherien herauszulösen und nach oben hin zu zentralisieren, sodass die Applikation beziehungsweise der Algorithmus in der Rechnerebene stattfindet. Zudem werden wir eine beachtliche Anzahl von Steuergeräten entfallen lassen; in der Body-Domäne gelingt das beispielsweise relativ einfach und ziemlich gut. Wir lösen die Funktion vom Steuergerät und rechnen sie zentral.

Antworten darauf, wie sich die neue Architektur auf den Kabelbaum auswirkt, welche wesentlichen Features die Domänencontroller aufweisen und welche Auswirkungen sich für den Einkauf und die Zulieferer ergeben, finden Sie im weiteren Verlauf dieses Beitrags – ergänzt um Statements rund um die Themen Safety, Integration, Software-Wiederverwendung, Fahrzeugbusse von (über)morgen, Zusammenarbeit mit den Halbleiterfirmen, Tier-1s und Ingenieursdienstleistern, das neue Bordnetz, Backend, Function-on-Demand etc.

Wie wirkt sich das auf einen Kabelbaum aus?

Dr. Thomas M. Müller: Dafür nehmen wir nur vereinzelt mehr Verkabelung in Kauf. Teilweise sparen wir auch Kabel, weil zum Beispiel die Datenleitungen und Stromversorgungen der nicht mehr vorhandenen ECUs entfallen. Wir haben uns die Architektur bewusst weniger unter dem Aspekt der Verkabelungskomplexität sondern mehr unter zwei anderen Leitfragen angeschaut. Es ging uns darum, Kosten zu sparen und damit einhergehend auch die Steuerungshoheit über Software, Logik und Algorithmik zu verstärken.

Welche wesentlichen Features haben die Domänencontroller?

Dr. Thomas M. Müller: Nach aktuellem Stand, den wir in 2022 auf den Markt bringen werden, beinhaltet die Architektur fünf Domänen und damit fünf Domänencontroller. Auf diesen Domänenrechnern läuft die Software-Umgebung. Damit das funktioniert, müssen wir noch einiges angleichen und anpassen. Wir können mit dieser Struktur auch ein einheitliches Security-Konzept aufsetzen. Indem wir das Thema Security ganzheitlich und systematisch angehen, erreichen wir eine viel höhere Ebene der Datensicherheit. Das gleiche gilt für das Update-Konzept, das als Querschnittsthema zentral einmal entwickelt wird, um es dann im gesamten Bordnetz zu applizieren. Wir können die Querschnittsthemen durch die Angleichung der Software-Umgebung auf der Rechnerebene deutlich besser zentral – also nur einmal – entwickeln und dann verbauen.

Welche Auswirkungen hat das auf den Einkauf und die Zulieferer?

Audi neu DSC_0448

Dr. Thomas M. Müller: „Wir gehen in Richtung Ethernet-­Kommunikation im Fahrzeug und beginnen mit Gigabit-Ethernet. Diese erste Migrationsstufe steht für 2022 auf unserem Zeitplan.“ Audi

Dr. Thomas M. Müller: Mit diesem Architektur-Ansatz, der die Hardware und Software trennt, arbeiten wir deutlich stärker zentralisiert, denn wir wollen die Logik und damit das OEM-spezifische Verhalten möglichst aus den Peripherie-Steuergeräten herauslösen. In der Praxis bedeutet das, dass wir in Zukunft nach Möglichkeit eher Standard-Sensoren und Standard-Aktuatoren sowie standardisierte Bauteile einkaufen. Die Anzahl der Lastenhefte, in denen wir das genaue Verhalten eines Bauteils aus OEM-Sicht vorschreiben, wird sich somit verringern, weil die OEM-spezifische Ausprägung auf der Rechnerebene passieren soll.

Was heißt das zum Beispiel für eine Frontkamera? Bisher sorgten Chips von Mobileye etc. für eine gewisse Intelligenz und Vorverarbeitung in der Kamera; sollen jetzt nur noch Rohdaten aus der Kamera gelangen?

Dr. Thomas M. Müller: In 2022 werden wir noch nicht mit den reinen Sensor-Rohdaten arbeiten, denn sie erzeugen noch eine zu große Buslast. Aber die Grundidee besteht darin, nur die Vorverarbeitung durchzuführen, die zwingend notwendig ist. Die Objekterkennung selbst könnte lokal erfolgen, aber das Reagieren und Auslösen einer Aktion, also das Plan-and-React, das soll zentral erfolgen. Analog dazu verfahren wir in der Body-Domäne, wo der Body-Controller deutlich stärker zentralisiert wird.

Im Infotainment gehen wir so weit, einen einzigen Cockpitrechner zu nutzen. Das heutige FPK, frei programmierbare Kombiinstrument, wird damit im Wesentlichen ein reines Anzeigeinstrument, während die Intelligenz auf einer erweiterten Head-Unit stattfindet. Der zentrale Cockpitcomputer wird dann alle Displays ansteuern: das Beifahrerdisplay, Rearseat etc.

Wie garantieren Sie dabei die Einhaltung der Safety gemäß ISO 26262?

Dr. Thomas M. Müller: Die Head-Unit arbeitet mit mehreren Partitionen, von denen einige ASIL-konform arbeiten. So läuft die Tacho-Funktion dann in einer eigenen Partition, um sozusagen als zentrales Steuergerät das Display im Cockpit mit anzusteuern. Die Ansteuerung des Displays erfolgt dann über eine schnelle Punkt-zu-Punkt-Datenautobahn.

Damit rücken die Themen Integration und Softwarekompetenzen viel stärker in den Vordergrund, denn durch den Wechsel auf diese Quasi-Großrechner müssen wir deutlich stärker als Integrator auf den Rechner fungieren.

Antworten rund um die Themen Integration, Software-Wiederverwendung, Fahrzeugbusse von (über)morgen, Zusammenarbeit mit den Halbleiterfirmen, Tier-1s und Ingenieursdienstleistern, das neue Bordnetz, Backend, Function-on-Demand etc. finden Sie auf den folgenden Seiten.

Wie soll die Integration in der Praxis erfolgen?

Dr. Thomas M. Müller: Die Integration könnte der OEM mit einem First-Tier machen; beim Cockpitrechner hat e.solutions diese Aufgabe übernommen. Es kann aber auch ein externer Partner sein. Entscheidend für uns ist, dass wir als OEM deutlich tiefer einsteigen, uns auch damit beschäftigen, welche Software beziehungsweise welche Applikation wir denn für welche Lösung haben wollen. Dabei fokussieren wir uns deutlich stärker auf das, was letztlich die Kundenfunktion ausmacht, nämlich die Software und die Applikation. Damit sind wir dann auch darauf vorbereitet, in einem nächsten Schritt vielleicht auch noch einmal stärker zu integrieren.

Noch weniger Steuergeräte sozusagen?

Dr. Thomas M. Müller: Noch weniger von den Rechnern auf der Rechnerebene. Man könnte ja auch eine sicherheitskritische Domäne wie Fahrwerk und ADAS bilden und zusätzlich eine Komfort-Infotainment-Connectivity-Domäne, um so statt fünf nur noch zwei, drei Domänen zu haben, wenn die Rechenkapazität deutlich steigt. Eine derartige Hochintegration funktioniert allerdings nur dann, wenn man die Software-Bausteine wiederverwenden kann, ohne sie jedes Mal komplett neu zu qualifizieren.

Solange wir ein Lastenheft vergeben, müssen wir im Prinzip ja immer alles noch einmal nachprogrammieren – insbesondere die OEM-spezifischen Elemente. Wenn wir Software getrennt sourcen oder getrennt entwickeln lassen oder vielleicht mit eigener IP arbeiten oder Lizenzen zukaufen, dann können wir die Softwarebausteine in Zukunft wiederverwenden. Wenn wir dann die Hardware ändern, upgraden etc., können wir die Software, die bereits auf einem anderen Produkt integriert funktioniert, wiederverwenden und auf einer ganz anderen Absicherungsqualität aufsetzen. Selbst wenn wir die Software um 5 oder 10 % erweitern, hätten wir bereits ein Basispaket, das stabil läuft.

Wie soll die Software-Wiederverwendung funktionieren?

DSC_0313 b

Dr. Thomas M. Müller: „Die Software der Zukunft ist nicht mehr monolithisch und damit nicht mehr als ein fort­laufender Code ­realisiert. Sie ist vielmehr in kleine Einheiten unterteilt, die sich Over-the-Air runterladen lassen.“ Audi

Dr. Thomas M. Müller: Wir müssen bei der Software mit neuen Architekturen arbeiten, wobei hier besonders Docker-Konzepte interessant sind, bei denen man Container ein- und auschecken kann: Die Software ist dabei in einzelne Container, im Prinzip sind das kleine Executables, verpackt, die dann gegen definierte Schnittstellen in der Umgebung eine bestimmte Aufgabe erfüllen beziehungsweise eine bestimmte Funktion abbilden. Die Software der Zukunft ist nicht mehr monolithisch und damit nicht mehr als ein fortlaufender Code realisiert. Sie ist vielmehr in kleine Einheiten unterteilt, die sich Over-the-Air runterladen lassen. Weil die Schnittstellen schon im Vorfeld stehen, ist die Software off-Board testbar – auch in sehr vielen automatisierten Tests.

Auch Microsoft Windows nutzt das Dockerkonzept. In punkto Blue-Screen war die Lernkurve da sehr lang. Wie sorgen Sie dafür, dass so etwas im Auto nicht passiert?

Dr. Thomas M. Müller: Wir gehen natürlich nur dort den Weg, wo wir es letztlich auch realisieren können. Deshalb springen wir gewiss nicht von 0 auf 100, um morgen alles dockerfähig zu haben. Wenn wir neue Aspekte angehen, können wir das Dockerkonzept von Anfang an nutzen, aber in Summe ist es ein Migrationspfad. Derzeit schauen wir gerade, an welcher Stelle wir wie und wann ansetzen.

Was ist in Zukunft jenseits des Dockerkonzepts wichtig?

Dr. Thomas M. Müller: Wir müssen und wollen serviceorientiert kommunizieren; dazu gilt es, die Kommunikation auch deutlich stärker zu abstrahieren. Die dedizierten Matritzen werden entfallen und stattdessen werden mehr Service-Aufrufe erfolgen, sodass es den Partnern auf dem Bordnetz letztlich egal ist, von wo aus der Service bedient wird. Da erfolgt dann zum Beispiel nur eine Anfrage „Gib mir die Systemzeit und die Position“, um diese Info zu bekommen, aber es erfolgt dann keine Anfrage mehr bei einem ganz bestimmten Bordnetzteilnehmer.

Auf welchen Datenbus setzen Sie?

Dr. Thomas M. Müller: Wir gehen in Richtung Ethernet-Kommunikation im Fahrzeug und beginnen mit Gigabit-Ethernet. Diese erste Migrationsstufe steht für 2022 auf unserem Zeitplan.
Bei Flexray laufen wir teilweise in eine Kosten- und Leistungs-Situation, die wir intensiv überdenken müssen. Dass MOST sehr teuer ist, wissen wir auch alle. Trotz der starken Konzentration auf Ethernet wird es noch den einen oder anderen CAN- oder CAN-FD Anschluss geben. Wir versuchen, eine größere Vereinheitlichung bei den Bussen zu erzielen.

Antworten rund um die Zukunft von LIN, MOST, CAN und Flexray sowie zu den Themen Zusammenarbeit mit den Halbleiterfirmen, Tier-1s und Ingenieursdienstleistern, das neue Bordnetz, Backend, Function-on-Demand etc. finden Sie auf den folgenden Seiten.

Welche Zukunft hat dabei LIN?

Dr. Thomas M. Müller: Low-Cost-Busse wie LIN werden zunächst im Fahrzeug bleiben, denn wir können nicht alles von heute auf morgen komplett revolutionieren. Es stellt sich nämlich die Frage, ob die Hersteller von Low-Cost-Steuergeräten überhaupt ein Gerät mit Ethernet-Anschluss liefern können und zu welchem Preis. Da wird es durchaus noch einen Mischverbau geben, aber bei den schnellen Datenverbindungen werden wir aufräumen, wo immer wir können.

Das klingt wie das längerfristige Aus für MOST und Flexray…

Dr. Thomas M. Müller: Ja. Wir werden da aussteigen in den nächsten Jahren. Allein aus Kosten- und aus Übernahmegründen werden wir CAN und LIN wohl noch länger sehen.

Wo spielen CAN und LIN dann noch eine Rolle?

Dr. Thomas M. Müller: CAN und LIN kommen dann bei relativ einfachen Funktionen zum Einsatz, wo man Low-Cost fast mit Commodities unterwegs ist, denn auf solchen Steuergeräten läuft ja in aller Regel nicht sehr viel Logik. Wir müssen eher schauen, dass wir an anderen Stellen aus den Steuergeräten Logiken rausnehmen, zentralisieren und dann auch dort eine stärkere Commodity-Schnittstelle schaffen.

Hier Höchstintegration, dort Peripherie mit möglichst wenig eigener Intelligenz.

Dr. Thomas M. Müller: „Wir müssen bei der Auswahl der Softwarebausteine mitreden, diese selber entwickeln oder getrennt beauftragen, sodass der Entscheidungsspielraum des Tier-1s sinkt.“ Audi

Dr. Thomas M. Müller: „Wir müssen bei der Auswahl der Softwarebausteine mitreden, diese selber entwickeln oder getrennt beauftragen, sodass der Entscheidungsspielraum des Tier-1s sinkt.“ Audi

Dr. Thomas M. Müller: Genau. Die Funktionalität integrieren wir hoch, und dann bleibt außen quasi noch ein Aktuator, im Wesentlichen ein Stellmotor mit Endanschlag etc., der mir im Prinzip die erforderlichen mechatronischen Dinge als Signale wieder zurückmeldet. So wird die Hardwareseite inklusive Aktoren und deren Ansteuerung stärker austauschbar und damit günstiger. Es soll wirklich eine Art Commodity werden, wo es dann nur noch um die Leistungsklasse geht, aber der OEM muss sich da nicht mehr selbst drum kümmern, dass das Lastenheft richtig umgesetzt ist, dass alles überall angepasst wird.

Was bedeutet das dann für die Zusammenarbeit mit den Tier-1, Tier-2 und Ingenieursdienstleistern?

Dr. Thomas M. Müller: Bis dato hat ein Tier-1 gegen Spezifikation in vielen Fällen eine Gesamtlösung als Blackbox oder Silverbox geliefert, bei der er sich um Software-Integration, Hardware-Erstellung und in vielen Fällen auch die Auswahl der SoCs und der Halbleiterbausteine selbst gekümmert hat, wobei Audi da schon auch aktiv mitgeredet hat.

Jetzt preschen die Chiphersteller massiv nach vorne, denn gerade bei den komplexeren Chips machen die SoCs den entscheidenden Unterschied zwischen zwei Steuergeräten aus. Es ist nun einmal ein grundlegender Unterschied, ob Sie einen Intel- oder einen Nvidia-Chip beim automatisierten Fahren nutzen.

Außerdem bestimmt der Chip die Software-Umgebung mit. Deshalb lautet die Frage mittlerweile weniger, mit welchem First-Tier ich eine Lösung realisiere sondern eher, welchen SoC-Hersteller ich auswähle. Eigentlich treffen wir auf Tier-2-Ebene eine Entscheidung, und dann suchen wir einen Tier-1, der diese Lösung implementiert. Die Wertschöpfungskette hat sich bereits verändert.

Gleichermaßen sehen wir das nach oben. Mit den in Software gegossenen Funktionen kommen da ja auch neue Player auf den Markt; entsprechend haben sich auch viele First-Tiers bereits verstärkt, zum Beispiel durch Zukäufe in den Bereichen Security oder Updates. Von unten wirken die Tier-2, also die Chiphersteller, stärker mit und von oben die Software- und Applikationsanbieter, sodass den First-Tiers im Wesentlichen die Integrationsaufgabe bleibt – und zwar mit geringerer eigener Entscheidungsfreiheit, weil der OEM deutlich mehr Rahmenbedingungen setzen wird. Gleichzeitig muss sich der OEM deutlich stärker um die Halbleiter kümmern.

In punkto Zusammenarbeit mit Halbleiterherstellern war Audi ein echter Pionier…

Dr. Thomas M. Müller: Richtig, und wir müssen auch in punkto Software-Umgebung die richtige Vorauswahl treffen. Der OEM muss sich deutlich stärker um die Themen Applikationen, Funktionen und Services kümmern: Hierzu muss er dann die richtigen Partner finden – und das sind nach wie vor die First-Tiers, aber die klassische Wertschöpfungskette bricht da ein Stück auf.

Da stellt sich die Frage, wo die Integrationsgrenze gesetzt wird, und was geschieht bei einem Wechsel von SoC-Hersteller A zu SoC-Hersteller B?

Dr. Thomas M. Müller: Deshalb müssen wir bei der Auswahl der Softwarebausteine mitreden, diese selber entwickeln oder getrennt beauftragen, sodass der Entscheidungsspielraum des Tier-1s sinkt. Schon heute vergeben wir an etlichen Stellen die Software getrennt von der Hardware, beispielsweise beim Infotainment. Das Audi-Joint-Venture TKI liefert uns zum Beispiel Software zur Klimasteuerung und für das Energiemanagement. Diese Software wird in Lizenz quasi als Teil eingekauft und dann von einem First-Tier verbaut. Ähnlich gehen wir beim Reifendruck-Monitoring und in anderen Anwendungen vor. Im Endeffekt wird der First Tier eigentlich zum Anbieter auf mehreren Ebenen, aber kein Anbieter des gesamten Steuergeräts mehr.

Antworten rund um die Themen Zusammenarbeit mit den Tier-1s und Ingenieursdienstleistern, das neue Bordnetz, Backend, Function-on-Demand etc. finden Sie auf der letzten Seite dieses Interviews.

Wann gehen die Tier-1s dann noch in starke technologische Vorleistung im Rahmen der Vorentwicklung?

Dr. Thomas M. Müller: Immer dann, wenn ein Tier-1 ein gewisses Alleinstellungsmerkmal bietet, wird er weiterhin in Vorleistung gehen – egal ob Modul, Software oder Sensor wie zum Beispiel Kamera oder Lidar. Wir werden aber aus unserer Sicht durchaus ein modulareres Anbieten sehen.

Wie verändert sich das Bordnetz der Fahrzeuge?

Dr. Thomas M. Müller: Wir diskutieren derzeit darüber, ob wir die Komplexität der Bordnetze verringern müssen, um die immens hohen Kosten des Kabelbaums zu senken. Ich nenne das Elektronifizierung des Bordnetzes und meine damit die Einführung von Zonensteuergeräten, die bestimmte Teile im Auto zusammenfassen. So könnte beispielsweise vielleicht vorne und hinten jeweils links und rechts je ein Zonensteuergerät sitzen, das mit einem zentralen Rechner kommuniziert. Wichtig ist eine Architektur, die grundsätzlich skalierbar ist.
Für das autonome Fahren muss das Bordnetz zudem deutlich intelligenter werden. So müssen wir zum Beispiel weg von der passiven Schmelzsicherung hin zum aktiven, regelbaren Abschalten.

Welche Rolle spielen die Ingenieursdienstleister in Zukunft?

Dr. Thomas M. Müller: Ingenieursdienstleister spielen da eine Rolle, wo sie in das Thema Integration einsteigen – und zwar verstärkt. Hinzu kommt deren Unterstützung beim Testen, Absichern etc. aber auch beim Schreiben von Software, bei der uns dann nachher der Quellcode gehört. Hierzu muss sich der Entwicklungsdienstleister natürlich auch weiterentwickeln.

Was tut sich in punkto Function-on-Demand?

Dr. Thomas M. Müller: Beim neuen e-tron bieten wir im Prinzip genau das an. So kann der Kunde als Function-on-Demand den Matrixbeam nachträglich kaufen, denn im Fahrzeug ist bereits ein Scheinwerfer verbaut, der das grundsätzlich kann. In Summe lassen sich knapp zehn Funktionen nachträglich over-the-air freischalten. Damit steigen die Stückzahlen der Sensorik und Aktuatorik, sodass man sich solche Business-Cases auch häufiger leisten kann; genau darauf wollen wir auch hinaus. Wir können dem Kunden dann Funktionen für einen beliebigen Zeitraum freischalten, beispielsweise für einen ausführlichen Test, in dem er die Funktionen schätzen lernt.

Welches Backend benötigen Sie dazu?

Dr. Thomas M. Müller: Wir entwickeln derzeit eine Ende-zu-Ende-Architektur mit momentan 5 Zonenrechnern, die dann nahtlos an das Backend angebunden wird. Bei den Funktionen muss es auch an vielen Stellen nahtlos möglich sein, Rechenleistung auf das Backend zu verlagern. Das machen wir heute schon, zum Beispiel beim A8, wo wir unsere Sprachbedienung auch auf dem Backend laufen lassen. Wenn der Kunde Connectivity hat, ist die Spracherkennung dann so richtig gut. Wir haben natürlich immer die Fallback-Ebene auch on Bord und sind auch dort State of the Art, aber naturgemäß wegen der geringeren Rechenleistung im Vergleich zum Backend eingeschränkt. Beim e-tron haben wir einen dynamischen Routenplaner, der auch Ladesäulen kennt und reserviert.
Damit ist das Thema Backend auf der gleichen Ebene zu sehen wie die Rechnerebene on Bord; das Backend ist quasi der sechste Rechner. Natürlich müssen auch Konzepte wie Over-the-Air-Updates oder Security Ende zu Ende entwickelt sein.

Wie viel Prozent der Entwicklungsaktivität geht dann in die Anbindung des Backbones und die Komplettintegration? Um wie viel steigt dadurch der Aufwand?

Dr. Thomas M. Müller: Wir sehen heute schon, dass bei den Ende-zu-Ende-Funktionen ein großer Teil des Aufwands genau an der Schnittstelle besteht. Je stärker die Partitionierung, desto größer der Aufwand für Integration, Absicherung und das Testen. Das Backend hat dabei den Vorteil, aber auch die Herausforderung, dass wir ein Stück weit vom Auto entkoppelt Dinge tun können, aber gleichzeitig müssen wir in einer Projektrealisierung sozusagen eine gewisse Synchronisierung sicherstellen, damit das Backend parallel mit dem Fahrzeug sozusagen entwickelt wird.
Da treffen durchaus zwei Welten aufeinander, nämlich die Denke eines klassischen ITlers, der nach Abschluss der Tests das Deployment durchführt, und dann die Frage, was passiert, wenn Autos draußen im Feld sind, die nicht in jedem Aspekt updatebar sind. Eine wichtige Aufgabe besteht darin, das zu synchronisieren und zu harmonisieren, um auch da eine vernünftige Architektur zu realisieren.

Alfred Vollmer

Chefredakteur AUTOMOBIL-ELEKTRONIK und all-electronics

(av)

Kostenlose Registrierung

Newsletter
Bleiben Sie stets zu allen wichtigen Themen und Trends informiert.
Das Passwort muss mindestens acht Zeichen lang sein.

Ich habe die AGB, die Hinweise zum Widerrufsrecht und zum Datenschutz gelesen und akzeptiere diese.

*) Pflichtfeld

Sie sind bereits registriert?