Die Automobilindustrie wandelt sich von einer Architektur mit vielen dezentralen Recheneinheiten zu einer Architektur, die mehrere Funktionen in wenigen, zentralen Recheneinheiten kombiniert und neue Funktionen wie Over-the-Air-Updates ermöglicht.
AAOS SDV nutzt das vorhandene Android-System und die vorhandene Infrastruktur, um eine Lösung anzubieten. Darüber hinaus suchen OEMs nach Lösungen, die auch in der Cloud ausgeführt werden können, da dies die frühe Entwicklung erleichtert und neue Testmöglichkeiten bietet.
Design
Abbildung 1 : SDV Core-Architektur
AAOS for SDV Core (SDV Core) ist ein Betriebssystem, das auf Android basiert. Aufgrund seiner eingebetteten Natur wird der JVM-Stack von Android nicht implementiert, sondern alle Systemfunktionen werden nativ entwickelt.
SDV Core wurde hauptsächlich für eine virtualisierte Umgebung entwickelt und einige Designentscheidungen gehen von dieser Integration aus. Dennoch ist es möglich, SDV Core nativ auszuführen. Dies erfordert jedoch im Vergleich zu anderen Android-Versionen einen größeren Integrationsaufwand.
SDV Core wurde für ein lokales verteiltes System entwickelt. Es wird beispielsweise davon ausgegangen, dass mehrere Instanzen von SDV Core (oder Derivaten) entweder auf demselben Chip oder auf mehreren Systemen nebeneinander ausgeführt werden und über eine Netzwerkverbindung kommunizieren können. Ein wichtiger Aspekt der Systemarchitektur ist daher die Implementierung von Funktionen als Dienste, die auf einer beliebigen Instanz gehostet werden können.
SDV Core ist die Mindestmenge an Funktionen, die für die Entwicklung von Funktionen im Auto erforderlich sind. Ein typischer Dienst empfängt einige Signale, verarbeitet sie und gibt das Ergebnis an andere Dienste weiter. Diese Einschränkung des Umfangs ist beabsichtigt, da SDV Core dadurch auf einer Vielzahl von SoCs (System-on-a-Chip) ausgeführt werden kann, die möglicherweise keine erweiterten Engines enthalten, und Kosten gespart werden können.
Detaillierte Konfiguration
Abbildung 2 : Detaillierte SDV Core-Architektur
SDV Core basiert auf Android und daher ist die Architektur so gut wie möglich an Android ausgerichtet. Das bedeutet, dass SDV Core auch GKI, Treiber, HALs und Kernbibliotheken von Android verwendet und Komponenten hinzufügt, die für die Dienstarchitektur erforderlich sind.
In den folgenden Abschnitten werden die Systemkomponenten im Detail behandelt.
Hostumgebung und Virtualisierung
SDV Core wurde mit der Annahme entwickelt, dass es in einer virtuellen Umgebung ausgeführt wird. Daher treffen wir einige Annahmen zur Hostumgebung:
In der Hostumgebung wird ein Hypervisor ausgeführt, der Virtio-Geräte unterstützt. Außerdem muss der Hypervisor Ethernet oder vsock, Energiestatus und Blockgeräte implementieren. Darüber hinaus muss der Hypervisor die Ausführung von Android/Linux unterstützen.
In Bezug auf die Hardware geht SDV Core von einer CPU und einer MMU aus, die Hardwarevirtualisierung unterstützen, und davon, dass das System über Ethernet verbunden ist. Das System muss keine GPU, IPU, CSI, Media-Engines, kein Display oder andere Automotive-Kommunikationsbusse (z.B. CAN, LIN) haben.
Android Base
SDV Core basiert auf Android, reduziert das System jedoch auf die wesentlichen Systemfunktionen und fügt die SDV-Laufzeitumgebung hinzu. Das bedeutet, dass SDV auch GKI, native Systemdienste (z. B. adbd und logd) und Systemfunktionen verwendet, aber keine JVM und keine JVM-basierten Dienste oder Systemanwendungen sowie keine für JVM implementierten Funktionen enthält.
Das bedeutet auch, dass SDV die Update-Strategie und das Partitionsschema von Android übernimmt. Es hat ähnliche Sicherheitsanforderungen, aber keine GUI.
GKI, Treiber und HAL
SDV Core verwendet den GKI-Kernel von Android mit dem Android 6.1-Kernel. Der Vorteil der Verwendung von GKI besteht darin, dass Änderungen, die im Upstream vorgenommen werden, letztendlich in Android landen. Außerdem verwendet Android einen Kernel für die gesamte Flotte. Patches werden beispielsweise zentral angewendet und nicht auf mehrere Anbieter-Kernel.
Dadurch hat SDV auch eine stabile Kernelschnittstelle. Sie können beispielsweise Treiber als Module kompilieren, die mit dem GKI funktionieren, auch wenn ein neuer Kernel mit Sicherheitskorrekturen bereitgestellt wird.
Der GKI-Kernel hat einen festen Zeitplan. Änderungen von Anbietern, die Teil des nächsten GKI-Kernels werden sollen, müssen bis Ende des Jahres an den Linux-Kernel übertragen werden.
Mit GKI werden Gerätetreiber und Module, die nicht für den Start erforderlich sind, als Kernelmodule kompiliert und in einer Ramdisk gespeichert, die während des frühen Starts geladen wird. Sehr frühe Gerätekonfigurationen, die nicht auf die Kernelmodulschnittstelle warten können (z. B. zufällige Initialisierung), müssen im Gerätetree erfolgen. Kernelmodule müssen nicht übertragen werden, sondern müssen mit den GKI-Schnittstellen kompiliert werden.
Da SDV Core davon ausgeht, dass es auf einem Virtio-kompatiblen Hypervisor basiert, werden Treiber als Virtio-Kernelmodule bereitgestellt, wenn die Funktion unterstützt wird, oder als ein anderer offener Standard (z. B. Open Profile for DICE und der Open-DICE-Kernel-Treiber für Vertrauenswürdigkeit).
Diese Kombination aus Virtio (und offenen Standards) und einem Hypervisor führt zu einer Hardwareabstraktion. Daher ist der Bedarf an HALs in SDV minimal, aber einige sind weiterhin erforderlich, da die Virtio-Unterstützung fehlt. Beispielsweise die KeyMint HAL für hardwaregestützte Kryptografie und die eng verwandte IRemotelyPrivisionedComponent HAL für die Attestierung zwischen SDV-VMs.
Netzwerk- und Kommunikationsstack
Abbildung 3 : Netzwerk- und Kommunikationsstack von SDV Core
Für die Vernetzung geht SDV Core davon aus, dass entweder vsock oder Ethernet für die Kommunikation zwischen VMs verfügbar sind. Für die VM-interne Kommunikation können auch IPC-Mechanismen wie Binder verwendet werden.
SDV unterstützt die serielle Kommunikation nur zu Debugging-Zwecken.
Abbildung 4 : Serielle Unterstützung von SDV Core für das Debugging
Innerhalb eines einzelnen Gastes bietet SDV mehrere Optionen, die vom Kommunikationsmodell und den Leistungsanforderungen abhängen.
Vsock
Vsock ist der bevorzugte Kanal für die lokale Kommunikation zwischen mehreren VMs oder zwischen Host und VM. VMs sollten die direkte vsock-Kommunikation untereinander verwenden, damit die Implementierung die Anzahl der Kopien optimieren kann.
Gemeinsamer Speicher
Der gemeinsam genutzte Speicher wird nur für die Kommunikation mit einer VM für IPC (Inter-Process Communication) verwendet, aber nicht als regulärer Kanal für die Kommunikation zwischen mehreren VMs angeboten. Der Host kann den gemeinsam genutzten Speicher verwenden, um Informationen mit dem Gast zu teilen, aber er ist nicht für Netzwerk-Traffic mit hoher Frequenz vorgesehen.
Ethernet
Ethernet wird für die Kommunikation zwischen mehreren SoCs verwendet, d.h. für die Kommunikation im Fahrzeug. Dabei kann es sich um virtualisierte Systeme, aber auch um native Systeme oder Legacy-ECUs handeln.
Das Fahrzeugnetzwerk ist klein genug, dass der IPv4-Adressraum ausreicht, um alle verfügbaren Systeme zu identifizieren. Damit das System jedoch mit potenziellen Uplinks und zukünftigen Entwicklungen kompatibel ist, müssen IPv4 und IPv6 unterstützt werden.
VLAN
VLAN ist ein Mechanismus zum Erstellen virtueller Netzwerkarchitekturen, mit denen verschiedene Subnetze isoliert und lokale Netzwerke gebildet werden können. Dies kann zum Erstellen verschiedener Sicherheitszonen verwendet werden und wird zu diesem Zweck in Autos eingesetzt. Die VLAN-Unterstützung ist erforderlich.
Protokolle
TCP und UDP
Je nach Anwendungsfall benötigt das System entweder ein zuverlässiges oder ein unzuverlässiges, aber schnelles Kommunikationsprotokoll. Daher werden TCP und UDP unterstützt.
Datentunnel
Data Tunnel ist ein neu entwickelter Kommunikationsmechanismus für SDV, der einen schnellen Kommunikationskanal nach dem Pub/Sub-Modell bietet. Eine Anwendung veröffentlicht beispielsweise ein Thema, während eine oder mehrere Anwendungen darauf hören können. Intern wird entweder der gemeinsam genutzte Speicher und FMQ (Fast Message Queues) innerhalb der VM oder vsock oder Ethernet für die Kommunikation zwischen VMs verwendet.
(SDV) RPC
SDV RPC implementiert Remoteprozeduraufrufe für SDV mithilfe von Binder. Dabei wird eine vordefinierte API verwendet, um eine Remoteprozedur aufzurufen. Ähnlich wie bei Data Tunnel wird entweder der gemeinsam genutzte Speicher für die Kommunikation innerhalb der VM oder vsock oder Ethernet für die VM-übergreifende Kommunikation verwendet.
Frameworks
SOMEIP
SOMEIP wird für die Kommunikation mit Nicht-SDV-Systemen verwendet. Es basiert auf TCP und UDP und erfordert keine spezielle Hardware oder Treiber. Google wird eine Referenz implementieren.
Service Discovery Agent (SD Agent)
Er bietet Service Discovery, Authentifizierung und Autorisierung für SDV. Für die Kommunikation können alle zuvor genannten Methoden verwendet werden. Für die Authentifizierung und Autorisierung benötigt der SD Agent Zugriff auf die Sicherheitshardware und eine funktionierende Vertrauenskette.
Middleware
SDV entwickelt ein Framework, um die Verwendung all dieser verschiedenen Protokolle zu vereinfachen. Es wird als Middleware bezeichnet. Außerdem wird mit der neuen Sprache VSIDL eine zentrale Informationsquelle für alle Fahrzeugsignale implementiert.
Neutrale Zone
Um Teile des Systems zu isolieren und Angriffe von einem weniger vertrauenswürdigen Teil des Systems zu verhindern (z. B. IVI mit benutzerdefinierten installierten Apps), können im Netzwerk verschiedene Zonen eingeführt werden, darunter eine oder mehrere demilitarisierte Zonen. In der Praxis bedeutet das, dass Subnetze physisch oder logisch getrennt sind und nur zugelassener Traffic diese Grenzen passieren kann.
Verbindungsmanager
In Android ist es üblich, die Anzahl der Anwendungen und Dienste zu begrenzen, die selbst Socketverbindungen öffnen können. Stattdessen ist eine zentrale Instanz für das Öffnen und Verwalten von Verbindungen zuständig. Da Android diese Funktion in einem Java-Dienst implementiert, erstellt SDV einen eigenen Verbindungsmanager.
Aktualisierbarkeit
Ein wichtiges SDV-Feature ist die Aktualisierbarkeit. Neue Funktionen können während der gesamten Lebensdauer von SDV über Android-Systemupdates und APEX-Pakete installiert werden.
Android-Systemupdates
Android bietet bereits einen Mechanismus zum Installieren von Updates. In den letzten Versionen werden A/B- und virtuelle A/B-Updates verwendet und SDV Core nutzt diesen Mechanismus. Bei A/B-Updates wird jede Partition zweimal erstellt. Das hat zwei Vorteile: Das System kann im Hintergrund aktualisiert werden und wenn das Update fehlschlägt, kann das System auf die letzte bekannte Version zurückgesetzt werden.
APEX-Pakete
Android teilt das System nicht nur in mehrere Partitionen auf und macht sie aktualisierbar, sondern bietet auch APEX-Pakete. Das ist ein Mechanismus, um Anwendungen und Bibliotheken in kleine Pakete zu packen, die unabhängig von Systemupdates installiert und aktualisiert werden können.
SDV Core verwendet APEX-Container, um Dienste dynamisch auf einer SDV-Instanz zu installieren, aber auch um die Bereitstellung mehrerer Dienste in einem einzigen Prozess zu verwalten. Nur Dienste, die im selben APEX gebündelt sind und dasselbe Zertifikat verwenden, können in derselben Binärdatei bereitgestellt werden, um Sicherheitsrisiken zu verringern.
Der Android-Mechanismus zum Installieren von APEX-Paketen verwendet Java-Code für die APK-Verwaltung, um Pakete zu überprüfen. SDV Core muss eine native Alternative implementieren, um die dynamische Installation von APEX-Paketen zu ermöglichen.
Updateverwaltung
SDV-Instanzen sind im Auto keine vollständig unabhängigen Einheiten, sondern müssen mit anderen SDV-Instanzen und Autodiensten koordiniert werden. Beispielsweise, um Dienstabhängigkeiten zu installieren oder um sicherzustellen, dass Updates nur in einem sicheren Systemzustand installiert werden.
SDV erwägt die Verwendung von Partitionen auf mehreren VMs. Das erfordert eine Koordination zwischen diesen VMs, da sie voneinander abhängig sind. Es muss eine primäre VM geben, um diese Partitionen zu aktualisieren, und einen Mechanismus, um die anderen VMs über die aktualisierte Partition zu informieren und die Aktualisierung aller VMs gleichzeitig zu synchronisieren, damit der zuvor bekannte funktionierende Zustand nicht unterbrochen wird.
Erste Schritte
In unserer Anleitung Erste Schritte finden Sie Details zum Quellcode sowie zum Erstellen und Starten mit Cuttlefish.