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.
AAOS SDV 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 for 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 maggiore lavoro di integrazione rispetto ad altre versioni di Android.
SDV Core è progettato per un sistema distribuito locale, ad esempio presuppone che più istanze di SDV Core (o derivati) vengano eseguite 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 una qualsiasi delle istanze.
SDV Core è il set minimo di funzionalità per sviluppare funzionalità in auto. Un servizio tipico riceverebbe alcuni segnali, li elaborerebbe e condividerebbe 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 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 il più 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 del servizio.
Le sezioni seguenti tratteranno in dettaglio i componenti del sistema.
Ambiente host e virtualizzazione
SDV Core è sviluppato presupponendo che verrà eseguito in un ambiente virtuale e, pertanto, facciamo alcune ipotesi sull'ambiente host host:
L'ambiente host esegue un hypervisor che supporta i dispositivi Virtio. Inoltre, l'hypervisor deve implementare Ethernet o vsock, gli stati di alimentazione e i dispositivi di blocco. 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 avere una GPU, un'IPU, un CSI, motori multimediali, un display o altri bus di comunicazione per il settore automobilistico (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 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
Utenti SDV Core kernel GKI di Android con kernel Android 6.1. Il vantaggio dell'utilizzo di GKI è che le modifiche upstream alla fine vengono implementate in Android. Inoltre, Android utilizza un unico kernel per l'intera flotta. Ad esempio, le patch vengono applicate centralmente anziché a più kernel del fornitore.
In questo modo, SDV dispone anche di un'interfaccia del kernel stabile. Ad esempio, puoi compilare i driver come moduli che funzionano con GKI anche quando viene implementato un nuovo kernel con correzioni di sicurezza.
Il kernel GKI ha una cronologia fissa, le modifiche del fornitore che devono far parte del kernel GKI successivo devono essere caricate nel kernel Linux fino alla fine dell'anno.
Con GKI, i driver del dispositivo e i moduli non richiesti per l'avvio verranno compilati come moduli kernel e saranno contenuti in un ramdisk caricato durante la fase iniziale di avvio.Le configurazioni del dispositivo molto anticipate che non possono attendere l'interfaccia del modulo kernel (ad es. l'inizializzazione casuale) devono essere eseguite nel Device Tree. Non è necessario eseguire l'upstream dei moduli del kernel, ma devono essere compilati in base alle interfacce GKI.
Poiché SDV Core presuppone di essere basato su un hypervisor compatibile con Virtio, i driver vengono forniti come moduli del kernel Virtio se la funzionalità è supportata o come un altro standard aperto (ad esempio, Open Profile for DICE e il driver del kernel open-dice per la fiducia).
Questa combinazione di Virtio (e standard aperti) e un hypervisor porta all'astrazione dell'hardware. Pertanto, la necessità di HAL in SDV è minima, ma alcune sono ancora necessarie a causa della mancanza di supporto 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 comunicazione e networking di base per SDV.
Per il networking, SDV Core presuppone che vsock o Ethernet siano disponibili per comunicare tra le VM. La comunicazione interna alla VM può utilizzare anche meccanismi IPC come Binder.
SDV supporta la comunicazione seriale solo a scopo 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 IPC (comunicazione tra processi), ma non viene offerta come canale normale per comunicare tra più VM. L'host può utilizzare la memoria condivisa per condividere informazioni con il guest, ma non è prevista per il traffico di rete ad alta frequenza.
Ethernet
Ethernet verrà utilizzato per la comunicazione tra più SoC, ad esempio per la comunicazione all'interno del veicolo. Possono essere sistemi virtualizzati, ma anche sistemi nativi o centraline elettroniche 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, devono essere supportati IPv4 e IPv6.
VLAN
La VLAN è un meccanismo per creare architetture di rete virtuali che consentono di isolare diverse sottoreti e formare reti locali. Può essere utilizzato per creare diverse zone di sicurezza e viene utilizzato a questo scopo all'interno delle auto. È richiesto il supporto della 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, TCP e UDP saranno supportati.
Data Tunnel
Data Tunnel è un meccanismo di comunicazione di nuova concezione per SDV che offre un canale di comunicazione veloce secondo il modello pub/sub, ad esempio un'applicazione pubblica un argomento mentre una o più applicazioni possono ascoltarlo. Internamente, utilizza la memoria condivisa e le FMQ (fast message queues) all'interno della VM oppure vsock o Ethernet per comunicare tra le VM.
RPC (SDV)
SDV RPC implementa chiamate di procedure remote per SDV utilizzando 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 oppure 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 qualsiasi dei metodi menzionati in precedenza. Per l'autenticazione e l'autorizzazione, l'agente SD dovrà 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 i segnali del veicolo con un nuovo linguaggio VSIDL.
Zona neutra
Per isolare parti del sistema per impedire attacchi da una parte meno attendibile del sistema (ad esempio, IVI con app personalizzate installate), la rete può introdurre zone diverse, incluse una o più zone demilitarizzate. In pratica, ciò significa che le subnet sono separate fisicamente o logicamente e solo il traffico consentito può superare questi confini.
Gestore connettività
In Android, è prassi comune limitare il numero di applicazioni e servizi che possono aprire autonomamente connessioni socket. Al contrario, un'istanza centrale è responsabile dell'apertura e della gestione delle connessioni. Poiché Android implementa questa funzionalità in un servizio Java, SDV creerà un proprio gestore della connettività.
Aggiornabilità
Una delle funzionalità principali del veicolo definito dal software è la possibilità di aggiornamento. Le nuove funzionalità possono essere installate durante il ciclo di vita del veicolo definito dal software tramite aggiornamenti del sistema Android e pacchetti APEX.
Aggiornamenti di sistema Android
Android fornisce già un meccanismo per installare gli aggiornamenti. Utilizza gli aggiornamenti A/B e A/B virtuali 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 dividere il sistema in più partizioni e a 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 dinamicamente i servizi su un'istanza SDV, ma anche per gestire il deployment di più servizi in un unico processo: solo i servizi raggruppati nello stesso APEX e che utilizzano lo stesso certificato possono essere implementati nello stesso binario per ridurre i rischi per la sicurezza.
Il meccanismo di Android per installare i pacchetti APEX utilizza 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 auto. Ad esempio, per installare le dipendenze del servizio o per assicurarsi che gli aggiornamenti vengano installati solo in uno stato sicuro del sistema.
SDV prende in considerazione l'utilizzo di partizioni su più VM. Ciò richiede il coordinamento tra queste VM, poiché hanno una dipendenza reciproca dai dati: deve esistere una VM primaria per aggiornare queste partizioni e un meccanismo per notificare alle altre VM la partizione aggiornata e la sincronizzazione per aggiornare tutte le VM contemporaneamente per garantire che lo stato di funzionamento precedente noto non venga interrotto.
Per iniziare
La nostra guida introduttiva fornisce dettagli su codice sorgente, creazione e lancio con Cuttlefish.