Interview: Vehicle OS als ein Enabler für das Software-Defined-Vehicle
Ein Vehicle OS stellt ein ganzheitliches Ökosystem für Automotive-Software dar. Die derzeit in der Entwicklung befindlichen Projekte basieren auf unterschiedlichen Ansätzen und Lösungen. Ist hier eine Vereinheitlichung wünschenswert, oder ist es dafür nicht schon zu spät? Und widerspricht eine Standardisierung nicht dem Bedarf nach einer schnellen Lösung? Darüber haben wir mit Dr. Günther Heling, Leiter Embedded Software und Systeme bei Vector, gesprochen.
all-electronics: Herr Dr. Heling, beim Thema Software für Fahrzeuge kursieren derzeit die Schlagworte Software-Defined-Vehicle, SDV und Vehicle OS. Wie ist Ihre Einschätzung zum Begriff Software-Defined-Vehicle – hat sich da schon ein gemeinsames Verständnis ausgeprägt?
Dr. Günther Heling: Der Begriff Software-Defined-Vehicle wird recht einheitlich gebraucht: Es bezeichnet eine neue Generation von Fahrzeugen, deren Verhalten nur noch zum Teil durch die Mechanik und die verbaute Hardware definiert ist. Stattdessen wird das Verhalten und der Funktionsumfang des Fahrzeugs ganz überwiegend durch die Software bestimmt. Die Software ist dabei auf Fahrzeug und Cloud verteilt und wird über die Lebensdauer des Fahrzeugs aktuell gehalten. In der Architektur eines SDV führen auf oberster Ebene zwei bis fünf Zentralrechner, High Performance Computer, kurz HPC genannt, die wettbewerbsdifferenzierenden Berechnungen mit hohem Ressourcenbedarf aus. Hier findet auch der Austausch mit ergänzenden Funktionen in der Cloud statt. Auf der nächsten Ebene übernehmen zwei bis vier Zonenrechner die Transformation der serviceorientierten Kommunikation.
all-electronics: Der Begriff „Vehicle OS“ ist aber doch eher missverständlich, da es sich nicht um ein „Operating System“ im eigentlichen Sinne handelt. Wie definieren Sie den Begriff?
Dr. Günther Heling: Das „Vehicle OS“ ist ein zentraler Baustein im SDV: Es besteht zum einen aus einer Laufzeitsoftware im Fahrzeug und in der Cloud („SW Base Layer“), die mit ihren Grundfunktionen den Rahmen für die Applikationssoftware darstellt. Im Fahrzeug gibt es verschiedene Ausprägungen des SW Base Layer: Auf den Zentralrechnern weist der zugehörige SW Base Layer den größten Funktionsumfang auf. So beispielsweise zur zentralen Erfassung von Security-relevanten Daten oder zur Steuerung von Softwareupdates im Fahrzeug. Entscheidend ist, dass alle Ausprägungen des SW Base Layer in einem Fahrzeug und in der Cloud aufeinander abgestimmt sind. Sie ergänzen sich also in ihren Funktionen und unterstützen eine effiziente und transparente Kommunikation zwischen den Elementen der Applikationssoftware.
Zum anderen gehört zum Vehicle OS neben dem SW Base Layer auch eine Entwicklungsumgebung („SW Factory“), die die gesamte Developer’s Journey mit einem hohen Maß an Automatisierung in den Bereichen „Continuous Integration“, „Continuous Testing“ und „Continuous Deployment“ (CI, CT, CD) unterstützt. Ohne eine leistungsfähige SW Factory, die die Entwicklung auf allen Hardwareplattformen und alle Steuergeräteklassen unterstützt, wird man das Potential eines Vehicle OS nicht heben können.
all-electronics: Wenn das Vehicle OS lediglich Grundfunktionen bereitstellt, ist es naheliegend, dass ein vereinheitlichtes Vehicle OS von verschiedenen Fahrzeugherstellern und Zulieferern genutzt wird. Das ist derzeit nicht zu beobachten. Wie sehen Sie die Chancen für eine einheitliche Lösung und wie könnte diese erreicht werden.
Dr. Günther Heling: Das ist in der Tat ein kritischer Punkt, da sich die Wettbewerbsdifferenzierung in den Applikationsfunktionen jenseits des Vehicle OS ausprägen sollte. Andererseits stellt das Vehicle OS das Rückgrat der Software insgesamt dar und so ist es nachvollziehbar, dass die Fahrzeug-Hersteller dieses Rückgrat gestalten und beherrschen wollen. Die individuelle Gestaltung lässt sich allerdings auch durch anpassbare Standardfunktionen und im Einzelfall spezifisch entwickelte Funktionen auf der Grundlage einer vereinheitlichten Struktur sehr effizient verwirklichen.
all-electronics: Eine Standardisierung widerspricht aber dem Bedarf nach schnellen und flexiblen Lösungen.
Dr. Günther Heling: Nicht unbedingt. Eine Standardisierung auf einer oberen Architekturebene sollte recht schnell gelingen und würde schon einen großen Vorteil bringen. Derzeit wird noch nicht einmal der Begriff „Middleware“ einheitlich verstanden. Durch die fehlende Definition entsprechender Schnittstellen lassen sich wiederverwendbare Softwarebausteine, wie beispielsweise zum Sammeln von Daten im Fahrzeug oder für das Update eines Steuergeräteverbunds, nur schwer umsetzen. Mit dem durch eine Standardisierung ermöglichten hohen Reuse-Anteil erreichen wir letztlich die benötigte hohe Entwicklungsgeschwindigkeit.
all-electronics: Könnte hier ein Open-Source-Ansatz mit dem „Code-First“ Gedanken ideal passen?
Dr. Günther Heling: Grundsätzlich ja. Open-Source funktioniert ja immer dann gut, wenn es viele gibt, die einen gleichen Bedarf haben, und eine Organisation das Open-Source-Projekt professionell steuert und verwaltet. Herausfordernd ist in diesem Fall, dass der Bedarf im Detail doch etwas unterschiedlich ist, dass die entstehende Software höchsten Qualitäts- und Sicherheitsansprüchen nachweislich genügen muss und dass die Nutzer sicher sein müssen, dass die Software langfristig gepflegt und erweitert wird. Letzteres nicht nur auf einem Entwicklungsstrang, sondern auf allen Varianten, die aktiv in Verwendung sind.
all-electronics: Derzeit befinden sich allerdings schon viele Vehicle OS-Projekte in Entwicklung. Ist es nicht schon zu spät, die Vereinheitlichung anzustreben?
Dr. Günther Heling: Ich denke, dass der Zeitpunkt geradezu ideal ist: Durch die laufenden Projekte liegen erste Erfahrungen vor und die Ziele, die angestrebt werden, sind schon deutlich klarer geworden. Zudem bildet sich aktuell die Erkenntnis heraus, dass viele losgelöste Aktivitäten nicht der Weisheit letzter Schluss sind. Und wir sollten uns bewusst machen, dass wir bezüglich des Themas „Vehicle OS“ erst am Anfang stehen. Hinzu kommt, dass die Umstellung von laufenden Projekten durch die Nutzung gemeinsamer Kernelemente – wie beispielsweise der AUTOSAR-Plattformen Classic und Adaptive oder auch einem POSIX-OS – erleichtert wird.
all-electronics: Sie hatten angesprochen, dass eine „SW Factory“ einen Teil eines Vehicle OS darstellt. Worin ist die enge Verbindung begründet?
Dr. Günther Heling: Ein Vehicle OS überspannt alle Domänen – vom Infotainment, über Body, Chassis und Powertrain bis zum Bereich ADAS und AD – sowie die beiden Welten „in-vehicle“ und „in-the-cloud“. Kurze Entwicklungszyklen sind nicht nur in jedem einzelnen dieser Domänen erforderlich, sondern auch Domänen-übergreifend. Kurze Zyklen sind nur erreichbar mit einem hohen Maß an Automatisierung in Konfiguration, Integration und Test. Dazu gehören klassische Build-Chains aber auch Möglichkeiten, die verschiedenen Beschreibungssprachen, die zum Beispiel in der Applikationsentwicklung, in der Kommunikation, in der Virtualisierung, in der Basissoftware-Konfiguration, im Test und im Deployment verwendet werden, möglichst weitgehend automatisiert ineinander zu übersetzen. Eine gewaltige Aufgabe, die aktuell an vielen Stellen gleichzeitig auftritt. Da scheint es mir sinnvoll zu sein, auch hier die Kräfte zu bündeln. Das gelingt umso besser, wenn das zugrunde liegende SW-Framework („SW Base Layer“) einheitlich gestaltet ist. Daraus ergibt sich die enge Verbindung zwischen SW Base Layer und SW-Factory – und damit insgesamt ein Vehicle OS, inklusive leistungsfähigem Ökosystem.