Architettura del driver GNSS (Global Navigation Satellite System)

2023-03-22

Offre una panoramica dell'architettura del driver UMDF 2.0 global Navigation Satellite System (GNSS) e illustra diversi tipi di sessioni di rilevamento e correzione.

Panoramica dell'architettura

Il diagramma a blocchi di componenti di alto livello seguente illustra come il driver UMDF (Global Navigation Satellite System) (GNSS) UMDF 2.0 si integra con la piattaforma Windows 10.

diagramma che mostra l'architettura gnss in modalità utente.

I componenti del diagramma sono descritti di seguito:

Applicazione LBS: Applicazione utente che usa la funzionalità di posizione della piattaforma Windows 10
Applicazione di test: Applicazione per il test della funzionalità GNSS.
API GNSS: Interfaccia IGnssAdapter COM (Component Object Model) che espone la funzionalità del dispositivo GNSS ai componenti interni del servizio di posizione, nonché per testare le applicazioni. La forma esatta di questa API non rientra nell'ambito di questo documento. I componenti di Windows usano il dispositivo GNSS programmando l'interfaccia COM IGnsssAdapter . Il set di API GNSS è l'API privata solo per i componenti della piattaforma di posizione (ad esempio, il servizio di posizione e le applicazioni di test della posizione) e non è disponibile per altre applicazioni di terze parti o di terze parti.
Adattatore GNSS: Si tratta di un oggetto COM singleton che implementa l'interfaccia COM IGnsssAdapter . Testare applicazioni e componenti interni del servizio location crea un'istanza di questo oggetto e usa il dispositivo GNSS tramite l'interfaccia IGnssAdapter . Il componente del motore di posizionamento GNSS del servizio posizione implementa la classe COM che espone l'interfaccia IGnssAdapter . Il servizio location espone un meccanismo factory per testare e altre applicazioni out-of-process per creare un'istanza di un oggetto COM singleton della classe COM dell'adapter GNSS all'interno del servizio posizione. Le applicazioni out-of-process usano il puntatore dell'interfaccia COM per programmare con il driver GNSS.

COM gestisce il puntatore dell'interfaccia alle applicazioni out-of-process in modo che le applicazioni trattino il puntatore dell'interfaccia IGnssAdapter come oggetto COM in-process, ma le chiamate vengono effettivamente gestite dall'oggetto adapter GNSS singleton all'interno del servizio posizione.

Il motore di posizionamento GNSS usa l'oggetto adattatore GNSS interno per fornire funzionalità specifiche della posizione al servizio posizione. L'adapter GNSS apre un handle di file al driver GNSS usando l'API CreateFile , quindi esegue il wrapping delle chiamate native GNSS nelle chiamate DeviceIoControl appropriate, gestisce il computer di stato con l'oggetto driver GNSS e mantiene lo stato delle varie richieste in ingresso dai livelli superiori. Questo componente interagisce direttamente con lo stack di dispositivi GNSS sottostante tramite l'interfaccia IOCTL GNSS pubblica definita in questo documento. Il dispositivo GNSS viene considerato logicamente come risorsa esclusiva e quindi la scheda GNSS singleton controlla tutti l'accesso al dispositivo GNSS.

Alcune applicazioni di test dei driver di tipo white box possono usare anche l'interfaccia IOCTL del driver GNSS direttamente in un ambiente non di produzione anziché usare l'adattatore GNSS tramite le API private GNSS. Tuttavia, queste applicazioni di test dovranno implementare il proprio computer di stato ed elaborazione per simulare determinate funzionalità dell'adattatore GNSS.
Driver GNSS: Un driver fornito da IHV implementato usando UMDF 2.0. Il driver GNSS supporta le API DeviceIoControl GNSS interfacciandosi con l'hardware GNSS effettivo. Il driver GNSS funziona anche come mediatore/integratore per le funzioni SUPL.
Dispositivo/motore GNSS: Si tratta di un componente concettuale che incapsula le parti soC e hardware del dispositivo GNSS. Un IHV può scegliere di implementare la maggior parte delle funzionalità GNSS all'interno di questo componente, rendendo così il livello di driver GNSS molto sottile (essenzialmente un adattatore per l'interfaccia con il dispositivo GNSS).

La piattaforma di posizione in Windows 10 supporta i dispositivi GNSS integrati tramite il driver di classe Sensor v1.0 legacy (vedere Scrittura di un driver del sensore di posizione) o integrato tramite il nuovo DDI GNSS descritto nel riferimento al driver GNSS.

Pertanto, i dispositivi Windows con un dispositivo GNSS che si integrano con il modello di estensione della classe Sensor v1.0 esistente in Windows 7, Windows 8 e Windows 8.1 devono continuare a funzionare in Windows 10 senza la necessità di modifiche. È consigliabile che questi driver (e tutti i nuovi driver) vengano pubblicati in Windows Update per migliorare il processo di aggiornamento per gli utenti.

Ci saranno anche due diversi set di test per i dispositivi GNSS in Hardware Lab Kit (HLK) rilasciati con Windows 10:

Un nuovo set di test per certificare i driver che seguono il nuovo modello.
Un altro set di test per certificare i driver che seguono il modello precedente. Questi saranno gli stessi set di test disponibili in WHCK in Windows 8.1.

Un nuovo componente di raccolta in HLK identifica quale dei due set di test deve essere eseguito in un sistema, se presente.

diagramma che mostra gnss 2.0 driver e comunicazione adattatore.

Nel raro caso di più dispositivi GNSS rilevati in un sistema, la piattaforma di posizione userà solo un dispositivo, principalmente per ridurre il consumo di energia complessivo nel sistema. Sono stati considerati i presupposti seguenti:

I dispositivi che usano il nuovo DDI sono probabilmente più recenti e quindi più probabilmente avranno un consumo di energia migliore, supportano più costellazioni e supportano assistenza migliore. Pertanto, se viene rilevato un dispositivo che usa il modello di driver precedente e un dispositivo che usa il nuovo modello di driver, quest'ultimo sarà quello selezionato.
Se un utente collega un dispositivo GNSS esterno quando è presente un dispositivo GNSS interno, è più probabile che l'utente voglia usare questo dispositivo esterno.

Il comportamento della piattaforma di posizione, in base a questi presupposti sarà il seguente:

Caso di due driver legacy esistenti: per evitare problemi di compatibilità indietro il comportamento sarà lo stesso di in Windows 8.1, in cui entrambi i dispositivi GNSS vengono usati simultaneamente e una delle risposte viene comunicata allo stack alle applicazioni.
Caso di un driver legacy nel dispositivo e un nuovo driver collegato esternamente: viene usato il dispositivo GNSS collegato esternamente.
Caso di un nuovo driver nel dispositivo e un nuovo driver collegato esternamente: viene usato il dispositivo GNSS collegato esternamente.

Se il dispositivo GNSS selezionato supporta il geofencing o altre operazioni offload, l'offload verrà eseguito durante l'uso del dispositivo. L'adattatore GNSS non dividerà le funzionalità o le sessioni tra più dispositivi GNSS.

L'interazione tra l'adapter GNSS e il driver GNSS rientrano nelle categorie seguenti:

Scambio di informazioni sulle funzionalità

Per supportare l'estendibilità e l'adattabilità dello stack GNSS nelle piattaforme Windows, l'adapter GNSS e il driver GNSS stabiliscono una conoscenza comune delle varie funzionalità ben definite dello stack GNSS sottostante, nonché del supporto fornito dalla piattaforma Windows. Gli aspetti delle funzionalità sono ben definiti da Microsoft come parte di questa definizione di interfaccia GNSS e si evolveranno come più innovazione nello spazio GNSS continua e un set diversificato di chipset/driver emerge nel mercato. L'adattatore GNSS esegue una query sulle varie funzionalità del driver/dispositivo GNSS sottostante al momento dell'inizializzazione o in base alle esigenze e ottimizza di conseguenza l'interazione con il driver GNSS.

Le informazioni sulla funzionalità scambiano tra l'adattatore GNSS e il driver GNSS usano i codici di controllo IOCTL_GNSS_SEND_PLATFORM_CAPABILITY e IOCTL_GNSS_GET_DEVICE_CAPABILITY.

L'adapter GNSS può eseguire una configurazione o una riconfigurazione periodica del driver GNSS. Analogamente, l'adapter GNSS può eseguire determinati comandi specifici di GNSS tramite il driver. Questa operazione viene eseguita definendo un protocollo di esecuzione dei comandi tra il driver e il sistema operativo di alto livello (HLOS). A seconda del tipo di comando specifico, l'azione prevista può essere eseguita immediatamente o dopo il riavvio del sistema. Analogamente alle informazioni sulla funzionalità dei dispositivi GNSS, i comandi GNSS sono ben definiti da Microsoft come parte di questa definizione di interfaccia GNSS e continueranno a evolversi con innovazioni future e diversificazione dei dispositivi/driver GNSS.

L'esecuzione e la configurazione dei comandi del dispositivo viene eseguita usando il codice di controllo IOCTL_GNSS_SEND_DRIVERCOMMAND.

Informazioni sulla posizione

Si tratta della funzione primaria del dispositivo GNSS sottostante. Nella forma più semplice, l'adattatore GNSS richiede la posizione corrente del dispositivo dal driver GNSS. Le varianti della richiesta di posizione includono (ma non sono limitate a) i tipi di sessione di posizione seguenti:

Posizione corrente del dispositivo (correzione a colpo singolo)
Flusso periodico continuo di correzioni (rilevamento basato sul tempo)
Flusso continuo di correzioni in base alla soglia di spostamento (rilevamento basato sulla distanza)

L'unico tipo di sessione di posizione obbligatoria richiesto da ogni hardware GNSS e driver GNSS è il tipo di sessione di correzione di colpo singolo. Nativo (implementato nel soC, nel dispositivo GNSS e non nel driver GNSS o in un servizio in esecuzione nel processore dell'applicazione), è possibile supportare le sessioni di rilevamento basate sul tempo e le sessioni di rilevamento basate su distanza facoltativamente. Il vantaggio principale per questi due tipi di sessioni di rilevamento nativo è un potenziale risparmio di energia mantenendo inattivo il processore di applicazioni (AP) per tempi più lunghi eseguendo più tempo l'elaborazione nel SOC e segnalando solo le modifiche quando necessario. Il supporto per il rilevamento basato sulla distanza nativa è più significativo rispetto alle sessioni di rilevamento in tempo nativo perché può offrire un risparmio di energia più elevato e perché è più ampiamente usato dalle applicazioni.

L'atto di recuperare le informazioni sulla posizione dal driver GNSS avviene tramite una sessione di correzione univoca con stato, costituita dalle azioni seguenti:

Avviare la sessione di correzione: L'adattatore GNSS avvia una sessione di correzione iniziale (come risultato di una richiesta da un'applicazione LBS). L'adattatore GNSS imposta i requisiti e le preferenze specifici associati alla richiesta e intima il driver GNSS per avviare il motore per ottenere la correzione emettendo il codice di controllo IOCTL_GNSS_START_FIXSESSION.
Ottenere la posizione del dispositivo (correzione dei dati): Dopo l'avvio di una sessione di correzione, l'adattatore GNSS rilascia il codice di controllo IOCTL_GNSS_GET_FIXDATA per iniziare ad attendere una correzione dal driver. Quando sono disponibili nuove informazioni sulla posizione dal motore, il driver GNSS risponde a questa richiesta di correzione in sospeso.

Se il tipo di sessione di correzione è LKG (anziché correzione corrente), le informazioni sulla posizione provengono dalla cache del driver.

L'adattatore GNSS assicura che una richiesta di I/O asincrona sia sempre disponibile per il driver GNSS per restituire i dati di correzione quando disponibili. A seconda della natura della correzione, se sono previsti altri dati di correzione, l'adattatore GNSS rilascia un'altra richiesta di I/O (usando la stessa IOCTL) e questa sequenza continua fino a quando non saranno disponibili altri dati o la sessione di correzione viene arrestata.
Modificare la sessione di correzione: Se il driver GNSS non supporta il multiplexing delle sessioni di correzione dello stesso tipo, l'adattatore GNSS può generare un IOCTL_GNSS_MODIFY_FIXSESSION per tale tipo di sessione di correzione quando esegue il multiplexing a livello.
Arrestare la sessione di correzione: L'adapter GNSS genera una sessione di arresto quando non sono necessarie ulteriori informazioni sulla posizione relative a una sessione di correzione specifica o previsto.

Supporto di geofencing nativo

GNSS DDI supporta scenari di offload di geofence usando un set di IOCTLs definiti in questa specifica. Un flag di funzionalità speciale è definito per il driver per indicare questo supporto, questo flag deve essere impostato solo se lo stack GNSS supporta il geofencing in modo nativo, ovvero implementa il geofencing nel chip GNSS anziché nel processore dell'applicazione. Se il driver non supporta in modo nativo il geofence, il flag non deve essere impostato. HLOS supporta già un motore di rilevamento di geofence basato su AP (suboptimal application processor); anche se questa soluzione non è ottimizzata come una soluzione nativa, è ben testata e ottimizzata, pertanto non dovrebbe essere sostituita da una soluzione equivalente implementata nell'API.

Geofence tracking by the HLOS richiede al processore dell'applicazione di riattivare periodicamente per rilevare violazioni del geofence, riducendo così la potenza anche quando le barriere non vengono violato. Pertanto, questa implementazione viene considerata non ottimale.

HLOS usa anche il rilevamento geofence basato su API come meccanismo di failover quando il driver sottostante non è in grado di tenere traccia dei geofences a causa di condizioni di segnale basso o di altri errori temporanei, quando le notifiche di errore ricevute dalla soluzione di rilevamento geofence nativo. Il supporto di geofencing nativo è utile solo quando il rilevamento geofence è completamente disattivato nel SoC e il processore di applicazioni viene svegliato solo per l'elaborazione di eventi correlati al geofence. Se l'hardware non supporta il rilevamento di geofence nativo, il driver GNSS non deve tentare di implementarlo a livello di driver.

Il motore GNSS deve anche esporre parametri di ottimizzazione specifici dell'IHV documentati per consentire di trovare il giusto equilibrio tra consumo di energia e esperienza utente. Inoltre, il numero di geofences supportati deve essere maggiore del valore MIN_GEOFENCES_REQUIRED definito nel file di intestazione. Si noti che il MIN_GEOFENCES_REQUIRED è definito per applicazione, poiché un'applicazione non conosce il numero di recinti virtuali usati da altre applicazioni o dall'operatore di telefonia mobile.

Il supporto dell'offload di geofencing prevede i requisiti seguenti:

HLOS sarà in grado di creare uno o più recinti virtuali tramite DDI e il driver li invia all'hardware per iniziare a monitorarli.
HLOS sarà in grado di eliminare uno o più recinti virtuali creati in precedenza tramite DDI e il driver li invia all'hardware per interrompere il rilevamento.
Idealmente, l'hardware GNSS deve comprendere lo stato iniziale di rilevamento del recinto virtuale per ogni recinto virtuale e usarlo per segnalare solo le modifiche da questo stato iniziale. Se l'hardware GNSS non supporta questa funzionalità, segnala lo stato iniziale a HLOS ogni volta che viene creato un recinto virtuale.
L'hardware GNSS tiene traccia della posizione corrente del dispositivo in modo efficiente dal punto di vista energetico e riattiva l'API ogni volta che il dispositivo è entrato e/o ha chiuso un recinto virtuale rilevato. Il driver GNSS passa gli avvisi del recinto virtuale a HLOS.
In condizioni di segnale satellite basso e altre condizioni di errore temporanee, il motore GNSS potrebbe non essere in grado di tenere traccia in modo affidabile dei recinti virtuali esistenti. Il motore GNSS sarà in grado di rilevare le interruzioni di rilevamento e il driver GNSS passerà l'avviso di errore di stato di rilevamento al modulo HLOS. HLOS passa al rilevamento predefinito del recinto virtuale basato su API fino a quando l'hardware GNSS non è in grado di ripristinare e tenere traccia dei recinti virtuali.
Le condizioni esatte in cui un motore GNSS deve fornire una notifica per indicare che non è possibile tenere traccia dei recinti virtuali variano e l'implementazione sarà specifica dell'IHV. Di seguito sono riportate alcune linee guida per l'implementazione:
- Se il motore GNSS è in grado di rilevare con alta sicurezza che l'utente non si sposta e non esiste un limite di recinto virtuale in 25 metri o meno, il motore GNSS non deve inviare un errore di rilevamento.
- Se il motore GNSS è in grado di rilevare con maggiore sicurezza che l'utente non si sposta ma è presente un limite di recinto virtuale in 25 metri o meno, il motore GNSS deve inviare un errore di rilevamento entro un minuto.
- Se il motore GNSS rileva che l'utente sta spostando ed è presente un limite di recinto virtuale entro 100 metri, il motore GNSS deve inviare un errore di rilevamento entro un minuto o meno.
- Se il motore GNSS non è in grado di determinare se l'utente sta spostando e c'è un limite di recinto virtuale entro 100 metri o meno, il motore GNSS deve inviare un errore di rilevamento entro un minuto o meno.
- Se il motore GNSS rileva che l'utente sta spostando, il motore GNSS deve inviare un errore di rilevamento in un tempo proporzionale alla velocità stimata di movimento e alla distanza al recinto virtuale più vicino. È consigliabile inviare un errore all'interno di [(Distance-to-closest-fence-boundary(m) /estimated speed (m/s)) - 15s]. Il motore GNSS può usare indicatori di rilevamento dello spostamento per determinare l'intervallo in cui deve essere inviato l'errore di rilevamento.
- Se il motore GNSS non è in grado di determinare se l'utente sta spostando, il motore GNSS deve inviare un errore di rilevamento in un tempo proporzionale alla velocità elevata di movimento e alla distanza del recinto virtuale più vicino. È consigliabile inviare un errore all'interno di [Distance-to-closest-fence-boundary(m) / 343(m/s)].
Durante il periodo in cui il motore GNSS ha segnalato un errore di stato di rilevamento del recinto virtuale, non dovrebbero esserci eventi di violazione del recinto virtuale inviati al servizio HLOS.
HLOS può reimpostare il rilevamento del recinto virtuale eliminando tutti i recinti virtuali creati in precedenza tramite un unico comando.
I recinti virtuali originati da dispositivi mobili non vengono resi persistenti nell'hardware GNSS o nel driver durante il riavvio o il driver. HLOS gestisce la persistenza per conto delle applicazioni dell'utente finale e crea/elimina recinti virtuali in base alle esigenze.

In termini di interazioni tra la scheda GNSS e il motore GNSS che supporta l'offload geofencing in modo nativo, in caso di errore di rilevamento dei recinti virtuali, l'adattatore GNSS eseguirà le operazioni seguenti:

Userà il rilevamento basato su API dopo che il driver GNSS restituisce un errore per tenere traccia.
Continuerà a eseguire il push di eventuali aggiornamenti (aggiunta/eliminazione) nei recinti virtuali attualmente monitorati a livello di sistema operativo al driver, in modo che siano sincronizzati. Ciò consentirà al motore GNSS di sapere quali recinti virtuali sono attualmente monitorati dal sistema operativo e può fare una traccia o non può tenere traccia della determinazione in base ai dati aggiornati.
Eseguirà il push delle modifiche dello stato del recinto virtuale come determinato dal tracker basato su API dopo che il driver GNSS restituisce SUCCESS nella sua capacità di tenere traccia.

Notifiche del driver per assistenza e dati helper

Di tanto in tanto, il driver GNSS potrebbe richiedere dati di assistenza o azioni helper dall'adattatore GNSS. Sono incluse le varie forme di dati AGNSS (time injection, ephemeris, initial grossolan position), pop-up di consenso utente per supportare il posizionamento del piano utente avviato dalla rete e così via.

I dati di assistenza GNSS possono essere ottenuti dal driver GNSS senza usare la scheda GNSS. Tuttavia, è consigliabile ottenere i dati di assistenza usando l'adattatore GNSS e sfruttare il servizio di posizionamento Microsoft per diversi motivi:
- Lo stack di percorsi Microsoft si occuperà di stabilire le connessioni dati e di rispettare eventuali vincoli di roaming, preferenze di dati, integrazione in modalità non interattiva della rete e così via.
- Il servizio di posizionamento Microsoft può ottenere periodicamente dati di assistenza specifici di un IHV tramite connessione da server a back-end del server e fornire a tutti i dispositivi che necessitano, risparmiando l'IHV la necessità di distribuire il servizio di assistenza front-end in tutto il mondo che soddisfa i requisiti di disponibilità, scalabilità e velocità di risposta.
I consenso utente per la privacy per le applicazioni posta in arrivo sono di proprietà del sistema operativo. Qualsiasi interfaccia utente per informare l'utente di una richiesta di percorso avviato dalla rete o di qualsiasi interfaccia utente per richiedere il consenso dell'utente per rispondere a una richiesta di percorso avviato dalla rete sarà di proprietà di Microsoft. Il driver GNSS informerà la scheda GNSS quando viene ricevuta una richiesta di percorso avviato dalla rete e, se necessario, attenderà la risposta dell'utente fino all'ora predefinita prima di procedere per soddisfare la richiesta.

Poiché il driver GNSS non è in grado di avviare una richiesta al livello superiore autonomamente, questo tipo di operazioni può essere eseguito dalla scheda GNSS cercando in modo proattivo tale richiesta dal driver GNSS e quindi mantenendo sempre uno o più IRP in sospeso in modo che il driver GNSS possa rispondere a tali richieste in sospeso. Al momento della ricezione della richiesta di assistenza/supporto, l'adattatore GNSS recupera i dati (o esegue l'azione specifica per conto del driver GNSS) e successivamente inserisce le informazioni necessarie al driver GNSS tramite un'altra chiamata DeviceIoControl .

La notifica dal driver viene gestita tramite un modello di evento comune. Ad esempio, per l'assistenza GNSS, l'adattatore GNSS usa il codice di controllo IOCTL_GNSS_LISTEN_AGNSS per ricevere la richiesta AGNSS dal driver GNSS. Successivamente, l'adattatore GNSS recupera i dati di assistenza di AGNSS e rilascia IOCTL_GNSS_INJECT_AGNSS per eseguire il push dei dati nel driver GNSS.

Questo meccanismo di notifica viene usato anche per ricevere i dati di avviso correlati al recinto virtuale e gli aggiornamenti dello stato. L'adattatore usa il codice di controllo IOCTL_GNSS_LISTEN_GEOFENCE_ALERT per ricevere singoli avvisi di recinto virtuale e IOCTL_GNSS_LISTEN_GEOFENCES_TRACKINGSTATUS per ricevere modifiche nello stato complessivo del rilevamento del recinto virtuale.

Ai fini della diagnostica, il driver GNSS deve registrare errori e altre informazioni di diagnostica usando il meccanismo di registrazione prescritto da Microsoft descritto di seguito o ETW. È consigliabile che i driver usino WPP a scopo di registrazione anziché ETW, anche se entrambi i meccanismi sono supportati. Tra i motivi per cui si consiglia WPP è la disponibilità di strumenti che consentono il debug dei driver.

Il conducente non deve registrare alcuna informazione, leggibile o meno, diversamente da questa tecnica di registrazione prescrittiva. Per altre informazioni, vedere WPP Software Tracing.For more information, see WPP Software Tracing.

La registrazione dei messaggi con la traccia software WPP è simile all'uso dei servizi di registrazione eventi di Windows. Il driver registra un ID messaggio e dati binari non formattati in un file di log. Successivamente, un postprocessore converte le informazioni nel file di log in un formato leggibile. Tuttavia, la traccia software WPP supporta formati di messaggi più compatibili e flessibili rispetto a quelli supportati dai servizi di registrazione eventi. Ad esempio, la traccia software WPP include il supporto incorporato per indirizzi IP, GUID, ID di sistema, timestamp e altri tipi di dati utili. Inoltre, gli utenti possono aggiungere tipi di dati personalizzati rilevanti per l'applicazione.

Supporto del protocollo dell'operatore mobile

Lo stack GNSS fornito dall'IHV (il driver GNSS, il dispositivo/motore GNSS) è necessario per supportare i vari protocolli di posizionamento degli operatori mobili (SUPL, UPL, CP e così via). In caso contrario, il dispositivo non passerà l'accettazione dagli operatori di telefonia mobile e limiterà significativamente la posizione in cui il dispositivo può essere commercializzato.

Il supporto per questi protocolli e la conformità ai requisiti degli operatori di telefonia mobile è obbligatorio per spedire i dispositivi per determinati operatori di telefonia mobile. Il supporto per i protocolli degli operatori mobili potrebbe non essere essenziale per la maggior parte delle piattaforme non telefoniche, specialmente se la piattaforma non include il supporto MBB (Mobile Broadband).

Tutti i componenti di implementazione sono astratti nello stack IHV e i componenti Microsoft HLOS sono indipendenti da:

Dettagli di implementazione specifici dei protocolli (ad esempio, funzionamento dei protocolli, interpretazione dei messaggi di protocollo e così via).
La forma dello stack di implementazione( ad esempio, l'implementazione può risiedere all'interno del dispositivo/motore GNSS o del driver GNSS o, se necessario, un servizio HLOS separato).
Interazione tra i vari componenti all'interno dello stack GNSS di proprietà IHV per l'implementazione dei protocolli. Ad esempio, se il driver GNSS richiede la Wi-Fi risultati dell'analisi per rispondere a un messaggio di protocollo SUPL specifico, può farlo con un'estensione in modalità utente inserire i risultati dell'analisi Wi-Fi al driver tramite una chiamata IOCTL privata o effettuare questa parte del driver UMDF 2.0 o gestire questa interazione a un livello inferiore. I componenti HLOS di Microsoft GNSS sono oblivious a tali interazioni tra i componenti dello stack IHV GNSS.

In sintesi, l'IHV o l'OEM deve fornire un client SUPL (e potenzialmente un client UPL se il sistema deve essere spedito in Cina) e integrarlo con/all'interno del driver GNSS. Tutte le interazioni della piattaforma di posizione con il client SUPL verranno eseguite tramite GNSS DDI.

Per facilitare l'implementazione dei protocolli degli operatori di telefonia mobile e ridurre il carico di sviluppo di software usando tecnologie specifiche della piattaforma, l'adattatore GNSS fornisce alcune funzionalità allo stack IHV GNSS. Il driver GNSS viene considerato come intermediario per la ricezione di tali funzionalità dai componenti HLOS, ad esempio, l'adattatore GNSS interagisce solo con il driver GNSS e non con nessun'altra parte dello stack GNSS IHV. IOCTLs del driver GNSS definisce la sintassi e la semantica di tali funzionalità tra il driver GNSS e l'adattatore GNSS. Il driver GNSS è responsabile del routing al componente IHV specifico che implementa il protocollo dell'operatore mobile. In generale, l'adattatore GNSS fornisce le funzionalità seguenti al driver GNSS:

Configurazione: Gli operatori di telefonia mobile effettuano il provisioning del dispositivo e modificano la configurazione usando il meccanismo di configurazione imposto dagli standard del protocollo OMA. Ad esempio, lo standard SUPL richiede che la configurazione SUPL venga eseguita in base a UICC e/o venga eseguita usando le informazioni del profilo di configurazione OMA SUPL ottenute tramite OMA-DM o OMA-CP.

Alcune funzionalità disponibili nel telefono a scopo di configurazione (OMA-DM e OMA CP) non erano disponibili in altre piattaforme fino a quando non Windows 10. A partire da Windows 10 tutte le piattaforme possono supportare la configurazione SUPL tramite il provider di servizi di configurazione SUPL (CSP), per quanto riguarda l'uso della nuova DDI GNSS. Il provisioning inserito tramite il CSP può provxml o multivariante dall'immagine stessa o dall'operatore di telefonia mobile tramite OMA-DM o OMA-CP. SUPL CSP è definito in SUPL CSP.

Windows 10 definisce una tecnologia proprietaria, la gestione dei dispositivi tramite un provider di servizi di configurazione (CSP), per interpretare ed estrarre i dati di configurazione. Microsoft fornisce un provider di servizi di configurazione per l'utilizzo della configurazione OMA e il push della configurazione nel driver GNSS tramite la scheda GNSS.

In alternativa, l'IHV può anche scrivere il componente in modalità utente per utilizzare la specifica di configurazione dell'operatore mobile usando la tecnologia di gestione dei dispositivi (CSP) specifica del telefono. Tuttavia, questo sarà un ulteriore onere per L'IHV e non è consigliato.

In un sistema è supportata una sola configurazione SUPL, inclusi i casi di dispositivi dual SIM. Microsoft fornisce la funzionalità per riconfigurare SUPL in base a UICC e alla modifica UICC. Oltre a questo, in caso di roaming del dispositivo, HLOS riconfigura il client SUPL in modo che funzioni in modalità autonoma. Questo documento definisce i valori IOCTLs per il push di tali dati di configurazione per un'ampia gamma di protocolli operativi mobili (SUPL 1.0 e 2.0, v2UPL e così via).
Gestione del consenso utente per le richieste ni: Per soddisfare i requisiti di privacy, alcune richieste di posizionamento avviate dalla rete richiedono il consenso dell'utente. Gli IHD non sono autorizzati a scrivere l'interfaccia utente per i componenti della piattaforma. Di conseguenza, l'adattatore GNSS gestisce l'interfaccia utente per il consenso dell'utente per conto del driver GNSS. IOCTLs di notifica per il driver GNSS per richiedere un popup dell'interfaccia utente e IOCTLs per l'adattatore GNSS per comunicare la risposta dell'utente a tale richiesta sono definiti in IOCTL driver GNSS.

Per implementare un client SUPL completamente funzionante, lo stack IHV dovrà usare interfacce o funzionalità generali disponibili in/tramite la piattaforma del sistema operativo. Di seguito è riportato l'elenco delle funzionalità disponibili in Windows 10 che IHD possono sfruttare per implementare il client SUPL:

Nessuna di queste funzionalità fa parte della piattaforma location o dell'DDI GNSS, ma è inclusa qui per chiarimenti e per aiutare gli sviluppatori di driver GNSS a comprendere cosa può essere sfruttato dal sistema operativo per implementare la funzionalità SUPL.

Interazione del client SUPL con un driver GNSS.

Router SMS: Il router SMS consente al client SUPL di sottoscrivere il push WAP dei messaggi push SIP che inducono richieste SUPL NI.
Gestione connessioni possibilità di configurare quale connessione deve essere usata per le API e SUPL per richiedere tale connessione: gli operatori mobili possono richiedere il traffico SUPL in una connessione dedicata o semplicemente su una connessione diversa dalla connessione Internet predefinita. A tale scopo, Gestione connessioni offerte:
- Provider di servizi di configurazione che l'OEM o l'operatore mobile possono usare per configurare la connessione che deve essere usata allo scopo delle comunicazioni SUPL.
- API per il client SUPL per eseguire query sui parametri di connessione della connessione SUPL.
- API per stabilire la connessione SUPL, con i parametri ottenuti nel passaggio precedente.
Configurazione connessione cellulare: Per configurare i parametri di connessioni cellulari diverse, ad esempio i parametri per una connessione SUPL, esiste un provider di servizi di configurazione che l'OEM o l'operatore mobile può usare. Questa connessione può quindi essere associata in Gestione connessioni allo scopo SUPL.
Richiedere di mantenere attive le connessioni mentre è in corso una connessione SUPL: Il client SUPL potrebbe dover avviare connessioni con HSLP mentre il sistema è in standby connesso. Ciò può verificarsi perché il dispositivo GNSS deve ottenere informazioni di assistenza quando configurate per l'uso della posizione basata su Microsoft o perché l'operatore mobile ha inviato una richiesta di interfaccia di rete. Se si tratta del caso, il client SUPL dovrà avviare una connessione con HSLP e assicurarsi che la connessione sia attiva fino al completamento della sessione SUPL.
Interazioni con il modulo Mobile Broadband (MBB): In Windows 10 non sono disponibili API tramite HLOS per recuperare le misurazioni cellulari, sapere quando è stata inserita una chiamata di emergenza e così via. Qualsiasi interazione con MBB deve essere eseguita tramite l'integrazione diretta con MBB (tramite comandi AT o altro metodo proprietario).

Test di produzione

Le macchine virtuali devono avere un modo per convalidare in fase di produzione e anche presso i punti di supporto clienti che l'hardware GNSS e lo stack GNSS (il driver GNSS e il motore del dispositivo/motore GNSS) funzionano correttamente. L'IHV può fornire meccanismi proprietari per consentire alle macchine virtuali di eseguire questo test o, facoltativamente, di implementare l'interfaccia nell'interfaccia DDI per consentire all'OEM di avviare i test di produzione e ottenere risultati.

Il framework di posizione verrà ignorato quando si esegue il test di produzione, dato che una grande attenzione al test è relativa alla convalida hardware o alla convalida del driver. In generale, il dispositivo sarà in una speciale modalità "sistema operativo sicuro" in cui verrà caricato il set minimo di componenti e servizi. In questa modalità, l'OEM può avviare un set di applicazioni di test che attiveranno i test case. Per l'efficienza e la velocità durante la produzione, è altamente desiderato avere supporto di concorrenza per i test all'interno di componenti diversi.

L'interfaccia per i test di produzione include due tipi di test:

Test dell'onda del vettore: Questo test consiste nel convalidare il test di connettività/antenna esterna. In questo test, il motore GNSS deve cercare un segnale CW e fornire le unità di rete (segnale alle rationi di rumore o alla trazione del vettore) nella risposta. Idealmente i test devono fornire risposte a 10 Hz.
Auto-test: Questo test consiste nel convalidare la funzionalità di base del motore GNSS. L'auto-test deve essere in grado di rilevare problemi di base nel motore (hardware difettoso, connessioni non riuscite nell'hardware GNSS senza richiedere alcun segnale esterno inserito. L'obiettivo di questa convalida è eseguire questo test economico e usarlo come cancello nella linea di produzione, prima che il dispositivo attraversi test più esaustivi e costosi. In questo test, il motore E driver GNSS eseguirà la convalida automatica per le connessioni pin e restituirà un codice di stato che indica che tutto è OK o che si è verificato un errore. Il codice di errore per gli errori deve indicare l'errore rilevato. I codici di errore vengono impostati dall'IHV.

Considerazioni di I/O

Poiché la funzionalità GNSS non esegue il mapping alle richieste di lettura e scrittura di file tradizionali ai driver di dispositivo, le funzioni ReadFile e WriteFile non verranno usate per le API del driver GNSS. Tutte le funzionalità GNSS verranno implementate usando richieste di I/O specifiche del dispositivo GNSS ben definite, note anche come IOCTLs.

Tutti i IOCTLs useranno METHOD_BUFFERED come meccanismo di trasferimento dei dati per i dati di input e di output. Poiché le dimensioni dei dati correlati al GNSS sono relativamente piccole, la copia del buffer aggiuntivo non deve influire sulle prestazioni del sistema.

Il driver GNSS verrà aperto usando l'opzione FILE_FLAG_OVERLAPPED nella funzione CreateFile . Di conseguenza, tutti i IOCTLs sono implicitamente asincroni. Tuttavia, mentre la maggior parte degli IOCTLs GNSS è semanticamente asincrona (ad esempio, un'attività IOCTL attiva un'attività all'interno del driver e i risultati sono previsti in modo asincrono), alcuni IOCTLs sono semanticamente sincroni nel senso che non esiste un'azione asincrona logica o attività coinvolte con tali IOCTL. Il comportamento sincrono di questi pochi IOCTLs verrà ottenuto bloccando il thread dell'adattatore GNSS dopo l'emissione della chiamata DeviceIoControl fino al completamento dell'operazione di I/O. Di conseguenza, è responsabilità del driver GNSS completare sempre l'IRP come parte dell'elaborazione di tutti gli IOCTLs. L'adattatore GNSS dovrebbe rispettare il contratto di una chiamata sincrona e in caso di errori potrebbe o non riprovare questi comandi. Il driver IHV deve assicurarsi che abbia incorporato tutte le logiche sul lato driver prima di restituire un errore.

Per le operazioni di richiesta e risposta, l'adapter GNSS mantiene sempre disponibile un'operazione di I/O in sospeso in modo che quando il driver GNSS disponga di dati da inviare come risposta a un'operazione richiamata in precedenza, la risposta può essere inviata tramite l'IRP in sospeso.

Sessione singola di colpo

Una richiesta di correzione iniziale per una singola correzione di colpo al driver include valori di accuratezza e tempo di risposta. Il motore GNSS può usare questi valori per comprendere la finalità della richiesta dell'applicazione e prendere decisioni intelligenti. Una volta ricevuta una richiesta dal driver, deve iniziare a restituire eventuali correzioni intermedie generate dal motore. Le correzioni intermedie sono correzioni generate dal motore durante il calcolo di una correzione che soddisfa i requisiti di accuratezza o è finale. La frequenza di queste correzioni intermedie non viene applicata ed è un dettaglio dell'implementazione del motore. L'adattatore GNSS prevede che le correzioni vengano apportate ogni pochi secondi e che siano diverse dall'ultima correzione intermedia.

Una volta che il motore GNSS determina che non può ottenere una correzione migliore in base alle condizioni di segnale correnti, dovrebbe restituire una correzione finale e dovrebbe interrompere l'esecuzione di ulteriori calcoli. La correzione finale soddisfa il requisito di accuratezza o indica che il motore non può migliorare l'accuratezza fornita in condizioni correnti.

L'adattatore GNSS genera una correzione di arresto per una singola sessione di colpo in uno dei due casi:

Ottiene una correzione finale dal driver.
Il tempo di risposta per la richiesta è stato raggiunto. Qui verrà inviata l'ultima correzione intermedia all'applicazione.

La figura seguente illustra due singole sessioni di ripresa:

diagramma che mostra le correzioni intermedie per due sessioni.

Sessione 1: Il driver è stato assegnato ai parametri Precisione e Tempo di risposta. Dopo il comando di correzione iniziale, il driver ha avviato l'invio di correzioni intermedie. Dopo un po', ha determinato che non poteva restituire una correzione più accurata, quindi indicava l'ultima correzione come finale. Questo problema si è verificato prima del raggiungimento del limite di tempo di risposta. L'adapter ha inviato la correzione finale all'applicazione ed ha rilasciato un comando di correzione di arresto.

Sessione 2: Come nella sessione 1 precedente, ma in questo caso il motore ha continuato ad andare per una correzione migliore per soddisfare il requisito di accuratezza e mantenuto l'invio di correzioni intermedie tra. Una volta raggiunto il limite di tempo di risposta della sessione, l'adapter ha rilasciato una correzione di arresto che dovrebbe chiudere questa sessione nel driver. L'ultima correzione intermedia ricevuta è stata inviata all'applicazione.

Un aspetto importante della progettazione da considerare quando si implementa il supporto a colpo singolo è che, se le sessioni di rilevamento in base alla distanza e le sessioni di rilevamento basate sul tempo non sono entrambe supportate, il motore GNSS continuerà a tenere traccia dei satelliti per 3-5 secondi dopo aver ricevuto un comando di correzione di arresto. Ciò avviene perché l'adattatore GNSS dovrà implementare sessioni di rilevamento basato sulla distanza simulate e/o sessioni di rilevamento basate sul tempo usando sessioni di correzione a colpo singolo e se il motore GNSS arresta immediatamente il rilevamento dei satelliti, la maggior parte dei dispositivi GNSS avrà un ritardo sull'acquisizione che rende impossibile un'implementazione di una sessione di rilevamento simulata che soddisfi le esigenze di navigazione, eseguire il rilevamento o il mapping delle applicazioni.

L'adattatore GNSS può avviare richieste di correzioni a singolo colpo mentre il sistema è in Standby connesso, non solo quando il sistema è Attivo. Ciò può verificarsi per soddisfare la necessità di attività in background, servizi di sistema, rilevamento dei geofences nel processore dell'applicazione o in altri casi. Il driver GNSS può passare queste richieste di sessione al dispositivo GNSS e soddisfare la richiesta o fornire un errore all'adattatore GNSS.

Il diagramma della sequenza seguente illustra le azioni di alto livello correlate al recupero di una correzione GNSS autonoma. Questo non include alcuna richiesta di dati di assistenza.

diagramma di sequenza per l'architettura gnss .

La descrizione della sequenza è la seguente:

L'adapter GNSS apre il driver GNSS usando l'API CreateFile . WDF/KMDF/UMDF rende i callback facoltativi necessari al driver GNSS. L'handle di file restituito viene usato per tutte le operazioni successive.
L'adattatore GNSS rilascia un IOCTL per comunicare le varie funzionalità della piattaforma al driver. Il driver GNSS completa l'operazione di I/O.
L'adattatore GNSS rilascia IOCTL per ottenere le funzionalità del dispositivo. Il driver GNSS restituisce le funzionalità del dispositivo e completa l'operazione di I/O.
L'adapter GNSS genera IOCTLs per qualsiasi configurazione o comando specifico del driver. Il driver GNSS esegue l'azione necessaria e completa l'operazione di I/O.
L'adattatore GNSS genera un IOCTL_GNSS_START_FIXSESSION, insieme ai parametri che specificano il tipo e altri aspetti della correzione. Dopo aver ricevuto questo IOCTL, il driver GNSS interagisce con il dispositivo sottostante per avviare la ricezione di correzioni e successivamente completa l'operazione di I/O.
L'adattatore GNSS genera un IOCTL_GNSS_GET_FIXDATA e attende il completamento dell'I/O. Ogni volta che il driver GNSS ha una correzione intermedia disponibile, restituisce i dati completando l'operazione di I/O.
Il passaggio 6 viene ripetuto fino a quando il driver GNSS indica che non sono previste altre correzioni (correzione finale ricevuta).
L'adattatore GNSS genera problemi IOCTL_GNSS_STOP_FIXSESSION. Il driver GNSS esegue l'operazione di pulizia necessaria associata alla richiesta di correzione originale.
L'adapter GNSS chiude l'handle del file driver usando l'API CloseHandle .

Gli IOCTLs GNSS e le strutture di dati associate sono descritti in dettaglio nel riferimento al driver GNSS.

Sessione di rilevamento basata sulla distanza

Le sessioni di rilevamento basate sulla distanza vengono usate spesso dalle applicazioni end-user, come storicamente, è stato l'unico tipo di sessione disponibile nelle API .NET. Un valore di distanza pari a 0 indica che il motore GNSS fornisce correzioni al tasso più alto possibile.

L'adattatore GNSS inizierà le sessioni di rilevamento della distanza con il driver GNSS, solo se quest'ultimo indica che ha la funzionalità SupportDistanceTracking.

Una richiesta di correzione iniziale al driver per una sessione di rilevamento distanza includerà l'accuratezza orizzontale desiderata e la soglia di spostamento, ovvero la distanza di spostamento in metri che il sistema deve coprire prima che il driver GNSS fornisca un aggiornamento della posizione. Il motore GNSS può usare questi valori per comprendere la finalità della richiesta dell'applicazione e prendere decisioni intelligenti, ad esempio adattare la frequenza in corrispondenza della quale verificare la posizione.

Una volta ricevuta una richiesta di correzione iniziale dal driver, dovrebbe iniziare a restituire eventuali correzioni intermedie generate dal motore, fino a quando non ottiene una correzione finale. Verrà considerata la prima posizione della sessione. Dopo che il motore GNSS deve iniziare a fornire correzioni ogni volta che rileva che la distanza di rsine è stata approssimativamente coperta.

Se il motore GNSS determina che non riesce più a tenere traccia della posizione del dispositivo (ad esempio, se i satelliti non sono più visibili), dovrebbe restituire un errore alla scheda GNSS in modo che la piattaforma di posizione possa tornare ad altri meccanismi per fornire aggiornamenti di posizione all'applicazione dell'utente finale. L'adattatore GNSS fornisce un errore entro il momento seguente:

[(Distanza rimanente-da-ultima posizione nota (m) / velocità stimata (m/s)- 5 secondi] o 5 secondi, che tuttavia è più grande.

Se il motore GNSS ha fornito un errore all'adattatore GNSS, ma l'adattatore GNSS non ha ancora arrestato la sessione di rilevamento, il motore GNSS deve continuare a controllare, in modo ottimizzato per la potenza, se può riprendere la posizione di rilevamento. L'IHV può usare ottimizzazioni per rendere questo rilevamento a bassa potenza. Le tecniche comuni per l'ottimizzazione includono:

Back-off progressivo
In attesa di segnali a basso costo che sono indicativi dei movimenti dei dispositivi per ricontrollare
Controlli di potenza ridotta per il segnale satellite

Una volta che il motore GNSS è in grado di fornire nuovamente una correzione finale dopo una condizione di errore, deve inviare tale posizione all'adattatore GNSS come indicazione che il rilevamento è stato ripreso correttamente.

L'adattatore GNSS genera un comando di correzione di modifica per una sessione di rilevamento basata su distanza se una o più applicazioni che hanno richiesto la sessione di rilevamento hanno annullato la richiesta o se le nuove applicazioni richiedono una sessione di rilevamento basata sulla distanza. In tal caso, l'adapter GNSS calcola i nuovi parametri di sessione aggregati necessari per multiplex le diverse sessioni attive e aggiorna il driver GNSS con questi parametri.

L'adapter GNSS genera un comando di correzione di arresto per una sessione di rilevamento basata sulla distanza se:

La sessione di rilevamento è stata passata a un altro motore di posizionamento disponibile nel sistema.
Le applicazioni che hanno richiesto la sessione di rilevamento hanno annullato la richiesta.

La figura seguente illustra due sessioni di rilevamento in base alla distanza:

rilevamento interno per il driver gnss .

Sessione 1: Il driver GNSS ha fornito parametri di precisione e soglia di spostamento durante l'avvio della sessione di rilevamento. Dopo il comando di correzione iniziale, il driver avvia l'invio di correzioni intermedie fino a quando non ottiene una correzione finale o una correzione che soddisfa il requisito di accuratezza al momento in cui tale correzione viene fornita all'adattatore GNSS e il motore GNSS inizierà il processo di rilevamento della distanza. Mentre la sessione è attiva, l'adattatore GNSS invia una richiesta per modificare i parametri della sessione a volte T1 e T2. Dopo ogni modifica dei parametri, il driver GNSS invierà un aggiornamento corretto alla scheda GNSS e riprenderà la sessione di rilevamento della distanza con i nuovi parametri, fino a quando l'adapter GNSS invia un comando di correzione di arresto.

Sessione 2: Il processo di avvio della sessione è simile alla sessione 1 precedente, ma a un determinato punto il motore GNSS non è in grado di tenere traccia della posizione. Dopo un periodo di tempo dipendente dalla distanza e dalla velocità stimata del movimento, il driver GNSS invia un errore. Il motore GNSS continua a controllare la potenza inferiore quando può essere ripristinato e quando viene ripristinato indica così all'adattatore GNSS inviando una nuova correzione. La sessione viene aggiornata con nuove correzioni in base alle esigenze finché l'adapter GNSS invia un comando di correzione di arresto.

La scheda GNSS può mantenere attive o anche avviare sessioni di rilevamento in base alla distanza mentre il sistema è in standby connesso, non solo quando il sistema è attivo. Ciò può verificarsi per soddisfare la necessità di attività in background, servizi di sistema, rilevamento di geofences nel processore dell'applicazione o in altri casi. Il driver GNSS può passare queste richieste di sessione al dispositivo GNSS e soddisfare la richiesta o fornire un errore all'adattatore GNSS.

Sessione di rilevamento basata sul tempo

Le sessioni di rilevamento basate sul tempo possono essere usate dalle applicazioni che richiedono un aggiornamento frequente e regolare della posizione per aggiornare l'interfaccia utente,ad esempio mappe, applicazioni di spostamento e così via.

L'adattatore GNSS inizierà le sessioni di rilevamento basate sull'ora con il driver GNSS, solo se in seguito indica che ha la funzionalità SupportContinuousTracking.

Una richiesta di correzione iniziale al driver per una sessione di rilevamento basata sul tempo includerà l'accuratezza orizzontale desiderata e l'intervallo di tempo preferito in corrispondenza del quale il driver GNSS deve fornire un aggiornamento della posizione. Il motore GNSS può usare questi valori per comprendere la finalità della richiesta dell'applicazione e prendere decisioni intelligenti, ad esempio adattare la frequenza in corrispondenza della quale verificare la posizione, avviare l'acquisizione di satelliti a pochi secondi prima dell'intervallo per fornire un aggiornamento tempestivo della posizione e così via.

Una volta ricevuta una richiesta di correzione iniziale dal driver, dovrebbe iniziare a restituire eventuali correzioni intermedie generate dal motore, fino a quando non ottiene una correzione finale. Verrà considerata la prima posizione della sessione. Dopo che il motore GNSS deve iniziare a fornire correzioni all'intervallo richiesto dai parametri di sessione. Se il motore GNSS non è in grado di fornire posizioni alla frequenza richiesta dall'applicazione, deve fornire correzioni alla velocità massima possibile.

Se il motore GNSS determina che non riesce più a tenere traccia della posizione del dispositivo (ad esempio, se i satelliti non sono più visibili), dovrebbe restituire un errore all'adattatore GNSS in modo che la piattaforma di posizione possa tornare ad altri meccanismi per fornire aggiornamenti della posizione all'applicazione dell'utente finale.

L'IHV può usare ottimizzazioni per rendere il rilevamento a bassa potenza, come illustrato nella sezione precedente. Una volta che il motore GNSS è in grado di fornire nuovamente una correzione finale dopo una condizione di errore, deve inviare tale posizione all'adattatore GNSS come indicazione che il rilevamento è stato ripreso correttamente.

L'adapter GNSS genera un comando di correzione di modifica per una sessione di rilevamento basata sul tempo se una o più applicazioni che hanno richiesto la sessione di rilevamento hanno annullato la richiesta o se le nuove applicazioni richiedono una sessione di rilevamento basata sul tempo. In tal caso, l'adapter GNSS calcola i nuovi parametri di sessione aggregati necessari per multiplex le diverse sessioni attive e aggiorna il driver GNSS con questi parametri.

L'adattatore GNSS genera un comando di correzione di arresto per una sessione di rilevamento basata sul tempo se:

La sessione di rilevamento è stata passata a un altro motore di posizionamento disponibile nel sistema.
Le applicazioni che hanno richiesto la sessione di rilevamento hanno annullato la richiesta.

La figura seguente illustra due sessioni di rilevamento basate sul tempo.

diagramma di rilevamento basato sul tempo per le correzioni dei driver gnss.

Sessione 1: Il driver GNSS è stato fornito con accuratezza e un parametro di intervallo preferito durante l'avvio della sessione di rilevamento. Dopo il comando di correzione iniziale, il driver inizierà a inviare correzioni intermedie fino a quando non ottiene una correzione finale o una correzione che soddisfa il requisito di accuratezza al momento in cui tale correzione viene fornita all'adattatore GNSS e il motore GNSS inizierà il processo di rilevamento basato sul tempo. Mentre la sessione è attiva, l'adattatore GNSS invia una richiesta per modificare i parametri della sessione a volte T1 e T2. Dopo ogni modifica dei parametri, il driver GNSS invierà un aggiornamento di correzione all'adapter GNSS e riprenderà la sessione di rilevamento basata sul tempo, con i nuovi parametri, fino a quando l'adapter GNSS invia un comando di correzione di arresto.

Sessione 2: Il processo di avvio della sessione è simile a quello precedente della sessione 1, ma a un determinato punto il motore GNSS smette di essere in grado di tenere traccia della posizione. Quando il motore GNSS non è in grado di fornire una correzione entro 15 secondi dell'intervallo richiesto dai parametri di sessione, il driver GNSS invia un errore. Il motore GNSS continua a controllare la potenza inferiore quando può essere ripristinato e quando viene ripristinato indica così all'adattatore GNSS inviando una nuova correzione. La sessione viene aggiornata con nuove correzioni in base alle esigenze finché l'adapter GNSS invia un comando di correzione di arresto.

L'adattatore GNSS può mantenere attive o anche avviare sessioni di rilevamento in base al tempo mentre il sistema è in standby connesso, non solo quando il sistema è attivo. Ciò può verificarsi per soddisfare la necessità di attività in background, servizi di sistema, rilevamento del geofence nel processore dell'applicazione o altri casi. Il driver GNSS può passare queste richieste di sessione al dispositivo GNSS e soddisfare la richiesta o fornire un errore all'adattatore GNSS.

Gestire diversi tipi di sessione di correzione contemporaneamente

Alcuni motori GNSS avanzati possono essere in grado di gestire simultaneamente una sessione Single Shot, con un Distance-Based e/o una sessione di rilevamento Time-Based. Le sessioni idealmente indipendenti non devono influenzare l'una l'altra, ma questo potrebbe non essere sempre possibile, specialmente nel caso di sessioni di rilevamento simultaneo basato su tempo e colpo singolo. Questa sezione fornisce alcune linee guida per l'implementazione IHV per nel caso in cui siano necessarie compromissioni per gestire sessioni simultanee di diversi tipi.

Gli acronimi seguenti vengono usati in questa sezione:

SS: Sessione a colpo singolo
DBT: Sessione di rilevamento basato sulla distanza
TBT: sessione di rilevamento in base al tempo
TBF: Tempo tra correzioni

La tabella seguente fornisce alcuni scenari per la gestione simultanea di sessioni di rilevamento in base al tempo e al singolo colpo:

Caso	SS attivo?	TBT attivo?	Dettagli del caso	Intervallo accettabile di correzioni	Commenti
1	X	X	Sessione SS in corso al momento della sessione periodica TBT avviata con timeout >rimanente = intervallo	Uguale all'intervallo TBT	Comportamento sessione SS: Le correzioni intermedie e finali vengono inviate fino al timeout. Sessione chiusa immediatamente dopo l'arresto ricevuto. Comportamento della sessione TBT: Vengono inviate correzioni intermedie e finali. Correzioni ricevute approssimativamente in base all'intervallo. Sessione chiusa immediatamente dopo l'arresto ricevuto.
2	X	X	Sessione SS in corso al momento della sessione periodica TBT avviata con l'intervallo di timeout < rimanente	L'intervallo rimane identico al timeout del servizio di configurazione, fino a quando non viene soddisfatta la sessione SS. L'intervallo può quindi essere aggiornato allo stesso intervallo TBT.	Comportamento sessione SS: Le correzioni intermedie e finali vengono inviate fino al timeout. Sessione chiusa immediatamente dopo l'arresto ricevuto. Comportamento della sessione TBT: Vengono inviate correzioni intermedie e finali Le correzioni ricevute approssimativamente in base all'intervallo, ma potrebbero essere più frequenti mentre viene eseguita la sessione SS. Sessione chiusa immediatamente dopo la ricezione dell'arresto.
3	X	X	Sessione SS avviata mentre è presente una sessione periodica TBT in corso avviata con timeout >= intervallo	Uguale all'intervallo TBT	Comportamento della sessione SS: Le correzioni intermedie e finali vengono inviate fino al timeout. Sessione chiusa immediatamente dopo la ricezione dell'arresto. Comportamento della sessione TBT: Vengono inviate correzioni intermedie e finali Correzioni ricevute approssimativamente in base all'intervallo. Sessione chiusa immediatamente dopo la ricezione dell'arresto.
4	X	X	Sessione SS avviata mentre è presente una sessione periodica TBT in corso avviata con l'intervallo di timeout <	L'intervallo cambia in modo che corrisponda al timeout SS, fino a quando non viene soddisfatta la sessione SS. È quindi possibile aggiornare l'intervallo in modo che corrisponda all'intervallo TBT.	Comportamento della sessione SS: Le correzioni intermedie e finali vengono inviate fino al timeout. Sessione chiusa immediatamente dopo la ricezione dell'arresto. Comportamento della sessione TBT: Vengono inviate correzioni intermedie e finali. Le correzioni ricevute approssimativamente in base all'intervallo, ma potrebbero essere più frequenti mentre viene servita la sessione SS. Sessione chiusa immediatamente dopo la ricezione dell'arresto.
5		X	Sessione periodica TBT avviata con intervallo modificato	La sessione con modem viene aggiornata al nuovo intervallo in modo che corrisponda all'intervallo TBT. Se necessario, la sessione modem verrà riavviata.	Comportamento della sessione SS: Non applicabile Comportamento della sessione TBT: Vengono inviate correzioni intermedie e finali. Correzioni ricevute approssimativamente in base all'intervallo. Sessione chiusa immediatamente dopo la ricezione dell'arresto.
6	X	X	Sessione SS in corso al momento in cui una sessione periodica TBT in corso riceve una modifica dell'intervallo, con timeout >rimanente = intervallo	Uguale all'intervallo TBT	Comportamento della sessione SS: Le correzioni intermedie e finali vengono inviate fino al timeout. Sessione chiusa immediatamente dopo la ricezione dell'arresto. Comportamento della sessione TBT: Vengono inviate correzioni intermedie e finali Correzioni ricevute approssimativamente in base all'intervallo. Sessione chiusa immediatamente dopo la ricezione dell'arresto.
7	X	X	Sessione SS in corso al momento in cui una sessione periodica TBT in corso riceve una modifica dell'intervallo, con l'intervallo di timeout < rimanente	L'intervallo cambia in modo che corrisponda al timeout rimanente di SS, fino a quando non viene soddisfatta la sessione SS. È quindi possibile aggiornare l'intervallo in modo che corrisponda all'intervallo TBT.	Comportamento della sessione SS: Le correzioni intermedie e finali vengono inviate fino al timeout. Sessione chiusa immediatamente dopo la ricezione dell'arresto./li> Comportamento della sessione TBT: Vengono inviate correzioni intermedie e finali Le correzioni ricevute approssimativamente in base all'intervallo, ma potrebbero essere più frequenti mentre viene servita la sessione SS. Sessione chiusa immediatamente dopo la ricezione dell'arresto.

Se sono presenti contemporaneamente sia una sessione di rilevamento basata sul tempo che una sessione di rilevamento basato sulla distanza, il rilevamento dell'accuratezza del motore GNSS può essere impostato per funzionare con il più piccolo dei due. La tabella seguente fornisce anche alcune linee guida per il caso di valori diversi per l'accuratezza necessaria quando sono presenti sessioni simultanee di tiro singolo e di rilevamento:

Caso	Accuratezza SS	Accuratezza DBT o TBT	Accuratezza complessiva del motore GNSS	Commenti
1	Medio/Basso -> Alto	Non applicabile	Medio/Basso -> Alto	Comportamento della sessione SS: La sessione con il dispositivo GNSS viene aggiornata o riavviata per ottenere un risultato di accuratezza elevata. Le correzioni intermedie vengono fornite al modulo HLOS perché sono disponibili.
2	Alto --> Medio/Basso	Non applicabile	Alto --> Medio/Basso	Comportamento della sessione SS: La sessione con il dispositivo GNSS viene aggiornata o riavviata per ottenere un risultato di accuratezza medio/basso. Se è già disponibile una correzione che soddisfa i requisiti, viene restituita come correzione finale. In caso contrario, le correzioni intermedie vengono fornite al modulo HLOS perché sono disponibili.
3	Medio/Basso -> Alto	Alto	Alto	Comportamento della sessione SS: Dato che esiste già una sessione di accuratezza elevata per la sessione DBT o TBT, la sessione SS fornisce solo ulteriori correzioni intermedie al file HLOS fino a quando non viene ottenuta l'accuratezza finale desiderata o viene ottenuta una correzione finale.
4	Alto --> Medio/Basso	Alto	Alto	Comportamento della sessione SS: Dato che esiste già una sessione di accuratezza elevata per la sessione DBT o TBT, la sessione SS fornisce solo ulteriori correzioni intermedie al file HLOS fino a quando non viene ottenuta l'accuratezza finale desiderata o viene ottenuta una correzione finale.
5	Medio/Basso -> Alto	Medio/Basso	Medio/Basso -> Alto, quindi torna a medio/basso dopo il completamento della sessione SS	Comportamento sessione SS: La sessione con il dispositivo GNSS viene aggiornata o riavviata per ottenere un risultato di accuratezza elevata. Le correzioni intermedie vengono fornite al file HLOS quando sono disponibili. Comportamento della sessione DBT o TBT: È OK per questa sessione per ricevere temporaneamente risultati di accuratezza elevata. Tuttavia, dopo aver servito la sessione SS, l'accuratezza di questa sessione deve tornare a Media/Bassa.
6	Alto --> Medio/Basso	Medio/Basso	Alto --> Medio/Basso	Comportamento sessione SS: La sessione con il dispositivo GNSS viene aggiornata o riavviata per ottenere risultati di accuratezza media/bassa. Se una correzione soddisfa i requisiti è già disponibile, viene restituita come correzione finale. In caso contrario, le correzioni intermedie vengono fornite al file HLOS quando sono disponibili.
7	Non applicabile	Medio/basso -> Alto	Medio/basso -> Alto	b>DBT o COMPORTAMENTO sessione TBT:** Sessione con dispositivo GNSS aggiornata o riavviata per ottenere risultati di accuratezza elevata. Le correzioni intermedie vengono fornite al file HLOS quando sono disponibili.
8	Non applicabile	Alto --> Medio/Basso	Alto --> Medio/Basso	Comportamento della sessione DBT o TBT: La sessione con il dispositivo GNSS viene aggiornata o riavviata per ottenere risultati di accuratezza media/bassa. Se una correzione soddisfa i requisiti è già disponibile, viene restituita come correzione finale. In caso contrario, le correzioni intermedie vengono fornite al file HLOS quando sono disponibili.
9	Alto	Medio/basso -> Alto	Alto	Comportamento della sessione DBT o TBT: La sessione ha già ottenuto correzioni di accuratezza elevata o correzioni intermedie, quindi nessuna modifica.
10	Alto	Alto --> Medio/Basso	Ad alto quindi cambia in Media/Basso dopo il completamento della sessione SS	Comportamento della sessione DBT o TBT: La sessione può continuare a ottenere correzioni di accuratezza elevata o correzioni intermedie, fino al completamento della sessione SS. Verrà quindi modificato in correzioni di accuratezza media/bassa.
11	Medio/Basso<	Medio/basso -> Alto	Medio/basso -> Alto	Comportamento della sessione DBT o TBT: La sessione con il dispositivo GNSS viene aggiornata o riavviata per ottenere risultati di accuratezza elevata. Le correzioni intermedie vengono fornite al file HLOS quando sono disponibili.
12	Medio/Basso	Alto --> Medio/Basso	Alto --> Medio/Basso	Comportamento della sessione DBT o TBT: La sessione con il dispositivo GNSS viene aggiornata o riavviata per ottenere risultati di accuratezza media/bassa. Se una correzione soddisfa i requisiti è già disponibile, viene restituita come correzione finale. In caso contrario, le correzioni intermedie vengono fornite al file HLOS quando sono disponibili.

Condividi tramite

Panoramica dell'architettura

Supporto per i dispositivi e i driver GNSS (Global Navigation Satellite System) che seguono il modello Windows legacy

Coesistenza dei dispositivi GNSS (Global Navigation Satellite System)

Panoramica dell'interfaccia global Navigation Satellite System (GNSS)