Architecture du pilote GNSS (Global Navigation Satellite System)

Fournit une vue d’ensemble de l’architecture du pilote UMDF 2.0 2.0 du global Navigation Satellite System (GNSS), des considérations relatives aux E/S, et traite de plusieurs types de sessions de suivi et de correction.

Présentation de l'architecture

Le diagramme de blocs de composants de haut niveau suivant montre comment le pilote UMDF 2.0 2.0 du global Navigation Satellite System (GNSS) 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 : Application de test des fonctionnalités GNSS.

• API SYNC : L’interface COM (Component Object Model) IGnssAdapter qui expose les fonctionnalités de l’appareil GNSS aux composants internes du service d’emplacement, 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 l’appareil GNSS en programmant par rapport à l’interface COM IGnssAdapter . L’ensemble d’API SYNC est une API privée destinée uniquement aux composants de la plateforme de localisation (par exemple, le service d’emplacement et les applications de test d’emplacement) et n’est pas disponible pour d’autres applications internes ou tierces.

• Adaptateur GNSS : Il s’agit d’un objet COM singleton qui implémente l’interface COM IGnssAdapter . Les applications de test et les composants internes du service d’emplacement instancient cet objet et utilisent l’appareil GNSS via l’interface IGnssAdapter . Le composant moteur de positionnement GNSS du service d’emplacement implémente la classe COM qui expose l’interface I Boutadapter . Le service d’emplacement expose un mécanisme d’usine pour tester et d’autres applications hors processus pour instancier un objet COM singleton de la classe COM de l’adaptateur RÉINITIALISATION au sein du service d’emplacement. Les applications hors processus utilisent le pointeur d’interface COM pour programmer sur le pilote GNSS.

  COM gère le proxy le pointeur d’interface vers les applications hors processus afin que les applications traitent le pointeur d’interface IRtcAdapter comme un objet COM in-process, mais les appels sont en fait gérés par l’objet d’adaptateur RTC singleton au sein du service d’emplacement.

  Le moteur de positionnement GNSS utilise l’objet d’adaptateur GNSS interne pour fournir des fonctionnalités spécifiques à l’emplacement au service de localisation. L’adaptateur RTC ouvre un handle de fichier au pilote RTC à l’aide de l’API CreateFile , puis encapsule les appels d’API natives RTC dans des appels DeviceIoControl appropriés, gère la machine d’état avec l’objet de pilote RTC et maintient l’état des différentes requêtes entrantes des couches supérieures. Ce composant interagit directement avec la pile d’appareils GNSS sous-jacente par le biais de l’interface IOCTL GNSS publique définie dans ce document. L’appareil GNSS est logiquement traité comme une ressource exclusive. Par conséquent, l’adaptateur GNSS singleton 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 GNSS directement dans un environnement de non-production au lieu d’utiliser l’adaptateur GNSS via les API privées GNSS. Toutefois, ces applications de test devront implémenter leur propre machine d’état et leur propre traitement pour imiter certaines fonctionnalités de l’adaptateur GNSS.

• Pilote GNSS : Un pilote fourni par IHV implémenté à l’aide d’UMDF 2.0. Le pilote GNSS prend en charge les API GNSS DeviceIoControl en 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 le SoC et les éléments matériels de l’appareil GNSS. Un IHV peut choisir d’implémenter la plupart des fonctionnalités AUTHENTIFICATION au sein de ce composant, ce qui rend la couche de pilote GNSS très mince (essentiellement une carte pour l’interfaçage avec le périphérique GNSS).

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

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

Par conséquent, les appareils Windows dotés d’un appareil SYNC qui s’intègrent au modèle d’extension sensor v1.0 qui existait dans Windows 7, Windows 8 et Windows 8.1 sont censés continuer à fonctionner dans Windows 10 sans aucune modification. Il est vivement recommandé de publier ces pilotes (et tous les nouveaux pilotes) 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 SYNC dans le kit de laboratoire matériel (HLK) fourni 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 étaient disponibles dans le WHCK dans Windows 8.1.

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

Coexistence d’appareils SYNC (Global Navigation Satellite System)

Dans le cas rare de plusieurs appareils RTC détectés dans un système, la plateforme de localisation 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 lorsqu’un appareil GNSS interne est présent, il est fort probable que l’utilisateur souhaite que cet appareil externe soit utilisé.

Le comportement de la plateforme d’emplacement, basé sur ces hypothèses, sera le suivant :

• Cas de deux pilotes hérités coexistants : pour éviter les problèmes de compatibilité arrière, le comportement sera le même que dans Windows 8.1, où les deux appareils SYNC sont utilisés simultanément et l’une des réponses est communiquée en haut de la pile aux applications.

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

• Cas d’un nouveau pilote dans l’appareil et d’un nouveau pilote branché en externe : l’appareil GNSS branché en externe est utilisé.

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

Vue d’ensemble de l’interface GNSS (Global Navigation Satellite System)

L’interaction entre l’adaptateur GNSS et le pilote GNSS se situe dans les catégories suivantes :

Échange d’informations sur les capacités

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

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 (Global Navigation Satellite System)

L’adaptateur RÉINITIALISATION peut effectuer une configuration ponctuelle ou une reconfiguration périodique du pilote RÉINITIALISATION. 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 commandes 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 le redémarrage du système. À l’instar des informations sur les capacités des appareils SYNC, les commandes SYNC sont également bien définies par Microsoft dans le cadre de cette définition d’interface SYNC et continueront d’évoluer avec les innovations futures et la diversification des périphériques/pilotes SYNC.

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 la forme la plus simple, l’adaptateur GNSS demande la position actuelle de l’appareil auprès du pilote GNSS. 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 (correction d’un seul coup)

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

• Flux continu de correctifs basés sur le seuil de déplacement (suivi basé sur la distance)

Le seul type de session de position obligatoire requis par chaque matériel AUTHENTIFICATION et pilote GNSS est le type de session de correction unique. Native (implémentée dans le SOC, dans l’appareil GNSS, et non dans le pilote GNSS ou dans un service exécuté dans le processeur de l’application), les sessions de suivi basées sur le temps et les sessions de suivi basées sur la distance peuvent être prises en charge éventuellement. L’avantage main pour ces deux types de sessions de suivi natifs est l’économie d’énergie potentielle en conservant le processeur d’application (AP) en dormant plus longtemps en effectuant davantage de traitement dans le SOC et en signalant uniquement les modifications si nécessaire. La prise en charge du suivi natif basé sur la distance a plus d’impact que les sessions de suivi basées sur le temps natives, car elle peut entraîner des économies d’énergie plus élevées et parce qu’elle est plus largement utilisée par les applications.

L’opération de récupération des informations de position du pilote GNSS se produit par le biais d’une session de correctif unique avec état, composée des actions suivantes :

1. Démarrer la session de correction : L’adaptateur GNSS lance une session de correctif de démarrage (à la suite d’une demande d’une application LBS). L’adaptateur GNSS définit les exigences et les préférences spécifiques associées à la demande, et indique au pilote GNSS de 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 (données de correction) : Une fois qu’une session de correction est démarrée, l’adaptateur GNSS émet le code de contrôle IOCTL_GNSS_GET_FIXDATA de commencer à attendre un correctif à partir du pilote. Lorsqu’une nouvelle information de position est disponible à partir du moteur, le pilote GNSS répond à cette demande de correction 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 s’assure qu’une demande d’E/S asynchrone est toujours disponible pour que le pilote GNSS retourne les données de correction lorsqu’elles sont disponibles. Selon la nature du correctif, si d’autres données de correction sont attendues, l’adaptateur GNSS émet une autre demande d’E/S (à l’aide du même IOCTL) et cette séquence continue jusqu’à ce qu’aucune donnée supplémentaire 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 de sessions de correction du même type, l’adaptateur GNSS peut émettre un IOCTL_GNSS_MODIFY_FIXSESSION pour ce type de session de correction lorsqu’il effectue le multiplexage à son niveau.

4. Arrêter la session de correction : L’adaptateur GNSS émet une session de correction d’arrêt lorsqu’aucune autre information de position relative à une session de correctif 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 de IOCTL définis dans cette spécification. Un indicateur de capacité spécial est défini pour le pilote afin d’indiquer cette prise en charge. Cet indicateur ne doit être défini que si la pile GNSS prend en charge la géofencing en mode natif (autrement dit, elle implémente le géofencing dans la puce GNSS 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 la géofence basé sur le processeur d’applications (AP) sous-optimal ; Bien que cette solution ne soit pas aussi optimisée en matière d’alimentation qu’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 le point d’accès.

Le suivi des limites géographiques par le HLOS exige que le processeur de l’application se réveille régulièrement pour détecter les violations de géofence, ce qui draine l’énergie 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 géofence basé sur l’AP comme mécanisme de basculement lorsque le pilote sous-jacent n’est pas en mesure de suivre les limites géographiques en raison de conditions de faible signal ou d’autres erreurs temporaires, lors des notifications d’erreur reçues de la solution de suivi de la géofence native. La prise en charge du géorefencing natif n’est utile que lorsque le suivi de la géoréfence est entièrement déchargé dans le SoC et que le processeur d’application est réveillé uniquement pour le traitement des événements liés à la géofence. Si le matériel ne prend pas en charge le suivi de la géofence natif, le pilote GNSS ne doit pas tenter de l’implémenter au niveau de la couche pilote.

Le moteur RTC doit également exposer des paramètres de réglage spécifiques à 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 du géorefencing implique les exigences suivantes :

• Le HLOS doit être 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 doit être en mesure de supprimer une ou plusieurs limites géographiques créées précédemment via la DDI et le pilote les envoie au matériel pour arrêter leur suivi.

• Dans l’idéal, le matériel RÉINITIALISATION doit comprendre l’état initial de suivi des limites géographiques pour chaque limite géographique et l’utiliser pour signaler uniquement les modifications de cet état initial. Si le matériel RÉINITIALISATION ne prend pas en charge cette fonctionnalité, il signale l’état initial au HLOS chaque fois qu’une limite géographique est créée.

• Le matériel GNSS suit la position actuelle de l’appareil de manière efficace en matière d’alimentation et réveille le point d’accès chaque fois que l’appareil a entré et/ou quitté une limite géographique suivie. Le pilote GNSS transmet les alertes de limite géographique au HLOS.

• En cas de faible signal satellite et d’autres conditions d’erreur temporaires, le moteur GNSS peut être incapable de suivre de manière fiable les limites géographiques existantes. Le moteur MESSAGE doit être en mesure de détecter les interruptions de suivi et le pilote MESSAGE doit transmettre le suivi status alerte d’erreur au SGH. Le HLOS bascule vers le suivi géographique par défaut basé sur l’AP jusqu’à ce que le matériel GNSS soit en mesure de récupérer et de suivre à nouveau les limites géographiques.

• Les conditions exactes dans lesquelles un moteur GNSS doit fournir une notification indiquant que les limites géographiques ne peuvent pas être suivies varient et l’implémentation sera spécifique à IHV. Voici quelques instructions pour l’implémentation :

  • Si le moteur GNSS est en mesure de détecter en toute confiance que l’utilisateur ne se déplace pas et qu’il n’y a pas de limite de limite géographique à 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 confiance que l’utilisateur ne se déplace pas, mais qu’il existe une limite de limite de limite géographique à 25 mètres ou moins, le moteur GNSS doit envoyer une erreur de suivi dans un délai d’une minute.

  • Si le moteur GNSS a détecté que l’utilisateur se déplace et qu’il existe une limite de valeurs géographiques à moins de 100 mètres, le moteur GNSS doit envoyer une erreur de suivi dans un délai d’une minute ou moins.

  • Si le moteur GNSS n’est pas en mesure de déterminer si l’utilisateur se déplace et qu’il existe une limite de limites géographiques à moins de 100 mètres, le moteur GNSS doit envoyer une erreur de suivi dans un délai d’une minute ou moins.

  • Si le moteur GNSS a détecté que l’utilisateur se déplace, celui-ci doit envoyer une erreur de suivi dans un temps proportionnel à la vitesse de déplacement estimée et à la distance jusqu’à la limite géographique la plus proche. Une recommandation consiste à envoyer une erreur dans [(Distance-à-closest-fence-boundary(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 GNSS ne parvient pas à déterminer si l’utilisateur se déplace, il doit envoyer une erreur de suivi dans un temps proportionnel à la vitesse de déplacement élevée et à la distance jusqu’à la limite géographique la plus proche. Une recommandation consiste à envoyer une erreur dans [Distance-à-closest-fence-boundary(m) / 343(m/s)].

• Pendant la période où le moteur GNSS a signalé le suivi de la géoréfence status erreur, aucun événement de violation de la limite géographique ne doit être envoyé au HLOS.

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

• Les limites géographiques d’origine mobile ne sont pas conservées dans le matériel ou le pilote RÉINITIALISATION pendant le redémarrage ou le redémarrage du pilote. Le 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 ce qui concerne les interactions entre l’adaptateur GNSS et le moteur GNSS qui prend en charge le déchargement de géorefencing en mode natif, en cas d’échec du suivi des limites géographiques, l’adaptateur GNSS effectue les opérations suivantes :

• Il utilise le suivi basé sur un point d’accès une fois que le pilote GNSS retourne l’échec à suivre.

• Il continuera d’envoyer au pilote toutes les mises à jour (ajout/suppression) dans les limites géographiques actuellement suivies au niveau du système d’exploitation vers le pilote afin 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 il peut effectuer un suivi/ne peut pas suivre la détermination en fonction des nouvelles données.

• Il envoie (push) les modifications d’état de limite géographique telles que déterminées par le tracker basé sur l’AP une fois que le pilote GNSS renvoie success dans sa capacité à effectuer le suivi.

Notifications de pilote pour les données d’assistance et d’assistance

De temps à autre, le pilote GNSS peut avoir besoin de données d’assistance ou d’actions d’assistance de la part de l’adaptateur GNSS. Cela inclut les différentes formes de données AGNSS (injection de temps, éphémérides, position grossière initiale), la fenêtre contextuelle de consentement de l’utilisateur pour la prise en charge du positionnement du plan utilisateur initié par le réseau, et ainsi de suite.

• 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 d’emplacements Microsoft se chargera d’établir les connexions de données et de respecter les contraintes d’itinérance, les préférences de données, l’intégration en mode silencieux réseau, etc.

  • 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, ce qui évite à IHV de déployer un service d’assistance front-end dans le monde entier qui répond 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 appartiennent au système d’exploitation. Par conséquent, toute interface utilisateur qui informe l’utilisateur d’une demande d’emplacement lancée par le réseau ou toute interface utilisateur pour demander le consentement de l’utilisateur pour répondre à une demande d’emplacement lancée par le réseau appartient à Microsoft. Le pilote GNSS notifiera l’adaptateur GNSS lorsqu’une demande d’emplacement lancée par le réseau est reçue et, si nécessaire, il attendra la réponse de l’utilisateur jusqu’à l’heure par défaut avant de continuer à exécuter la demande.

Étant donné que le pilote GNSS n’est pas en mesure d’initier une requête à la couche supérieure par lui-même, ce type d’opérations peut être effectué par l’adaptateur AUTHENTIFICATION en recherchant de manière proactive une telle demande auprès du pilote GNSS et par conséquent en conservant toujours un ou plusieurs IRP en attente afin que le pilote AUTHENTIFICATION puisse répondre à ces demandes en attente. À la réception de la date de demande d’assistance/d’assistance, l’adaptateur RTC extrait les données (ou exécute l’action spécifique pour le compte du pilote RTC), puis injecte les informations nécessaires au pilote RTC par le biais d’un autre appel DeviceIoControl .

La notification du pilote est gérée via un modèle d’événement commun. Par exemple, pour l’assistance GNSS, l’adaptateur GNSS utilise le code de 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 pose des problèmes 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 status. L’adaptateur utilise le code de contrôle IOCTL_GNSS_LISTEN_GEOFENCE_ALERT pour recevoir des alertes de géoréfence individuelles et IOCTL_GNSS_LISTEN_GEOFENCES_TRACKINGSTATUS pour recevoir les modifications apportées à la status globale du suivi des limites géographiques.

Journalisation des pilotes du Global Navigation Satellite System (GNSS)

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

Le pilote ne doit pas enregistrer d’informations, lisibles par l’homme ou autrement, autres que par le biais de cette technique de journalisation prescrite. Pour plus d’informations, consultez 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 consigne 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 du fichier journal en un formulaire lisible par l’utilisateur. Toutefois, le suivi logiciel WPP prend en charge les formats de message plus performants 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 d’opérateur mobile

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

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

Tous les éléments d’implémentation sont abstraits 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, le fonctionnement des protocoles, l’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/moteur GNSS ou le pilote GNSS, ou, si nécessaire, dans 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 RTC nécessite le Wi-Fi résultats de l’analyse pour répondre à un message de protocole SUPL spécifique, il peut le faire en faisant en sorte qu’une extension en mode utilisateur injecte les résultats de l’analyse Wi-Fi au pilote via un appel IOCTL privé, ou en faisant cette partie du pilote UMDF 2.0, ou en gérant cette interaction à un niveau inférieur. Les composants HLOS de Microsoft GNSS sont inconscients de ces interactions entre les composants de la pile GNSS IHV.

En résumé, iHV ou 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 GNSS. Toutes les interactions de la plateforme de localisation avec le client SUPL sont effectuées via le DDI GNSS.

Pour faciliter l’implémentation des protocoles de l’opérateur mobile et réduire la charge du développement logiciel à l’aide de technologies spécifiques à la plateforme, l’adaptateur GNSS fournit certaines fonctionnalités à la pile GNSS IHV. Le pilote GNSS est traité comme l’intermédiaire pour la réception de ces fonctionnalités à partir des composants HLOS, par exemple, l’adaptateur GNSS interagit uniquement avec le pilote GNSS et non avec toute autre partie de la pile GNSS IHV. Les IOCTL du pilote GNSS définissent la syntaxe et la sémantique de ces fonctionnalités 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 d’opérateur mobile. Dans l’ensemble, l’adaptateur GNSS fournit les fonctionnalités suivantes au pilote GNSS :

1. Configuration: Les opérateurs mobiles approvisionnent l’appareil et modifient la configuration à l’aide du mécanisme de configuration imposé par les normes de protocole OMA. Par exemple, la norme SUPL exige que la configuration SUPL soit effectuée en fonction de l’UICC et/ou qu’elle 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 sur d’autres plateformes avant Windows 10. À compter de Windows 10 toutes les plateformes peuvent prendre en charge la configuration SUPL via le fournisseur de services de configuration SUPL (CSP), dans la mesure où le nouveau DDI GNSS est utilisé. L’approvisionnement injecté via le CSP 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 LE CSP SUPL.

   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 solutions cloud pour l’utilisation de la configuration OMA et l’envoi de la configuration au pilote GNSS via l’adaptateur GNSS.

   L’IHV peut également écrire un composant en mode utilisateur pour utiliser 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’AVS et non recommandé.

   Une seule configuration SUPL est prise en charge dans un système, y compris dans le cas d’appareils double SIM. Microsoft fournit les fonctionnalités permettant de reconfigurer SUPL en fonction de l’UICC et de la modification de l’UICC. En outre, en cas d’itinérance de l’appareil, le HLOS reconfigure le client SUPL pour qu’il fonctionne en mode autonome. Ce document définit les IOCTL permettant d’envoyer de telles données de configuration pour divers protocoles d’opération mobiles (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 lancées par le réseau nécessitent le consentement de l’utilisateur. Les IHVs ne sont pas autorisés à écrire l’interface utilisateur pour les 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 IOCTLs de notification pour que le pilote GNSS demande une fenêtre contextuelle d’interface utilisateur, et les IOCTLs pour l’adaptateur AUTHENTIFICATION pour transmettre la réponse de l’utilisateur à une telle demande sont définis dans les IOCTL des pilotes 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 IHVs peuvent exploiter pour implémenter leur client SUPL :

Aucune de ces fonctionnalités ne fait partie de la plateforme d’emplacement ou de la DDI GNSS, mais elle est incluse ici à des fins de clarification et pour aider les développeurs de pilotes GNSS à comprendre ce qui peut être exploité à partir du système d’exploitation pour implémenter la fonctionnalité SUPL.

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

• Gestionnaire des connexions possibilité de configurer la connexion qui doit être utilisée pour le SUPL et les API pour demander une telle connexion : les opérateurs mobiles peuvent avoir besoin d’avoir 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, Gestionnaire des connexions propose :

  • Un fournisseur de services de configuration que l’OEM ou l’opérateur mobile peut utiliser pour configurer la connexion à utiliser pour les communications SUPL.

  • API permettant au client SUPL d’interroger les paramètres de connexion de la connexion SUPL.

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

• Configuration de la connexion cellulaire : Pour configurer les paramètres de 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 Gestionnaire des connexions à l’objectif SUPL.

• Demande de maintenir les connexions actives pendant qu’une connexion SUPL est en cours : Le client SUPL peut avoir besoin d’initier des connexions avec le HSLP pendant que le système est en veille connectée. Cela peut se produire parce que l’appareil GNSS a besoin d’obtenir des informations d’assistance lorsqu’il est configuré pour utiliser le positionnement basé sur Microsoft ou parce que l’opérateur mobile a envoyé une requête NI. Si tel est le cas, le client SUPL doit lancer une connexion avec le HSLP et s’assurer que la connexion est active jusqu’à ce que la session SUPL soit terminée.

• Interactions avec le module Mobile Broadband (MBB) : Dans Windows 10, aucune API n’est disponible via le HLOS pour récupérer des mesures cellulaires, savoir quand un appel d’urgence a été placé, etc. Toute interaction avec le MBB doit être effectuée via une intégration directe avec le MBB (via des commandes AT ou une autre méthode propriétaire).

Tests de fabrication

Les OEM doivent disposer d’un moyen de vérifier au moment de la fabrication et aux points de support client que le matériel GNSS et la pile GNSS (le pilote GNSS et le périphérique/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 à l’OEM d’initier des tests de fabrication et d’obtenir des résultats.

L’infrastructure de localisation sera contournée lors des tests de fabrication, étant donné que l’accent est mis sur la validation matérielle ou la validation des pilotes. En général, l’appareil se trouve en mode « système d’exploitation sans échec » spécial 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éclenchent des cas de test. Pour plus d’efficacité et de rapidité pendant la fabrication, il est vivement souhaitable d’avoir la prise en charge de la concurrence pour les tests au sein de différents composants.

L’interface pour les tests de fabrication comprend deux types de tests :

1. Test d’onde de porteur : Ce test consiste à valider le test de connectivité externe/d’antenne. Dans ce test, le moteur RTC doit rechercher un signal CW et fournir les mesures SNR (rations signal to noise ou carrier to noise rations) dans la réponse. Dans l’idéal, les tests doivent fournir des réponses à 10 Hz.

2. Auto-test : Ce test vise à 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 GNSS sans nécessiter d’injection de signal externe. L’objectif de cette validation est d’effectuer 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 RÉINITIALISATION effectuent une validation automatique pour les connexions de broche et retournent un code status indiquant que tout va bien ou qu’une défaillance s’est produite. Le code d’erreur des é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é AUTHENTIFICATION ne correspond pas aux demandes de lecture et d’écriture de fichiers traditionnelles aux pilotes de périphérique, les fonctions ReadFile et WriteFile ne sont pas utilisées pour les API de pilote GNSS. Toutes les fonctionnalités GNSS seront implémentées à l’aide de demandes de contrôle d’E/S d’appareil (DeviceIoControl) bien définies, également appelées IOCTL.

Toutes les IOCTL utiliseront 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 GNSS est ouvert à l’aide de l’option FILE_FLAG_OVERLAPPED dans la fonction CreateFile . Par conséquent, toutes les IOCTL sont implicitement asynchrones. Toutefois, alors que la plupart des IOCTL SYNCHRO sont sémantiquement asynchrones (par exemple, un IOCTL déclenche une activité au sein du pilote et que les résultats sont attendus de manière asynchrone), certaines IOCTL sont sémantiquement synchrones dans le sens où il n’y a aucune action asynchrone logique ou activité impliquée avec ces IOCTL. Le comportement synchrone de ces quelques IOCTL sera obtenu en bloquant le thread de l’adaptateur RTC après l’émission de l’appel DeviceIoControl jusqu’à ce que l’opération d’E/S soit terminée. Par conséquent, il est de la responsabilité du pilote GNSS de toujours effectuer l’IRP dans le cadre du traitement de toutes les IOCTL. L’adaptateur RTC 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 renvoyer une erreur.

Pour les opérations de requête et de réponse, l’adaptateur GNSS conserve toujours une opération d’E/S en attente disponible afin que lorsque le pilote GNSS a des 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 de tir unique

Une demande de correctif de démarrage pour un correctif de tir unique au pilote inclut les 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 à renvoyer tous 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 lors du calcul d’un correctif qui répond aux exigences de précision ou qui est final. La fréquence de ces correctifs intermédiaires n’est pas appliquée et constitue un détail d’implémentation du moteur. L’adaptateur GNSS s’attend à ce que les correctifs arrivent toutes les quelques secondes et ils doivent être différents du dernier correctif intermédiaire.

Une fois que le moteur GNSS a déterminé qu’il ne peut pas obtenir un meilleur correctif dans les conditions de signal actuelles, il doit retourner un correctif final et doit 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 GNSS émet un correctif d’arrêt pour une session unique dans l’un des deux cas :

• Il obtient un correctif final du pilote.

• Le temps de réponse de la demande est 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 d’exactitude et de temps de réponse. Après la commande start fix, le pilote a commencé à envoyer des correctifs intermédiaires. Après un certain temps, il a déterminé qu’il ne pouvait pas retourner un correctif plus précis. Il a donc indiqué le dernier correctif comme final. Cela s’est produit avant que la limite de temps de réponse ne soit atteinte. L’adaptateur a envoyé le correctif final à l’application et a émis une commande stop fix.

Session 2 : Identique à la session 1 ci-dessus, mais dans ce cas, le moteur a continué à obtenir un meilleur correctif pour répondre à l’exigence de précision et a continué à 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.

Un aspect de conception important à prendre en compte lors de l’implémentation de la prise en charge de la prise en charge d’un plan unique est que, si les sessions de suivi basées sur les distances et les sessions de suivi basées sur le temps ne sont pas prises en charge, le moteur AUTHENTIFICATION continue de suivre les satellites pendant 3 à 5 secondes après avoir reçu une commande stop fix. Cela est dû au fait que l’adaptateur SYNC doit implémenter des sessions de suivi basées sur la distance simulées et/ou des sessions de suivi basées sur le temps à l’aide de sessions de correction à un seul coup, et si le moteur SYNC arrête immédiatement le suivi des satellites, la plupart des appareils SYNC auront un retard lors de l’acquisition, ce qui rend impossible l’implémentation d’une session de suivi simulée qui répond aux besoins de la navigation, exécuter des applications de suivi ou de mappage.

L’adaptateur GNSS peut lancer des demandes de correctifs de tir unique lorsque le système est en veille connectée, et 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 de l’application ou d’autres cas. Le pilote GNSS doit être en mesure de transmettre ces demandes de session au périphérique GNSS et de répondre à la demande ou de fournir une erreur à l’adaptateur GNSS.

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

La description de la séquence est la suivante :

1. L’adaptateur SYNC ouvre le pilote SYNC à l’aide de l’API CreateFile . WDF/KMDF/UMDF effectue les rappels facultatifs nécessaires au pilote RTC. 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 la plateforme au pilote. Le pilote GNSS termine l’opération d’E/S.

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

4. L’adaptateur GNSS émet des IOCTL 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 un IOCTL_GNSS_START_FIXSESSION, ainsi que les paramètres spécifiant le type et d’autres aspects du correctif. À la réception de ce IOCTL, le pilote GNSS interagit avec l’appareil sous-jacent pour commencer à recevoir des correctifs, puis termine l’opération d’E/S.

6. L’adaptateur GNSS émet un IOCTL_GNSS_GET_FIXDATA et attend la fin de l’E/S. Chaque fois que le pilote GNSS a un correctif intermédiaire disponible, 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 AUTHENTIFICATION indique qu’aucun autre correctif n’est attendu (correctif final reçu).

8. L’adaptateur GNSS pose des problèmes IOCTL_GNSS_STOP_FIXSESSION. Le pilote GNSS effectue l’opération de nettoyage nécessaire associée à la demande de correctif d’origine.

9. L’adaptateur SYNC ferme le handle de fichier de pilote à l’aide de l’API CloseHandle .

Les IOCTL 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 des utilisateurs finaux, car 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 correctifs au taux le plus élevé possible.

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

Une demande de correctif de démarrage adressée au conducteur pour une session de suivi de distance inclura la précision horizontale souhaitée et le seuil de déplacement, qui est la distance haversine en mètres que le système doit couvrir avant que le pilote GNSS ne fournisse une mise à jour de position. Le moteur GNSS 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 case activée pour l’emplacement.

Une fois qu’une demande de correctif de démarrage est reçue par le pilote, il doit commencer à retourner tous les correctifs intermédiaires générés par le moteur, jusqu’à ce qu’il obtienne un correctif final. Il s’agit de la première position de la session. Après cela, le moteur RECOMH doit commencer à fournir des correctifs chaque fois qu’il détecte que la distance de haversine a été approximativement couverte.

Si le moteur TRUI 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 PAA afin que la plateforme de localisation puisse revenir à d’autres mécanismes pour fournir des mises à jour de position à l’application de l’utilisateur final. L’adaptateur GPS doit fournir une erreur dans le délai suivant :

[(Distance-restante-depuis la dernière position connue (m) / vitesse estimée (m/s)) – 5 secondes] ou 5 secondes, selon la plus grande.

Si le moteur RDP a fourni une erreur à l’adaptateur RECOM, mais que celui-ci n’a pas encore arrêté la session de suivi, il doit continuer à case activée, de manière optimisée, s’il peut reprendre l’emplacement de suivi. L’IHV peut utiliser des optimisations pour effectuer cette détection à faible consommation. Les techniques courantes d’optimisation sont les suivantes :

• Arrêt progressif

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

• Contrôles de faible puissance pour le signal satellite

Une fois que le moteur ENTEMENT est en mesure de fournir à nouveau un correctif final après une condition d’erreur, il doit envoyer cette position à l’adaptateur ENTEMENT pour indiquer que le suivi a repris avec succès.

L’adaptateur RDP émet une commande modify fix 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 RECALCUL calcule les nouveaux paramètres de session agrégés requis pour multiplexer les différentes sessions actives et met à jour le pilote RECALCUL avec ces paramètres.

L’adaptateur GPS émet une commande stop fix 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 : Des paramètres de seuil de précision et de mouvement ont été attribués au pilote GPS lors du lancement de la session de suivi. Après la commande start fix, 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 à partir duquel ce correctif est fourni à l’adaptateur JDBC et que le moteur JDBC démarre le processus de suivi à distance. Pendant que la session est active, l’adaptateur ODA envoie une demande de modification des paramètres de session aux fois T1 et T2. Après chaque modification des paramètres, le pilote CUMULATIVE envoie une mise à jour de correctif à l’adaptateur CUMULATIVE et reprend la session de suivi à distance avec les nouveaux paramètres, jusqu’à ce que l’adaptateur ODA envoie une commande stop fix.

Session 2 : Le processus d’initiation de session est similaire à la session 1 ci-dessus, mais à un moment donné, le moteur BOUT N’est pas en mesure de suivre la position. Après un temps qui dépend de la distance et de la vitesse estimée du mouvement, le pilote ESTIMAT envoie une erreur. Le moteur GPS continue à case activée à plus faible puissance lorsqu’il peut récupérer, et lorsqu’il récupère, il l’indique à l’adaptateur AUTHENTIFICATION en envoyant un nouveau correctif. La session est mise à jour avec de nouveaux correctifs en fonction des besoins jusqu’à ce que l’adaptateur BOUTA envoie une commande stop fix.

L’adaptateur 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 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 RDP doit être en mesure de transmettre ces demandes de session à l’appareil JDBC et de satisfaire la demande ou de fournir une erreur à l’adaptateur JDBC.

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, les cartes, les applications de navigation, etc.).

L’adaptateur ZIM démarre des sessions de suivi basées sur le temps avec le pilote CONFIG, uniquement si le plus tard indique qu’il dispose de la capacité SupportContinuousTracking.

Une demande de correctif de démarrage au pilote pour une session de suivi basée sur le temps inclut la précision horizontale souhaitée et l’intervalle de temps préféré auquel le pilote CUMULATIVE doit fournir une mise à jour de position. Le moteur CUMULATIVE peut utiliser ces valeurs pour comprendre l’intention de la demande d’application et prendre des décisions intelligentes, comme adapter la fréquence à laquelle case activée pour 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 tous les correctifs intermédiaires générés par le moteur, jusqu’à ce qu’il obtienne un correctif final. Il s’agit de la première position de la session. Après cela, le moteur RDP doit commencer à fournir des correctifs à l’intervalle requis par les paramètres de session. Si le moteur BOUT N’est pas en mesure de fournir des positions à la fréquence requise par l’application, il doit fournir des correctifs à la vitesse maximale qu’il peut.

Si le moteur PAA 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 PAA afin que la plateforme d’emplacement puisse revenir à d’autres mécanismes pour fournir des mises à jour de position à l’application de l’utilisateur final.

Si le moteur RDP a fourni une erreur à l’adaptateur RECOM, mais que celui-ci n’a pas encore arrêté la session de suivi, il doit continuer à case activée, de manière optimisée, s’il peut reprendre l’emplacement de suivi.

L’IHV peut utiliser des optimisations pour effectuer cette détection à faible consommation, comme expliqué dans la section précédente. Une fois que le moteur ENTEMENT est en mesure de fournir à nouveau un correctif final après une condition d’erreur, il doit envoyer cette position à l’adaptateur ENTEMENT pour indiquer que le suivi a repris avec succès.

L’adaptateur RDP émet une commande modify fix pour une session de suivi basée sur le temps 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 le temps. Dans ce cas, l’adaptateur RECALCUL calcule les nouveaux paramètres de session agrégés requis pour multiplexer les différentes sessions actives et met à jour le pilote RECALCUL avec ces paramètres.

L’adaptateur RDP émet une commande stop fix pour une session de suivi basée sur le temps 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 le temps.

Session 1 : La précision et un paramètre d’intervalle préférés ont été attribués au pilote RDP lors du lancement de la session de suivi. Après la commande de correction de démarrage, le pilote doit commencer à envoyer des correctifs intermédiaires jusqu’à ce qu’il obtienne un correctif final ou un correctif répondant à l’exigence de précision à partir duquel ce correctif est fourni à l’adaptateur JDBC et que le moteur JDBC démarre le processus de suivi basé sur le temps. Pendant que la session est active, l’adaptateur ODA envoie une demande de modification des paramètres de session aux fois T1 et T2. Après chaque modification des paramètres, le pilote CUMULATIVE envoie une mise à jour de correctif à l’adaptateur CUMULATIVE et reprend la session de suivi basée sur le temps, avec les nouveaux paramètres, jusqu’à ce que l’adaptateur JDBC envoie une commande stop fix.

Session 2 : Le processus d’initiation de session est similaire à celui de la session 1 ci-dessus, mais à un moment donné, le moteur DOCKER cesse de pouvoir suivre la position. Lorsque le moteur RDP n’est pas en mesure de fournir un correctif dans les 15 secondes suivant l’intervalle requis par les paramètres de session, le pilote GPS envoie une erreur. Le moteur GPS continue à case activée à plus faible puissance lorsqu’il peut récupérer, et lorsqu’il récupère, il l’indique à l’adaptateur AUTHENTIFICATION en envoyant un nouveau correctif. La session est mise à jour avec de nouveaux correctifs en fonction des besoins jusqu’à ce que l’adaptateur BOUTA envoie une commande stop fix.

L’adaptateur ORÉAL peut rester actif ou même lancer des sessions de suivi basées sur le temps pendant que 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 RDP doit être en mesure de transmettre ces demandes de session à l’appareil JDBC et de satisfaire la demande ou de fournir une erreur à l’adaptateur JDBC.

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

Certains moteurs GPS avancés peuvent être en mesure de gérer simultanément une session Single Shot, avec une Distance-Based et/ou une session de suivi Time-Based. Dans l’idéal, les sessions indépendantes ne doivent pas s’influencer mutuellement, mais cela n’est pas toujours possible, en particulier dans le cas de sessions simultanées de tir unique et de suivi temporel. Cette section fournit des instructions pour l’implémentation d’IHV pour le cas où des compromissions doivent être effectuées pour gérer des sessions simultanées de différents types.

Les acronymes suivants sont utilisés dans cette section :

• SS: Session single shot

• DBT: Session de suivi basé sur la distance

• TBT : session de suivi basé sur le temps

• TBF: Temps entre les correctifs

Le tableau suivant fournit quelques scénarios permettant de gérer simultanément des sessions de suivi basées sur une seule capture et basées sur le temps :

Cas	SS active ?	TbT actif ?	Détails de l’incident	Intervalle acceptable de correctifs	Commentaires
1	X	X	Session SS en cours au moment de la session périodique TBT démarrée avec le délai d’expiration >restant = intervalle	Identique à l’intervalle TBT	Comportement de la session SS : Les correctifs intermédiaires et finaux sont envoyés jusqu’au délai d’expiration. Session fermée immédiatement après la réception de l’arrêt. Comportement de session TBT : Les correctifs intermédiaires et finaux sont envoyés. Correctifs reçus approximativement selon l’intervalle. Session fermée immédiatement après la réception de l’arrêt.
2	X	X	Session SS en cours au moment de la session périodique TBT démarrée avec l’intervalle de délai d’expiration < restant	L’intervalle reste le même que le délai d’expiration SS, jusqu’à ce que la session SS soit satisfaite. Ensuite, l’intervalle peut être mis à jour pour être identique à l’intervalle TBT.	Comportement de la session SS : Les correctifs intermédiaires et finaux sont envoyés jusqu’au délai d’expiration. Session fermée immédiatement après la réception de l’arrêt. Comportement de session TBT : Les correctifs intermédiaires et finaux sont envoyés Les correctifs reçus approximativement selon l’intervalle, mais peuvent être plus fréquents pendant que la session SS est servie. Session fermée immédiatement après la réception de l’arrêt.
3	X	X	Session SS démarrée alors qu’une session périodique TBT est en cours démarrée avec délai d’expiration >= intervalle	Identique à l’intervalle TBT	Comportement de la session SS : Les correctifs intermédiaires et finaux sont envoyés jusqu’au délai d’expiration. Session fermée immédiatement après la réception de l’arrêt. Comportement de session TBT : Les correctifs intermédiaires et finaux sont envoyés Correctifs reçus approximativement selon l’intervalle. Session fermée immédiatement après la réception de l’arrêt.
4	X	X	Session SS démarrée alors qu’une session périodique TBT est en cours démarrée avec un intervalle de délai d’expiration <	L’intervalle change pour être identique au délai d’expiration SS, jusqu’à ce que la session SS soit satisfaite. Ensuite, l’intervalle peut être mis à jour pour être identique à l’intervalle TBT.	Comportement de la session SS : Les correctifs intermédiaires et finaux sont envoyés jusqu’au délai d’expiration. Session fermée immédiatement après la réception de l’arrêt. Comportement de session TBT : Les correctifs intermédiaires et finaux sont envoyés. Les correctifs reçus approximativement selon l’intervalle, mais peuvent être plus fréquents pendant que la session SS est servie. Session fermée immédiatement après la réception de l’arrêt.
5		X	Session périodique TBT démarrée avec l’intervalle modifié	La session avec modem est mise à jour vers le nouvel intervalle pour être identique à l’intervalle TBT. Si nécessaire, la session du modem est redémarrée.	Comportement de la session SS : Non applicable Comportement de session TBT : Les correctifs intermédiaires et finaux sont envoyés. Correctifs reçus approximativement selon l’intervalle. Session fermée immédiatement après la réception de l’arrêt.
6	X	X	Session SS en cours à l’heure à laquelle une session périodique à tbT en cours reçoit une modification d’intervalle, avec délai d’expiration >restant = intervalle	Identique à l’intervalle TBT	Comportement de la session SS : Les correctifs intermédiaires et finaux sont envoyés jusqu’au délai d’expiration. Session fermée immédiatement après la réception de l’arrêt. Comportement de session TBT : Les correctifs intermédiaires et finaux sont envoyés Correctifs reçus approximativement selon l’intervalle. Session fermée immédiatement après la réception de l’arrêt.
7	X	X	Session SS en cours à l’heure à laquelle une session périodique à tbT en cours reçoit une modification de l’intervalle, avec l’intervalle de délai d’expiration < restant	L’intervalle change pour être identique au délai d’expiration restant de SS, jusqu’à ce que la session SS soit satisfaite. Ensuite, l’intervalle peut être mis à jour pour être identique à l’intervalle TBT.	Comportement de la session SS : Les correctifs intermédiaires et finaux sont envoyés jusqu’au délai d’expiration. Session fermée immédiatement après la réception de l’arrêt./li> Comportement de session TBT : Les correctifs intermédiaires et finaux sont envoyés Les correctifs reçus approximativement selon l’intervalle, mais peuvent être plus fréquents pendant que la session SS est servie. Session fermée immédiatement après la réception de l’arrêt.

S’il existe à la fois 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 peut être défini pour fonctionner avec le plus petit des deux. Le tableau suivant fournit également quelques recommandations pour le cas de valeurs disparates pour la précision requise lorsqu’il existe simultanément des sessions de suivi et de tir unique :

Cas	Précision SS	Précision DBT ou TBT	Précision globale du moteur BOUT	Commentaires
1	Moyen/faible --> Élevé	Non applicable	Moyen/faible --> Élevé	Comportement de la session SS : La session avec l’appareil RECOM est actualisée ou redémarrée pour obtenir un résultat de haute précision. Des correctifs intermédiaires sont fournis au HLOS dès qu’ils sont disponibles.
2	Élevé --> Moyen/Faible	Non applicable	Élevé --> Moyen/Faible	Comportement de la session SS : La session avec l’appareil RDP est actualisée ou redémarrée pour obtenir un résultat de précision moyenne/faible. Si un correctif répondant aux exigences est déjà disponible, il est retourné en tant que correctif final. Sinon, des correctifs intermédiaires sont fournis au HLOS dès qu’ils sont disponibles.
3	Moyen/faible --> Élevé	Élevé	Élevé	Comportement de la session SS : Étant donné qu’une session de haute précision existe déjà pour la session DBT ou TBT, la session SS fournit simplement des correctifs intermédiaires supplémentaires au HLOS jusqu’à ce que la précision finale souhaitée soit obtenue ou qu’un correctif final soit obtenu.
4	Élevé --> Moyen/Faible	Élevé	Élevé	Comportement de la session SS : Étant donné qu’une session de haute précision existe déjà pour la session DBT ou TBT, la session SS fournit simplement des correctifs intermédiaires supplémentaires au HLOS jusqu’à ce que la précision finale souhaitée soit obtenue ou qu’un correctif final soit obtenu.
5	Moyen/faible --> Élevé	Moyen/faible	Moyen/Faible :> élevé, puis retour à moyen/faible une fois la session SS terminée	Comportement de la session SS : La session avec un appareil GNSS est actualisée ou redémarrée pour obtenir un résultat de haute précision. Des correctifs intermédiaires sont fournis au HLOS dès qu’ils sont disponibles. Comportement de session DBT ou TBT : Cette session peut recevoir temporairement des résultats de haute précision. Toutefois, une fois la session SS traitée, la précision de cette session doit revenir à Moyen/Faible.
6	Élevé --> Moyen/Faible	Moyen/faible	Élevé --> Moyen/Faible	Comportement de la session SS : La session avec un appareil GNSS est actualisée ou redémarrée pour obtenir un résultat de précision moyenne ou faible. Si un correctif répondant aux exigences est déjà disponible, il est retourné en tant que correctif final. Sinon, des correctifs intermédiaires sont fournis au HLOS dès qu’ils sont disponibles.
7	Non applicable	Moyen/faible --> Élevé	Moyen/faible --> Élevé	b>Comportement de la session DBT ou TBT :** La session avec appareil GNSS est actualisée ou redémarrée pour obtenir des résultats de haute précision. Des correctifs intermédiaires sont fournis au HLOS dès qu’ils sont disponibles.
8	Non applicable	Élevé --> Moyen/Faible	Élevé --> Moyen/Faible	Comportement de session DBT ou TBT : La session avec un appareil GNSS est actualisée ou redémarrée pour obtenir un résultat de précision moyenne ou faible. Si un correctif répondant aux exigences est déjà disponible, il est retourné en tant que correctif final. Sinon, des correctifs intermédiaires sont fournis au HLOS dès qu’ils sont disponibles.
9	Élevé	Moyen/faible --> Élevé	Élevé	Comportement de session DBT ou TBT : La session recevait déjà des correctifs de haute précision ou des correctifs intermédiaires, donc aucune modification.
10	Élevé	Élevé --> Moyen/Faible	Élevé, puis passe à Moyen/Faible une fois la session SS terminée	Comportement de session DBT ou TBT : La session peut continuer à obtenir des correctifs de haute précision ou des correctifs intermédiaires, jusqu’à ce que la session SS soit terminée. Ensuite, il doit passer à des correctifs de précision moyenne/faible.
11	Moyen/faible<	Moyen/faible --> Élevé	Moyen/faible --> Élevé	Comportement de session DBT ou TBT : La session avec un appareil GNSS est actualisée ou redémarrée pour obtenir des résultats de haute précision. Des correctifs intermédiaires sont fournis au HLOS dès qu’ils sont disponibles.
12	Moyen/faible	Élevé --> Moyen/Faible	Élevé --> Moyen/Faible	Comportement de session DBT ou TBT : La session avec un appareil GNSS est actualisée ou redémarrée pour obtenir un résultat de précision moyenne ou faible. Si un correctif répondant aux exigences est déjà disponible, il est retourné en tant que correctif final. Sinon, des correctifs intermédiaires sont fournis au HLOS dès qu’ils sont disponibles.