Software-defined Vehicle und Middleware sowie das passende Betriebssystem finden Definition Beim Vehicle OS, manchmal auch Betriebssystem genant, handelt es sich um ein ganzheitliches Ökosystem für Automotive-Software.

Beim Vehicle OS, manchmal auch Betriebssystem genant, handelt es sich um ein ganzheitliches Ökosystem für Automotive-Software. (Bild: Vector Informatik)

Ein Vehicle OS, oft auch Betriebssystem genannt, 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 eventuell 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 in signalbasierte Kommunikation und binden die große Zahl der Funktionssteuergeräte an. Diese werden als intelligente Sensoren beziehungsweise Aktuatoren mit nur geringer Wettbewerbsrelevanz gesehen und sind ohne OEM-spezifische Ausprägung vorstellbar.

 

Definition: Betriebssystem im Fahrzeug / Vehicle OS

All-electronics: Der Begriff „Vehicle OS“ ist aber doch eher missverständlich, da es sich nicht um ein Operating System, also nicht um ein Betriebssystem 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; diese SW Base Layer genannte Laufzeitsoftware stellt mit ihren Grundfunktionen den Rahmen für die Applikationssoftware dar. 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 Software-Updates 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, die SW Factory genannt wird. Die SW Factory unterstützt die gesamte Developer’s Journey mit einem hohen Maß an Automatisierung in den Bereichen Continuous Integration, Continuous Testing und Continuous Deployment, also in den abgekürzt CI, CT und CD genannten Bereichen. 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.

 

Dr Günther Heling Vehicle OS Middleware
Dr. Günther Heling: „Wir sollten uns bewusst machen, dass wir bezüglich des Themas Vehicle OS erst am Anfang stehen.“ (Bild: Vector Informatik)

Die Chancen für ein einheitliches Vehicle OS

All-electronics: Wenn das Vehicle OS lediglich Grundfunktionen bereitstellt, dann ist ja auch nicht wettbewerbsdifferenzierend. Da ist es naheliegend, dass verschiedene Fahrzeughersteller und Zulieferer ein vereinheitlichtes Vehicle OS verwenden. 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 oft 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.

Vehicle OS als Open Source?

All-electronics: Könnte hier ein Open-Source-Ansatz mit dem Code-First-Gedanken doch eine sehr gute Lösung sein…

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 vielleicht sogar 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.

SW Factory als Teil des Vehicle OS

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, also der 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.

Sie möchten gerne weiterlesen?

Unternehmen

Vector Informatik GmbH

Ingersheimer Str. 24
70499 Stuttgart
Germany