Die Automobilindustrie bewegt sich von einer Architektur mit vielen dezentralen Recheneinheiten zu einer Architektur, die mehrere Funktionen in wenigen zentralen Recheneinheiten kombiniert, die neue Funktionen wie Over-the-Air-Updates ermöglichen.
AAOS SDV nutzt das vorhandene Android-System und die vorhandene Infrastruktur, um eine Lösung anzubieten. Außerdem 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 für SDV Core (SDV Core) ist ein Betriebssystem, das auf Android basiert. Aufgrund seiner eingebetteten Natur wird der JVM-Stack von Android nicht implementiert. Stattdessen werden alle Systemfunktionen nativ entwickelt.
SDV Core wurde hauptsächlich für eine virtualisierte Umgebung entwickelt und einige Designentscheidungen setzen diese Integration voraus. Es ist jedoch möglich, SDV Core nativ auszuführen. Dies erfordert jedoch im Vergleich zu anderen Android-Releases einen größeren Integrationsaufwand.
SDV Core ist für ein lokales verteiltes System konzipiert. Es wird davon ausgegangen, dass mehrere Instanzen von SDV Core (oder Derivate) nebeneinander auf demselben Chip oder auf mehreren Systemen ausgeführt werden und über eine Netzwerkverbindung kommunizieren können. Ein Kernaspekt der Systemarchitektur ist daher die Implementierung von Funktionen als Dienste, die auf jeder der Instanzen gehostet werden können.
SDV Core ist der Mindestsatz an Funktionen, die für die Entwicklung von Funktionen im Fahrzeug 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 so auf einer Vielzahl von SoCs (System-on-a-Chip) ausgeführt werden kann, die möglicherweise keine erweiterten Engines enthalten, und Kosten spart.
Detailliertes Design
Abbildung 2: Detaillierte Architektur von SDV Core.
SDV Core basiert auf Android. Daher ist die Architektur so weit wie möglich an Android ausgerichtet. Im Wesentlichen bedeutet dies, 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 beschrieben.
Hostumgebung und Virtualisierung
SDV Core wird unter der Annahme entwickelt, dass es in einer virtuellen Umgebung ausgeführt wird. Daher treffen wir einige Annahmen über die 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 blockorientierte Geräte implementieren. Außerdem muss der Hypervisor die Ausführung von Android/Linux unterstützen.
In Bezug auf die Hardware setzt SDV Core eine CPU und eine MMU voraus, die Hardwarevirtualisierung unterstützen, und dass das System über Ethernet verbunden ist. Das System muss keine GPU, IPU, CSI, Medien-Engines, kein Display oder andere Kommunikationsbusse für Fahrzeuge (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 JVM-basierten Dienste oder Systemanwendungen oder für JVM implementierte Funktionen enthält.
Das bedeutet auch, dass SDV die Updatestrategie und das Partitionslayout 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 Upstream landen, schließlich in Android landen. Außerdem wird auf allen Android-Geräten derselbe Kernel verwendet. Patches werden beispielsweise zentral und nicht auf mehreren Anbieter-Kernels angewendet.
Dadurch kann SDV auch eine stabile Kernel-Schnittstelle haben. 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 in den Linux-Kernel übernommen werden.
Mit dem GKI werden Gerätetreiber und Module, die nicht für den Start erforderlich sind, als Kernelmodule kompiliert und in einer Ramdisk enthalten, 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ätebaum vorgenommen werden. Kernelmodule müssen nicht upstreamed werden, müssen aber für die 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-Kerneltreiber für Vertrauen).
Diese Kombination aus Virtio (und offenen Standards) und einem Hypervisor führt zu einer Hardwareabstraktion. Daher sind HALs in SDVs nur minimal erforderlich, aber einige sind aufgrund der fehlenden Virtio-Unterstützung dennoch erforderlich. Beispiele sind der KeyMint-HAL für hardwaregestützte Kryptografie und der eng damit verbundene IRemotelyPrivisionedComponent-HAL für die Attestierung zwischen SDV-VMs.
Netzwerk- und Kommunikationsstack
Abbildung 3: SDV Core Networking and Communication Stack.
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: SDV Core-Unterstützung für serielle Verbindungen zur Fehlerbehebung.
Innerhalb eines einzelnen Gasts 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 Host und VM. VMs sollten die direkte vsock-Kommunikation untereinander verwenden, damit die Implementierung die Anzahl der Kopien optimieren kann.
Gemeinsamer Speicher
Gemeinsam genutzter Speicher wird nur für die Kommunikation mit einer VM für die IPC (Interprozesskommunikation) verwendet, aber nicht als regulärer Kanal für die Kommunikation zwischen mehreren VMs angeboten. Der Host kann freigegebenen Speicher verwenden, um Informationen mit dem Gast zu teilen. Dies ist jedoch nicht für Netzwerkverkehr mit hoher Frequenz vorgesehen.
Ethernet
Ethernet wird für die Kommunikation zwischen mehreren SoCs verwendet, d. h. für die Kommunikation im Fahrzeug. Das können entweder virtualisierte Systeme, aber auch native Systeme oder ältere Steuergeräte sein.
Das Fahrzeugnetzwerk ist klein genug, dass der IPv4-Adressraum ausreicht, um alle verfügbaren Systeme zu identifizieren. Damit das System mit potenziellen Uplinks und zukünftigen Entwicklungen kompatibel ist, müssen jedoch IPv4 und IPv6 unterstützt werden.
VLAN
VLAN ist ein Mechanismus zum Erstellen virtueller Netzwerkarchitekturen, mit denen verschiedene Subnetzwerke isoliert und lokale Netzwerke gebildet werden können. Damit können verschiedene Sicherheitszonen erstellt werden, was auch in Autos genutzt wird. 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. Beispielsweise veröffentlicht eine Anwendung ein Thema, während eine oder mehrere Anwendungen es abhören können. Intern werden entweder freigegebener 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 Remote-Prozeduraufrufe für SDV mithilfe von Binder. Dabei wird eine vordefinierte API verwendet, um eine Remote-Prozedur aufzurufen. Ähnlich wie Data Tunnel wird entweder der freigegebene Arbeitsspeicher 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 implementiert eine Referenz.
Service Discovery Agent (SD-Agent)
Sie bietet Service Discovery, Authentifizierung und Autorisierung für SDV. Für die Kommunikation kann eine der zuvor genannten Methoden verwendet werden. Für die Authentifizierung und Autorisierung benötigt der SD-Agent Zugriff auf Sicherheitshardware und eine funktionierende Vertrauenskette.
Middleware
SDV entwickelt ein Framework, um die Verwendung all dieser verschiedenen Protokolle zu vereinfachen, die als Middleware bezeichnet werden. Außerdem wird mit der neuen Sprache VSIDL eine „Source of Truth“ für alle Fahrzeugsignale implementiert.
Neutrale Zone
Um Teile des Systems zu isolieren und Angriffe von weniger vertrauenswürdigen Teilen des Systems (z. B. IVI mit benutzerdefinierten installierten Apps) zu verhindern, können im Netzwerk verschiedene Zonen, einschließlich demilitarisierter Zonen, eingerichtet werden. In der Praxis bedeutet dies, dass Subnetzwerke physisch oder logisch getrennt sind und nur Traffic auf der Zulassungsliste diese Grenzen passieren kann.
Verbindungsmanager
In Android ist es üblich, die Anzahl der Anwendungen und Dienste zu begrenzen, die selbst Socket-Verbindungen öffnen können. Stattdessen ist eine zentrale Instanz für das Öffnen und Verwalten von Verbindungen verantwortlich. Da Android diese Funktion in einem Java-Dienst implementiert, erstellt SDV einen eigenen Verbindungsmanager.
Aktualisierbarkeit
Ein wichtiges Merkmal von SDVs ist die Aktualisierbarkeit. Neue Funktionen können während der gesamten Lebensdauer des SDV über Android-Systemupdates und APEX-Pakete installiert werden.
Android-Systemupdates
Android bietet bereits einen Mechanismus zum Installieren von Updates. In neueren Versionen werden A/B- und virtuelle A/B-Updates verwendet. 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 funktionierende Version zurückgesetzt werden.
APEX-Pakete
Zusätzlich zur Aufteilung des Systems in mehrere Partitionen und zur Aktualisierung dieser Partitionen bietet Android auch APEX-Pakete. Mit diesem Mechanismus können Anwendungen und Bibliotheken in kleine Pakete gepackt werden, 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 reduzieren.
Der Android-Mechanismus zur Installation von APEX-Paketen nutzt 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 keine vollständig unabhängigen Einheiten im Auto und müssen mit anderen SDV-Instanzen und Autodiensten orchestriert werden. Beispielsweise, um Dienstabhängigkeiten zu installieren oder um sicherzustellen, dass Updates nur in einem sicheren Systemzustand installiert werden.
SDV zieht die Verwendung von Partitionen über mehrere VMs hinweg in Betracht. Dies erfordert eine Koordination zwischen diesen VMs, da sie eine Datenabhängigkeit voneinander haben: Es muss eine primäre VM geben, um diese Partitionen zu aktualisieren, und einen Mechanismus, um die anderen VMs über die aktualisierte Partition und die Synchronisierung zu benachrichtigen, damit alle VMs gleichzeitig aktualisiert werden und der vorherige bekannte Arbeitszustand nicht unterbrochen wird.
Erste Schritte
In unserem Startleitfaden finden Sie Details zum Quellcode, zum Erstellen und zum Starten mit Cuttlefish.