Sincronizzazione dell'ora

La piattaforma Software Defined Vehicle (SDV) di AAOS definisce meccanismi standard per la generazione di report sull'origine dell'ora dalle unità di controllo elettronico (ECU) e superfici standard per l'esposizione delle informazioni sull'ora nelle istanze SDV. Questa pagina fornisce dettagli e indicazioni per lo standard SDV.

Architettura dell'orologio

La piattaforma SDV ha due orologi standard:

  • Orologio UTC:questo è l'orologio standard del tempo universale coordinato. SOME/IP di solito lo fornisce dalle ECU al runtime della piattaforma. I casi d'uso includono l'aggiornamento dei certificati, la diagnostica e V2X.

  • Orologio monotono di rete:si tratta di un segnale di orologio non decrescente e molto preciso fornito dalle ECU che l'architettura del veicolo più ampia utilizza per garantire il coordinamento degli eventi. Le ECU forniscono queste informazioni alla piattaforma SDV tramite gPTP. Questo orologio è noto anche come steady clock.

Gli orologi nella piattaforma SDV hanno requisiti architetturali specifici:

  • Distribuzione dell'orologio: ogni istanza VM ha accesso allo stesso segnale di orologio monotono fornito dalle ECU.

  • Integrità dell'orologio:l'input dell'orologio monotono di rete dovrebbe essere una fonte affidabile per coordinare gli eventi tra i servizi. La difesa contro possibili vulnerabilità del sistema, come attacchi di tipo replay o inversione temporale, si basa sull'integrità dell'orologio monotono.

  • Utilizzo della sveglia:le API dell'orologio della piattaforma SDV non devono essere utilizzate per eventi con occorrenza ad alta frequenza (> 100 Hz) o latenza < 10 ms tra la pianificazione e l'ora dell'evento. Le API ad alta frequenza o bassa latenza devono utilizzare un driver del kernel.

API Clock

L'orologio monotono di rete è esposto tramite l'API standard clock_gettime(3):

// Network monotonic clock uses standard Linux API.
// This is represented as a dynamic clock in clock_gettime(3)
clock_gettime(clockid_t id, &timespec)

Questo orologio viene fornito tramite un meccanismo di rete PTP a tutte le VM ed è registrato come orologio dinamico per scopi di clock_gettime(3).

L'orologio UTC è rappresentato da CLOCK_REALTIME in clock_gettime(3).

Driver del dispositivo opzionale

Gli OEM hanno la possibilità di esporre un blocco del dispositivo Linux per proprietà di tempo aggiuntive. Esporre questo problema con la gestione delle autorizzazioni tramite sepolicy:

# in device/OEM/target/sepolicy/time/file_contexts
/dev/sdvtime u:object_r:time_device:s0

Gli OEM sono responsabili dello sviluppo e delle funzionalità del driver del dispositivo Linux personalizzato che espone le API al blocco del dispositivo.

Notifiche e callback

Le notifiche e i callback per i componenti temporali in SDV sono funzionalità userland fornite dall'OEM. La piattaforma SDV non fornisce API specifiche per queste funzioni.

Deve essere presente un solo servizio OEM per ogni VM che richiede la funzionalità di sincronizzazione dell'ora che gestisce tutte le modifiche dell'ora pertinenti da monitorare. Ad esempio, quando lo stato attendibile cambia per l'origine ora corrente:

  • Le modifiche agli stati dell'origine ora sono previste come eventi a bassa frequenza, pertanto un servizio OEM può controllare le modifiche tramite polling, ad esempio una volta al minuto.

  • Le ECU comunicano lo stato di attendibilità dell'orologio UTC tramite la rete, ad esempio tramite SOME/IP.

  • Un servizio OEM pubblica argomenti Data Tunnel specifici per mostrare queste modifiche agli abbonati.

  • Gli OEM personalizzano la policy di autorizzazione per i servizi per determinare a quali è consentito iscriversi a questi argomenti di Data Tunnel per ascoltare le modifiche attendibili dello stato temporale.

Stato e gestione degli errori

I codici di errore seguono le convenzioni delle API Linux standard coinvolte, ad esempio:

  • Se clock_gettime() non va a buon fine, viene restituito -1 e viene impostato errno; ciò implica che l'operazione di clock non è supportata o che l'origine di clock sottostante non è pronta.

  • Se fopen() non va a buon fine, viene restituito un puntatore nullo e viene impostato errno; ciò implica che il dispositivo a blocchi non è disponibile.

  • Se una chiamata ioctl() non va a buon fine, viene restituito -1 e viene impostato errno. Ciò implica che il codice di richiesta specificato non ha una risposta corrispondente dal driver sottostante.