Configuration requise pour les pilotes GNSS (Global Navigation Satellite System)

Décrit les exigences, les hypothèses et les contraintes à prendre en compte lors du développement d’un pilote GNSS (Global Navigation Satellite System) pour Windows 10.

Conditions générales

• Infrastructure de pilote : Le pilote GNSS doit être écrit en tant que pilote UMDF 2.0 sur la base de cette définition d’interface, par opposition à un pilote WDM brut ou à un pilote KMDF. Les pilotes UMDF 1.0 ne sont pas non plus pris en charge. La définition de l’interface du pilote GNSS ou les composants GNSS du système d’exploitation haut niveau (HLOS) Microsoft, tels que l’adaptateur GNSS, n’effectuent pas de distinction entre un pilote WDF, un pilote KMDF GNSS et un pilote UMDF 2.0, tant que le pilote fournit les fonctionnalités nécessaires pour cette conception d’interface. UMDF 2.0 offre une stabilité, une simplicité et une flexibilité supérieures pour implémenter des fonctionnalités qui nécessitent des fonctionnalités uniquement offertes en mode utilisateur. En règle générale, les IHVs doivent préférer UMDF 2.0 à KMDF lorsque l’ancienne infrastructure est disponible sur la plateforme.

 UMDF 2.0 est disponible sur toutes les plateformes et il est vivement recommandé d’utiliser le pilote écrit en mode utilisateur.

• Plusieurs sessions d’application : Une session d’application est une session de positionnement provenant d’un composant HLOS qui interagit directement avec le pilote GNSS. Le pilote GNSS peut choisir de prendre en charge en mode natif plusieurs sessions d’application en partitionnant ses variables d’état et ses fonctionnalités en fonction de chaque application. Il s’agit d’une fonctionnalité facultative du pilote qui est indiquée spécifiquement par des informations bien définies sur la capacité du pilote GNSS. Pour prendre en charge ce comportement facultatif, le pilote GNSS doit effectuer le suivi du handle de fichier que les applications HLOS obtiennent pendant CreateFile et associer toutes les opérations HLOS suivantes au handle de fichier spécifique à la session d’application. Cette prise en charge native du pilote GNSS permet aux composants HLOS d’être plus flexibles et moins restrictifs quant à l’exposition du pilote au reste de la plateforme. Un pilote GNSS qui prend en charge cette fonctionnalité peut avoir besoin de partitionner et de gérer logiquement les informations d’état pour chaque session d’application individuelle. Un pilote GNSS qui ne prend pas en charge cette fonctionnalité doit uniquement maintenir l’état global pour toutes les sessions d’application au lieu de la partition logique spécifique à l’application. Dans ce dernier mode, le pilote RÉINITIALISATION ignore la présence de plusieurs sessions d’application parallèles et traite toutes les requêtes de HLOS comme si elles provenaient de la même session d’application.

  

  La prise en charge dans le pilote GNSS pour plusieurs sessions d’application a l’avantage de permettre à une application de test dans le HLOS d’interagir directement avec le pilote GNSS en même temps que l’adaptateur GNSS. L’application de test et l’adaptateur GNSS sont ce que nous avons considéré comme différentes applications qui peuvent demander à un seul pilote GNSS différentes sessions simultanément. Si plusieurs sessions d’application ne sont pas prises en charge, le pilote GNSS doit être testé par le biais de la plateforme de localisation du système d’exploitation, sinon, le service hébergeant la plateforme de localisation du système d’exploitation doit être arrêté pour éviter d’interférer avec l’application de test.

• Correction de la session : Le fait d’obtenir des informations de positionnement à partir du pilote sous-jacent (tir unique ou suivi) est abstrait dans une notion de session de correction. Les pilotes doivent prendre en charge au moins une session de correctif de chaque type de session pris en charge. Les types de session sont définis sous l’énumération GNSS_FIXSESSIONTYPE .

  • Au minimum, les pilotes GNSS doivent prendre en charge une session de correction d’un seul coup.

  • Les pilotes qui prennent en charge les sessions de correction basées sur le suivi à distance doivent prendre en charge simultanément une session de correction unique et une session de correction de suivi basée sur la distance.

  • Les pilotes qui prennent en charge les sessions de correctifs de suivi basé sur le temps doivent prendre en charge simultanément une session de correctif à coup unique et une session de correctif de suivi basée sur le temps.

  • Les pilotes qui prennent en charge les sessions de correction de suivi basées sur la distance et les sessions de correctif de suivi basée sur le temps doivent prendre en charge simultanément une session de correctif de suivi unique, une session de correctif de suivi basé sur la distance et une session de correctif de suivi basée sur le temps.

  

  Si le pilote prend en charge plusieurs sessions de correction simultanées ou non est exprimé par un paramètre de capacité de pilote bien défini. Si un pilote ne prend pas explicitement en charge plusieurs sessions de correctif parallèle, il doit échouer une nouvelle demande de session de correctif si une session du même type de correctif est déjà démarrée et active. Si la prise en charge de plusieurs sessions de correctif n’est pas présente, il incombe au composant HLOS de s’assurer que plusieurs demandes GNSS provenant des applications de haut niveau sont multiplexées et mappées dans une seule demande de session de correction au pilote GNSS.

  Le pilote GNSS n’est pas nécessaire pour prendre en charge plusieurs sessions de correctif parallèle du même type. En fait, dans Windows 10, l’adaptateur GNSS HLOS ne prend pas en charge l’utilisation de la fonctionnalité de pilote GNSS pour avoir plusieurs sessions de correctif du même type. Par conséquent, les IHVs ne sont pas encouragés à investir sur cette fonctionnalité pour le moment. Dans les versions ultérieures, il sera envisagé d’autoriser l’adaptateur GNSS à démarrer directement des sessions avec le pilote GNSS pour chaque demande de correctif obtenue à partir des couches supérieures de la plateforme d’emplacement, plutôt que d’effectuer le multiplexage de session lui-même. La prise en charge du multiplexage des sessions de correctif dans l’adaptateur RTC simplifie l’implémentation du pilote, car elle n’a pas besoin de gérer plusieurs sessions du même type pour une application ou une implémentation de multiplexage, elle réduit l’utilisation de la mémoire dans le pilote et elle ne nécessite pas que l’adaptateur RTC gère le cas du HLOS en commençant un nombre de sessions de correctif plus grand que ce qui est pris en charge par le pilote RTC. Différents niveaux d’appareils et différents pilotes prendraient en charge un nombre différent de sessions de correction simultanées. Par conséquent, ce cas devrait être géré, ce qui introduit une complexité dans l’adaptateur SYNC pour gérer tous les cas. Par conséquent, dans Windows 10 l’adaptateur GNSS implémente uniquement la session de correctif unique de chaque type pris en charge et ignore la prise en charge de plusieurs sessions de correctif par le pilote jusqu’à ce que nous ayons besoin de cette fonctionnalité.

  Chaque session de correctif est avec état et doit suivre cette séquence bien définie :

  1. Démarrage d’une session de correctif

  2. Obtention d’un ou de plusieurs correctifs

  3. Modifier la session de correctif si nécessaire

  Cela est nécessaire au moins jusqu’à ce que l’adaptateur AUTHENTIFICATION gère le multiplexage des sessions de correctif du même type et peut même être nécessaire ultérieurement pour gérer le cas de sessions de correction simultanées plus actives que le nombre pris en charge par le pilote GNSS.

  1. Arrêt de la session de correctif

  Les sessions de correction sont identifiées de manière unique par un ID de session de correction. Aucune information de position ne peut être récupérée par le HLOS en dehors du contexte d’une session de correction. Le pilote GNSS doit autoriser la modification des paramètres de session à la volée pour faciliter l’opération de multiplexage par le composant HLOS, sans qu’il soit nécessaire de redémarrer la session de correction.

  

• Type de correctif : Le pilote GNSS doit au minimum prendre en charge le correctif simple de base. En outre, le pilote doit prendre en charge en mode natif les types de correctifs avancés (tels que le suivi). Comme indiqué précédemment, la prise en charge de types de correctifs supplémentaires implique que même si le pilote ne prend pas en charge plusieurs sessions de correctif du même type, il doit prendre en charge simultanément au moins une session de correctif d’un type de correctif pris en charge. Le composant HLOS ne multiplexe pas différents types de correction en un seul type.

• Interface de l’appareil et PnP : Le pilote SYNC doit publier une interface d’appareil définie par Microsoft à l’aide de l’API WdfDeviceCreateDeviceInterface afin que le HLOS puisse être informé de l’arrivée et du départ du pilote SYNC. Cela sera nécessaire pour gérer un pilote GNSS dans un paramètre Plug-and-Play (PnP) et également dans les cas où un déchargement inattendu du pilote se produit en raison d’un incident de service au niveau de l’utilisateur si le pilote est un pilote UMDF 2.0. Le pilote RTC doit s’assurer que l’interface de l’appareil est annoncée uniquement lorsque le matériel sous-jacent est capable de prendre en charge les appels HLOS IOCTL et pas avant cela.

• Stratégie d’alimentation de l’appareil : Le pilote GNSS doit gérer la stratégie d’alimentation de son appareil et gérer les événements de gestion de l’alimentation déclenchés par le système d’exploitation. Le pilote doit s’inscrire au WDF_PNPPOWER_EVENT_CALLBACKS. Rappel EvtDeviceD0Entry (déclenché par WDF lorsque le système passe à l’état D0) et WDF_PNPPOWER_EVENT_CALLBACKS. Rappel EvtDeviceD0Exit (déclenché par WDF lorsque le système quitte l’état D0). Le pilote GNSS doit être configurable pour désactiver éventuellement la gestion de l’alimentation.

  La gestion de l’alimentation exacte qui doit être effectuée dans un appareil GNSS dans les différents états d’alimentation du système doit être adaptée en fonction des capacités de l’appareil GNSS (prend-elle en charge les opérations déchargées ou non), si les opérations déchargées sont actives et comment la communication entre le système et l’appareil GNSS est effectuée. En général, les attentes sont les suivantes :

  • L’appareil GNSS fonctionne dans le mode d’alimentation le plus bas possible lorsqu’il n’y a pas de sessions actives ou d’opérations déchargées, quel que soit l’état d’alimentation du système.

  • En cas de scénarios de déchargement, encore une fois quel que soit l’état d’alimentation du système, l’appareil RTC peut devoir case activée pour la position à différents intervalles ou recevoir des notifications. Par conséquent, l’appareil RTC peut avoir besoin de rester à l’état D0 même pendant la veille connectée (il s’agit de l’état de mise en veille de l’écran), mais le matériel doit toujours réduire la consommation d’énergie au minimum. Ce modèle fonctionne pour les appareils qui utilisent DMA (Direct Memory Access) ou un port série sur un UART pour communiquer avec l’hôte, par exemple. Mais sera un défi pour les appareils AUTHENTIFICATION connectés via un bus USB, auquel cas la fonction USB de l’appareil doit être dans l’état d’alimentation D2 (suspendre) pendant la veille connectée. En général, les appareils SYNC connectés via USB doivent être en mesure d’entrer un état D2 faible consommation (interruption) après qu’ils n’ont pas de sessions de correction ou d’opérations déchargées en cours et que l’interface du bus USB passe à l’état de suspension. Toutes les transitions d’alimentation de veille et de veille doivent être signalées via le bus USB. Si l’appareil GNSS a des sessions de correction actives ou déchargées, l’appareil doit être en mesure d’utiliser la signalisation de reprise usb en bande pour sortir le SoC ou le silicium de cœur de la veille connectée. Le SoC ou le silicium de cœur doit être en mesure de se réveiller à partir de son état d’alimentation le plus bas en réponse à la signalisation de reprise USB en bande à partir de l’appareil GNSS.

  • Les appareils qui ne prennent pas en charge la veille connectée auront toutes les opérations déchargées annulées au moment où l’appareil passe à la veille ou à la mise en veille prolongée moderne. Cela inclut les limites géographiques déchargées, le suivi à distance ou les sessions de suivi périodiques.

  • Les appareils qui prennent en charge la secours connectée continuent d’avoir toutes les opérations déchargées actives lorsque l’appareil passe en mode de secours connecté, et l’appareil SYNC est censé poursuivre les opérations de suivi aussi efficacement que possible, et il est censé fournir des notifications au HLOS au cas où la condition du déclencheur de limite géographique ou une mise à jour de session de suivi est pertinente. S’il n’y a pas d’opérations déchargées dans un appareil qui prend en charge la secours connectée, l’appareil GNSS est censé atteindre l’état d’alimentation le plus bas possible, mais il est toujours en mesure d’écouter les demandes de session d’emplacement à partir du HLOS. Dans les appareils qui prennent en charge SUPL, il doit également être possible pour l’appareil SYNC et la pile SUPL de se réveiller sur les notifications NI pendant la veille connectée.

  Vous trouverez des informations générales sur la gestion de l’alimentation pour les pilotes dans Responsabilités de gestion de l’alimentation pour les pilotes.

• Prise en compte de l’alimentation : La pile de pilotes GNSS doit prendre en compte l’empreinte énergétique comme objectif de conception principal et réduire autant que possible le main processeur éveillé. Toutes les fonctionnalités avancées prises en charge (par exemple, les différents types de correctifs) doivent être exécutées de manière efficace en termes d’alimentation, de sorte que le processeur d’application main n’a pas besoin d’être actif plus que nécessaire et que la plupart des traitements peuvent être déchargés sur le chipset/processeur de faible consommation. En règle générale, sauf indication contraire du SGH, le pilote RTC doit toujours considérer la consommation d’énergie comme la contrainte la plus importante et doit être conçu pour effectuer les opérations normales avec un encombrement minimal. L’interface du pilote RTC est explicitement conçue pour permettre à l’appareil mobile de passer au mode basse consommation aussi souvent que possible, et pour fournir les indicateurs d’alimentation nécessaires au pilote RTC afin d’optimiser la consommation d’énergie. Pour le suivi, la géorefencing et d’autres fonctionnalités qui nécessitent une surveillance de position omniprésente de longue durée, le pilote/moteur GNSS doit tirer parti du matériel/processeurs à faible consommation. Si cette fonctionnalité doit être implémentée à l’aide d’un mécanisme d’interrogation en force brute dans le pilote ou si elle doit être implémentée dans le processeur d’application, le pilote ne doit pas se déclarer capable de telles opérations. Cela permettra au HLOS de limiter l’exposition de ces fonctionnalités au reste de la plateforme ou d’utiliser une implémentation alternative de ces fonctionnalités basée sur d’autres services de plateforme/primitives.

• Langage de programmation : L’interface du pilote GNSS est fournie sous la forme d’un fichier d’en-tête de langage C qui n’utilise aucune primitive de langage spécifique À C++ (par exemple, héritage de structure). Cela permet à l’IHV de choisir entre C et C++. Le fichier d’en-tête d’interface GNSS laisse le choix aux IHVs.

• Pilote de filtre : La pile d’appareils GNSS ne doit pas être contrainte de telle sorte qu’elle empêche l’ajout d’un pilote de filtre futur dans la pile pour prendre en charge les fonctionnalités étendues. Le pilote GNSS fourni par IHV ne doit pas inclure son propre pilote de filtre en haut ou en bas de la pile de pilotes.

• Notifications et événements : Étant donné qu’un pilote WDF n’est pas en mesure d’envoyer une notification non sollicitée au HLOS, il y aura toujours au moins un IRP en attente lancé par le HLOS qui sert à recevoir une notification non sollicitée de la part de la couche pilote. Cela inclut le cas où le système est en mode de secours connecté. Pour le pilote MESSAGE, ces notifications non sollicitées incluent (mais ne sont pas limitées à) les demandes lancées par le réseau, les données d’assistance pour la prise en charge d’AMESSAGE et d’autres notifications spécifiques au fournisseur. Le HLOS garantit qu’une demande d’E/S en attente est toujours présente pour gérer ces notifications.

• Extension IHV en mode utilisateur : Les IVS peuvent écrire un composant accessoire en mode utilisateur qui interagit avec le pilote GNSS via des IOCTL privés définis par IHV. Cela est particulièrement nécessaire si le pilote GNSS est en mode noyau, auquel cas il n’a pas accès aux fonctionnalités disponibles exclusivement en mode utilisateur (par exemple, analyse Wi-Fi, API Gestionnaire des connexions, etc.). Notez qu’avec UMDF 2.0 dans Windows 10, un pilote GNSS UMDF n’a pas besoin d’un composant en mode utilisateur distinct, bien que l’IHV puisse toujours implémenter un composant en mode utilisateur distinct. Ces composants en mode utilisateur sont traités comme une simple extension du pilote GNSS et seront traités dans le cadre de la suppression du BSP fourni par IHV. Les composants HLOS fournis par Microsoft ignorent les détails d’implémentation exacts de ces composants et le mécanisme d’interaction entre les composants IHV en mode utilisateur/en mode noyau. Si le pilote RTC est écrit en tant que pilote UMDF 2.0 à l’aide d’extensions IHV en mode utilisateur n’est pas recommandé, car ce modèle nécessitera probablement davantage d’utilisation de la mémoire.

  Les extensions IHV en mode utilisateur doivent respecter les règles suivantes :

  • La sémantique et le comportement des IOCTL des pilotes NETWORK publics doivent rester inchangés et non entravés par l’extension IHV en mode utilisateur et son interaction avec le pilote NETWORK.

  • L’extension en mode utilisateur doit être conforme à la sécurité, à l’alimentation et aux autres principes de base et stratégies de plateforme imposés par la plateforme Windows 10.

  • L’extension en mode utilisateur doit effectuer uniquement les activités autorisées approuvées par Microsoft, sans que la plateforme du système d’exploitation applique/valide cette autorisation au moment de l’exécution.

  Microsoft peut toujours appliquer des stratégies de sécurité et contrôler la durée de vie de ces composants. Le point clé ici est que les composants IHV en mode utilisateur ne doivent pas compter sur la plateforme pour appliquer ces stratégies, car le composant d’extension est traité comme un composant de système d’exploitation approuvé.

  Les IVS n’ajoutent pas de fonctionnalités arbitraires ou n’utilisent pas de services de système d’exploitation/ressources sécurisées non autorisés.

Conditions minimales de support

Il y aura une grande variété d’appareils du système global de navigation par satellite (SYNC) qui peuvent être utilisés pour les plateformes Windows afin de répondre aux besoins de divers niveaux d’appareils (faible coût, haut de gamme, différents types d’appareils, etc.). Pour permettre un écosystème aussi riche et augmenter le nombre de tablettes, d’ordinateurs portables et d’autres types d’appareils pouvant inclure une puce SYNC à moindre coût, Microsoft n’a pas besoin de tous les appareils TRUI pour prendre en charge l’ensemble complet des fonctionnalités décrites dans la référence du pilote SYNC. Le tableau suivant fournit une vue d’ensemble des fonctionnalités minimales requises pour différents types d’appareils et des fonctionnalités facultatives ou recommandées.

Fonctionnalités	Conditions requises pour toutes les plateformes	Exigences spécifiques pour les téléphones	Notes
Signaler avec précision le GNSS_DEVICE_CAPABILITIES	Obligatoire		Exigences minimales en matière de fonctionnalités
Prise en charge de MultipleFixSessions	Facultatif		Non pris en charge par l’adaptateur BOUTA
Prise en charge de MultipleAppSessions	Recommandé
Prise en charge de l’assistance PCI (spécifique à IHV)	Recommandé	Obligatoire
Obtention de la prise en charge de l’assistance PORO via Microsoft (utilisation des Agss_inject IOCTL)	Recommandé
Prise en charge de la structure GNSS_FixData complète	Obligatoire
Session mono-plan	Obligatoire
Prise en charge native des sessions de suivi basées sur le temps	Facultatif		S’il est pris en charge, il doit inclure la prise en charge pour modifier les paramètres de session.
Prise en charge native des sessions de suivi basées sur la distance	Facultatif		S’il est pris en charge, il doit inclure la prise en charge pour modifier les paramètres de session.
Dernière session connue	Facultatif
Prise en charge native du géofencing	Facultatif	Recommandé	Seules les limites géographiques circulaires requises et prises en charge
Fourniture de ChipsetInfo	Obligatoire		Utilisation du GNSS_ChipsetInfo
Rapports d’erreurs	Recommandé		Utilisation de la GNSS_ErrorInfo
Rapports via NMEA	Facultatif
Prise en charge des tests de fabrication (onde porteuse ou auto-test)	Facultatif
Emplacement du plan de contrôle avec intégration à MBB	Obligatoire uniquement si l’opérateur mobile l’exige	Obligatoire	Normalement requis par les opérateurs mobiles sur les appareils avec prise en charge vocale. Presque toujours requis pour les téléphones.
SUPL 1.0	Obligatoire uniquement si l’opérateur mobile l’exige		En général remplacé par SUPL 2.0. Inclut l’implémentation du client complet répondant aux exigences de l’opérateur mobile, la configuration via la DDI, la création de rapports d’événements NI au système d’exploitation via la DDI et l’intégration à MBB.
SUPL 2.x	Obligatoire uniquement si l’opérateur mobile l’exige	Obligatoire	Normalement requis par les opérateurs mobiles sur les appareils avec prise en charge vocale. Presque toujours requis pour les téléphones. Inclut l’implémentation du client complet répondant aux exigences de l’opérateur mobile, la configuration via la DDI, la création de rapports d’événements NI au système d’exploitation via la DDI et l’intégration à MBB.
UPL	Obligatoire uniquement si l’opérateur mobile l’exige		Seuls doivent être pris en charge pour les appareils CDMA expédiés en Chine, si requis par l’opérateur mobile. Inclut l’implémentation du client complet répondant aux exigences de l’opérateur mobile, la configuration via la DDI, la création de rapports d’événements NI au système d’exploitation via la DDI et l’intégration à MBB.
GNSS_SetLocationServiceEnabled commande du pilote	Obligatoire
GNSS_SetLocationNIRequestAllowed commande du pilote	Obligatoire uniquement si SUPL est pris en charge et requis par l’opérateur mobile		Plus aucun opérateur mobile connu n’en a besoin
GNSS_ForceSatelliteSystem commande du pilote	Recommandé		Convient à des fins de test. Certains opérateurs mobiles ou oem peuvent en avoir besoin pour les tests.
GNSS_ForceOperationMode commande du pilote	Obligatoire uniquement si SUPL est pris en charge		Certains opérateurs mobiles peuvent avoir besoin à des fins de test.
GNSS_ResetEngine commande du pilote	Obligatoire		À des fins de test
GNSS_ClearAgnssData commande du pilote	Obligatoire		À des fins de test
GNSS_SetNMEALogging commande du pilote	Facultatif		Uniquement si les opérateurs mobiles ou les oem en ont besoin à des fins de test
GNSS_SetSuplVersion commande du pilote	Obligatoire uniquement si SUPL est pris en charge		Obligatoire pour SUPL
GNSS_SetUplServerAccessInterval commande du pilote	Obligatoire uniquement si SUPL est pris en charge et requis par l’opérateur mobile		Uniquement si l’opérateur mobile l’exige
GNSS_SetNiTimeoutInterval commande du pilote	Obligatoire uniquement si SUPL est pris en charge et requis par l’opérateur mobile		Uniquement si l’opérateur mobile l’exige
GNSS_ResetGeofencesTracking commande du pilote	Obligatoire uniquement si le géofencing est pris en charge
GNSS_CustomCommand commande du pilote	Facultatif