Architecture du pilote GNSS (Système mondial de navigation par satellite)

Fournit une vue d’ensemble de l’architecture du pilote UMDF 2.0, des considérations relatives aux E/S et traite de plusieurs types de sessions de repérage et de fixation.

Vue d’ensemble de l’architecture

Le diagramme de blocs de composants de haut niveau suivant montre comment le pilote UMDF UMDF 2.0 (Global Navigation Satellite System) s’intègre à la plateforme Windows 10.

Les composants du diagramme sont décrits ici :

• Application LBS : Application utilisateur qui utilise la fonctionnalité d’emplacement de la plateforme Windows 10

• Application de test : Une application permettant de tester la fonctionnalité GNSS.

• API GNSS : L’interface COM (Component Object Model) IGnssAdapter qui expose les fonctionnalités de l’appareil GNSS aux composants internes du service de localisation, ainsi qu’aux applications de test. La forme exacte de cette API est en dehors de l’étendue de ce document. Les composants Windows utilisent le dispositif GNSS en programmant avec l’interface COM IGnssAdapter. L'ensemble d'API GNSS est une API privée destinée uniquement aux composants de la plateforme de localisation (par exemple, le service de localisation et les applications de test de localisation) et n'est pas disponible pour d'autres applications de première partie ou de tierce partie.

• Adaptateur GNSS : Il s’agit d’un objet COM singleton qui implémente l’interface COM IGnssAdapter. Testez les applications et les composants internes du service de localisation qui instancient cet objet et utilisent l’appareil GNSS via l’interface IGnssAdapter. Le composant du moteur de positionnement GNSS du service de localisation implémente la classe COM qui expose l’interface IGnssAdapter. Le service de localisation expose un mécanisme de création permettant à des applications de test et à d'autres applications hors processus d'instancier un objet COM singleton de la classe COM de l'adaptateur GNSS au sein du service de localisation. Les applications hors processus utilisent le pointeur d'interface COM pour interagir avec le pilote GNSS.

  COM gère le proxy du pointeur d’interface vers les applications hors processus afin que les applications traitent le pointeur d’interface IGnssAdapter comme un objet COM in-process, mais les appels sont réellement gérés par l’objet adaptateur singleton GNSS dans le service de localisation.

  Le moteur de positionnement GNSS utilise l’objet d’adaptateur GNSS interne pour fournir des fonctionnalités spécifiques à la localisation au service de localisation. L’adaptateur GNSS ouvre un handle de fichier au pilote GNSS à l’aide de l’API CreateFile, puis encapsule les appels d’API natives GNSS dans les appels DeviceIoControl appropriés, maintient la machine à états avec l’objet du pilote GNSS, et conserve l’état des différentes requêtes entrantes provenant des couches supérieures. Ce composant interagit directement avec la pile d’appareils SEE sous-jacente par le biais de l’interface IOCTL publique SEE définie dans ce document. L’appareil GNSS est traité logiquement comme une ressource exclusive et, par conséquent, l’adaptateur singleton GNSS contrôle tous les accès à l’appareil GNSS.

  Certaines applications de test de pilotes à boîte blanche peuvent également utiliser l’interface IOCTL du pilote SEE directement dans un environnement de non-production au lieu d’utiliser l’adaptateur SEE via les API privées SEE. Toutefois, ces applications de test devront implémenter leur propre machine d'état et des processus pour imiter certaines fonctionnalités de l'adaptateur GNSS.

• Pilote GNSS : Un pilote livré par IHV implémenté à l’aide de UMDF 2.0. Le pilote GNSS prend en charge les API GNSS DeviceIoControl en s'interfaçant avec le matériel GNSS réel. Le pilote GNSS fonctionne également en tant que médiateur/intégrateur pour les fonctions SUPL.

• Appareil/moteur GNSS : Il s’agit d’un composant conceptuel qui encapsule les composants SoC et matériels de l’appareil GNSS. Un IHV peut choisir d’implémenter la plupart des fonctionnalités PSEC au sein de ce composant, ce qui rend la couche de pilote PSEC très mince (essentiellement un adaptateur pour l’interfacing avec l’appareil PSEC).

Prise en charge des périphériques et pilotes GNSS (Global Navigation Satellite System) qui suivent le modèle Windows hérité.

La plateforme de localisation dans Windows 10 prend en charge les dispositifs GNSS intégrés via le pilote de classe Sensors v1.0 hérité (voir Rédaction d’un pilote de capteur de localisation) ou intégrés via le nouveau DDI GNSS décrit dans la référence du pilote GNSS.

Par conséquent, les appareils Windows avec un appareil SEE qui s’intègrent au modèle d’extension de classe Sensor v1.0 qui existait dans Windows 7, Windows 8 et Windows 8.1 sont censés continuer à fonctionner dans Windows 10 sans avoir besoin de modifications. Il est fortement recommandé pour ces pilotes (et tous les nouveaux pilotes) d’être publiés sur Windows Update afin d’améliorer le processus de mise à niveau pour nos utilisateurs.

Il y aura également deux ensembles de tests différents pour les appareils SEE dans le Kit de laboratoire matériel (HLK) émis avec Windows 10 :

• Un nouvel ensemble de tests pour certifier les pilotes suivant le nouveau modèle.

• Un autre ensemble de tests pour certifier les pilotes suivant l’ancien modèle. Il s’agit du même ensemble de tests qui ont été disponibles dans le WHCK dans Windows 8.1.

Un nouveau composant de collecte dans le HLK identifie lequel des deux ensembles de tests doit être exécuté dans un système, le cas échéant.

Coexistence des appareils du Système mondial de navigation par satellite (GNSS)

Dans le cas rare de plusieurs appareils SEE détectés dans un système, la plateforme d’emplacement n’utilisera qu’un seul appareil, principalement pour réduire la consommation d’énergie globale dans le système. Les hypothèses suivantes ont été prises en compte :

• Les appareils utilisant la nouvelle DDI sont susceptibles d’être plus récents, et donc plus susceptibles d’avoir une meilleure consommation d’énergie, de prendre en charge plus de constellations et de prendre en charge une meilleure assistance. Par conséquent, si un appareil utilisant l’ancien modèle de pilote et un appareil utilisant le nouveau modèle de pilote sont détectés, ce dernier est celui sélectionné.

• Si un utilisateur branche un appareil GNSS externe alors qu’un appareil GNSS interne est présent, il est très probable que l’utilisateur souhaite que cet appareil externe soit utilisé.

Le comportement de la plateforme d’emplacement, en fonction de ces hypothèses, sera le suivant :

• Cas de deux drivers hérités coexistants : pour éviter les problèmes de rétrocompatibilité, le comportement sera le même que dans Windows 8.1, dans lequel les deux appareils sont utilisés simultanément et l'une des réponses est communiquée dans la pile vers les applications.

• Cas d’un pilote hérité dans l’appareil et d’un nouveau pilote branché en externe : le périphérique GNSS connecté à l’extérieur est utilisé.

• Cas d’un nouveau pilote dans l’appareil et d’un nouveau pilote enfiché en externe : le périphérique GNSS branché à l’extérieur est utilisé.

Si l'appareil GNSS sélectionné prend en charge le géorepérage ou d'autres opérations déchargées, le déchargement sera effectué pendant l'utilisation de cet appareil. L'adaptateur GNSS ne fractionne pas les fonctionnalités ou les sessions entre plusieurs appareils GNSS.

Vue d’ensemble de l’interface du système de navigation par satellite global (GNSS)

L'interaction entre l'adaptateur GNSS et le pilote GNSS relève des catégories suivantes :

Échange d’informations sur les capacités

Pour prendre en charge l’extensibilité et l’adaptabilité de la pile JDBC sur les plateformes Windows, l’adaptateur JDBC et le pilote PSEC établissent une compréhension commune des différentes fonctionnalités bien définies de la pile JDBC sous-jacente, ainsi que la prise en charge fournie par la plateforme Windows. Les aspects des capacités sont bien définis par Microsoft dans le cadre de cette définition d’interface SEE et évolueront à mesure que plus d’innovation dans l’espace SEE continue et un ensemble diversifié de circuits/pilotes émergent sur le marché. L’adaptateur GNSS interroge les différentes fonctionnalités du pilote/périphérique GNSS sous-jacent au moment de l’initialisation ou en fonction des besoins et optimise en conséquence l’interaction avec le pilote GNSS.

L’échange d’informations de capacité entre l’adaptateur GNSS et le pilote GNSS s’effectue à l’aide des codes de contrôle IOCTL_GNSS_SEND_PLATFORM_CAPABILITY et IOCTL_GNSS_GET_DEVICE_CAPABILITY.

Commande et configuration du pilote GNSS (Système Mondial de Navigation par Satellite)

L’adaptateur GNSS peut effectuer une configuration ponctuelle ou une reconfiguration périodique du pilote GNSS. De même, l'adaptateur GNSS peut exécuter certaines commandes spécifiques au GNSS via le pilote. Pour ce faire, définissez un protocole d’exécution de commande entre le pilote et le système d’exploitation de haut niveau (HLOS). Selon le type de commande spécifique, l’action prévue peut prendre effet immédiatement ou après un redémarrage du système. À l’instar des informations sur les capacités des appareils GNSS, les commandes GNSS sont également bien définies par Microsoft dans le cadre de cette définition d’interface GNSS et continueront d’évoluer avec les innovations futures et la diversification des périphériques/pilotes.

L’exécution et la configuration des commandes d’appareil sont effectuées à l’aide du code de contrôle IOCTL_GNSS_SEND_DRIVERCOMMAND.

Informations de position

Il s’agit de la fonction principale de l’appareil GNSS sous-jacent. Dans le formulaire le plus simple, l’adaptateur SEE demande la position actuelle de l’appareil à partir du pilote SEE. Les variantes de la demande de position incluent (mais ne sont pas limitées à) les types de session de position suivants :

• Position actuelle de l'appareil (détermination ponctuelle)

• Flux périodique continu de correctifs (suivi basé sur le temps)

• Flux continu de correctifs en fonction du seuil de déplacement (suivi basé sur la distance)

Le seul type de session de position obligatoire requis par chaque matériel GNSS et le pilote GNSS est le type de session de réparation instantanée. Native (implémentée dans le SoC, dans l'appareil GNSS, et non dans le pilote GNSS ou dans un service s'exécutant dans le processeur d'application), les sessions de suivi basées sur le temps et celles basées sur la distance peuvent être prises en charge de manière optionnelle. L’avantage principal pour ces deux types de sessions de suivi natives est d’économiser de l’énergie en conservant le processeur d’applications (AP) dormant pendant plus de temps en effectuant davantage de traitement dans le SOC et en signalant uniquement les modifications si nécessaire. La prise en charge du suivi basé sur la distance native est plus impactante que les sessions de suivi basées sur le temps natif, car il peut entraîner des économies d’énergie plus importantes et est plus couramment utilisée dans les applications.

La récupération des informations de position à partir du pilote GNSS a lieu via une session de fixation d'état unique, constituée des actions suivantes :

1. Démarrer la session de démarrage : L’adaptateur GNSS lance une session de démarrage de la position (à la suite d’une demande d’une application LBS). L’adaptateur PSEC définit les exigences et préférences spécifiques associées à la demande, et intime le pilote PSEC pour démarrer le moteur pour obtenir le correctif en émettant le code de contrôle IOCTL_GNSS_START_FIXSESSION.

2. Obtenir la position de l’appareil (corriger les données) : Une fois qu’une session de correction est démarrée, l’adaptateur PSEC émet le code de contrôle IOCTL_GNSS_GET_FIXDATA pour commencer à attendre un correctif du pilote. Lorsqu’une nouvelle donnée de position est disponible à partir du moteur, le pilote GNSS répond à cette demande de correction de position en attente.

   Si le type de session de correction est le correctif LKG (plutôt que le correctif actuel), les informations de position proviennent du cache du pilote.

   L'adaptateur GNSS garantit qu'une requête d'E/S asynchrone est toujours disponible pour le pilote GNSS afin de retourner les données de positionnement lorsqu'elles sont disponibles. Selon la nature du correctif, si des données plus précises sont attendues, l’adaptateur UO émet une autre requête d’E/S (à l’aide du même IOCTL) et cette séquence continue jusqu’à ce qu’aucune autre donnée ne soit disponible ou que la session de correction soit arrêtée.

3. Modifier la session de correction : Si le pilote GNSS ne prend pas en charge le multiplexage des sessions du même type, l’adaptateur GNSS peut émettre un IOCTL_GNSS_MODIFY_FIXSESSION pour ce type de session lorsque le multiplexage est effectué à son niveau.

4. Arrêter la session de localisation : L'adaptateur GNSS arrête une session de localisation lorsque plus aucune information de position relative à une session de localisation spécifique n'est nécessaire ou attendue.

Prise en charge du géofencing natif

Le DDI GNSS prend en charge les scénarios de déchargement de limite géographique à l’aide d’un ensemble d’IOCTL définis dans cette spécification. Un indicateur de capacité spécial est défini pour que le pilote indique cette prise en charge, cet indicateur ne doit être défini que si la pile SEE prend en charge la géofencing en mode natif (autrement dit, elle implémente la géofencing dans la puce SEE plutôt que dans le processeur d’application). Si le pilote ne prend pas en charge la limite géographique en mode natif, l’indicateur ne doit pas être défini. Le HLOS prend déjà en charge un moteur de suivi de géofence basé sur AP (Suboptimal Application Processor) ; Bien que cette solution ne soit pas aussi optimisée que celle d’une solution native, elle est bien testée et optimisée. Elle ne doit donc pas être remplacée par une solution équivalente implémentée dans l’API.

Le suivi de la limite géographique par le HLOS exige que le processeur d’application se réveille régulièrement pour détecter les violations de limite géographique, ce qui draine la puissance même lorsque les clôtures ne sont pas violées. Par conséquent, cette implémentation est considérée comme non optimale.

Le HLOS utilise également le suivi de la limite géographique basée sur l’API comme mécanisme de basculement lorsque le pilote sous-jacent ne parvient pas à suivre les limites géographiques en raison de conditions de signal faibles ou d’autres erreurs temporaires, lors des notifications d’erreur reçues de la solution de suivi de la limite géographique native. La prise en charge native du géorepérage est bénéfique uniquement lorsque le suivi du géorepérimètre est entièrement délégué au SoC et que le processeur d'application est réveillé uniquement pour traiter les événements liés au géorepérage. Si le matériel ne prend pas en charge le suivi de la limite géographique native, le pilote GNSS ne doit pas tenter de l’implémenter au niveau de la couche pilote.

Le moteur GNSS doit également mettre à disposition les paramètres de réglage spécifiques à un IHV documentés pour permettre de trouver le bon équilibre entre la consommation d’énergie et l’expérience utilisateur. En outre, le nombre de limites géographiques prises en charge doit être supérieur à la valeur MIN_GEOFENCES_REQUIRED définie dans le fichier d’en-tête. Notez que le MIN_GEOFENCES_REQUIRED est défini par application, car une application n’a aucune connaissance du nombre de limites géographiques utilisées par d’autres applications ou par l’opérateur mobile.

La prise en charge du déchargement de géofencing implique les exigences suivantes :

• Le HLOS sera en mesure de créer une ou plusieurs limites géographiques via la DDI et le pilote les envoie au matériel pour commencer à les suivre.

• Le HLOS devrait pouvoir supprimer une ou plusieurs zones géographiques préalablement créées via la DDI, et le pilote transmet ces instructions au matériel pour qu'il cesse de les suivre.

• Dans l’idéal, le matériel GNSS doit comprendre l’état de suivi initial de chaque limite géographique et l’utiliser pour signaler uniquement les modifications par rapport à cet état initial. Si le matériel GNSS ne prend pas en charge cette fonctionnalité, il signale l’état initial au HLOS chaque fois qu’un géorepérage est créé.

• Le matériel SEE suit la position actuelle de l’appareil de manière efficace et réveille l’AP chaque fois que l’appareil a entré et/ou quitté une limite géographique suivie. Le pilote GNSS transmet les alertes de géorepérage au HLOS.

• Dans le cas d’un signal satellite faible et d’autres conditions d’erreur temporaires, le moteur GNSS peut ne pas être en mesure de suivre de manière fiable les limites géographiques existantes. Le moteur GNSS doit être en mesure de détecter les interruptions de suivi et le pilote GNSS doit transmettre l’alerte d’erreur d’état de suivi à HLOS. Le HLOS passe au suivi des géofences basé sur le point d’accès par défaut jusqu’à ce que le matériel GNSS puisse récupérer et suivre à nouveau les géofences.

• Les conditions exactes dans lesquelles un moteur GNSS doit fournir une notification pour indiquer que les géofences ne peuvent pas être suivies varieront, et l'implémentation sera spécifique à chaque IHV. Voici quelques instructions pour l’implémentation :

  • Si le moteur GNSS est en mesure de détecter avec une grande confiance que l'utilisateur ne bouge pas et qu'il n'y a pas de limite de géorepérage à 25 mètres ou moins, le moteur GNSS n'a pas besoin d'envoyer une erreur de suivi.

  • Si le moteur GNSS est en mesure de détecter avec une grande certitude que l’utilisateur ne se déplace pas, mais qu’il existe un périmètre géographique dans une distance de 25 mètres ou moins, le moteur GNSS doit envoyer une erreur de suivi dans la minute.

  • Si le moteur GNSS a détecté que l’utilisateur se déplace et qu’il y a un périmètre de géofences à 100 mètres ou moins, le moteur GNSS doit envoyer une alerte de suivi dans la minute.

  • Si le moteur GNSS ne peut pas déterminer si l’utilisateur se déplace et qu’il y a une limite de géofences dans un rayon de 100 mètres ou moins, le moteur doit envoyer une erreur de suivi dans un délai d’une minute ou moins.

  • Si le moteur SEE a détecté que l’utilisateur se déplace, le moteur SEE doit envoyer une erreur de suivi dans un temps proportionnel à la vitesse estimée du mouvement et à la distance à la limite géographique la plus proche. Une recommandation consiste à envoyer une erreur dans [(Distance-à-la-limite-de-clôture-la-plus-proche (m) / vitesse estimée (m/s)) - 15s]. Le moteur GNSS peut utiliser des indicateurs de détection de mouvement pour déterminer le moment où l’erreur de suivi doit être envoyée.

  • Si le moteur SEE ne parvient pas à déterminer si l’utilisateur se déplace, le moteur SEE doit envoyer une erreur de suivi dans un temps proportionnel à la vitesse élevée du mouvement et à la distance la plus proche de la limite géographique la plus proche. Il est recommandé d'envoyer une notification d'erreur dans [Distance jusqu'à la limite la plus proche de la clôture (m) / 343 (m/s)].

• Pendant la période où le moteur GNSS a signalé une erreur d’état de suivi de géorepérage, aucun événement de violation de géorepérage ne doit être envoyé au HLOS.

• Le HLOS peut réinitialiser le suivi de la limite géographique en supprimant toutes les limites géographiques créées précédemment via une seule commande.

• Les limites géographiques provenant du mobile ne sont pas conservées dans le matériel ou le pilote GNSS lors du redémarrage ou du redémarrage des pilotes. HLOS gère la persistance pour le compte des applications de l’utilisateur final et crée/supprime des limites géographiques en fonction des besoins.

En termes d’interactions entre l’adaptateur GNSS et le moteur GNSS qui prend en charge le déchargement du géorepérage en mode natif, en cas d’échec de suivi des géorepérages, l’adaptateur GNSS effectue les opérations suivantes :

• Il utilisera le suivi basé sur l'AP lorsque le pilote GNSS retourne un échec de suivi.

• Il continuera à envoyer toutes les mises à jour (ajout/suppression) concernant les limites géographiques actuellement suivies au niveau du système d'exploitation vers le pilote pour qu'elles soient synchronisées. Cela aidera le moteur GNSS à savoir quelles limites géographiques sont actuellement suivies par le système d'exploitation et à déterminer s'il peut ou ne peut pas les suivre en fonction des nouvelles données.

• Il envoie les modifications de l'état de limite géographique telles que déterminées par le suivi basé sur le réseau AP, une fois que le pilote GNSS confirme sa capacité à effectuer le suivi avec succès.

Notifications de pilote pour l'assistance et les données auxiliaires.

De temps à autre, le pilote GNSS peut avoir besoin de données d’assistance ou d’actions d’assistance à partir de l’adaptateur GNSS. Cela inclut les différentes formes de données AGNSS (injection de temps, éphémérides, position initiale approximative), une fenêtre contextuelle de consentement utilisateur pour prendre en charge le positionnement du plan utilisateur initié par le réseau, etc.

• Les données d’assistance GNSS peuvent être obtenues par le pilote GNSS sans utiliser l’adaptateur GNSS. Néanmoins, il est recommandé d’obtenir les données d’assistance à l’aide de l’adaptateur GNSS et de tirer parti du service de positionnement Microsoft pour plusieurs raisons :

  • La pile de localisation Microsoft s'occupe de l'établissement des connexions de données et du respect de toutes les contraintes d'itinérance, préférences de données, intégration du mode silencieux réseau, et ainsi de suite.

  • Le service de positionnement Microsoft peut obtenir régulièrement des données d’assistance spécifiques à un IHV via une connexion serveur à serveur principal et les fournir à tous les appareils qui en ont besoin, évitant ainsi à l'IHV la nécessité de déployer un service d’assistance frontal dans le monde entier, répondant aux exigences de disponibilité, d’extensibilité et de réactivité.

• Les consentements de l’utilisateur pour la confidentialité des applications de boîte de réception sont détenus par le système d’exploitation. Par conséquent, toute interface utilisateur pour informer l’utilisateur d’une demande d’emplacement initiée par le réseau ou toute interface utilisateur pour demander le consentement de l’utilisateur pour répondre à une demande d’emplacement initié par le réseau, appartient à Microsoft. Le pilote GNSS notifiera l'adaptateur GNSS lorsqu'une demande de localisation initiée par le réseau sera reçue et, si nécessaire, il attendra la réponse de l'utilisateur jusqu'à l'expiration du délai par défaut avant de poursuivre le traitement de la demande.

Étant donné que le pilote PSEC n’est pas en mesure d’initier une demande à la couche supérieure par lui-même, ce type d’opérations peut être effectué par l’adaptateur PSEC de manière proactive à la recherche de cette demande auprès du pilote JDBC et ainsi conserver un ou plusieurs IRPs en attente afin que le pilote JDBC puisse répondre à ces demandes en attente. Lors de la réception de la demande d'assistance/date d'assistance, l’adaptateur GNSS récupère les données (ou exécute l’action spécifique pour le compte du pilote GNSS), puis injecte les informations nécessaires au pilote GNSS via un autre appel DeviceIoControl.

La notification du pilote est gérée par le biais d’un modèle d’événement commun. Par exemple, pour l’assistance GNSS, l’adaptateur GNSS utilise le code contrôle IOCTL_GNSS_LISTEN_AGNSS pour recevoir la requête AGNSS du pilote GNSS. Par la suite, l’adaptateur GNSS récupère les données d’assistance AGNSS et émet IOCTL_GNSS_INJECT_AGNSS pour envoyer les données dans le pilote GNSS.

Ce mécanisme de notification est également utilisé pour recevoir les données d’alerte liées à la limite géographique et les mises à jour d’état. L’adaptateur utilise le code de contrôle IOCTL_GNSS_LISTEN_GEOFENCE_ALERT pour recevoir des alertes de limite géographique individuelles et IOCTL_GNSS_LISTEN_GEOFENCES_TRACKINGSTATUS pour recevoir des modifications dans l’état global du suivi de la limite géographique.

Journalisation des pilotes GNSS (Global Navigation Satellite System)

À des fins de diagnostic, le pilote PSEC doit consigner des erreurs et d’autres informations de diagnostic à l’aide du mécanisme de journalisation prescrit par Microsoft (WPP) décrit ci-dessous ou ETW. Il est recommandé aux conducteurs d’utiliser WPP à des fins de journalisation plutôt que qu'ETW, bien que les deux mécanismes soient pris en charge. Parmi les raisons pour lesquelles WPP est recommandé, il y a la disponibilité des outils qui peuvent aider le débogage des pilotes.

Le pilote ne doit consigner aucune information, lisible par l'homme ou autrement, autre que par cette technique de journalisation prescrite. Pour plus d’informations, consultez le suivi logiciel WPP.

La journalisation des messages avec le suivi logiciel WPP est similaire à l’utilisation des services de journalisation des événements Windows. Le pilote enregistre un ID de message et des données binaires non mises en forme dans un fichier journal. Par la suite, un postprocesseur convertit les informations dans le fichier journal sous forme lisible par l’homme. Toutefois, le suivi logiciel WPP prend en charge les formats de messages plus capables et flexibles que ceux pris en charge par les services de journalisation des événements. Par exemple, le suivi logiciel WPP prend en charge les adresses IP, les GUID, les ID système, les horodatages et d’autres types de données utiles. En outre, les utilisateurs peuvent ajouter des types de données personnalisés pertinents pour leur application.

Prise en charge du protocole de l'opérateur mobile

La pile GNSS fournie par l'IHV (le pilote GNSS, le périphérique/moteur GNSS) est nécessaire pour prendre en charge les différents protocoles de positionnement des opérateurs mobiles (SUPL, UPL, CP, etc.). L’échec de cette opération signifie que l’appareil ne passera pas l’acceptation des opérateurs mobiles et limitera considérablement l’emplacement où l’appareil peut être commercialisé.

La prise en charge de ces protocoles et de la conformité avec les exigences des opérateurs mobiles est obligatoire pour expédier des appareils pour certains opérateurs mobiles. La prise en charge des protocoles d’opérateur mobile n’est peut-être pas essentielle pour la plupart des plateformes non téléphoniques, spécialement si la plateforme n’inclut pas la prise en charge du haut débit mobile (MBB).

Toutes les parties d’implémentation sont abstraites dans la pile IHV et les composants Microsoft HLOS sont indépendants des éléments suivants :

• Détails d’implémentation spécifiques des protocoles (par exemple, fonctionnement des protocoles, interprétation des messages de protocole, etc.).

• Forme de la pile d’implémentation (par exemple, l’implémentation peut résider dans le périphérique/le moteur PSEC, ou le pilote PSEC, ou si nécessaire un service HLOS distinct).

• Interaction entre les différents éléments de la pile GNSS appartenant à IHV pour l’implémentation des protocoles. Par exemple, si le pilote GNSS requiert les résultats d’analyse Wi-Fi pour répondre à un message de protocole SUPL spécifique, il peut le faire en ayant une extension en mode utilisateur injecter les résultats d’analyse Wi-Fi au pilote via un appel IOCTL privé, ou en intégrant cela dans le pilote UMDF 2.0, ou en gérant cette interaction à un niveau inférieur. Les composants HLOS GNSS de Microsoft sont indifférents à ces interactions entre les composants de la pile GNSS IHV.

En résumé, l’IHV ou l’OEM doit fournir un client SUPL (et potentiellement un client UPL si le système doit être expédié en Chine) et l’intégrer au pilote PSEC. Toutes les interactions de la plateforme d’emplacement avec le client SUPL sont effectuées via la DDI GNSS.

Pour faciliter l’implémentation des protocoles d’opérateur mobile et réduire la charge de développement logiciel à l’aide de technologies spécifiques à la plateforme, l’adaptateur GNSS fournit certaines fonctionnalités à la pile GNSS IHV. Le pilote PSEC est traité comme l’intermédiaire pour la réception de ces fonctionnalités à partir des composants HLOS, par exemple, l’adaptateur PSEC interagit uniquement avec le pilote PSEC et non avec une autre partie de la pile IHV PSEC. Les IOCTLs du pilote GNSS définissent la syntaxe et la sémantique de cette fonctionnalité entre le pilote GNSS et l’adaptateur GNSS. Le pilote GNSS est responsable du routage vers le composant IHV spécifique qui implémente le protocole de l'opérateur mobile. En général, l’adaptateur PSEC fournit les fonctionnalités suivantes au pilote PSEC :

1. Configuration: Les opérateurs mobiles approvisionnent l’appareil et modifient la configuration à l’aide du mécanisme de configuration imposé par les normes du protocole OMA. Par exemple, la norme SUPL nécessite que la configuration SUPL soit effectuée en fonction de l’UICC et/ou soit effectuée à l’aide des informations de profil de configuration SUPL OMA obtenues via OMA-DM ou OMA-CP.

   Certaines fonctionnalités disponibles dans le téléphone à des fins de configuration (OMA-DM et OMA CP) n’étaient pas disponibles dans d’autres plateformes tant que Windows 10 n’était pas disponible. À compter de Windows 10, toutes les plateformes peuvent prendre en charge la configuration SUPL via le fournisseur de services de configuration SUPL (CSP), jusqu’à ce que la nouvelle DDI SEE soit utilisée. L’approvisionnement injecté par le biais du fournisseur de solutions Cloud peut provenir de l’image elle-même (via provxml ou multivariant) ou de l’opérateur mobile via OMA-DM ou OMA-CP. Le CSP SUPL est défini dans SUPL CSP.

   Windows 10 définit une technologie propriétaire, la gestion des appareils à l’aide d’un fournisseur de services de configuration (CSP), pour interpréter et extraire les données de configuration. Microsoft fournit un fournisseur de services cloud pour consommer la configuration OMA et pousser la configuration au pilote GNSS via l'adaptateur GNSS.

   L’IHV peut également écrire un composant en mode utilisateur pour consommer la spécification de configuration de l’opérateur mobile à l’aide de la technologie de gestion des appareils (CSP) spécifique au téléphone. Toutefois, il s’agit d’un fardeau supplémentaire pour l’IHV, ce qui n'est pas recommandé.

   Une seule configuration SUPL est prise en charge dans un système, notamment dans les cas d’appareils double SIM. Microsoft fournit la fonctionnalité permettant de reconfigurer SUPL en fonction de l’UICC et de la modification de l’UICC. En plus de cela, en cas d’itinérance de l’appareil, le HLOS configure à nouveau le client SUPL pour fonctionner en mode autonome. Ce document définit les IOCTLs pour envoyer (push) ces données de configuration pour divers protocoles d’opération mobile (SUPL 1.0 et 2.0, v2UPL, etc.).

2. Gestion du consentement de l’utilisateur pour les demandes NI : Pour répondre aux exigences de confidentialité, certaines demandes de positionnement initiées par le réseau nécessitent le consentement de l’utilisateur. Les IHD ne sont pas autorisés à écrire l’interface utilisateur pour des composants de la plateforme. Par conséquent, l'adaptateur GNSS gère l'interface utilisateur pour le consentement de l'utilisateur pour le compte du pilote GNSS. Les notifications IOCTL pour le pilote GNSS afin de demander une fenêtre contextuelle d’interface utilisateur, ainsi que les IOCTL pour l’adaptateur GNSS pour transmettre la réponse de l’utilisateur à une telle demande, sont définies dans les IOCTLs du pilote GNSS.

Pour implémenter un client SUPL entièrement fonctionnel, la pile IHV doit utiliser des interfaces ou des fonctionnalités générales disponibles dans/via la plateforme du système d’exploitation. Voici la liste des fonctionnalités disponibles dans Windows 10 que les IHD peuvent tirer parti pour implémenter leur client SUPL :

Aucune de ces fonctionnalités ne fait partie de la plateforme d’emplacement ou de la DDI PSEC, mais elle est incluse ici pour obtenir des précisions et aider les développeurs de pilotes PSEC à comprendre ce qui peut être utilisé par le système d’exploitation pour implémenter la fonctionnalité SUPL.

• Routeur SMS : Le routeur SMS permet au client SUPL de s’abonner au WAP Push des messages Push SIP qui contiennent des demandes SUPL NI.

• Capacité du Gestionnaire de connexions à configurer la connexion qui doit être utilisée pour supL et les API pour demander cette connexion : Les opérateurs mobiles peuvent nécessiter le trafic SUPL dans une connexion dédiée, ou simplement sur une connexion différente de la connexion Internet par défaut. Pour ce faire, le Gestionnaire de connexions offre :

  • Fournisseur de services de configuration que l’OEM ou l’opérateur mobile peut utiliser pour configurer la connexion qui doit être utilisée à des fins de communications SUPL.

  • API pour le client SUPL afin d'interroger les paramètres de la connexion SUPL.

  • API permettant d’établir la connexion SUPL, avec les paramètres obtenus à l’étape précédente.

• Configuration de la connexion cellulaire : Pour configurer les paramètres des différentes connexions cellulaires, par exemple les paramètres d’une connexion SUPL, il existe un fournisseur de services de configuration que l’OEM ou l’opérateur mobile peut utiliser. Cette connexion peut ensuite être associée dans le Gestionnaire de connexions à l’objectif SUPL.

• Demandez à conserver les connexions actives pendant qu’une connexion SUPL est en cours : Le client SUPL peut avoir besoin de lancer des connexions avec le HSLP pendant que le système est connecté en secours. Cela peut se produire parce que l’appareil GNSS doit obtenir des données d’assistance lorsqu’il est configuré pour utiliser le positionnement basé sur Microsoft ou parce que l’opérateur mobile a envoyé une demande initiée par le réseau. Si c’est le cas, le client SUPL doit lancer une connexion avec HSLP et vérifier que la connexion est active jusqu’à ce que la session SUPL soit terminée.

• Interactions avec le module MBB (Mobile Broadband) : Dans Windows 10, il n’existe aucune API disponible via le HLOS pour récupérer les mesures cellulaires, savoir quand un appel d’urgence a été placé, et ainsi de suite. Toute interaction avec le MBB doit être effectuée via l’intégration directe avec le MBB (via des commandes AT ou d’autres méthodes propriétaires).

Tests de fabrication

Les fabricants OEM doivent disposer d’un moyen de valider au moment de la fabrication, ainsi qu’aux points de support client que le matériel GNSS et la pile GNSS (le pilote GNSS et le dispositif/moteur GNSS) fonctionnent correctement. L’IHV peut fournir des mécanismes propriétaires pour permettre aux oem d’effectuer ce test, ou peut éventuellement implémenter l’interface dans le DDI pour permettre au fabricant OEM de lancer des tests de fabrication et d’obtenir des résultats.

L’infrastructure d’emplacement sera contournée lors du test de fabrication, étant donné que l'objectif principal des tests est la validation matérielle ou la validation des pilotes. En règle générale, l’appareil se trouve en mode spécial de fonctionnement sécurisé où l’ensemble minimal de composants et de services sera chargé. Dans ce mode, l’OEM peut lancer un ensemble d’applications de test qui déclencheront des cas de test. Pour l’efficacité et la vitesse pendant la fabrication, il est fortement souhaitable d’avoir un support de la simultanéité pour les tests entre différents composants.

L’interface des tests de fabrication comprend deux types de tests :

1. Test d’onde de transporteur : Ce test consiste à valider le test de connectivité/antenne externe. Dans ce test, le moteur GNSS doit rechercher un signal CW et fournir les mesures de SNR (rapport signal sur bruit ou rapport porteur sur bruit) dans la réponse. Idéalement, les tests doivent fournir des réponses à 10 Hz.

2. Autotest : Ce test consiste à valider les fonctionnalités de base du moteur GNSS. L’auto-test doit être en mesure de détecter les problèmes de base dans le moteur (matériel défectueux, connexions incorrectes dans le matériel SEE sans nécessiter de signal externe injecté. L’objectif de cette validation est de faire ce test bon marché et de l’utiliser comme porte dans la ligne de production, avant que l’appareil passe par des tests plus exhaustifs et coûteux. Dans ce test, le moteur et le pilote GNSS doivent effectuer une auto-validation pour les connexions de broche et retourner un code d’état indiquant que tout est correct ou qu’une défaillance s’est produite. Le code d’erreur pour les échecs doit indiquer l’erreur détectée. Les codes d’erreur sont définis par l’IHV.

Considérations relatives aux E/S

Étant donné que la fonctionnalité PSEC ne mappe pas aux demandes traditionnelles de lecture et d’écriture de fichiers aux pilotes de périphérique, les fonctions ReadFile et WriteFile ne seront pas utilisées pour les API de pilote PSEC. Toutes les fonctionnalités GNSS seront implémentées à l’aide de requêtes d’E/S spécifiques au GNSS, bien définies (DeviceIoControl), également appelées IOCTLs.

Tous les IOCTL utilisent METHOD_BUFFERED comme mécanisme de transfert de données pour les données d’entrée et de sortie. Étant donné que la taille des données liées au GNSS est relativement petite, la copie de mémoire tampon supplémentaire ne doit pas affecter les performances du système.

Le pilote SEE est ouvert à l’aide de l’option FILE_FLAG_OVERLAPPED dans la fonction CreateFile . Par conséquent, toutes les IOCTL sont implicitement asynchrones. Toutefois, même si la plupart des IOCTL sont sémantiquement asynchrones (par exemple, un IOCTL déclenche une activité au sein du pilote et les résultats sont attendus de manière asynchrone), certaines IOCTL sont sémantiquement synchrones dans le sens où il n’existe aucune action ou activité asynchrone logique impliquée dans ces IOCTLs. Le comportement synchrone de cette IOCTL sera réalisé en bloquant le thread de l’adaptateur GNSS après avoir émis l’appel DeviceIoControl jusqu’à ce que l’opération d’E/S soit terminée. Par conséquent, il incombe au pilote GNSS de toujours effectuer l'IRP dans le cadre du traitement de tous les IOCTL. L’adaptateur SEE est censé respecter le contrat d’un appel synchrone et, en cas d’erreurs, peut ou non réessayer ces commandes. Le pilote IHV doit s’assurer qu’il a incorporé toutes les logiques côté pilote avant de retourner une erreur.

Pour les opérations de demande et de réponse, l'adaptateur GNSS conserve toujours une opération d'E/S en attente disponible, afin que lorsque le pilote GNSS dispose de données à envoyer en réponse à une opération précédemment appelée, la réponse puisse être envoyée via l'IRP en attente.

Session à capture unique

Une demande de correctif de démarrage pour un correctif de tir unique pour le pilote inclut des valeurs de précision et de temps de réponse. Le moteur GNSS peut utiliser ces valeurs pour comprendre l’intention de la demande d’application et prendre des décisions intelligentes. Une fois qu’une demande est reçue par le pilote, elle doit commencer à retourner les correctifs intermédiaires générés par le moteur. Les correctifs intermédiaires sont des correctifs générés par le moteur tout en calculant un correctif qui répond aux exigences de précision ou est final. La fréquence de ces correctifs intermédiaires n’est pas appliquée et est un détail d’implémentation du moteur. L’adaptateur CONTOSO s’attend à ce que les correctifs soient apportés toutes les quelques secondes et qu’ils doivent être différents du dernier correctif intermédiaire.

Une fois que le moteur GNSS détermine qu’il ne peut pas obtenir une meilleure position dans les conditions de signal actuelles, il doit retourner une position finale et cesser d’effectuer d’autres calculs. Le correctif final répond à l’exigence de précision ou indique que le moteur ne peut pas améliorer la précision fournie dans les conditions actuelles.

L’adaptateur SEE émet un correctif d’arrêt pour une session de capture unique dans l’un des deux cas suivants :

• Il se voit appliquer une correction finale par le pilote.

• Le temps de réponse pour la requête a été atteint. Ici, le dernier correctif intermédiaire sera envoyé à l’application.

La figure suivante illustre deux sessions de capture unique :

Session 1 : Le pilote a reçu des paramètres De précision et de temps de réponse. Après la commande de correction de démarrage, le pilote a commencé à envoyer des correctifs intermédiaires. Après un certain temps, il a déterminé qu’il n’a pas pu retourner un correctif plus précis, de sorte qu’il a indiqué le dernier correctif comme final. Cela s’est produit avant que la limite de temps de réponse ait été atteinte. L’adaptateur a envoyé le correctif final à l’application et a émis une commande d’arrêt.

Session 2 : Identique à la session 1 ci-dessus, mais dans ce cas, le moteur a continué à passer à un meilleur correctif pour répondre à l’exigence de précision et à envoyer des correctifs intermédiaires entre les deux. Une fois la limite de temps de réponse de session atteinte, l’adaptateur a émis un correctif d’arrêt qui doit fermer cette session dans le pilote. Le dernier correctif intermédiaire reçu a été envoyé à l’application.

L’un des aspects importants à prendre en compte lors de l'implémentation du support pour la capture unique est que, si les sessions de suivi basées sur la distance et les sessions de suivi basées sur le temps ne sont pas prises en charge, le moteur GNSS continue de suivre les satellites pendant 3 à 5 secondes après la réception d’une commande d'arrêt de correction. Cela est dû au fait que l’adaptateur GNSS doit implémenter des sessions de suivi simulées basées sur la distance et/ou sur le temps en utilisant des sessions de correction ponctuelles, et si le moteur GNSS arrête immédiatement le suivi des satellites, la plupart des appareils auront un délai lors de l’acquisition, ce qui rend impossible l’implémentation d’une session de suivi simulé qui répond aux besoins de navigation, de suivi de course ou d’applications de cartographie.

L'adaptateur GNSS peut initier des demandes de corrections instantanées lorsque le système est en veille connectée, pas seulement lorsque le système est actif. Cela peut se produire pour répondre aux besoins des tâches en arrière-plan, des services système, du suivi des limites géographiques dans le processeur d’application ou d’autres cas. Le pilote PSEC doit être en mesure de transmettre ces demandes de session au périphérique PSEC et de répondre à la demande ou de fournir une erreur à l’adaptateur PSEC.

Le diagramme de séquence suivant illustre les actions de haut niveau liées à l’obtention d’un fix GNSS autonome. Cela n’inclut aucune demande de données d’assistance.

La description de séquence est la suivante :

1. L’adaptateur GNSS ouvre le pilote GNSS à l’aide de l’API CreateFile. WDF/KMDF/UMDF effectue les rappels facultatifs nécessaires au pilote GNSS. Le handle de fichier retourné est utilisé pour toutes les opérations suivantes.

2. L’adaptateur GNSS émet un IOCTL pour communiquer les différentes fonctionnalités de plate-forme au pilote. Le pilote GNSS termine l'opération d'E/S.

3. L’adaptateur GNSS émet IOCTL pour obtenir les capacités de l’appareil. Le pilote GNSS retourne les capacités de l’appareil et termine l’opération d’E/S.

4. L'adaptateur GNSS émet des IOCTLs pour toute configuration ou commande spécifique au pilote. Le pilote GNSS effectue l’action nécessaire et termine l’opération d’E/S.

5. L’adaptateur GNSS émet une IOCTL_GNSS_START_FIXSESSION, ainsi que les paramètres spécifiant le type et d’autres aspects de la localisation. Lors de la réception de ce IOCTL, le pilote PSEC interagit avec l’appareil sous-jacent pour commencer à recevoir des correctifs et termine par la suite l’opération d’E/S.

6. L’adaptateur GNSS émet une IOCTL_GNSS_GET_FIXDATA et attend la fin de l’E/S. Chaque fois que le pilote GNSS dispose d'une solution intermédiaire, il retourne les données en effectuant l'opération d'E/S.

7. L’étape 6 est répétée jusqu’à ce que le pilote GNSS indique qu’aucun correctif supplémentaire n’est attendu (correctif final reçu).

8. L’adaptateur GNSS émet IOCTL_GNSS_STOP_FIXSESSION. Le pilote PSEC effectue l’opération de nettoyage nécessaire associée à la demande de correctif d’origine.

9. L’adaptateur GNSS ferme le descripteur de fichier du pilote en utilisant l’API CloseHandle.

Les IOCTLs GNSS et les structures de données associées sont décrits en détail dans la référence du pilote GNSS.

Session de suivi basée sur la distance

Les sessions de suivi basées sur la distance sont fréquemment utilisées par les applications de l’utilisateur final, comme historiquement, il s’agissait du seul type de session disponible dans les API .NET. Une valeur de distance de 0 indique que le moteur GNSS doit fournir des positions à la fréquence maximale possible.

L’adaptateur JDBC démarre les sessions de suivi de distance avec le pilote JDBC, uniquement si ce dernier indique qu’il dispose de la fonctionnalité SupportDistanceTracking.

Une demande de fixation de départ pour le pilote dans le cadre d'une session de suivi de distance inclut la précision horizontale souhaitée et le seuil de mouvement, qui est la distance haversine en mètres que le système doit couvrir avant que le pilote GNSS fournisse une mise à jour de position. Le moteur GNSS peut utiliser ces valeurs pour comprendre l’intention de la requête de l'application et prendre des décisions intelligentes, telles que l’adaptation de la fréquence à laquelle vérifier la position.

Une fois qu’une demande de correctif de démarrage est reçue par le pilote, elle doit commencer à retourner les correctifs intermédiaires générés par le moteur, jusqu’à ce qu’il obtienne un correctif final. Cela sera considéré comme la première position de la session. Le moteur GNSS doit commencer à fournir des solutions chaque fois qu’il constate que la distance haversine a été approximativement couverte.

Si le moteur GNSS détermine qu’il ne peut plus suivre l’emplacement de l’appareil (par exemple, si les satellites ne sont plus visibles), il doit renvoyer une erreur à l’adaptateur GNSS afin que la plateforme de localisation puisse revenir à d’autres mécanismes pour fournir des mises à jour de position à l’application utilisateur final. L'adaptateur GNSS doit présenter une marge d'erreur dans le délai suivant :

[(Distance-restant-depuis-last-known-position (m) / vitesse estimée (m/s)) – 5 secondes] ou 5 secondes, selon le plus grand.

Si le moteur GNSS a fourni une erreur à l’adaptateur GNSS, mais que l’adaptateur GNSS n’a pas encore arrêté la session de suivi, le moteur GNSS doit continuer à vérifier, de manière optimisée pour la consommation d'énergie, s’il peut reprendre la localisation de suivi. L’IHV peut utiliser des optimisations pour rendre cette détection à faible puissance. Les techniques courantes d’optimisation sont les suivantes :

• Retour progressif

• Attente de signaux à faible coût qui indiquent les mouvements de l’appareil à revérifier

• Vérifications de faible puissance pour le signal satellite

Une fois que le moteur GNSS est en mesure de fournir à nouveau une position finale après une condition d'erreur, il doit envoyer cette position à l'adaptateur GNSS comme indication que le suivi a été repris avec succès.

L’adaptateur GNSS émet une commande de modification de correction pour une session de suivi basée sur la distance si une ou plusieurs applications qui ont demandé la session de suivi ont annulé la demande ou si de nouvelles applications demandent une session de suivi basée sur la distance. Dans ce cas, l’adaptateur GNSS calcule les nouveaux paramètres de session agrégés requis pour multiplexer les différentes sessions actives et met à jour le pilote GNSS avec ces paramètres.

L’adaptateur GNSS émet une commande d'arrêt de correction pour une session de suivi basée sur la distance si :

• La session de suivi a été remise à un autre moteur de positionnement disponible dans le système.

• Les applications qui ont demandé la session de suivi ont annulé la demande.

La figure suivante illustre deux sessions de suivi basées sur la distance :

Session 1 : Le pilote GNSS a reçu des paramètres de précision et de seuil de mouvement au début de la session de suivi. Après la commande de correction de démarrage, le pilote commence à envoyer des correctifs intermédiaires jusqu’à ce qu’il obtienne un correctif final ou un correctif qui répond à l’exigence de précision à laquelle ce correctif est fourni à l’adaptateur PSEC et que le moteur PSEC démarre le processus de suivi de distance. Pendant que la session est active, l’adaptateur GNSS envoie une demande pour modifier les paramètres de session aux moments T1 et T2. Après chaque modification des paramètres, le pilote PSEC envoie une mise à jour de correctif à l’adaptateur PSEC et reprend la session de suivi de distance avec les nouveaux paramètres, jusqu’à ce que l’adaptateur PSEC envoie une commande de correction d’arrêt.

Session 2 : Le processus d’initiation de session est similaire à la session 1 ci-dessus, mais à un moment donné, le moteur GNSS ne parvient pas à déterminer la position. Après une durée qui dépend de la distance et de la vitesse estimée du mouvement, le pilote GNSS envoie une erreur. Le moteur GNSS continue de vérifier à faible puissance lorsqu'il peut retrouver ses fonctions, et lorsqu'il y parvient, il l'indique à l'adaptateur GNSS en envoyant une nouvelle position. La session est mise à jour avec de nouveaux correctifs si nécessaire jusqu'à ce que l'adaptateur GNSS envoie une commande de correctif d'arrêt.

L’adaptateur GNSS peut rester actif ou même lancer des sessions de suivi basées sur la distance pendant que le système est en veille connectée, pas seulement lorsque le système est actif. Cela peut se produire pour satisfaire le besoin de tâches en arrière-plan, de services système, de suivi des limites géographiques dans le processeur d’application ou d’autres cas. Le pilote PSEC doit être en mesure de transmettre ces demandes de session au périphérique PSEC et de répondre à la demande ou de fournir une erreur à l’adaptateur PSEC.

Session de suivi basée sur le temps

Les sessions de suivi basées sur le temps peuvent être utilisées par les applications qui nécessitent une mise à jour de position fréquente et régulière pour actualiser l’interface utilisateur (par exemple, cartes, applications de navigation, etc.).

L’adaptateur JDBC démarre les sessions de suivi basées sur le temps avec le pilote JDBC, uniquement si la version ultérieure indique qu’elle dispose de la fonctionnalité SupportContinuousTracking.

Une demande de correctif de démarrage adressée au pilote pour une session de suivi basée sur le temps inclura la précision horizontale souhaitée et l'intervalle de temps préféré auquel le pilote GNSS devrait fournir une mise à jour de position. Le moteur INSIGHTS peut utiliser ces valeurs pour comprendre l’intention de la demande d’application et prendre des décisions intelligentes, telles que l’adaptation de la fréquence à laquelle vérifier l’emplacement, commencer à acquérir des satellites quelques secondes avant l’intervalle pour fournir une mise à jour de position en temps opportun, etc.

Une fois qu’une demande de correctif de démarrage est reçue par le pilote, elle doit commencer à retourner les correctifs intermédiaires générés par le moteur, jusqu’à ce qu’il obtienne un correctif final. Cela sera considéré comme la première position de la session. Après cela, le moteur GNSS commencera à fournir des solutions à l'intervalle requis par les paramètres de session. Si le moteur GNSS ne parvient pas à fournir des positions à la fréquence requise par l’application, il doit fournir des calculs de position à la fréquence maximale possible.

Si le moteur GNSS détermine qu’il ne peut plus suivre l’emplacement de l’appareil (par exemple, si les satellites ne sont plus visibles), il doit renvoyer une erreur à l’adaptateur GNSS afin que la plateforme de localisation puisse utiliser d'autres mécanismes pour fournir des mises à jour de position à l’application de l’utilisateur final.

Si le moteur GNSS a fourni une erreur à l’adaptateur GNSS, mais que l’adaptateur GNSS n’a pas encore arrêté la session de suivi, le moteur GNSS doit continuer à vérifier, de manière optimisée pour l'économie d'énergie, s’il peut reprendre le suivi de l’emplacement.

L’IHV peut utiliser des optimisations pour rendre cette détection à faible puissance, comme expliqué dans la section précédente. Une fois que le moteur GNSS est en mesure de fournir à nouveau une position finale après avoir corrigé une erreur, il doit envoyer cette position à l'adaptateur GNSS pour indiquer que le suivi a été repris avec succès.

L'adaptateur GNSS émet une commande de modification du correctif pour une session de suivi basée sur le temps si une ou plusieurs applications qui ont demandé la session de suivi ont annulé ou si de nouvelles applications demandent une session de suivi basée sur le temps. Dans ce cas, l'adaptateur GNSS calcule les nouveaux paramètres de session agrégés requis pour multiplexer les différentes sessions actives et met à jour le pilote GNSS avec ces paramètres.

L'adaptateur GNSS émet une commande d'arrêt de correction pour une session de suivi basée sur le temps si :

• La session de suivi a été transférée à un autre moteur de positionnement disponible dans le système.

• Les applications qui ont demandé la session de suivi ont annulé la demande.

La figure suivante illustre deux sessions de suivi basées sur le temps.

Session 1 : Le pilote GNSS a reçu des paramètres de précision et d'intervalle préféré au démarrage de la session de suivi. Après la commande de correction de démarrage, le pilote commence à envoyer des correctifs intermédiaires jusqu'à ce qu'il obtienne un correctif final ou un correctif qui répond à l'exigence de précision, auquel cas ce correctif est fourni à l'adaptateur GNSS, et le moteur GNSS démarre le processus de suivi basé sur le temps. Pendant que la session est active, l’adaptateur GNSS envoie une demande pour modifier les paramètres de session aux moments T1 et T2. Après chaque modification des paramètres, le pilote PSEC envoie une mise à jour de correctif à l’adaptateur PSEC et reprend la session de suivi basée sur le temps, avec les nouveaux paramètres, jusqu’à ce que l’adaptateur PSEC envoie une commande de correction d’arrêt.

Session 2 : Le processus d’initiation de session est similaire à celui de la session 1 ci-dessus, mais à un moment donné, le moteur SEE cesse de suivre la position. Lorsque le moteur PSEC ne parvient pas à fournir un correctif dans les 15 secondes suivant l’intervalle requis par les paramètres de session, le pilote PSEC envoie une erreur. Le moteur GNSS continue de vérifier à faible puissance quand il peut se rétablir, et lorsqu’il se rétablit, il l’indique à l’adaptateur GNSS en envoyant une nouvelle position. La session est mise à jour avec de nouvelles corrections au besoin jusqu'à ce que l'adaptateur GNSS envoie une commande pour arrêter les corrections.

L’adaptateur GNSS peut rester actif ou même lancer des sessions de suivi basées sur le temps non seulement lorsque le système est actif, mais aussi pendant que le système est en veille connectée. Cela peut se produire pour répondre aux besoins des tâches en arrière-plan, des services système, du suivi de la limite géographique dans le processeur d’application ou d’autres cas. Le pilote PSEC doit être en mesure de transmettre ces demandes de session au périphérique PSEC et de répondre à la demande ou de fournir une erreur à l’adaptateur PSEC.

Gérer simultanément différents types de session de correctif

Certains moteurs GNSS avancés peuvent être en mesure de gérer simultanément une session Single Shot, avec une session de suivi Distance-Based et/ou Time-Based. Dans l'idéal, les sessions indépendantes ne devraient pas s'influencer mutuellement, mais cela peut ne pas toujours être possible, particulièrement dans le cas de sessions de suivi temporel et de sessions à prise unique simultanées. Cette section fournit des directives pour l'implémentation de l'IHV, dans les cas où il est nécessaire de faire des compromis pour gérer des sessions simultanées de différents types.

Les acronymes suivants sont utilisés dans cette section :

• ß: Session à capture unique

• DBT : Session de suivi basé sur la distance

• TBT : session de suivi en fonction du temps

• TBF : Temps entre les correctifs

Le tableau suivant fournit quelques scénarios de gestion simultanées de sessions de suivi basées sur le temps et à une seule capture :

S’il existe simultanément une session de suivi basée sur le temps et une session de suivi basée sur la distance, le suivi de la précision du moteur GNSS peut être configuré pour fonctionner avec celle qui a la plus petite valeur des deux. Le tableau suivant fournit également des instructions pour le cas de valeurs disparates pour la précision requise lorsqu’il existe simultanément des sessions de tir unique et de suivi :