Il settore automobilistico sta passando da un'architettura con molte unità di calcolo decentralizzate a un'architettura che combina più funzionalità in poche unità di calcolo centralizzate che consentono nuove funzionalità come gli aggiornamenti over-the-air.
L'SDV AAOS utilizza il sistema e l'infrastruttura Android esistenti per offrire una soluzione. Inoltre, gli OEM cercano soluzioni che possano essere eseguite anche nel cloud, in quanto ciò facilita lo sviluppo iniziale e consente nuove possibilità di test.
Design
Figura 1. Architettura SDV Core.
AAOS per SDV Core (SDV Core) è un sistema operativo basato su Android. A causa della sua natura incorporata, non implementa lo stack JVM di Android, ma tutte le funzionalità di sistema sono sviluppate in modo nativo.
SDV Core è sviluppato principalmente per un ambiente virtualizzato e alcune decisioni di progettazione presuppongono questa integrazione. Tuttavia, è possibile eseguire SDV Core in modo nativo, ma ciò richiede un lavoro di integrazione maggiore rispetto ad altre release di Android.
SDV Core è progettato per un sistema distribuito locale, ad esempio presuppone che più istanze di SDV Core (o derivati) vengano eseguite l'una accanto all'altra sullo stesso chip o su più sistemi e che possano comunicare tramite una connessione di rete. Pertanto, un aspetto fondamentale dell'architettura del sistema è l'implementazione della funzionalità come servizi che possono essere ospitati su qualsiasi istanza.
SDV Core è l'insieme minimo di funzionalità per sviluppare funzionalità per l'auto. Un servizio tipico riceve alcuni indicatori, li elabora e condivide il risultato con altri servizi. Questa limitazione dell'ambito è intenzionale, in quanto consente a SDV Core di eseguire un'ampia gamma di SoC (System-on-a-chip) che potrebbero non contenere motori avanzati e di risparmiare sui costi.
Progettazione dettagliata
Figura 2. Architettura dettagliata di SDV Core.
SDV Core deriva da Android, pertanto la sua architettura cerca di allinearsi ad Android nel miglior modo possibile. In sostanza, ciò significa che SDV Core utilizza anche GKI, driver, HAL e librerie di base di Android e aggiunge i componenti necessari per l'architettura dei servizi.
Le sezioni seguenti descrivono in dettaglio i componenti del sistema.
Ambiente host e virtualizzazione
SDV Core è sviluppato partendo dal presupposto che verrà eseguito in un ambiente virtuale, pertanto facciamo alcune ipotesi sull'ambiente host:
L'ambiente host esegue un hypervisor che supporta i dispositivi Virtio. Inoltre, l'hypervisor deve implementare Ethernet o vsock, stati di alimentazione e dispositivi a blocchi. Inoltre, l'hypervisor deve supportare l'esecuzione di Android/Linux.
Per quanto riguarda l'hardware, SDV Core presuppone una CPU e una MMU che supportano la virtualizzazione hardware e che il sistema sia connesso tramite Ethernet. Il sistema non deve necessariamente disporre di GPU, IPU, CSI, motori multimediali, display o altri bus di comunicazione per il settore automotive (ad es. CAN, LIN).
Android Base
SDV Core si basa su Android, ma riduce il sistema alle funzionalità di sistema essenziali e aggiunge l'ambiente di runtime SDV. Ciò significa che SDV utilizza anche GKI, servizi di sistema nativi (ad esempio adbd e logd) e funzionalità di sistema, ma non include JVM, servizi o applicazioni di sistema basati su JVM, né funzionalità implementate per JVM.
Ciò significa anche che l'SDV adotterà la strategia di aggiornamento e il layout delle partizioni di Android. Ha requisiti di sicurezza simili, ma non ha una GUI.
GKI, driver e HAL
SDV Core utilizza il kernel GKI di Android con il kernel Android 6.1. Il vantaggio di utilizzare GKI è che le modifiche apportate upstream finiscono per essere integrate in Android. Inoltre, Android utilizza un unico kernel per l'intero parco risorse. Ad esempio, le patch vengono applicate centralmente anziché a più kernel dei fornitori.
In questo modo, l'SDV può anche avere un'interfaccia kernel stabile. Ad esempio, puoi compilare i driver come moduli che funzionano con la GKI anche quando viene eseguito il deployment di un nuovo kernel con correzioni di sicurezza.
Il kernel GKI ha una cronologia fissa, le modifiche del fornitore che dovrebbero far parte del kernel GKI successivo devono essere integrate nel kernel Linux entro la fine dell'anno.
Con GKI, i driver dei dispositivi e i moduli non necessari per l'avvio verranno compilati come moduli kernel e saranno contenuti in un ramdisk caricato durante la fase iniziale di avvio.Le configurazioni dei dispositivi molto iniziali che non possono attendere l'interfaccia del modulo kernel (ad es. l'inizializzazione casuale) devono essere eseguite nel Device Tree. Non è necessario che i moduli kernel siano upstream, ma devono essere compilati in base alle interfacce GKI.
Poiché SDV Core presuppone che sia basato su un hypervisor compatibile con Virtio, i driver vengono forniti come moduli kernel Virtio se la funzionalità è supportata o come un altro standard aperto (ad esempio, Open Profile per DICE e il driver kernel open-dice per l'attendibilità).
Questa combinazione di Virtio (e standard aperti) e un hypervisor porta all'astrazione dell'hardware. Pertanto, la necessità di HAL negli SDV è minima, ma alcuni sono comunque necessari a causa della mancanza del supporto di Virtio. Ad esempio, l'HAL KeyMint per la crittografia hardware e l'HAL IRemotelyPrivisionedComponent strettamente correlato per l'attestazione tra le VM SDV.
Stack di networking e comunicazione
Figura 3. Stack di networking e comunicazione di base SDV.
Per il networking, SDV Core presuppone che siano disponibili vsock o Ethernet per comunicare tra le VM. La comunicazione interna alle VM può anche utilizzare meccanismi IPC come binder.
SDV supporta la comunicazione seriale solo per scopi di debug.
Figura 4. Supporto seriale SDV Core per il debug.
All'interno di un singolo guest, SDV offre più opzioni che dipendono dal modello di comunicazione e dai requisiti di prestazioni.
Vsock
Vsock è il canale preferito per la comunicazione locale tra più VM o tra host e VM. Le VM devono utilizzare la comunicazione vsock diretta tra loro per consentire all'implementazione di ottimizzare il numero di copie.
Memoria condivisa
La memoria condivisa viene utilizzata solo per comunicare con una VM per l'IPC (comunicazione tra processi), ma non viene offerta come canale regolare per comunicare tra più VM. L'host può utilizzare la memoria condivisa per condividere informazioni con il guest, ma non è previsto per il traffico di rete ad alta frequenza.
Ethernet
Ethernet viene utilizzato per la comunicazione tra più SoC, ovvero per la comunicazione all'interno del veicolo. Possono essere sistemi virtualizzati, ma anche sistemi nativi o ECU legacy.
La rete del veicolo è abbastanza piccola da consentire allo spazio di indirizzi IPv4 di identificare tutti i sistemi disponibili. Tuttavia, per garantire che il sistema sia compatibile con potenziali uplink e sviluppi futuri, è necessario supportare IPv4 e IPv6.
VLAN
La VLAN è un meccanismo per creare architetture di rete virtuale che consentono di isolare diverse sottoreti e di formare reti locali. Questo può essere utilizzato per creare diverse zone di sicurezza e viene utilizzato a questo scopo all'interno delle auto. È richiesto il supporto di VLAN.
Protocolli
TCP e UDP
A seconda del caso d'uso, il sistema richiede un protocollo di comunicazione affidabile o non affidabile, ma veloce. Pertanto, saranno supportati i protocolli TCP e UDP.
Tunnel di dati
Data Tunnel è un meccanismo di comunicazione di nuova concezione per SDV che offre un canale di comunicazione veloce che segue il modello pubsub, ad esempio un'applicazione pubblica un argomento mentre una o più applicazioni possono ascoltarlo. Internamente, utilizza la memoria condivisa e le FMQ (code di messaggi veloci) all'interno della VM oppure vsock o Ethernet per comunicare tra le VM.
RPC (SDV)
SDV RPC implementa le chiamate di procedura remota per SDV sfruttando il binder. Utilizza un'API predefinita per chiamare una procedura remota. Analogamente a Data Tunnel, utilizza la memoria condivisa per la comunicazione all'interno della VM o vsock o Ethernet per la comunicazione tra VM.
Framework
SOMEIP
SOMEIP viene utilizzato per comunicare con sistemi non SDV. È basato su TCP e UDP e non richiede hardware o driver speciali. Google implementerà un riferimento.
Service Discovery Agent (SD Agent)
Fornisce Service Discovery, autenticazione e autorizzazione all'SDV. Per la comunicazione, può utilizzare uno dei metodi menzionati in precedenza. Per l'autenticazione e l'autorizzazione, l'agente SD avrà bisogno di accedere all'hardware di sicurezza e a una catena di attendibilità funzionante.
Middleware
SDV sviluppa un framework per semplificare l'utilizzo di tutti questi diversi protocolli, chiamato middleware. Implementa anche una fonte di riferimento per tutti gli indicatori del veicolo con un nuovo linguaggio VSIDL.
Zona Neutrale
Per isolare parti del sistema e impedire attacchi da una parte meno attendibile del sistema (ad esempio, IVI con app installate personalizzate), la rete potrebbe introdurre zone diverse, incluse zone demilitarizzate. In pratica, ciò significa che le subnet sono separate fisicamente o logicamente e solo il traffico nella lista consentita può superare questi confini.
Gestore connettività
In Android, è prassi comune limitare il numero di applicazioni e servizi che possono aprire connessioni socket autonomamente. Invece, un'istanza centrale è responsabile dell'apertura e della gestione delle connessioni. Poiché Android implementa questa funzionalità in un servizio Java, SDV creerà il proprio gestore della connettività.
Aggiornabilità
Una caratteristica fondamentale degli SDV è l'aggiornabilità. Le nuove funzionalità possono essere installate durante l'intero ciclo di vita dell'SDV tramite aggiornamenti di sistema Android e pacchetti APEX.
Aggiornamenti di sistema Android
Android fornisce già un meccanismo per installare gli aggiornamenti. Utilizza gli aggiornamenti A/B e virtuali A/B nelle versioni recenti e SDV Core sfrutterà questo meccanismo. Gli aggiornamenti A/B creano ogni partizione due volte, il che offre due vantaggi: il sistema può essere aggiornato in background e, se l'aggiornamento non va a buon fine, il sistema può eseguire il rollback all'ultima versione nota per funzionare.
Pacchetti APEX
Oltre a suddividere il sistema in più partizioni e renderle aggiornabili, Android fornisce anche pacchetti APEX, un meccanismo per inserire applicazioni e librerie in piccoli pacchetti che possono essere installati e aggiornati indipendentemente dagli aggiornamenti di sistema.
SDV Core utilizzerà i container APEX per installare i servizi in modo dinamico su un'istanza SDV, ma anche per gestire il deployment di più servizi in un unico processo: per ridurre i rischi per la sicurezza, è possibile eseguire il deployment nello stesso binario solo dei servizi raggruppati nello stesso APEX e che utilizzano lo stesso certificato.
Il meccanismo di Android per l'installazione dei pacchetti APEX sfrutta un po' di codice Java per la gestione degli APK per verificare i pacchetti. SDV Core dovrà implementare un'alternativa nativa per consentire l'installazione dinamica dei pacchetti APEX.
Gestione degli aggiornamenti
Le istanze SDV non sono unità completamente indipendenti nell'auto e richiedono l'orchestrazione con altre istanze SDV e servizi dell'auto. Ad esempio, per installare le dipendenze del servizio o per garantire che gli aggiornamenti vengano installati solo in uno stato di sistema sicuro.
SDV valuta l'utilizzo di partizioni su più VM. Ciò richiede il coordinamento tra queste VM, poiché hanno una dipendenza dai dati l'una dall'altra: deve esserci una VM principale per aggiornare queste partizioni e un meccanismo per notificare alle altre VM la partizione aggiornata e la sincronizzazione per l'aggiornamento di tutte le VM contemporaneamente per garantire che lo stato di funzionamento noto precedente non venga interrotto.
Per iniziare
La nostra guida introduttiva fornisce dettagli sul codice sorgente, sulla creazione e sul lancio con Cuttlefish.