Configurations requises pour le pilote 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

• Framework de pilote : Le pilote GNSS doit être écrit en tant que pilote UMDF 2.0 basé sur cette définition d’interface, par opposition à un pilote WDM brut ou à un pilote KMDF. Les pilotes UMDF 1.0 ne sont pas pris en charge non plus. La définition de l'interface du pilote GNSS ou les composants Microsoft du système d'exploitation de haut niveau (HLOS) tels que l’adaptateur GNSS ne font pas de distinction entre un pilote GNSS WDF, KMDF 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é plus élevées pour implémenter des fonctionnalités qui nécessitent des fonctionnalités uniquement proposées en mode utilisateur. En règle générale, les IHD doivent préférer UMDF 2.0 à KMDF lorsque l’ancien framework est disponible sur la plateforme.

 UMDF 2.0 est disponible sur toutes les plateformes et les IHD sont fortement recommandés d’utiliser le pilote écrit en mode utilisateur.

• Sessions d’application multiples : Une session d’application est une session de positionnement provenant d’un composant HLOS qui interagit directement avec le pilote PSEC. Le pilote PSEC 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 l’application. Il s'agit d'une fonctionnalité optionnelle du pilote, indiquée spécifiquement par des informations bien définies sur les capacités du pilote GNSS. Pour prendre en charge ce comportement facultatif, le pilote GNSS doit suivre le 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 sur l’exposition du pilote au reste de la plateforme. Un pilote GNSS qui prend en charge cette fonctionnalité peut avoir besoin de partitionner logiquement et de gérer les informations d’état pour chaque session individuelle de l'application. Un pilote GNSS qui ne prend pas en charge cette fonctionnalité a uniquement besoin de maintenir un état global pour toutes les sessions d'application, au lieu d'une partition logique spécifique à une application. Dans ce dernier mode, le pilote PSEC est inconscient de la présence de plusieurs sessions d’application parallèles et traite toutes les requêtes de HLOS comme si elles proviennent de la même session d’application.

  

  La prise en charge du pilote GNSS pour plusieurs sessions d’application présente 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 PSEC sont ce que nous avons considéré comme des applications différentes qui peuvent demander simultanément à un seul pilote PSEC différentes sessions. Si plusieurs sessions d’application ne sont pas prises en charge, le pilote GNSS doit être testé soit via la plateforme de localisation du système d'exploitation, soit le service hébergeant cette plateforme doit être arrêté pour éviter d’interférer avec l’application de test.

• Session de localisation : L'obtention d'informations de positionnement à partir du pilote sous-jacent (acquisition instantanée ou suivi) est abstraite dans la notion d'une session de localisation. Les pilotes doivent prendre en charge au moins une session de correctif de chaque type de session prise 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 localisation unique.

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

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

  • Les pilotes qui prennent en charge les sessions de correctif de suivi basées sur la distance et sur le temps doivent également prendre en charge simultanément une session de correction ponctuelle, une session de correctif de suivi basée 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 fonctionnalité 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 multiples sessions de positionnement n’est pas présente, le composant HLOS doit s’assurer que plusieurs requêtes GNSS provenant des applications de haut niveau sont multiplexées et mappées en une seule demande de session de positionnement au pilote GNSS.

  Le pilote GNSS n'est pas nécessaire pour prendre en charge plusieurs sessions de localisation parallèles du même type. En fait, dans Windows 10, l’adaptateur HLOS SEE ne prend pas en charge l’utilisation de la fonctionnalité de pilote SEE pour avoir plusieurs sessions de correctif du même type, donc les IHD ne sont pas encouragés à investir sur cette fonctionnalité pour le moment. Dans les versions ultérieures, il sera considéré comme permettant à l’adaptateur SEE de démarrer directement des sessions avec le pilote SEE pour chaque demande de correctif obtenue à partir des couches supérieures de la plateforme d’emplacement, plutôt que de faire le multiplexage de session lui-même. La prise en charge du multiplexage des sessions de correction dans l’adaptateur SEE simplifie l’implémentation du pilote, car elle ne nécessite pas 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 n’exige pas que l’adaptateur RTC gère le cas du HLOS en démarrant un certain nombre de sessions de réparation supérieures à ce qui est pris en charge par le pilote RTC. Différents niveaux d’appareils et différents pilotes prennent en charge un nombre différent de sessions de réparation simultanées. Ce cas doit donc être géré, en introduisant une complexité dans l’adaptateur SEE pour gérer tous les cas. Par conséquent, dans Windows 10, l’adaptateur SEE implémente uniquement la session de correctif unique de chaque type pris en charge et ignore la prise en charge de plusieurs sessions de correction 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 réparation

  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 PSEC gère le multiplexage des sessions de correctif du même type et qu’il puisse même être nécessaire ultérieurement de gérer le cas de sessions de réparation plus simultanées actives que le nombre pris en charge par le pilote PSEC.

  1. Arrêt de la session de correction

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

  

• Type de correctif : Le pilote GNSS doit au minimum prendre en charge la correction de positionnement 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 des 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 correctifs en un seul type.

• Interface de l’appareil et PnP : Le pilote PSEC 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 PSEC. Cela sera nécessaire pour gérer un pilote GNSS dans un environnement Plug-and-Play (PnP), ainsi que dans les cas où le déchargement inattendu du pilote se produit en raison d’un crash du 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 IOCTL HLOS et non avant cela.

• Stratégie d’alimentation de l’appareil : Le pilote PSEC 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 éventuellement désactiver la gestion de l’alimentation.

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

  • L’appareil SEE fonctionne en 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 de l’alimentation du système.

  • Dans le cas de scénarios déchargés, encore une fois quel que soit l’état de l’alimentation du système, l’appareil SEE peut avoir besoin de vérifier la position à différents intervalles ou recevoir des notifications et, par conséquent, l’appareil SEE peut avoir besoin de rester dans l’état D0 même pendant la secours connectée (il s’agit de l’état de veille hors écran), mais le matériel doit toujours réduire la consommation d’alimentation au minimum. Ce modèle pourrait convenir pour des appareils utilisant le DMA (Accès en mémoire directe) ou un port série sur un UART afin de communiquer avec l'hôte, par exemple. Cependant, cela représentera un défi pour ces appareils GNSS connectés via un bus USB, auquel cas la fonction USB de l’appareil devrait probablement être dans l’état d’alimentation de l’appareil D2 (suspendre) pendant la veille connectée. En règle générale, les appareils GNSS connectés via USB doivent être en mesure d’entrer dans un état de basse consommation D2 (suspension) une fois qu'ils n'ont plus de sessions de fixation ou d'opérations déchargées en cours et que l’interface de bus USB entre dans l'état de suspension. Toutes les transitions d’alimentation de veille et de réveil doivent être signalées sur le bus USB. Si l’appareil GNSS a des sessions de correction actives ou des opérations déchargées, l’appareil doit être en mesure d’utiliser la signalisation en bande, la signalisation de reprise USB pour réveiller le SoC ou le silicium de cœur à partir de la veille connectée. Le SoC ou le silicium de noyau doit pouvoir être réveillé de son état de consommation le plus bas en réponse à un signal de reprise USB interne provenant de l'appareil GNSS.

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

  • Les appareils qui prennent en charge la veille connectée continueront d’avoir toutes les opérations déchargées actives lorsque l’appareil passe à la veille connectée. L’appareil GNSS est censé poursuivre les opérations de suivi aussi efficacement que possible. Il est également prévu de fournir des notifications au HLOS au cas où une condition de déclenchement de géorepérage ou une mise à jour de session de suivi serait pertinente. S’il n’y a pas d’opérations déchargées dans un appareil prenant en charge la veille connectée, l’appareil GNSS est censé atteindre l’état d’alimentation le plus bas possible, mais il doit encore être capable d'écouter les demandes de session de localisation du HLOS. Dans les appareils qui prennent en charge SUPL, il doit également être possible que l’appareil GNSS et la pile SUPL se réveillent à partir des notifications NI pendant le mode veille connecté.

  Vous trouverez des informations générales sur la gestion de l’alimentation pour les pilotes dans les 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 en tant qu’objectif de conception principal et minimiser que le processeur principal reste éveillé autant que possible. Le support de toutes les fonctionnalités avancées (comme différents types de correctifs) doit être réalisé de manière économe en énergie, afin que le processeur principal de l'application n'ait pas besoin de rester actif plus que nécessaire, et que la plupart des traitements puissent être déchargés sur le chipset/processeur à faible puissance. En règle générale, sauf indication contraire du HLOS, le pilote PSEC doit toujours traiter la consommation d’énergie comme la contrainte la plus importante et doit être conçu pour effectuer les opérations normales avec une empreinte d’alimentation minimale. L’interface du pilote RTC est explicitement conçue pour permettre à l’appareil mobile de passer au mode à faible alimentation le plus souvent possible, et de fournir des indicateurs de puissance nécessaires au pilote RTC pour optimiser l’utilisation de l’alimentation. Pour le suivi, le géorepérage et d’autres fonctionnalités qui nécessitent une surveillance de position omniprésente à long terme, le pilote/moteur GNSS doit tirer parti du matériel et des processeurs à faible consommation d'énergie. Si de telles fonctionnalités doivent être implémentées à l’aide d’un mécanisme d’interrogation par force brute dans le pilote ou s’il doit être implémenté dans le processeur d’application, le pilote ne doit pas se déclarer comme capable de telles opérations. Cela permettra au HLOS de restreindre l’exposition de ces fonctionnalités au reste de la plateforme ou d’utiliser une autre implémentation de ces fonctionnalités basées sur d’autres services/primitives de plateforme.

• Langage de programmation: L’interface du pilote PSEC est fournie en tant que 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 au IHV de choisir entre C et C++. Le fichier d’en-tête de l’interface GNSS laisse le choix ouvert aux IHV.

• Pilote de filtre : La pile d’appareils SEE 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 l'IHV ne doit pas inclure son propre pilote de filtre, ni en haut ni en bas de la pile des 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 telle notification non sollicitée de la couche pilote. Cela inclut le cas où le système est en veille connectée. Pour le pilote PSEC, ces notifications non sollicitées incluent (mais ne sont pas limitées à) les demandes initiées par le réseau, les données d’assistance pour le support APSEC, 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 IHVs peuvent rédiger un composant en mode utilisateur complémentaire qui interagit avec le pilote GNSS via des IOCTLs privés définis par l'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 exclusivement disponibles en mode utilisateur (par exemple, analyse Wi-Fi, API du gestionnaire de connexions, etc.). Notez que, avec UMDF 2.0 dans Windows 10, un pilote UMDF PSEC 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 considérés comme faisant partie de la version BSP fournie par l'IHV. Les composants HLOS fournis par Microsoft sont inconscients des détails d’implémentation exacts de ces composants et du mécanisme d’interaction entre les composants en mode utilisateur/noyau IHV. Il n'est pas recommandé d'écrire le pilote GNSS en tant que pilote UMDF 2.0 avec des extensions IHV en mode utilisateur, car ce modèle nécessite probablement davantage de mémoire.

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

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

  • L’extension en mode utilisateur doit se conformer à la sécurité, à l’alimentation et à d’autres bases et stratégies de plateforme imposées 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 en mode utilisateur IHV ne doivent pas compter sur la plateforme pour appliquer des stratégies telles que le composant d’extension est traité comme un composant de système d’exploitation approuvé.

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

Exigences minimales pour la prise en charge

Il y aura une grande variété de dispositifs GNSS (Global Navigation Satellite System) qui peuvent être utilisés sur les plateformes Windows pour répondre aux besoins de différents niveaux de dispositifs (faible coût, haut de gamme, différents types, etc.). Pour permettre un écosystème aussi riche et augmenter le nombre de tablettes, d’ordinateurs portables et d’autres types d’appareils qui peuvent inclure une puce SEE à moindre coût, Microsoft ne nécessite pas tous les appareils PSEC pour prendre en charge l’ensemble complet des fonctionnalités décrites dans la référence du pilote PSEC. Le tableau suivant fournit une vue générale des fonctionnalités minimales requises pour différents types d’appareils et les fonctionnalités facultatives ou recommandées.