Software-defined-Vehicle: Lava verbindet Android mit Autosar

Die Automobilbranche definiert sich zunehmend als eine durch Software-Innovationen geprägte Industrie, und häufig taucht auch der Begriff „SDV“ (Software-Defined Vehicle) auf. Doch oft ist „SDV“ nur ein Schlagwort, das verschleiert, dass die Automobilindustrie vor einer erheblichen Softwarekrise steht. Ein gutes Beispiel dafür sind die zahlreichen Berichte über teilweise monatelange Verzögerungen in der Fahrzeugproduktion, die aufgrund von Softwareproblemen entstehen.

Die Gründe für diese Verzögerungen sind vielfältig. Ein Faktor ist die komplexe Autosar-basierte Entwicklungsumgebung. Autosar hat seine Wurzeln in sicherheitskritischen Fahrzeugsystemen und ist zweifellos wichtig, aber für die Entwickler aktueller Apps, insbesondere aus dem Android-Ökosystem, äußerst unattraktiv. Android-Entwickler finden es oft mühsam und wenig ansprechend, sich in automobilspezifische Entwicklungsumgebungen einzuarbeiten. Daher hat die Automobilindustrie Schwierigkeiten, erstklassige Android-Entwickler für ihre Software-Entwicklungsprojekte zu gewinnen.

Um dieses Problem anzugehen, hat der serbische Software-Engineering-Dienstleister RT-RK eine Lösung entwickelt, mit der sich Android-Entwicklungen einfach und schnell in Automobilprojekte einbinden lassen. Die Entwickler bei RT-RK nutzen diese Lösung bereits seit einiger Zeit. Jetzt ist sie unter dem Namen Lava als Produkt erhältlich und öffnet damit der gesamten Android-Entwickler-Community einen einfachen Weg, Software-Applikationen für das Automobil zu entwickeln, ohne sich in die Komplexität von Autosar einarbeiten zu müssen. (Bild 1). Die Abkürzung Lava steht dabei für „Linking Android with Vehicle Autosar“. Das Lava-Tool kann sowohl für klassische als auch für adaptive Autosar-Frameworks und Communication-Stacks zum Einsatz kommen.

Die Ingenieure bei RT-RK haben einen Generator entwickelt, der Autosar-spezifische ARXML-Datenmodelle in AIDL-Modelle wandelt, und mit AIDL (Android Interface Definition Language) sind Android-Entwickler vertraut. Darüber hinaus generiert das Tool automatisch die notwendigen Software-Bindings – „Lava-Bridge“ genannt – für den Android-System-Stack. Diese Lava-Bridges ermöglichen einen nahtlosen Datenaustausch zwischen der Android- und der Autosar-Welt (Bild 2).

Die Prinzipien, die Lava zugrunde liegen, orientieren sich an einer streng modellbasierten Entwicklung (Model Driven Development). Diese Vorgehensweise nutzt Modelle zur Definition des Systemverhaltens. Solche Modelle werden in der Regel in einer spezifischen Schnittstellen-Definitionssprache geschrieben und enthalten einen integrierten Code-Generator, der das beschriebene Modell in den Embedded-Code übersetzt. Modellgetriebene Entwicklung ermöglicht zusätzlich die Erstellung von Metamodellen, die Parameter und Felder der Zielmodell-Sprache beschreiben.

Derzeit nutzt Lava das Eclipse Modelling Framework (EMF) zur Manipulation und Übersetzung von Autosar-Modellen. Zukünftig wird RT-RK auch eine EMF-unabhängige Lava-Variante anbieten. Unabhängig vom Ansatz bleibt eines gleich: Lava ist nicht auf ARXML (Autosar XML, eine Sprache zur Definition des Autosar-Datenmodells), AIDL, FIDL (Franka Interface Definition Language, wird für das Franka Framework von Govesa, vormals Genevi, genutzt) oder OMG (Object Group Managing Group, z. B. für das Managing im DDS-Standard) IDL beschränkt. Neue IDLs lassen sich bei Bedarf direkt und ohne nennenswerte Anpassungen übernehmen.

Lava-Prozessablauf

Der Übersetzungs- und Generierungsprozess von Lava beginnt mit einer ARXML-Datei (Bild 3), die exakt die Autosar-Daten beschreibt, die Android-Entwickler benötigen oder diesen zur Verfügung gestellt werden sollen. Diese ARXML-Datei dient als Input für Lava. Zuerst wird die Datei geparst, um die Datenstruktur anhand von Autosar-XML-Tags und -Entitäten zu extrahieren. Anschließend erstellt Lava ein Modell aller verfügbaren Autosar-Schnittstellen. Darin können die Lava-Anwender auswählen, welche Schnittstellen den Android-Entwicklern zur Verfügung stehen sollen. Wenn alle Schnittstellen verfügbar gemacht werden sollen, kann dieser Schritt entfallen.

Im nächsten Schritt erfolgt die Extrahierung der ausgewählten Schnittstellen. Diese Schnittstellen, die immer noch in der „Autosar-Sprache“ beschrieben sind, übersetzt Lava dann mit Hilfe eines MTM-Translators (MTM: Modell-zu-Modell) in AIDL und stellt sie als AIDL-Dateien bereit. Dabei basiert der gesamte Arbeitsablauf, einschließlich der Datensicherung, auf dem Eclipse Modelling Framework.

Im zweiten Schritt generiert Lava die Bridge-Software für den Android Communication-Stack, wobei die Benutzer zwischen den drei Kommunikationsprotokollen ARA::COM, CommonAPI und Open DDS wählen können:

Das Lava-Bridge-Modul fungiert als Android-Service, der Android-konform mit der Android-Umgebung kommuniziert und gleichzeitig die Inter-Domain-Kommunikation in Richtung Autosar mit den Autosar-spezifischen Protokollen kapselt. Auf diese Weise ermöglicht das Lava-Bridge-Modul den Android-Anwendungen die Nutzung von Daten, die aus Autosar-Steuergeräten oder Autosar-Partitionen stammen; hierfür müssen die Lava-Anwender die zugrunde liegenden Protokolle nicht verstehen, denn die Software generiert automatisch die notwendigen Stub- und Proxy-Code-Sequenzen, die für die Android-Client- und Service-Anwendungen erforderlich sind.

Derzeit unterstützt Lava Some/IP und DDS. Lava-Bridge ist jedoch so konzipiert, dass es Protokoll-agnostisch ist und die Integration anderer Protokolle bei Bedarf einfach ermöglicht. Das Tool unterstützt momentan zwei Ansätze zur Integration von Inter-Domain-Kommunikationsprotokollen bzw. -stacks innerhalb des Lava-Bridge-Moduls. Lava unterstützt zum einen ara::com – und zwar einschließlich aller Protokolle, die der Autosar-Standard unterstützt. Bei den anderen von Lava unterstützten Kommunikations-Management-APIs handelt es sich um Open-Source-Lösungen wie CommonAPI (für SOME/IP) oder OpenDDS (für DDS).

Lava generiert die protokollspezifischen IDL-Dateien (z. B. FIDL/FDEPL oder OMG IDL) sowie die Bridge-Software unter Berücksichtigung zusätzlicher Deployment-Parameter, die nicht durch AIDL ausgedrückt werden können und direkt zum protokollabhängigen IDL-Modell geleitet werden. Zu diesen zusätzlichen Deployment-Parametern zählen zum Beispiel Instanz-IDs, Ereignis-IDs oder IP-Adressen. Die Bridge-Software enthält auch Stub- und Proxy-Code-Sequenzen, die für die Kompatibilität des protokollabhängigen Kommunikations-Stacks erforderlich sind. Diese protokollabhängigen Funktionsaufrufe sind bereits in die Android-Dienst-APIs integriert, wodurch der Android-Dienst einen kohärenten Kommunikationskanal zur Autosar-Welt bildet.

Dieser Ansatz ermöglicht eine nahtlose Integration sowie den Datenaustausch zwischen Autosar- und Android-Umgebungen und ebnet damit den Weg für fortschrittliche Softwarelösungen im Automobilbereich.

Android-Entwickler können sich vollständig auf Android-spezifische Datenmodelle und Werkzeuge konzentrieren, weil Lava die Komplexität von Autosar abstrahiert. Dies vergrößert den Pool an Software-Entwicklern, die der Automobilindustrie zur Verfügung stehen. Mit Lava können diese Entwickler ihr Innovations-Potenzial voll ausnutzen, um das derzeit vage Konzept des „Software-Defined Vehicle“ durch zeitgemäße Software-Lösungen zu konkretisieren und damit für den Endkunden im Fahrzeug erlebbar zu machen.

Dieser Ansatz löst nicht nur bestehende Softwareprobleme in der Automobilindustrie, sondern ebnet auch den Weg für eine neue Ära, in der sich die Expertise der gesamten Android-Entwicklergemeinschaft barriereloser nutzen lässt. (na)