Display Safety prende di mira i controller del dominio del cockpit e consente ad Android di alimentare tutti i display dell'auto, inclusi quelli con requisiti di sicurezza e disponibilità.
Figura 1. Panoramica del cluster.
Informazioni correlate
Per saperne di più su GitHub, consulta Automotive Design for Compose.
Terminologia
- platform
- Una combinazione di hardware, hypervisor, sistema operativo e librerie correlate.
- safety monitor
- Un'app per monitorare lo stato del veicolo e verificare che le rispettive informazioni visive vengano visualizzate come previsto per l'utente.
Visualizzare i componenti di sicurezza
Il software Display Safety è composto da tre componenti principali:
DriverUI:un'app di sistema Android che esegue il rendering di un intero quadro strumenti, esclusi gli elementi di sicurezza o normativi di cui esegue il rendering HAR.
Renderer ad alta affidabilità (HAR): un processo di gestione della qualità che esegue il rendering degli elementi di visualizzazione che devono essere presenti rapidamente dopo un avvio a freddo e degli elementi segnaposto quando Android non è disponibile. HAR è portatile e si concentra sulle informazioni di guida critiche.
Toolchain di progettazione della sicurezza:un insieme di strumenti per generare configurazioni per implementazioni di monitor di sicurezza dalla fonte di progettazione, per raggiungere gli obiettivi di sicurezza ASIL-B pertinenti.
Tutti i componenti utilizzano la toolchain di progettazione Automotive Design for Compose per verificare che siano creati dalla stessa definizione di progettazione OEM.
Figura 2. Visualizza i componenti di sicurezza.
Renderer ad alta affidabilità
Il file HAR è scritto in Rust ed è costituito dai seguenti componenti:
Livello di astrazione della piattaforma (PAL). Astrazione per interfacciarsi con più sottosistemi, tra cui grafica, videocamera, audio, input dell'utente (ad esempio comandi del volante), dati del veicolo (chiamati anche segnali o proprietà), configurazione del veicolo (ad esempio, a benzina o elettrico, con guida a sinistra o a destra) e preferenze dell'utente (ad esempio, km/h e mph).
Implementazione del PAL per la piattaforma di destinazione.
App HAR, sviluppata con PAL.
Google definisce la PAL e fornisce implementazioni di riferimento della PAL e dell'app HAR. L'app HAR di riferimento fornisce tutti i blocchi costitutivi e include un ciclo principale di riferimento. Gli OEM devono personalizzare l'implementazione di PAL e l'app HAR in base ai propri requisiti. HAR utilizza Impeller per il rendering.
Per saperne di più, vedi:
- Livello di astrazione della piattaforma HAR
- Pipeline grafica HAR
- Audio HAR e suoni
- Inquadratura della videocamera HAR
DriverUI
L'interfaccia utente del cluster si trova in genere dietro il volante in un display separato. Gli OEM combinano gradualmente il cluster e l'IVI. Questa UI combinata è la DriverUI.
DriverUI è un'app di sistema Android che esegue il rendering di un intero display del quadro strumenti, esclusi gli elementi di sicurezza o normativi eseguiti da HAR. La DriverUI mostra informazioni relative alla riproduzione di contenuti multimediali, alle chiamate telefoniche, alle mappe, alla navigazione e ad altre cose e viene implementata utilizzando Automotive Design per Compose.
AAOS dispone di due API per la creazione di quadri strumenti. L'API Instrument Clusters (chiamata anche Cluster 1) è in modalità di manutenzione e i produttori OEM sono invitati a eseguire la migrazione all'API ClusterHomeManager (chiamata anche Cluster 2).
Google fornisce implementazioni di riferimento delle API Cluster 1 e Cluster 2.
Per saperne di più, consulta DriverUI.
Unire l'output di HAR e DriverUI
L'HAR e la DriverUI utilizzano display separati per il rendering di un'interfaccia utente. Entrambe le uscite vengono composte e visualizzate come un'unica immagine nell'interfaccia utente del conducente.
Per ottenere questo risultato, HAR controlla la trasparenza delle aree in cui viene visualizzato l'output di Android in base alla ricezione di messaggi heartbeat periodici da DriverUI per indicare che è in esecuzione.
Quando DriverUI non è in esecuzione, HAR rileva la mancanza di battiti cardiaci e rende opache le aree di DriverUI e visualizza i segnaposto. Quando vengono ricevuti i battiti, HAR rimuove i segnaposto e imposta le aree DriverUI su trasparente.
DriverUI e HAR comunicano tra loro tramite chiamate di procedura remota (RPC). Il messaggio heartbeat è un esempio di dati inviati tramite il canale RPC e consiste in un timestamp come uno dei suoi campi.
gRPC viene utilizzato per le RPC. Su SDV, lo stack di comunicazione SDV fornisce al client gateway SDV la possibilità di scoprire e stabilire un canale dalla DriverUI all'HAR.
Figura 3. Composizione di HAR e DriverUI.
Toolchain di progettazione della sicurezza
La toolchain di progettazione della sicurezza è una serie di strumenti che un OEM può utilizzare in sequenza per fornire una soluzione di monitoraggio della sicurezza generata da un documento di progettazione Figma.
Il compilatore di progettazione di sicurezza produce artefatti di sicurezza per guidare la successiva generazione di codice per la creazione di un monitor di sicurezza. Questa separazione tra la compilazione del progetto e la generazione di codice consente al generatore di codice utilizzato di ottenere una classificazione ISO-26262 TCL-3.
Figura 4. Utilizza la toolchain di progettazione della sicurezza.
Una volta generati gli artefatti del compilatore, la toolchain può generare un report leggibile. Questo report è un file che un ingegnere della sicurezza OEM può ispezionare per convalidare gli artefatti generati dal progetto Figma.
Google fornisce un'implementazione di riferimento del monitor di sicurezza che non è certificata ASIL. Gli OEM devono personalizzare il monitor di sicurezza in base ai propri requisiti e ottenere la certificazione della propria implementazione.
Per scoprire di più, consulta Toolchain di progettazione della sicurezza.
Visualizzare la sicurezza su SDV
Puoi creare ed eseguire Display Safety su SDV. SDV è completo di funzionalità e utilizza due VM guest per eseguire un cluster Display Safety completo.
Veicolo software-defined
Software Defined Vehicle (SDV) Android Automotive OS (AAOS):
- Richiede due VM guest per mostrare l'intero cluster.
- Esegue HAR in SDV Media (nota anche come VM di avvio rapido) in una VM guest.
- Esegue DriverUI in una VM guest separata che esegue la VM SDV-IVI.