La visualizzazione accurata dell'ora è una funzionalità di base prevista per un sistema di infotainment per auto. Anche se può sembrare ingannevolmente semplice, soprattutto quando le aspettative di gestione dell'ora e del fuso orario sono basse e devono essere soddisfatte, il tempo diventa rapidamente complesso quando è necessario visualizzare una data e un'ora affidabili e accurate senza intervento manuale.
Tutti gli orologi in tempo reale in genere utilizzati nei system on chip (SoC) contengono una deriva che si accumula nel tempo e può portare a errori significativi se non viene corretta. Inoltre, poiché le aspettative di visualizzazione dell'ora locale sono elevate, è necessario considerare la differenza corretta rispetto al tempo coordinato universale (UTC).
Le informazioni sul fuso orario, nonché l'applicazione dell'ora legale, possono cambiare durante la vita utile prevista di un veicolo. Ad esempio, dopo molti anni di implementazione dell'ora legale, il Brasile ha scelto di non avviare una pianificazione dell'ora legale nel 2019.
Android fornisce l'infrastruttura necessaria per gestire le complicazioni della gestione delle regole del fuso orario. Per maggiori dettagli, vedi Regole del fuso orario, che consente agli OEM di inviare dati aggiornati sulle regole del fuso orario ai dispositivi senza richiedere un aggiornamento di sistema. Questo meccanismo consente di:
- Gli utenti ricevono aggiornamenti tempestivi (che prolungano la durata utile di un dispositivo Android).
- I produttori OEM possono testare gli aggiornamenti del fuso orario indipendentemente dagli aggiornamenti dell'immagine di sistema.
Nota: AAOS 10 non supporta il meccanismo di aggiornamento dei moduli basato su APEX fornito nelle versioni di Android 10 (e successive).
Nota:per implementare questo meccanismo, è necessario riavviare il sistema.
Fonti di informazioni su ora (zona) nelle auto
I dispositivi Android gestiscono l'ora in formato Unix a livello di sistema, applicano l'offset del fuso orario desiderato e poi convertono il valore in ora locale per la visualizzazione agli utenti. L'ID zona dell'utente corrente (spesso denominato ID Olson) viene memorizzato come impostazione. Ad esempio, Europe/London.
Gran parte del meccanismo descritto di seguito riguarda le informazioni sull'ora. Lo scopo di questi standard è fornire agli utenti l'ora corrente, non descrivere le regole del fuso orario applicabile. Per determinare il fuso orario effettivo, il dispositivo deve risalire a fattori quali paese, offset e offset DST prima di impostare l'ID zona.
Il processo può essere impegnativo. Ricostruire la cronologia in base alle informazioni disponibili può essere ambiguo. Ad esempio, la regola del fuso orario America/Denver osserva l'ora legale, ma adotta l'ora legale della montagna (MDT) durante l'estate, mentre America/Phoenix continua a riconoscere l'MDT.
Segnale radio cell
Le informazioni di sistema (SI) sono un aspetto essenziale dell'interfaccia aerea Long-Term Evolution (LTE), che viene trasmessa dalla stazione base (BS) sul canale di controllo della trasmissione (BCCH). 3GPP TS 36.331 specifica SystemInformationBlockType16 (SIB16), che contiene informazioni relative a GPS e UTC (Tempo Coordinato Universale), offset dell'ora locale, nonché informazioni sull'ora legale.
Funzionalità simili sono disponibili in 2G e 3G, dove è possibile trasmettere informazioni sull'identità di rete e sul fuso orario (NITZ) (per maggiori dettagli, vedi 3GPP TS 22.042). Altri standard di radiocomunicazione cellulare hanno funzionalità equivalenti.
Purtroppo, la caratteristica comune della maggior parte degli standard è che l'invio di queste informazioni è facoltativo, pertanto non sono disponibili universalmente su tutte le reti.
| Vantaggi | Svantaggi |
|---|---|
|
|
Network Time Protocol
Il Network Time Protocol (NTP) viene spesso utilizzato per ottenere informazioni sull'ora Unix epoch relativamente precise. Android supporta la sincronizzazione dell'ora di sistema con quella di un server NTP se può essere esposta ai client di RadioManager tramite i metadati RadioTuner.getParameters() generici. NTP aggiorna l'ora di sistema quando non è sincronizzata e un operatore non ha fornito di recente un aggiornamento NITZ. Se l'utente attiva
AUTO_TIME quando NITZ non è disponibile, il sistema controlla immediatamente l'ora
di rete.
| Vantaggi | Svantaggi |
|---|---|
|
Semplicità, supportata da Android. |
|
Sintonizzatore radio
Sebbene l'utilizzo di un sintonizzatore integrato per recuperare le informazioni su ora e fuso orario sia allettante, comporta delle sfide. Numerosi standard di trasmissione radiofonica definiscono le opzioni per esporre le informazioni desiderate. In generale, un sintonizzatore radiofonico fornisce le stesse informazioni di una radio cellulare.
La sezione 8.1 della norma ETSI EN 300 401 V1.4.1 (2006-06) specifica le funzionalità delle informazioni di servizio che forniscono informazioni supplementari sui servizi sia per i programmi audio sia per i dati per i sistemi di trasmissione audio digitale (DAB). La sezione 8.1.3 definisce il formato per ora e data, nonché le informazioni per il paese e l'offset dell'ora locale.
Analogamente, per il Radio Data System (RDS) comunemente implementato nei sintonizzatori FM, la sezione 3.1.5.6 dello standard EN 50067 definisce il formato per l'ora e la data (trasmesse una volta al minuto). Inoltre, il codice paese esteso (ECC) può essere recuperato anche nell'ambito dell'identificazione del programma trasmesso.
HD Radio contiene le opzioni corrispondenti nell'ambito della specifica HD Radio™ Air Interface Design Description Station Information Service Transport nel messaggio di parametri del servizio di informazioni sulla stazione (SIS) (ID messaggio 0111). La sezione 5 indica chiaramente le parole di avvertimento che devono essere prese in considerazione quando si tenta di utilizzare il supporto dell'orologio della trasmissione. Lo stesso vale per gli altri sistemi:
| ... questi dati descrivono la consuetudine locale nella sede dell'emittente, che potrebbe non coincidere con la consuetudine locale nel luogo del destinatario. In prossimità dei confini dei fusi orari, i consumatori possono ricevere una molteplicità di stazioni che forniscono dati diversi. Pertanto, questi dati vengono forniti solo come suggerimenti, la cui interpretazione e utilizzo devono essere effettuati in modo discrezionale, soggetti al controllo del cliente. …" |
Inoltre, almeno per HD Radio, la trasmissione di queste informazioni è facoltativa e non deve essere considerata l'unica fonte di informazioni.
Pro Contro- In genere disponibile in diversi standard radiofonici di trasmissione regionali.
- Non richiede la connettività a internet.
- Android non supporta questa funzionalità predefinita.
- Richiede che il sintonizzatore sia acceso (almeno occasionalmente in background) per rilevare in modo affidabile le informazioni.
-
L'affidabilità dipende dall'emittente.
Suggerimenti per l'implementazione
Android supporta la sincronizzazione dell'ora di sistema con quella di un server NTP se può essere esposto ai client diRadioManager. La soluzione consigliata è sfruttare la funzionalità di estensione del fornitore.
L'implementazione di questa funzionalità deve avvenire nel livello di astrazione hardware (HAL), dopodiché
può essere esposta ai client di RadioManager tramite il metodo
RadioTuner.getParameters() generico.
Affinché la soluzione rimanga solida, il consumatore di questa estensione del fornitore deve determinare che l'HAL supporta la funzionalità (non presupporre la sua esistenza). Le stringhe di parametri per la chiamata
getParameters devono essere organizzate in modo chiaro per un utilizzo univoco tra i fornitori. Ad esempio, utilizzando lo spazio dei nomi della tua organizzazione anteponendo il dominio appropriato, ad esempio com.me.timezoneTuner.currenttimezone.
Data la natura basata sugli eventi delle informazioni, può essere utile utilizzare il
callback RadioTuner.Callback.onParametersUpdated() per ricevere queste informazioni. Se
questa funzionalità deve essere configurabile, progetta un insieme di routine personalizzate in base a
setParameters. Ad esempio:
com.me.timezoneTuner.currenttimezoneEvent.enable
Global Navigation Satellite System
Di per sé, il Global Navigation Satellite System (GNSS) può fornire solo informazioni precise su ora e posizione.
Geolocalizzazione
La soluzione a questo inconveniente è eseguire il geocoding inverso e determinare il paese e il fuso orario eseguendo una ricerca in base alla posizione. Il GNSS è la scelta più ovvia (e di migliore qualità) per le informazioni sulla posizione in un veicolo. L'API Time Zone di Google offre tutto il necessario per eseguire la conversione richiesta. Naturalmente, è necessaria una connessione a internet. Garantire la privacy degli utenti deve essere una priorità assoluta quando implementi una soluzione online. È necessario richiedere l'autorizzazione di un utente ad accettare (o meno) i costi di utilizzo dei dati.
È possibile creare una soluzione adatta all'utilizzo offline. Un database di mappe locale con una risoluzione sufficiente per determinare con precisione il paese e il fuso orario può essere memorizzato nel veicolo. Con questa e una strategia completamente implementata per aggiornare le informazioni sul fuso orario (e sul paese) in base alle necessità, è possibile eseguire il geocoding inverso del paese/fuso orario in base alla posizione GNSS ottenuta dal sottosistema di localizzazione.
| Vantaggi | Svantaggi |
|---|---|
|
|
Smartphone connesso tramite Bluetooth, Wi-Fi o USB
Per ottenere i dati relativi all'ora e al fuso orario, è possibile utilizzare diverse tecnologie. Per tutti gli smartphone, una coppia di app personalizzate e app complementari deve essere installata sullo smartphone e sul sistema di infotainment del veicolo (IVI). È quindi possibile sincronizzare l'ora all'intervallo desiderato. Ad esempio, al momento della connessione e quando lo smartphone rileva una nuova nel fuso orario.
Alcuni smartphone che supportano Bluetooth Low Energy (BLE) offrono la possibilità di recuperare l'ora tramite la caratteristica GATT Current Time e la specifica del profilo Current Time Service 1.1. Tuttavia, questa opzione non si rivolge a un segmento di mercato sufficientemente ampio da poter essere utilizzata in modo esclusivo.
| Vantaggi | Svantaggi |
|---|---|
|
|
Utilizzare le fonti
Ogni fornitore di dispositivi deve determinare il livello di qualità da impostare e quali percorsi utente considerare più critici. Solo con una chiara comprensione delle esperienze utente critiche desiderate è possibile prendere la decisione migliore. Nella maggior parte dei casi, i fornitori devono valutare i compromessi tra praticità e complessità di implementazione.
Ciascuna opzione descritta sopra presenta vantaggi e svantaggi. Ad esempio, una scelta di progettazione critica deve essere fatta in merito a quanta resilienza, rispetto alla visualizzazione occasionale di un orario errato, è accettabile e come gestire gli svantaggi. Una soluzione completamente automatica che dovrebbe funzionare bene in tutti gli scenari, ma deve basarsi su una combinazione di diverse fonti di informazioni. Nessuna singola opzione può garantire una disponibilità del 100%.
Un'opzione di configurazione manuale come fallback temporaneo è facile da eseguire e, in pratica, può essere sufficiente per molti utenti.