Condividi tramite

Requisiti del driver GNSS (Global Navigation Satellite System)

  • Articolo

Descrive i requisiti, i presupposti e i vincoli da considerare quando si sviluppa un driver GNSS (Global Navigation Satellite System) per Windows 10.

Requisiti generali

  • Framework driver: Il driver GNSS deve essere scritto come driver UMDF 2.0 basato su questa definizione di interfaccia, anziché come driver WDM non elaborato o driver KMDF. I driver UMDF 1.0 non sono supportati. La definizione dell'interfaccia driver GNSS O i componenti GNSS di Microsoft high level system (HLOS) GNSS come adattatore GNSS non fanno una distinzione tra un driver WDF, un driver GNSS kmDF e un driver UMDF 2.0, purché il driver fornisca le funzionalità necessarie per questa progettazione dell'interfaccia. UMDF 2.0 offre una maggiore stabilità, semplicità e flessibilità per implementare funzionalità che richiedono funzionalità offerte solo in modalità utente. Come regola generale, le IHV devono preferire UMDF 2.0 a KMDF quando il framework precedente è disponibile nella piattaforma.

 UMDF 2.0 è disponibile in tutte le piattaforme e le IHV sono fortemente consigliate per usare il driver scritto in modalità utente.

  • Più sessioni dell'applicazione: Una sessione dell'applicazione è una sessione di posizionamento proveniente da un componente HLOS che interagisce direttamente con il driver GNSS. Il driver GNSS può scegliere di supportare in modo nativo più sessioni dell'applicazione partizionando le variabili di stato e le funzionalità in base all'applicazione. Si tratta di una funzionalità facoltativa del driver e viene indicata in modo specifico tramite informazioni sulla funzionalità del driver GNSS ben definite. Per supportare questo comportamento facoltativo, il driver GNSS deve tenere traccia dell'handle di file che le applicazioni HLOS ottengono durante CreateFile e associano tutte le operazioni HLOS successive all'handle di file specifico della sessione dell'applicazione. Questo supporto nativo dal driver GNSS consente ai componenti HLOS di essere più flessibili e meno restrittivi sull'esposizione del driver al resto della piattaforma. Un driver GNSS che supporta questa funzionalità potrebbe dover partizionare logicamente e mantenere le informazioni sullo stato per ogni singola sessione dell'applicazione. Un driver GNSS che non supporta questa funzionalità dovrà solo mantenere lo stato globale per tutte le sessioni dell'applicazione anziché la partizione specifica dell'app logica. In questa modalità, il driver GNSS è oblivioso alla presenza di più sessioni dell'applicazione parallele e considera tutte le richieste da HLOS come se siano originati dalla stessa sessione dell'applicazione.

    supporto del driver gnss per più sessioni dell'applicazione.

    Il supporto nel driver GNSS per più sessioni dell'applicazione ha il vantaggio di abilitare un'applicazione di test nel modulo HLOS per interagire direttamente con il driver GNSS contemporaneamente all'adapter GNSS. L'applicazione di test e l'adattatore GNSS sono le diverse applicazioni che possono richiedere a un singolo driver GNSS diverse contemporaneamente. Se più sessioni dell'applicazione non sono supportate, il driver GNSS deve essere testato tramite la piattaforma posizione del sistema operativo o altrimenti il servizio che ospita la piattaforma posizione del sistema operativo deve essere arrestato per evitare l'interferimento con l'applicazione di test.

  • Correzione della sessione: L'atto di ottenere informazioni di posizionamento dal driver sottostante (singolo colpo o rilevamento) viene astratti in una nozione di una sessione di correzione. I driver devono supportare almeno una sessione di correzione di ogni tipo di sessione supportata. I tipi di sessione vengono definiti sotto l'enumerazione GNSS_FIXSESSIONTYPE .

    • Almeno, i driver GNSS devono supportare una singola sessione di correzione dei colpi.

    • I driver che supportano le sessioni di correzione in base alla distanza devono supportare simultaneamente una singola sessione di correzione degli scatti e una sessione di correzione basata sulla distanza.

    • I driver che supportano le sessioni di correzione basate sul tempo devono supportare contemporaneamente una singola sessione di correzione degli scatti e una sessione di correzione basata sul tempo.

    • I driver che supportano sessioni di correzione del rilevamento basato sulla distanza e sessioni di correzione basate sul tempo devono supportare simultaneamente una singola sessione di correzione del rilevamento in base alla distanza, una sessione di correzione basata sulla distanza e una sessione di correzione basata sul tempo.

    supporto driver di più sessioni di correzione simultanee.

    Se il driver supporta più sessioni di correzione simultanee o meno è espresso da un parametro di funzionalità del driver ben definito. Se un driver non supporta in modo esplicito più sessioni di correzione parallele, deve non riuscire una nuova richiesta di sessione di correzione se una sessione dello stesso tipo di correzione è già avviata e attiva. Se il supporto di più sessioni di correzione non è presente, l'onus si trova nel componente HLOS per garantire che più richieste GNSS provenienti dalle applicazioni di alto livello siano multiplexed e mappate in una singola richiesta di sessione di correzione al driver GNSS.

    Il driver GNSS non è necessario per supportare più sessioni di correzione parallele dello stesso tipo. Infatti, in Windows 10, l'adattatore HLOS GNSS non supporta l'uso della funzionalità del driver GNSS per avere più sessioni di correzione dello stesso tipo, pertanto le IHV non sono incoraggiate a investire su questa funzionalità per il momento. Nelle versioni future verrà considerato che l'adattatore GNSS inizierà direttamente le sessioni con il driver GNSS per ogni richiesta di correzione ottenuta dai livelli superiori della piattaforma di posizione, anziché eseguire il multiplexing della sessione stesso. Il supporto di multiplexing delle sessioni di correzione nell'adattatore GNSS semplifica l'implementazione del driver perché non richiede che gestisca più sessioni dello stesso tipo per un'applicazione o un'implementazione di multiplexing, riduce l'utilizzo della memoria nel driver e non richiede che l'adattatore GNSS gestisca il caso della scheda HLOS a partire da una serie di sessioni di correzione più grandi di quelle supportate dal driver GNSS. Diversi livelli di dispositivi e driver diversi supportano un numero diverso di sessioni di correzione simultanee, pertanto questo caso deve essere gestito, introducendo complessità nell'adattatore GNSS per gestire tutti i casi. Pertanto, in Windows 10 la scheda GNSS implementerà solo la singola sessione di correzione di ogni tipo supportato e ignorerà il supporto della sessione di correzione multipla dal driver fino a quando non è necessaria questa funzionalità.

    Ogni sessione di correzione è con stato e deve seguire questa sequenza ben definita:

    1. Avvio di una sessione di correzione

    2. Ottenere una o più correzioni

    3. Modificare la sessione di correzione se necessario

    Questa operazione è necessaria almeno fino a quando l'adattatore GNSS gestisce il multiplexing delle sessioni di correzione dello stesso tipo e potrebbe anche essere necessario in un secondo momento gestire il caso di sessioni di correzione simultanee attive rispetto al numero supportato dal driver GNSS.

    1. Arresto della sessione di correzione

    Le sessioni di correzione sono identificate in modo univoco da un ID sessione di correzione. Non è possibile recuperare informazioni posizionali da HLOS al di fuori del contesto di una sessione di correzione. Il driver GNSS deve consentire la modifica dei parametri di sessione al volo per facilitare l'operazione multiplexing dal componente HLOS, senza la necessità di riavviare la sessione di correzione.

    correzione della comunicazione del report tra un driver gnss e un'applicazione.

  • Tipo di correzione: Il driver GNSS deve supportare almeno la correzione singola di base. Inoltre, il driver deve supportare in modo nativo i tipi di correzione avanzati (ad esempio il rilevamento). Come indicato in precedenza, il supporto di tipi di correzione aggiuntivi implica che anche se il driver non supporta più sessioni di correzione dello stesso tipo, deve supportare simultaneamente almeno una sessione di correzione di un tipo di correzione supportato. Il componente HLOS non esegue più tipi di correzione diversi in un singolo tipo.

  • Interfaccia del dispositivo e PnP: Il driver GNSS deve annunciare un'interfaccia del dispositivo definita da Microsoft usando l'API WdfDeviceCreateDeviceInterface in modo che HLOS possa ricevere una notifica sull'arrivo e la partenza del driver GNSS. Ciò sarà necessario per gestire un driver GNSS in un'impostazione Plug and Play (PnP) e anche nei casi in cui si verifica un arresto anomalo del driver a livello di utente a causa dell'arresto anomalo del servizio a livello di utente se il driver è un driver UMDF 2.0. Il driver GNSS deve assicurarsi che l'interfaccia del dispositivo sia pubblicizzata solo quando l'hardware sottostante è in grado di supportare le chiamate IOCTL HLOS e non prima.

  • Criteri di alimentazione del dispositivo: Il driver GNSS deve gestire i criteri di alimentazione del dispositivo e deve gestire gli eventi di risparmio energia generati dal sistema operativo. Il driver deve registrarsi per il WDF_PNPPOWER_EVENT_CALLBACKS. Callback evtDeviceD0Entry (generato da WDF quando il sistema passa allo stato D0) e WDF_PNPPOWER_EVENT_CALLBACKS. Callback EvtDeviceD0Exit (generato da WDF quando il sistema viene chiuso dallo stato D0). Il driver GNSS deve essere configurabile per disabilitare facoltativamente la gestione energia.

    La gestione esatta dell'alimentazione che deve essere eseguita in un dispositivo GNSS nei diversi stati di alimentazione del sistema deve essere adattata in base alle funzionalità del dispositivo GNSS (supporta operazioni offload o meno), se sono attive operazioni effettive di offload e come viene eseguita la comunicazione tra il sistema e il dispositivo GNSS. In generale le aspettative sono le seguenti:

    • Il dispositivo GNSS funzionerà nella modalità di alimentazione più bassa possibile quando non sono presenti sessioni attive o operazioni disattivate, indipendentemente dallo stato di alimentazione del sistema.

    • In caso di scenari disattivati, anche in caso di stato di alimentazione del sistema, il dispositivo GNSS potrebbe dover verificare la posizione a intervalli diversi o ricevere notifiche e quindi il dispositivo GNSS potrebbe dover rimanere in stato D0 anche durante lo stato di standby connesso (questo è lo stato di sospensione dello schermo), ma ancora l'hardware deve ridurre il consumo di energia al minimo. Questo modello funziona per tali dispositivi usando DMA (Direct Memory Access) o una porta seriale in un UART per comunicare con l'host, ad esempio. Ma sarà una sfida per i dispositivi GNSS connessi tramite il bus USB, in cui probabilmente la funzione USB del dispositivo dovrebbe trovarsi nello stato di alimentazione del dispositivo D2 (sospeso) durante la standby connessa. In generale, i dispositivi GNSS connessi tramite USB devono essere in grado di immettere uno stato D2 (sospeso) a bassa potenza dopo che non hanno sessioni di correzione o operazioni disattivate in corso e l'interfaccia del bus USB entra nello stato di sospensione. Tutte le transizioni di alimentazione di sospensione e riattivazione devono essere segnalate sul bus USB. Se il dispositivo GNSS ha sessioni fisse attive o disattivate, il dispositivo deve essere in grado di usare in banda, il segnale USB riprende a riattivare il soC o il core silicon da standby connesso. Il soC o il core silicon deve essere in grado di riattivare dallo stato di alimentazione più basso in risposta alla banda in banda, la ripresa del segnale USB dal dispositivo GNSS.

    • I dispositivi che non supportano lo standby connesso avranno tutte le operazioni disattivate annullate al momento in cui il dispositivo passa alla modalità di standby o di ibernazione moderna. Sono inclusi i geofences offloaded, il rilevamento della distanza o le sessioni di rilevamento periodico.

    • I dispositivi che supportano lo standby connesso continueranno a avere tutte le operazioni disattivate attive quando il dispositivo passa allo standby connesso e il dispositivo GNSS dovrebbe continuare le operazioni di rilevamento in modo più efficiente possibile e si prevede di fornire notifiche al modulo HLOS nel caso in cui la condizione del trigger geofence o un aggiornamento della sessione di rilevamento sia pertinente. Se non sono presenti operazioni offload in un dispositivo che supporta lo standby connesso, il dispositivo GNSS dovrebbe passare allo stato di alimentazione più basso possibile, ma comunque essere in grado di ascoltare le richieste di sessione di posizione da HLOS. Nei dispositivi che supportano SUPL, è anche possibile che il dispositivo GNSS e lo stack SUPL vengano riattivati nelle notifiche di ni durante la connessione in standby.

    Informazioni generali sulla gestione delle energia per i driver sono disponibili in Responsabilità di Power Management per i driver.

  • Considerazioni sull'alimentazione: Lo stack di driver GNSS deve prendere in considerazione il footprint di alimentazione come obiettivo principale della progettazione e ridurre al minimo il più possibile il mantenimento del processore principale. Tutte le funzionalità avanzate supportano (ad esempio diversi tipi di correzione) devono essere eseguite in modo efficiente, ad esempio il processore di app principale non deve essere attivo più di quanto necessario e la maggior parte dell'elaborazione può essere disattivata nel processore di chipset/bassa potenza. Come regola generale, a meno che non sia diversamente indicato dal modulo HLOS, il driver GNSS deve sempre considerare il consumo di energia come vincolo più importante e deve essere progettato per eseguire le normali operazioni con impronta di alimentazione minima. L'interfaccia del driver GNSS è progettata in modo esplicito per consentire al dispositivo mobile di passare alla modalità a bassa potenza il più spesso possibile e fornire hint relativi all'alimentazione necessari per il driver GNSS per ottimizzare l'utilizzo di energia. Per il rilevamento, il geofencing e altre funzionalità che richiedono il monitoraggio di posizioni pervasive a esecuzione prolungata, il driver/motore GNSS deve sfruttare hardware/processori a bassa potenza. Se tale funzionalità deve essere implementata usando un meccanismo di polling di forza bruta nel driver o se deve essere implementato nel processore dell'app, il driver non deve dichiararsi come in grado di tali operazioni. Ciò consentirà al HLOS di limitare l'esposizione di tali funzionalità al resto della piattaforma o usare un'implementazione alternativa di tali funzionalità in base ad altri servizi o primitive della piattaforma.

  • Linguaggio di programmazione: L'interfaccia del driver GNSS viene recapitata come file di intestazione del linguaggio C che non usa primitive di linguaggio specifiche C++ (ad esempio, ereditarietà della struttura). Ciò consente all'IHV di scegliere tra C e C++. Il file di intestazione dell'interfaccia GNSS lascia aperta la scelta a IHV.

  • Driver di filtro: Lo stack di dispositivi GNSS non deve essere vincolato in modo da impedire l'aggiunta di un driver di filtro futuro nello stack per supportare funzionalità estese. Il driver GNSS fornito da IHV non deve includere il proprio driver di filtro nella parte superiore o nella parte inferiore dello stack di driver.

  • Notifiche ed eventi: Poiché un driver WDF non è in grado di inviare una notifica non richiesta al modulo HLOS, sarà sempre presente almeno un IRP in sospeso avviato da HLOS che serve allo scopo di ricevere una notifica non richiesta dal livello driver. Ciò include il caso in cui il sistema è in standby connesso. Per il driver GNSS, tali notifiche non richieste includono (ma non sono limitate a) richieste avviate dalla rete, dati di assistenza per il supporto di AGNSS, altre notifiche specifiche del fornitore. HLOS garantisce che una richiesta di I/O in sospeso sia sempre presente per gestire tali notifiche.

  • Estensione IHV in modalità utente: IHV può scrivere componente in modalità utente accessorio che interagisce con il driver GNSS su IHV-defined IOCTLs. Ciò è particolarmente necessario se il driver GNSS è in modalità kernel, in questo caso non ha accesso alle funzionalità esclusivamente disponibili in modalità utente (ad esempio, Wi-Fi analisi, Gestione connessioni API e così via). Si noti che con UMDF 2.0 in Windows 10, un driver GNSS UMDF non necessita di un componente in modalità utente separato, anche se l'IHV potrebbe comunque implementare un componente di modalità utente separato. Questi componenti in modalità utente vengono considerati come una semplice estensione al driver GNSS e verranno trattati come parte dell'eliminazione BSP fornita dall'IHV. I componenti HLOS forniti da Microsoft sono oblio ai dettagli di implementazione esatti di tali componenti e il meccanismo di interazione tra i componenti in modalità utente/kernel IHV. Se il driver GNSS viene scritto come driver UMDF 2.0 tramite estensioni IHV in modalità utente non è consigliato perché questo modello richiederà probabilmente un utilizzo maggiore della memoria.

    Le estensioni IHV in modalità utente devono rispettare le regole seguenti:

    • La semantica e il comportamento dei driver GNSS pubblici IOCTLs devono rimanere invariati e non interessati dall'estensione IHV in modalità utente e dalla relativa interazione con il driver GNSS.

    • L'estensione in modalità utente deve essere conforme alle nozioni di base e ai criteri di sicurezza, alimentazione e altre piattaforme imposte dalla piattaforma Windows 10.

    • L'estensione in modalità utente deve eseguire solo le attività autorizzate approvate da Microsoft, senza avere la piattaforma del sistema operativo applicare/convalidare tale autorizzazione in fase di esecuzione.

    Microsoft può comunque applicare criteri di sicurezza e controllare la durata di tali componenti. Il punto chiave è che i componenti in modalità utente IHV non devono contare sulla piattaforma per applicare criteri come il componente di estensione viene considerato come componente del sistema operativo attendibile.

    IHV non aggiungerà funzionalità arbitrarie o userà servizi del sistema operativo non autorizzati/risorse sicure.

Requisiti minimi di supporto

Ci saranno un'ampia gamma di dispositivi GNSS (Global Navigation Satellite System) che possono essere usati per le piattaforme Windows per soddisfare le esigenze di diversi livelli di dispositivi (costi bassi, high-end, diversi tipi di dispositivo e così via). Per abilitare tale ecosistema ricco e aumentare il numero di tablet, portatili e altri tipi di dispositivo che possono includere un chip GNSS a costi inferiori, Microsoft non richiede tutti i dispositivi GNSS per supportare il set completo di funzionalità descritte in riferimento al driver GNSS. La tabella seguente offre una visualizzazione generale delle funzionalità minime necessarie per diversi tipi di dispositivo e le funzionalità facoltative o consigliate.

Funzionalità Requisito per tutte le piattaforme Requisito specifico per i telefoni Note
Creazione di report accurati sui GNSS_DEVICE_CAPABILITIES Obbligatorio Requisito minimo di funzionalità
Supporto per MultipleFixSessions Facoltativo Non supportato dall'adapter GNSS
Supporto per MultipleAppSessions Consigliato
Supporto di assistenza GNSS (specifico IHV) Consigliato Obbligatorio
Recupero del supporto di assistenza GNSS tramite Microsoft (uso dei Agss_inject IOCTLs) Consigliato
Supporto per la struttura di GNSS_FixData completa Obbligatorio
Sessione singola di colpo Obbligatorio
Supporto nativo della sessione di rilevamento basato sul tempo Facoltativo Se supportato, deve includere il supporto per modificare i parametri della sessione.
Supporto nativo della sessione di rilevamento basato sulla distanza Facoltativo Se supportato, deve includere il supporto per modificare i parametri della sessione.
Ultima sessione nota Facoltativo
Supporto nativo di Geofencing Facoltativo Consigliato Solo geofences circolari necessarie e supportate
Fornitura di ChipsetInfo Obbligatorio Uso della GNSS_ChipsetInfo
Segnalazione di errori Consigliato Uso del GNSS_ErrorInfo
Report tramite NMEA Facoltativo
Supporto dei test di produzione (onda del vettore o auto test) Facoltativo
Posizione del piano di controllo con integrazione con MBB Obbligatorio solo se richiesto dall'operatore mobile Obbligatorio Normalmente richiesto dagli operatori mobili nei dispositivi con supporto vocale. Quasi sempre richiesto per i telefoni.
SUPL 1.0 Obbligatorio solo se richiesto dall'operatore mobile In generale sostituito da SUPL 2.0.

Include l'implementazione dei requisiti dell'operatore mobile completi, la configurazione tramite DDI, la segnalazione degli eventi ni al sistema operativo tramite DDI e l'integrazione con MBB.
SUPL 2.x Obbligatorio solo se richiesto dall'operatore mobile Obbligatorio Normalmente richiesto dagli operatori mobili nei dispositivi con supporto vocale. Quasi sempre richiesto per i telefoni.

Include l'implementazione dei requisiti dell'operatore mobile completi, la configurazione tramite DDI, la segnalazione degli eventi ni al sistema operativo tramite DDI e l'integrazione con MBB.
UPL Obbligatorio solo se richiesto dall'operatore mobile È necessario supportare solo i dispositivi CDMA in Cina, se richiesto dall'operatore mobile.

Include l'implementazione dei requisiti dell'operatore mobile completi, la configurazione tramite DDI, la segnalazione degli eventi ni al sistema operativo tramite DDI e l'integrazione con MBB.
comando driver GNSS_SetLocationServiceEnabled Obbligatorio
comando GNSS_SetLocationNIRequestAllowed driver Obbligatorio solo se SUPL supportato e richiesto dall'operatore mobile Nessun operatore mobile noto richiede più questo
comando GNSS_ForceSatelliteSystem driver Consigliato Buono a scopo di test. Alcuni operatori mobili o OEMS possono richiedere questo per il test.
comando GNSS_ForceOperationMode driver Obbligatorio solo se SUPL supportato Alcuni operatori mobili possono richiedere per scopi di test.
comando GNSS_ResetEngine driver Obbligatorio A scopo di test
comando GNSS_ClearAgnssData driver Obbligatorio A scopo di test
comando GNSS_SetNMEALogging driver Facoltativo Solo se richiesto dagli operatori mobili o dagli OEMS richiede questo scopo per i test
comando GNSS_SetSuplVersion driver Obbligatorio solo se SUPL supportato Obbligatorio per SUPL
comando GNSS_SetUplServerAccessInterval driver Obbligatorio solo se SUPL supportato e richiesto dall'operatore mobile Solo se richiesto dall'operatore mobile
comando GNSS_SetNiTimeoutInterval driver Obbligatorio solo se SUPL supportato e richiesto dall'operatore mobile Solo se richiesto dall'operatore mobile
comando GNSS_ResetGeofencesTracking driver Obbligatorio solo se il geofencing supportato
comando GNSS_CustomCommand driver Facoltativo