Interview: Auswirkungen der Baukastenstrategie auf die Elektronikentwicklung

Kaum ein Automobilhersteller hat das Baukastenprinzip so konsequent und erfolgreich umgesetzt wie Volkswagen. In einem Exklusiv-Interview mit Elektronik automotive erklärt der VW-Elektronikentwicklungsleiter Dr. Volkmar Tanneberger, wie sich diese Strategie auf die E/E-Architektur und deren Entwicklungsprozesse auswirkt.

Herr Dr. Tanneberger, worauf basiert das VW-Baukastenprinzip?
Dr. Volkmar Tanneberger: Grundsätzlich haben wir im VW-Konzern verschiedene Baukästen, die sich über die Einbaurichtung des Motors definieren. Das sind der modulare Längsbaukasten (MLB; z.B. A4 – Anm. d. Red.), der modulare Querbaukasten (MQB; z.B. Golf – Anm. d. Red.) und ein weiterer Baukasten für unsere „New Small Family“. Diese Baukästen enthalten natürlich neben den mechanischen Komponenten auch elektrische und elektronische Komponenten, vom Sensor bis zum Steuergerät. Die Zielsetzung dabei ist es, Volumen bei der Beschaffung zu bündeln, um möglichst kosteneffizient arbeiten zu können, Entwicklungsressourcen zu bündeln und das Entwicklungsrisiko zu minimieren. Denn die Wiederverwendung von erprobten Technologien wirkt sich immer positiv auf das Qualitätsniveau aus.
Bedeutet das, dass jeder Baukasten seine eigenen Elektronikkomponenten hat?
Tanneberger: Im Gegenteil, im E/EBereich werden viele Module baukastenübergreifend eingesetzt oder bilden eine eigene Plattform, die wiederum an die einzelnen Baukästen angepasst wird. Das kann eine unveränderte Übernahme, eine Neuparametrierung bis hin zu einer speziellen Hardware- oder Software-Variante bedeuten. Im Infotainment-Bereich
haben wir beispielsweise einen modularen Infotainment-Baukasten (MIB).
Wie weit unterscheiden sich die Anwendungen des MIB in verschiedenen Fahrzeugen?
Tanneberger: Beim MIB unterscheiden wir zwei wesentliche Elemente: den Zentralrechner und die HMI. Der Zentralrechner, der nicht design-relevant ist und verdeckt verbaut wird, ist bei MQB und MLB identisch und trägt einen Großteil der Funktionen bzw. der Entwicklungsleistungen und auch des Entwicklungsrisikos. Bei der Bedienung nutzt Audi einen Dreh-Drück Drücksteller, VW setzt auf Touchscreen. Wir haben also durchaus unterschiedliche  Bedienkonzepte oder -teile, die dann aber wieder über standardisierte Schnittstellen mit dem universellen Zentralrechner kommunizieren. Der Kunde meint, er hätte zwei verschiedene Systeme vor sich, in Wahrheit  haben wir nur einen kleinen Teil des Systems variiert: das HMI. Daneben gibt es noch mehrere standardisierte Komponenten wie DVD-Spieler/ -Wechlser, TV-Tuner, Telefon oder Verstärker, die in mehreren Modellen unverändert eingesetzt werden, und einige fahrzeugspezifische Komponenten, die markenabhängig sind. Beispielsweise setzt Audi bei Lautsprechern und Audiosystemen auf Bang & Olufsen, VW auf Dynaudio.
Wo liegt dann die Verantwortung, z.B. bei der Entwicklung eines neuen Infotainment-Systems?
Tanneberger: Wir haben vor mehreren Jahren begonnen, sehr eng in Konzernarbeitskreisen zusammenzuarbeiten. Wir treffen uns mehrfach pro Jahr an den verschiedenen Entwicklungsstandorten. Dort werden Roadmaps präsentiert, die grundsätzlich nur abgenickt werden, wenn die entsprechenden Fahrzeuge aller Konzernmarken enthalten sind. So bin ich für die Konzernabstimmung im E/E-Bereich verantwortlich und akzeptiere in dieser Funktion keine Modulentwicklung, die sich nur an VW-Modellen orientiert und andere Konzernmarken ausspart. Natürlich sind bei vielen Entwicklungen VW und Audi federführend und Seat bzw. Skoda übernehmen das, worauf sich die beiden großen Marken geeinigt haben, aber das ist kein Dogma. Beispielsweise wird Skoda für den neuen MIB das Einstiegsmodell entwickeln, das dann auch von den anderen Marken übernommen wird. Wichtig bei dieser Vorgehensweise  ist aber auch, dass wir die Protokolle standardisiert haben: Das CAN-Protokoll, das Bedienanzeige-
Protokoll und auch MOST, das bisher nur bei Audi eingesetzt wurde, sind jetzt Teil des MIB und weitgehend ver-einheitlicht. Diese Standardisierung ermöglicht erst die Modularisierung. Die Entwickler haben dabei gemerkt, dass diese Modularisierung eine echte Entlastung und maßgeblich für den Firmenerfolg ist – das fördert dann auch ein gewisses Vertrauensverhältnis zwischen den einzelnen Konzernmarken.
Inwieweit betrifft die Standardisierung auch die Software?
Tanneberger: Unsere Zulieferer werden bereits seit zehn Jahren mit unserer  Standard-Software versorgt, die im Wesentlichen Diagnose-Funktionen sowie CAN- und LIN-Kommunikation bündelt. Zusätzlich haben wir jetzt, mit der Zielsetzung, die CO2-Emissionen zu reduzieren, damit begonnen, das Energie-Management zu standardisieren. Auch im HMI-Bereich haben wir in den letzten Jahren viel Eigenentwicklung betrieben. Stammte unser HMI noch vor zehn Jahren vollständig von unseren Zulieferern, so verfügen wir mittlerweile über ein komplett selbst entwickeltes VW-HMI, das gute Kritiken erhält und im Markt als Wiedererkennungsmerkmal dient. Eine HMI-Spezifikation – so unsere Erfahrung – ist sehr umfangreich. Diese Software selbst zu entwickeln, ist daher deutlich effizienter.
 

Heißt Software-Standardisierung bei VW automatisch AUTOSAR?
Tanneberger: AUTOSAR ist uns bisher noch den Nachweis schuldig geblieben, dass wir den Kostenvorteil in den Steuergerätepreisen wiederfinden. Das ist für mich das entscheidende Kriterium. Ich baue nicht AUTOSAR ins Auto um des AUTOSARs willen. Wenn ich Standard-Software wiederverwende, sinkt der Entwicklungsaufwand bei den Lieferanten. Daraufhin sollten sich die Entwicklungszeiten verkürzen und so die Entwicklungskosten sinken. Im Moment sehe ich aber eher, dass die Kosten nach oben gehen, da mit AUTOSAR mehr Rechenleistung und Speicher benötigt wird. Deshalb fällt in Zeiten, in denen verstärkt kosteneffizient entwickelt werden muss, die Entscheidung teilweise auch gegen AUTOSAR. In einigen Steuergeräten, z.B. dem Gateway im MQB, werden wir aber AUTOSAR-konform implementieren, nicht dogmatisch, aber unter wirtschaftlichen Gesichtspunkten. Speziellbeim Gateway haben wir ein Angebot bekommen, bei dem die AUTOSAR- Implementierung wettbewerbsfähig ist. Wir entscheiden uns aber nicht für AUTOSAR, wenn es einen Aufpreis bedeutet.
AUTOSAR wird mittlerweile vorgeworfen, viel zu umfangreich zu sein, um es effizient umsetzen zu können. Wie stehen Sie dazu?
Tanneberger: Das sehe ich ähnlich. Jede Form von Standardisierung ist prinzipiell richtig, weil sich daraus Effizienzsteigerungen und Synergieeffekte ergeben. Allerdings kann es passieren, dass der Aufwand, um komplexe Systeme zu beschreiben und zu spezifizieren, größer ist als der eigentliche Entwicklungsaufwand. Man muss deshalb die Systemgrenzen von AUTOSAR betrachten. Für Komfortelektronik passt AUTOSAR wunderbar. Bei Infotainment ist es eher schwierig. Zudem kommt noch Politik mit ins Spiel: Jeder OEM integriert unterschiedliche  ettbewerbsgesichtspunkte in seine Entwicklungen.  Das macht es schwierig, auf einen gemeinsamen Nenner zu kommen.
In Bereichen, in denen man bei der Standardisierung einen gemeinsamen Konsens findet und innerhalb eines definierten Zeitraums, z.B. innerhalb von zwei Jahren, eine Referenzimplementierung vorweisen kann, ist eine
Standardisierung aber sicher sinnvoll.
Ist damit der Misserfolg von AUTOSAR 4.0 bereits vorprogrammiert?
Tanneberger: Nein, AUTOSAR wird mehr und mehr in komplexen Systemen Anwendung finden. Allerdings wird dieser Prozess evolutionär und nicht revolutionär vonstatten gehen. Wir brauchen erst einige Erfolgsgeschichten bei kleinen überschaubaren Steuergeräten, dann wird der AUTOSAR- Anteil stetig zunehmen. Wir treffen aber keine Voraussagen wie „Unser nächstes Modell wird 100 Prozent AUTOSAR-konform“.
Betrifft die Standardisierung der Protokolle auch FlexRay und MOST, die bisher ja nur bei Audi zum Einsatz kommen?
Tanneberger: Ja, CAN ist und bleibt bei VW der Standard-Bus für Komfort und Infotainment, allerdings wird FlexRay kurzfristig wegen der Echtzeit- Fähigkeit und der höheren Datenübertragungsrate bei Fahrerassistenzsystemen zum Einsatz kommen, z.B. im nächsten Touareg. Dabei bauen wir zwar auf Audi-Know-how auf, allerdings müssen bei FlexRay ohnehin für jedes Fahrzeug, aufgrund unterschiedlicher Busteilnehmer und Leitungslängen, die Busabschlüsse neu definiert und die Timings neu festgelegt werden. Das bedeutet natürlich auch, dass wir den Audi-Standard-Parametersatz anpassen müssen. MOST150 wollen wir  in die nächste MQB-Version (Golf/Passat) integrieren. Deshalb versuchen wir derzeit, unsere Zulieferer zu motivieren, bis Ende 2010 serienreife MOST150-Komponenten – v.a. MOST150-Transceiver – zur Verfügung zu stellen. Wir beginnen gerade jetzt, über diese neue Plattform nachzudenken, SOPs werden definiert und B-Muster sollen bereits Ende nächsten Jahres vorliegen. Nach Ablauf dieser Frist wird die Plattform nicht mehr geändert, gegebenenfalls müssen wir uns auch für eine andere Technologie entscheiden, um unsere Kundenanforderungen zu erfüllen. Der Kunde kauft schließlich nicht MOST, er kauft eine Funktion. Wie diese implementiert wird, ist für ihn irrelevant.