Arquitetura dos controladores do Sistema Global de Navegação por Satélite (GNSS)

Fornece uma visão geral da arquitetura de driver UMDF 2.0 do Sistema Global de Navegação por Satélite (GNSS), considerações de E/S e discute vários tipos de sessões de rastreamento e correção.

Visão geral da arquitetura

O diagrama de blocos de componentes de alto nível a seguir mostra como o driver UMDF 2.0 do Sistema Global de Navegação por Satélite (GNSS) se integra à plataforma Windows 10.

Os componentes no diagrama são descritos aqui:

• Aplicação LBS: Um aplicativo de usuário que usa a funcionalidade de localização da plataforma Windows 10

• Aplicação do teste: Uma aplicação para testar a funcionalidade GNSS.

• API GNSS: A interface IGnssAdapter COM (Component Object Model) que expõe a funcionalidade do dispositivo GNSS aos componentes internos do serviço de localização, bem como às aplicações de teste. A forma exata desta API está fora do escopo deste documento. Os componentes do Windows utilizam o dispositivo GNSS programando contra a interface COM IGnssAdapter. O conjunto de API do GNSS é uma API privada apenas para componentes da plataforma de localização (por exemplo, o serviço de localização e as aplicações de teste de localização) e não está disponível para outras aplicações próprias ou de terceiros.

• Adaptador GNSS: Este é um objeto COM singleton que implementa a interface COM IGnssAdapter . Aplicativos de teste e componentes internos do serviço de localização instancia esse objeto e usa o dispositivo GNSS através da interface IGnssAdapter . O componente do mecanismo de posicionamento GNSS do serviço de localização implementa a classe COM que expõe a interface IGnssAdapter . O serviço de localização expõe um mecanismo de fábrica para testar e outros aplicativos fora de processo para instanciar um objeto COM singleton da classe COM do adaptador GNSS dentro do serviço de localização. Aplicações fora do processo usam o ponteiro da interface COM para interagir com o driver GNSS.

  COM manipula o ponteiro de interface proxy para as aplicações fora do processo para que as aplicações tratem o ponteiro de interface do IGnssAdapter como um objeto COM em processo, mas as chamadas são realmente tratadas pelo objeto adaptador GNSS único dentro do serviço de localização.

  O mecanismo de posicionamento GNSS usa o objeto do adaptador GNSS interno para fornecer funcionalidade específica de localização ao serviço de localização. O adaptador GNSS abre um identificador de arquivo para o driver GNSS usando a API CreateFile e, em seguida, encapsula as chamadas de APIs nativas do GNSS em chamadas DeviceIoControl apropriadas, mantém a máquina de estado com o objeto de driver GNSS e mantém o estado das várias solicitações de entrada das camadas superiores. Este componente interage diretamente com a pilha de dispositivos GNSS subjacente através da interface pública GNSS IOCTL definida no presente documento. O dispositivo GNSS é logicamente tratado como um recurso exclusivo e, portanto, o adaptador GNSS singleton controla todo o acesso ao dispositivo GNSS.

  Certos aplicativos de teste de driver de caixa branca também podem usar a interface IOCTL do driver GNSS diretamente em um ambiente de não produção, em vez de usar o adaptador GNSS por meio das APIs privadas do GNSS. No entanto, essas aplicações de teste terão que implementar sua própria máquina de estado e processamento para imitar certas funcionalidades do adaptador GNSS.

• Condutor GNSS: Um driver fornecido por IHV implementado usando UMDF 2.0. O driver GNSS suporta as APIs DeviceIoControl ao interagir com o hardware GNSS efetivo. O condutor GNSS funciona também como mediador/integrador das funções SUPL.

• Dispositivo/motor GNSS: Este é um componente conceitual que encapsula o SoC e peças de hardware do dispositivo GNSS. Um IHV pode optar por implementar a maior parte da funcionalidade GNSS dentro deste componente, tornando assim a camada de driver GNSS muito fina (essencialmente um adaptador para interface com o dispositivo GNSS).

Suporte para dispositivos e drivers do Sistema Global de Navegação por Satélite (GNSS) que seguem o modelo herdado do Windows

A plataforma de localização no Windows 10 suporta dispositivos GNSS integrados através do driver de classe Sensors v1.0 herdado (consulte Escrevendo um driver de sensor de localização) ou integrado através do novo GNSS DDI descrito na referência do driver GNSS.

Portanto, espera-se que os dispositivos Windows com um dispositivo GNSS que se integram com o modelo de extensão de classe Sensor v1.0 que existia no Windows 7, Windows 8 e Windows 8.1 continuem funcionando no Windows 10 sem a necessidade de alterações. É altamente recomendável que esses drivers (e quaisquer novos drivers) sejam publicados no Windows Update para melhorar o processo de atualização para nossos usuários.

Também haverá dois conjuntos diferentes de testes para dispositivos GNSS no Hardware Lab Kit (HLK) emitido com o Windows 10:

• Um novo conjunto de testes para certificar os condutores seguindo o novo modelo.

• Mais um conjunto de testes para certificar os condutores seguindo o modelo antigo. Estes serão o mesmo conjunto de testes que estavam disponíveis no WHCK no Windows 8.1.

Um novo componente coletor no HLK identifica qual dos dois conjuntos de testes precisa ser executado em um sistema, se houver.

Coexistência de dispositivos do Sistema Global de Navegação por Satélite (GNSS)

No caso raro de vários dispositivos GNSS detetados em um sistema, a plataforma de localização usará apenas um dispositivo, principalmente para reduzir o consumo geral de energia no sistema. Foram considerados os seguintes pressupostos:

• Os dispositivos que usam o novo DDI provavelmente serão mais novos e, portanto, mais propensos a ter melhor consumo de energia, suportar mais constelações e suportar melhor assistência. Portanto, se um dispositivo usando o modelo de driver antigo e um dispositivo usando o novo modelo de driver forem detetados, este último será o selecionado.

• Se um utilizador ligar um dispositivo GNSS externo quando um dispositivo GNSS interno estiver presente, é mais provável que o utilizador pretenda que esse dispositivo externo seja utilizado.

O comportamento da plataforma de localização, com base nestes pressupostos, será o seguinte:

• Caso de dois drivers legados coexistentes: Para evitar problemas de compatibilidade retroativa, o comportamento será o mesmo do Windows 8.1, em que ambos os dispositivos GNSS são usados simultaneamente e uma das respostas é comunicada através da pilha para aplicações.

• Caso de um driver herdado no dispositivo e um novo driver conectado externamente: O dispositivo GNSS conectado externamente é usado.

• Quando há um novo driver no dispositivo e outro ligado externamente: É usado o dispositivo GNSS ligado externamente.

Se o dispositivo GNSS selecionado suportar cerca geográfica ou outras operações descarregadas, o descarregamento será feito enquanto esse dispositivo é usado. O adaptador GNSS não dividirá a funcionalidade ou as sessões entre vários dispositivos GNSS.

Visão geral da interface do Sistema Global de Navegação por Satélite (GNSS)

A interação entre o adaptador GNSS e o controlador GNSS enquadra-se nas seguintes categorias:

Intercâmbio de informações sobre capacidades

Para suportar a extensibilidade e adaptabilidade da pilha GNSS em plataformas Windows, o adaptador GNSS e o driver GNSS estabelecem um entendimento comum das várias capacidades bem definidas da pilha GNSS subjacente, bem como o suporte fornecido pela plataforma Windows. Os aspetos de funcionalidades são bem definidos pela Microsoft como parte desta definição de interface GNSS e evoluirão à medida que mais inovações no sector GNSS continuam e um conjunto diversificado de chipsets e drivers emerge no mercado. O adaptador GNSS consulta as várias capacidades do driver/dispositivo GNSS subjacente no momento da inicialização ou conforme necessário e, consequentemente, otimiza a interação com o driver GNSS.

A troca de informações de capacidade entre o adaptador GNSS e o driver GNSS é feita usando os códigos de controle IOCTL_GNSS_SEND_PLATFORM_CAPABILITY e IOCTL_GNSS_GET_DEVICE_CAPABILITY.

Comando e configuração do condutor do Sistema Global de Navegação por Satélite (GNSS)

O adaptador GNSS pode efetuar uma configuração única ou uma reconfiguração periódica do controlador GNSS. Da mesma forma, o adaptador GNSS pode executar certos comandos específicos do GNSS através do driver. Isso é feito definindo um protocolo de execução de comando entre o driver e o sistema operacional de alto nível (HLOS). Dependendo do tipo de comando específico, a ação pretendida pode entrar em vigor imediatamente ou após a reinicialização do sistema. À semelhança das informações sobre a capacidade dos dispositivos GNSS, os comandos GNSS também são bem definidos pela Microsoft como parte desta definição de interface GNSS e continuarão a evoluir com futuras inovações e diversificação dos dispositivos/controladores GNSS.

A execução e configuração do comando do dispositivo é feita usando o código de controle IOCTL_GNSS_SEND_DRIVERCOMMAND.

Informações sobre a posição

Esta é a função principal do dispositivo GNSS subjacente. Na forma mais básica, o adaptador GNSS solicita a posição atual do dispositivo do driver GNSS. As variações do pedido de posição incluem (mas não estão limitadas a) os seguintes tipos de sessão de posição:

• Posição atual do dispositivo (correção pontual única)

• Fluxo periódico contínuo de correções (rastreamento baseado no tempo)

• Fluxo contínuo de correções com base no limiar de movimento (rastreamento baseado em distância)

O único tipo de sessão de determinação de posição obrigatório exigido por cada hardware GNSS e driver GNSS é o tipo de sessão de correção instantânea. Nativo (implementado no SOC, no dispositivo GNSS e não no driver GNSS ou em um serviço em execução no processador de aplicativos), sessões de rastreamento baseadas em tempo e sessões de rastreamento baseadas em distância podem ser suportadas opcionalmente. O principal benefício para esses dois tipos de sessões de rastreamento nativas é a economia de energia potencial, mantendo o processador de aplicativos (AP) inativo por mais tempo, fazendo mais processamento no SOC e relatando alterações apenas quando necessário. O suporte para rastreamento nativo baseado em distância é mais impactante do que sessões nativas de rastreamento baseado em tempo porque pode trazer maior economia de energia e porque é mais amplamente usado por aplicativos.

O ato de recuperar informações de posição do driver GNSS acontece através de uma sessão de correção única e com estado, que consiste nas seguintes ações:

1. Iniciar sessão de correção: O adaptador GNSS inicia uma sessão de correção de início (como resultado de uma solicitação de um aplicativo LBS). O adaptador GNSS define os requisitos específicos e a associação de preferências com a solicitação e intima o driver GNSS a iniciar o mecanismo para obter a correção emitindo o código de controle IOCTL_GNSS_START_FIXSESSION.

2. Obter a posição do dispositivo (corrigir dados): Uma vez que uma sessão de correção é iniciada, o adaptador GNSS emite o código de controle IOCTL_GNSS_GET_FIXDATA para começar a esperar por uma correção do driver. Quando novos dados de posição estão disponíveis a partir do módulo, o driver GNSS responde a este pedido de correção pendente.

   Se o tipo de sessão fix for LKG fix (em vez de current fix), as informações de posição vêm do cache do driver.

   O adaptador GNSS garante que uma solicitação de E/S assíncrona esteja sempre disponível para que o driver GNSS retorne os dados de correção quando disponíveis. Dependendo da natureza da correção, se mais dados de correção forem esperados, o adaptador GNSS emitirá outra solicitação de E/S (usando o mesmo IOCTL) e essa sequência continuará até que mais dados não estejam disponíveis ou a sessão de correção seja interrompida.

3. Modificar sessão de correção: Se o driver GNSS não suportar a multiplexação de sessões de correção do mesmo tipo, o adaptador GNSS pode emitir um IOCTL_GNSS_MODIFY_FIXSESSION para esse tipo de sessão de correção quando ele faz multiplexação em seu nível.

4. Parar sessão de fixação: O adaptador GNSS emite uma sessão de encerramento de fixação quando não é necessária nem esperada qualquer informação adicional de posição referente a uma sessão de fixação específica.

Suporte nativo de delimitação geográfica

O GNSS DDI suporta cenários de descarregamento de cerca geográfica usando um conjunto de IOCTLs definidos nesta especificação. Um sinalizador de capacidade especial é definido para o driver indicar esse suporte, esse sinalizador só deve ser definido se a pilha GNSS suportar geofencing nativamente (ou seja, implementa geofencing no chip GNSS em vez de no processador do aplicativo). Se o driver não suportar nativamente a cerca geográfica, a bandeira não deve ser ativada. O HLOS já suporta um mecanismo de rastreamento de cerca geográfica baseado num processador de aplicações (AP) que não é otimizado; embora esta solução não esteja tão otimizada em termos de consumo de energia quanto uma solução nativa poderia estar, ela é bem testada e otimizada, portanto, não deve ser substituída por uma solução equivalente implementada no AP.

O rastreamento de cerca geográfica pelo HLOS exige que o processador de aplicações se ative periodicamente para detetar violações de cerca geográfica, consumindo energia mesmo quando as cercas não são violadas. Por conseguinte, esta implementação é considerada subótima.

O HLOS também utiliza o rastreamento de cerca geográfica baseado em AP como um mecanismo de recurso quando o driver subjacente não consegue rastrear cercas geográficas devido a condições de sinal baixo ou outros erros transitórios. Isto ocorre após receber notificações de erro da solução nativa de rastreamento de cerca geográfica. O suporte nativo a "geofencing" é benéfico apenas quando o rastreamento é totalmente transferido para o SoC e o processador do aplicativo é ativado apenas para processar eventos relacionados a "geofencing". Se o hardware não suportar o rastreamento nativo de geofencing, o driver GNSS não deve tentar implementá-lo na camada de driver.

O motor GNSS também deve expor parâmetros de ajuste específicos do IHV documentados para permitir encontrar o equilíbrio certo entre o consumo de energia e a experiência do usuário. Além disso, o número de geofences suportados deve ser maior do que o valor MIN_GEOFENCES_REQUIRED definido no ficheiro de cabeçalho. Observe que o MIN_GEOFENCES_REQUIRED é definido por aplicativo, pois um aplicativo não tem conhecimento do número de cercas geográficas usadas por outros aplicativos ou pela operadora móvel.

O suporte de transferência de carga de geofencing envolve os seguintes requisitos:

• O HLOS deve ser capaz de criar uma ou mais cercas geográficas através do DDI e o driver as envia para o hardware para começar a rastreá-las.

• O HLOS deve ser capaz de excluir uma ou mais cercas geográficas criadas anteriormente através do DDI e o driver as envia para o hardware para parar de rastreá-las.

• Idealmente, o hardware GNSS deve entender o estado inicial de rastreamento de cerca geográfica para cada cerca geográfica e usá-lo para relatar apenas alterações a partir desse estado inicial. Se o hardware GNSS não suportar essa funcionalidade, ele relatará o estado inicial para o HLOS toda vez que uma cerca geográfica for criada.

• O hardware GNSS rastreia a posição atual do dispositivo de forma eficiente em termos de energia e acorda o AP sempre que o dispositivo entra e/ou sai de uma cerca geográfica rastreada. O condutor do GNSS passa os alertas de cerca geográfica para o HLOS.

• Sob baixo sinal de satélite e outras condições de erro transitório, o motor GNSS pode ser incapaz de rastrear de forma confiável as cercas geográficas existentes. O motor GNSS deve ser capaz de detetar as interrupções de localização e o condutor do GNSS deve transmitir o alerta de erro de estado de localização ao HLOS. O HLOS muda para o rastreamento de cerca geográfica baseado em AP padrão até que o hardware GNSS seja capaz de recuperar e rastrear cercas geográficas novamente.

• As condições exatas em que um motor GNSS precisa fornecer uma notificação para indicar que os geofences não podem ser rastreados variam e a implementação será específica do IHV. Seguem-se algumas orientações para a implementação:

  • Se o motor GNSS é capaz de detetar com alta confiança que o usuário não está se movendo e não há limite de cerca geográfica em 25 metros ou menos, o motor GNSS não precisa enviar um erro de rastreamento.

  • Se o motor GNSS é capaz de detetar com alta confiança que o usuário não está se movendo, mas há um limite de cerca geográfica em 25 metros ou menos, o motor GNSS precisa enviar um erro de rastreamento dentro de um minuto.

  • Se o motor GNSS detetou que o usuário está se movendo e há um limite de cercas geográficas dentro de 100 metros ou menos, o mecanismo GNSS precisa enviar um erro de rastreamento dentro de um minuto ou menos.

  • Se o motor GNSS não conseguir determinar se o utilizador está a mover-se e se existir um limite de vedações geográficas a menos de 100 metros, o motor GNSS tem de enviar um erro de seguimento dentro de um minuto ou menos.

  • Se o motor GNSS detetou que o utilizador está em movimento, o motor GNSS tem de enviar um erro de seguimento num tempo proporcional à velocidade estimada de movimento e à distância até à cerca geográfica mais próxima. Uma recomendação é enviar um alerta dentro de [(Distância até ao limite mais próximo da cerca (m) / velocidade estimada (m/s)) - 15s]. O motor GNSS pode utilizar indicadores de deteção de movimento para determinar o momento em que o erro de seguimento deve ser enviado.

  • Se o motor GNSS não conseguir determinar se o utilizador está em movimento, o motor GNSS tem de enviar um erro de rastreio num tempo proporcional à alta velocidade de movimento e à distância até à cerca geográfica mais próxima. Uma recomendação é reportar um erro dentro de [Distance-to-closest-fence-boundary(m) / 343(m/s)].

• Durante o período em que o motor GNSS comunicou um erro de estado de rastreio de cerca geográfica, não devem ser enviados eventos de violação de cerca geográfica para o HLOS.

• O HLOS pode redefinir o rastreamento de cerca geográfica excluindo todas as cercas geográficas criadas anteriormente por meio de um único comando.

• As cercas geográficas originadas por dispositivos móveis não persistem no hardware ou driver GNSS durante a reinicialização ou reinicialização do driver. O HLOS lida com a persistência em nome dos aplicativos do usuário final e cria/exclui cercas geográficas conforme necessário.

Em termos de interações entre o adaptador GNSS e o motor GNSS que suporta o descarregamento de cerca geográfica nativa, no caso de falha de rastreamento de cercas geográficas, o adaptador GNSS fará o seguinte:

• Ele usará o rastreamento baseado em AP assim que o driver GNSS retornar a incapacidade de rastrear.

• Ele continuará enviando quaisquer atualizações (adicionar/excluir) nas cercas geográficas atualmente sendo rastreadas no nível do sistema operacional para o driver, garantindo que estejam em sincronia. Isso ajudará o mecanismo GNSS a saber quais cercas geográficas estão sendo rastreadas atualmente pelo sistema operacional e pode determinar se pode ou não rastrear com base nos dados atualizados.

• Ele empurrará as mudanças de estado da cerca geográfica, conforme determinado pelo rastreador baseado em AP, uma vez que o driver GNSS envia de volta SUCESSO em sua capacidade de rastrear.

Notificações do motorista para assistência e dados auxiliares

De tempos em tempos, o driver GNSS pode precisar de dados de assistência ou ações auxiliares do adaptador GNSS. Isso inclui as várias formas de dados AGNSS (injeção de tempo, efemérides, posição grosseira inicial), janela pop-up de consentimento do utilizador para suportar o posicionamento do plano do utilizador iniciado pela rede, etc.

• Os dados de assistência GNSS podem ser obtidos pelo condutor GNSS sem utilizar o adaptador GNSS. No entanto, recomenda-se que os dados de assistência sejam obtidos usando o adaptador GNSS e aproveitando o serviço de posicionamento da Microsoft por vários motivos:

  • A pilha de localização da Microsoft encarregar-se-á de estabelecer as conexões de dados e de aderir a quaisquer restrições de roaming, preferências de dados, integração com o modo de rede silencioso, entre outras funcionalidades.

  • O serviço de posicionamento da Microsoft pode obter periodicamente dados de assistência específicos para um IHV através de uma conexão de servidor para servidor e distribuí-los para todos os dispositivos que necessitam, poupando ao IHV a necessidade de implantar um serviço de assistência front-end global que satisfaça requisitos de disponibilidade, escalabilidade e capacidade de resposta.

• Os consentimentos do usuário para privacidade para aplicativos de caixa de entrada são de propriedade do sistema operacional. Portanto, qualquer interface do usuário para notificar o usuário sobre uma solicitação de local iniciada pela rede ou qualquer interface do usuário para solicitar o consentimento do usuário para responder a uma solicitação de local iniciada pela rede, será de propriedade da Microsoft. O condutor GNSS notificará o adaptador GNSS quando for recebida uma solicitação de localização iniciada pela rede e, se necessário, aguardará a resposta do usuário até o tempo padrão antes de prosseguir para atender à solicitação.

Uma vez que o condutor GNSS não é capaz de iniciar um pedido para a camada superior por si só, este tipo de operações pode ser realizado pelo adaptador GNSS procurando proactivamente esse pedido do condutor GNSS e, assim, mantendo sempre um ou mais IRPs pendentes para que o condutor GNSS possa responder a tais pedidos pendentes. Após a receção do pedido de assistência/data de ajuda, o adaptador GNSS busca os dados (ou executa a ação específica em nome do driver de GNSS) e, subsequentemente, fornece a informação necessária ao driver de GNSS através de outra chamada DeviceIoControl.

A notificação do controlador é tratada por meio de um modelo de eventos comum. Por exemplo, para assistência GNSS, o adaptador GNSS usa código de controle IOCTL_GNSS_LISTEN_AGNSS para receber a solicitação AGNSS do driver GNSS. Subsequentemente, o adaptador GNSS busca os dados de assistência AGNSS e emite IOCTL_GNSS_INJECT_AGNSS para enviar os dados para o driver GNSS.

Esse mecanismo de notificação também é usado para receber dados de alerta relacionados à cerca geográfica e atualizações de status. O adaptador usa o código de controlo IOCTL_GNSS_LISTEN_GEOFENCE_ALERT para receber alertas individuais de geocerca, e IOCTL_GNSS_LISTEN_GEOFENCES_TRACKINGSTATUS para receber alterações no estado geral da monitorização de geocercas.

Registo dos condutores do Sistema Global de Navegação por Satélite (GNSS)

Para fins de diagnóstico, o driver GNSS deve registrar erros e outras informações de diagnóstico usando o mecanismo de registro prescrito pela Microsoft (WPP) descrito abaixo ou ETW. É recomendado que os drivers utilizem o WPP para fins de registro em vez de ETW, embora ambos os mecanismos sejam suportados. Entre as razões para o WPP ser recomendado está a disponibilidade de ferramentas que podem ajudar na depuração de drivers.

O condutor não deve registar qualquer informação, legível por pessoas ou outra, a não ser através desta técnica de registo prescrita. Para obter mais informações, consulte WPP Software Tracing.

O registo de mensagens utilizando o rastreio de software WPP é semelhante ao uso dos serviços de registo de eventos do Windows. O driver registra um ID de mensagem e dados binários não formatados em um arquivo de log. Posteriormente, um pós-processador converte as informações no arquivo de log em um formulário legível por humanos. No entanto, o rastreamento de software do WPP suporta formatos de mensagem que são mais avançados e flexíveis do que os suportados pelos serviços de log de eventos. Por exemplo, o rastreamento de software WPP tem suporte integrado a endereços IP, GUIDs, IDs do sistema, carimbos temporais e outros tipos de dados úteis. Além disso, os usuários podem adicionar tipos de dados personalizados relevantes para seus aplicativos.

Suporte ao protocolo da operadora móvel

A pilha GNSS fornecida pelo IHV (o driver GNSS, o dispositivo/motor GNSS) é necessária para suportar os vários protocolos de posicionamento do operador móvel (SUPL, UPL, CP e assim por diante). Não fazer isso significa que o dispositivo não passará pela aceitação das operadoras móveis e limitará significativamente onde o dispositivo pode ser comercializado.

O suporte a esses protocolos e a conformidade com os requisitos das operadoras móveis são obrigatórios para enviar dispositivos para determinadas operadoras móveis. O suporte para protocolos de operadoras móveis pode não ser essencial para a maioria das plataformas não telefônicas, especialmente se a plataforma não incluir suporte de banda larga móvel (MBB).

Todas as partes de implementação são abstraídas na pilha IHV e os componentes do Microsoft HLOS são agnósticos a:

• Os detalhes específicos de implementação dos protocolos (por exemplo, como os protocolos funcionam, a interpretação das mensagens de protocolo e assim por diante).

• A forma da pilha de implementação (por exemplo, a implementação pode residir dentro do dispositivo/motor GNSS, do driver GNSS ou, se necessário, de um serviço de sistema operativo de alto nível (HLOS) separado).

• Interação entre as várias componentes dentro da stack GNSS, de propriedade do IHV, para a implementação dos protocolos. Por exemplo, se o driver GNSS exigir os resultados da verificação Wi-Fi para responder a uma mensagem de protocolo SUPL específica, ele pode fazê-lo fazendo com que uma extensão de modo de usuário injete os resultados da verificação de Wi-Fi para o driver através de uma chamada IOCTL privada, ou faça isso parte do driver UMDF 2.0, ou manipule essa interação em um nível mais baixo. Os componentes do Microsoft GNSS HLOS são alheios a tais interações entre os componentes da pilha GNSS IHV.

Em resumo, o IHV ou OEM precisa fornecer um cliente SUPL (e potencialmente um cliente UPL se o sistema for enviado para a China) e integrá-lo com/dentro do driver GNSS. Todas as interações da plataforma de localização com o cliente SUPL serão feitas através do GNSS DDI.

Para facilitar a implementação dos protocolos da operadora móvel e reduzir a carga do desenvolvimento de software usando tecnologias específicas da plataforma, o adaptador GNSS fornece certas funcionalidades para a pilha GNSS IHV. O driver GNSS é tratado como o intermediário para receber tal funcionalidade dos componentes HLOS, por exemplo, o adaptador GNSS interage apenas com o driver GNSS e não com qualquer outra parte da pilha GNSS IHV. O driver GNSS IOCTLs define a sintaxe e semântica de tal funcionalidade entre o driver GNSS e o adaptador GNSS. O driver GNSS é responsável pelo roteamento para o componente IHV específico que implementa o protocolo da operadora móvel. Em termos gerais, o adaptador GNSS fornece a seguinte funcionalidade para o driver GNSS:

1. Configuração: As operadoras móveis provisionam o dispositivo e alteram a configuração usando o mecanismo de configuração imposto pelos padrões do protocolo OMA. Por exemplo, o padrão SUPL requer que a configuração SUPL seja feita com base no UICC e/ou seja feita usando as informações do perfil de configuração SUPL OMA obtidas via OMA-DM ou OMA-CP.

   Certas funcionalidades disponíveis no telefone para fins de configuração (OMA-DM e OMA CP) não estavam disponíveis em outras plataformas até o Windows 10. A partir do Windows 10, todas as plataformas podem suportar a configuração SUPL através do SUPL Configuration Service Provider (CSP), na medida em que o novo GNSS DDI é usado. O provisionamento injetado através do CSP pode vir da própria imagem (através de provxml ou multivariante) ou da operadora móvel via OMA-DM ou OMA-CP. SUPL CSP é definido em SUPL CSP.

   O Windows 10 define uma tecnologia proprietária, o gerenciamento de dispositivos usando um CSP (Configuration Service Provider), para interpretar e extrair os dados de configuração. A Microsoft fornece um CSP para consumir a configuração do OMA e enviar a configuração para o driver GNSS através do adaptador GNSS.

   Como alternativa, o IHV também pode escrever um componente em modo de utilizador para usar a especificação de configuração da operadora móvel através da tecnologia de gestão de dispositivos específica do telefone (CSPs). No entanto, este será um encargo adicional para o IHV e não recomendado.

   Apenas uma configuração SUPL é suportada em um sistema, incluindo em casos de dispositivos dual SIM. A Microsoft fornece a funcionalidade para reconfigurar o SUPL com base no UICC e na alteração do UICC. Além disso, no caso do roaming do dispositivo, o HLOS reconfigura o cliente SUPL para funcionar em modo autônomo. Este documento define as IOCTLs para enviar esses dados de configuração para uma variedade de protocolos de operação móvel (SUPL 1.0 e 2.0, v2UPL e assim por diante).

2. Tratamento do consentimento do usuário para solicitações da NI: Para atender aos requisitos de privacidade, certas solicitações de posicionamento iniciadas pela rede precisam do consentimento do usuário. Os IHVs não estão autorizados a escrever UI para componentes de plataforma. Assim, o adaptador GNSS manipula a interface do usuário para consentimento do usuário em nome do driver GNSS. Os IOCTLs de notificação para o driver GNSS solicitar um pop-up de UI, e os IOCTLs para o adaptador GNSS transmitirem a resposta do utilizador a esse pedido, estão definidos em IOCTLs do driver GNSS.

A fim de implementar um cliente SUPL totalmente funcional, a pilha IHV precisará fazer uso de interfaces ou funcionalidades gerais disponíveis em/através da plataforma OS. A seguir está a lista de funcionalidades disponíveis no Windows 10 que os IHVs podem aproveitar para implementar seu cliente SUPL:

Nenhuma destas funcionalidades faz parte da plataforma de localização ou do DDI GNSS, mas está incluída aqui para esclarecimento e para ajudar os programadores de controladores GNSS a compreender o que pode ser aproveitado do SO para implementar a funcionalidade SUPL.

• Encaminhador SMS: O Encaminhador SMS permite que o cliente SUPL assine mensagens WAP Push de SIP Push que contêm pedidos SUPL NI.

• Capacidade do Connection Manager de configurar qual conexão deve ser usada para SUPL e APIs para solicitar tal conexão: As operadoras móveis podem precisar ter o tráfego SUPL em uma conexão dedicada ou simplesmente em uma conexão diferente da conexão padrão com a Internet. Para fazer isso, o Connection Manager oferece:

  • Um provedor de serviços de configuração que o OEM ou a operadora móvel pode usar para configurar qual conexão deve ser usada para fins de comunicações SUPL.

  • Uma API para o cliente SUPL consultar os parâmetros de conexão da conexão SUPL.

  • Uma API para estabelecer a conexão SUPL, com os parâmetros obtidos na etapa anterior.

• Configuração da conexão celular: Para configurar os parâmetros de diferentes conexões celulares, por exemplo, os parâmetros para uma conexão SUPL, há um provedor de serviços de configuração que o OEM ou a operadora móvel pode usar. Em seguida, esta conexão pode ser associada no Connection Manager à finalidade SUPL.

• Solicitação para manter as conexões ativas enquanto uma conexão SUPL está em andamento: O cliente SUPL pode precisar iniciar conexões com o HSLP enquanto o sistema está em modo de espera conectado. Isso pode acontecer porque o dispositivo GNSS precisa obter informações de assistência quando configurado para usar o posicionamento baseado na Microsoft ou porque a operadora móvel enviou uma solicitação da NI. Se esse for o caso, o cliente SUPL precisará iniciar uma conexão com o HSLP e garantir que a conexão esteja ativa até que a sessão SUPL seja concluída.

• Interações com o módulo de banda larga móvel (MBB): No Windows 10, não há APIs disponíveis através do HLOS para recuperar medições de celular, saber quando uma chamada de emergência foi feita e assim por diante. Qualquer interação com o MBB precisa ser feita através da integração direta com o MBB (através de comandos AT ou outro método proprietário).

Testes de fabricação

Os OEMs precisam ter uma maneira de validar no momento da fabricação e também nos pontos de suporte ao cliente que o hardware GNSS e a pilha GNSS (o driver GNSS e o dispositivo/motor GNSS) estão funcionando corretamente. O IHV pode fornecer mecanismos proprietários para permitir que os OEMs façam esse teste ou, opcionalmente, pode implementar a interface no DDI para permitir que o OEM inicie testes de fabricação e obtenha resultados.

A estrutura de localização será ignorada durante os testes de fabricação, dado que os testes têm como grande foco a validação do hardware ou a validação do controlador. Em geral, o dispositivo estará em um "modo de sistema operacional seguro" especial, onde o conjunto mínimo de componentes e serviços será carregado. Nesse modo, o OEM pode iniciar um conjunto de aplicativos de teste que acionarão casos de teste. Para eficiência e velocidade durante a fabricação, é altamente desejado ter suporte simultâneo para testes em diferentes componentes.

A interface para testes de fabricação inclui dois tipos de testes:

1. Teste de onda portadora: Este teste é para validar o teste de conectividade/antena externa. Neste ensaio, o motor GNSS deve procurar um sinal CW e fornecer as medições SNRs (razão sinal-ruído ou razão portadora-ruído) na resposta. Idealmente, os testes devem fornecer respostas a 10 Hz.

2. Autoteste: Este ensaio destina-se a validar a funcionalidade básica do motor GNSS. O autoteste deve ser capaz de detetar problemas básicos no motor (hardware defeituoso, conexões ruins no hardware GNSS sem exigir qualquer sinal externo injetado. O objetivo desta validação é fazer esse teste barato e usá-lo como uma porta na linha de produção, antes que o dispositivo passe por testes mais exaustivos e caros. Neste ensaio, o motor GNSS e o condutor devem proceder à autovalidação das ligações por pinos e devolver um código de estado indicando que está tudo bem ou que ocorreu uma avaria. O código de erro para falhas deve indicar a falha detetada. Os códigos de erro são definidos pelo IHV.

Considerações de E/S

Como a funcionalidade GNSS não mapeia para solicitações tradicionais de leitura e gravação de arquivos para drivers de dispositivo, as funções ReadFile e WriteFile não serão usadas para as APIs de driver GNSS. Todas as funcionalidades do GNSS serão implementadas utilizando pedidos de controlo de E/S de dispositivos específicos do GNSS (DeviceIoControl) bem definidos, também conhecidos como IOCTLs.

Todas as IOCTLs utilizarão METHOD_BUFFERED como mecanismo de transferência de dados para dados de entrada e de saída. Como o tamanho dos dados relacionados ao GNSS é relativamente pequeno, a cópia extra do buffer não deve afetar o desempenho do sistema.

O driver GNSS será aberto usando a opção FILE_FLAG_OVERLAPPED na função CreateFile . Portanto, todas as IOCTLs são implicitamente assíncronas. No entanto, enquanto a maioria das IOCTLs GNSS são semanticamente assíncronas (por exemplo, uma IOCTL aciona uma atividade dentro do driver e os resultados são esperados de volta de forma assíncrona), algumas IOCTLs são semanticamente síncronas no sentido de que não há nenhuma ação ou atividade assíncrona lógica envolvida com tais IOCTLs. O comportamento síncrono desses poucos IOCTLs será alcançado bloqueando o thread do adaptador GNSS depois de emitir a chamada DeviceIoControl até que a operação de E/S seja concluída. Portanto, é da responsabilidade do condutor do GNSS preencher sempre o IRP como parte do processamento de todos os IOCTLs. Espera-se que o adaptador GNSS honre o contrato de uma chamada síncrona e, em caso de erros, pode ou não repetir esses comandos. O driver IHV precisa certificar-se de que incorporou toda a lógica do lado do condutor antes de retornar um erro.

Para operações de solicitação e resposta, o adaptador GNSS sempre manterá uma operação de E/S pendente disponível para que, quando o driver GNSS tiver dados para enviar como resposta a uma operação invocada anteriormente, a resposta possa ser enviada através do IRP pendente.

Sessão de tiro único

Pedido de correção inicial para uma correção pontual única para o driver inclui valores de precisão e tempo de resposta. O motor GNSS pode fazer uso destes valores para compreender a intenção do pedido de aplicação e tomar decisões inteligentes. Uma vez que uma solicitação é recebida pelo driver, ele deve começar a retornar quaisquer correções intermediárias geradas pelo motor. Correções intermediárias são correções geradas pelo mecanismo durante o cálculo de uma correção que atende aos requisitos de precisão ou é final. A frequência dessas correções intermediárias não é imposta e é um detalhe de implementação do mecanismo. O adaptador GNSS espera que as correções venham a cada poucos segundos e elas devem ser diferentes da última correção intermediária.

Uma vez que o motor GNSS determina que não pode obter uma melhor correção sob as condições de sinal atuais, ele deve retornar uma correção final e deve parar de fazer quaisquer cálculos adicionais. A correção final atende ao requisito de precisão ou indica que o motor não pode melhorar a precisão fornecida nas condições atuais.

O adaptador GNSS emite uma correção de parada para uma sessão de disparo único em qualquer um dos dois casos:

• Recebe um ajuste final do condutor.

• O tempo de resposta para o pedido foi atingido. Aqui a última correção intermediária será enviada para o aplicativo.

A figura a seguir ilustra duas sessões de tiro único:

Sessão 1: O motorista recebeu parâmetros de Precisão e Tempo de Resposta. Após o comando start fix, o driver começou a enviar correções intermediárias. Depois de um tempo, ele determinou que não poderia retornar uma correção mais precisa, então indicou a última correção como final. Isto aconteceu antes de o prazo de resposta ter sido atingido. O adaptador enviou a correção final para o aplicativo e emitiu um comando stop fix.

Sessão 2: O mesmo que na Sessão 1 acima, mas neste caso o motor continuou em busca de uma melhor correção para atender ao requisito de precisão e continuou enviando correções intermediárias no meio. Uma vez que o limite de tempo de resposta da sessão foi atingido, o adaptador emitiu um mecanismo de paragem que deverá encerrar esta sessão no driver. A última correção intermediária recebida foi enviada para o aplicativo.

Um aspeto de conceção importante a ter em conta na implementação do suporte de disparo único é que, se as sessões de seguimento baseadas na distância e as sessões de seguimento baseadas no tempo não forem suportadas, o motor GNSS deve continuar a seguir os satélites durante 3 a 5 segundos após receber um comando stop fix. Isso ocorre porque o adaptador GNSS precisará implementar sessões simuladas de rastreamento baseadas em distância e/ou tempo, usando sessões de correção pontual, e caso o motor GNSS deixe de rastrear os satélites imediatamente, a maioria dos dispositivos GNSS terá um atraso na aquisição, o que impossibilita a implementação de uma sessão de rastreamento simulada que atenda às necessidades de navegação, rastreamento de corrida ou aplicações de mapeamento.

O adaptador GNSS pode iniciar solicitações de correções instantâneas enquanto o sistema está em modo de espera ligado, não apenas quando o sistema está ativo. Isso pode acontecer para satisfazer a necessidade de tarefas em segundo plano, serviços do sistema, rastreamento de cercas geográficas no processador do aplicativo ou outros casos. O condutor do GNSS deve poder transmitir estes pedidos de sessão ao dispositivo GNSS e satisfazer o pedido ou apresentar um erro ao adaptador GNSS.

O diagrama de sequência a seguir ilustra as ações de alto nível relacionadas à obtenção de uma correção GNSS autônoma. Isso não inclui nenhum pedido de dados de assistência.

A descrição da sequência é a seguinte:

1. O adaptador GNSS abre o driver GNSS usando a API CreateFile . WDF/KMDF/UMDF faz os retornos de chamada opcionais necessários para o driver GNSS. O identificador de arquivo retornado é usado para todas as operações subsequentes.

2. O adaptador GNSS emite um IOCTL para comunicar as várias capacidades da plataforma ao condutor. O driver GNSS conclui a operação de E/S.

3. O adaptador GNSS emite IOCTL para obter os recursos do dispositivo. O driver GNSS retorna os recursos do dispositivo e conclui a operação de E/S.

4. O adaptador GNSS emite IOCTLs para qualquer configuração ou comandos específicos do driver. O driver GNSS executa a ação necessária e conclui a operação de E/S.

5. O adaptador GNSS emite um IOCTL_GNSS_START_FIXSESSION, juntamente com os parâmetros que especificam o tipo e outros aspetos da correção. Ao receber este IOCTL, o driver GNSS interage com o dispositivo subjacente para começar a receber correções e, posteriormente, conclui a operação de E/S.

6. O adaptador GNSS emite um IOCTL_GNSS_GET_FIXDATA e aguarda a conclusão da E/S. Sempre que o driver GNSS tem uma correção intermediária disponível, ele retorna os dados completando a operação de E/S.

7. O passo 6 é repetido até que o driver GNSS indique que não são esperadas mais correções (correção final recebida).

8. O adaptador GNSS emite IOCTL_GNSS_STOP_FIXSESSION. O driver GNSS faz a operação de limpeza necessária associada à solicitação de correção original.

9. O adaptador GNSS fecha o identificador de arquivo do driver usando a API CloseHandle .

As IOCTL do GNSS e as estruturas de dados associadas são descritas em pormenor na referência do condutor do GNSS.

Sessão de rastreamento baseada em distância

As sessões de rastreamento baseadas em distância são usadas com frequência por aplicativos de usuário final, já que, historicamente, era o único tipo de sessão disponível nas APIs do .NET. Um valor de distância de 0 indica que o motor GNSS deve fornecer correções à taxa mais elevada possível.

O adaptador GNSS iniciará sessões de rastreamento de distância com o driver GNSS, somente se este indicar que tem a capacidade SupportDistanceTracking.

Uma solicitação inicial ao driver para uma sessão de rastreamento de distância incluirá a precisão horizontal desejada e o limite de movimento, que é a distância calculada através da fórmula de haversine em metros que o sistema deve cobrir antes de o driver GNSS fornecer uma atualização de posição. O motor GNSS pode fazer uso destes valores para compreender a intenção do pedido de aplicação e tomar decisões inteligentes, tais como adaptar a frequência com que se verifica a localização.

Assim que uma solicitação de correção inicial é recebida pelo driver, ele deve começar a devolver quaisquer correções intermediárias geradas pelo mecanismo, até obter uma correção final. Esta será considerada a primeira posição da sessão. Depois disso, o motor GNSS deve começar a fornecer correções sempre que detetar que a distância de haversina foi aproximadamente coberta.

Se o motor GNSS determinar que já não pode rastrear a localização do dispositivo (por exemplo, se os satélites já não estiverem visíveis), deverá devolver um erro ao adaptador GNSS para que a plataforma de localização possa recorrer a outros mecanismos para fornecer atualizações de posição à aplicação do utilizador final. O adaptador GNSS deve apresentar um erro no seguinte prazo:

[(Distância-restante-desde-última-posição-conhecida (m) / velocidade estimada (m/s)) – 5 segundos] ou 5 segundos, o que for maior.

Se o motor GNSS forneceu um erro ao adaptador GNSS, mas o adaptador GNSS ainda não parou a sessão de seguimento, o motor GNSS deve continuar a verificar, de uma forma otimizada em termos de energia, se pode retomar a localização de seguimento. O IHV pode usar otimizações para fazer essa deteção em baixa potência. As técnicas comuns de otimização incluem:

• Recuo progressivo

• À espera de sinais de baixo custo indicativos de movimentos do dispositivo para verificar novamente

• Verificações de baixa potência para o sinal de satélite

Uma vez que o motor GNSS é capaz de fornecer uma correção final novamente após uma condição de erro, ele deve enviar essa posição para o adaptador GNSS como uma indicação de que o rastreamento foi retomado com êxito.

O adaptador GNSS emite um comando modify fix para uma sessão de rastreamento baseada em distância se um ou mais aplicativos que solicitaram a sessão de rastreamento cancelaram a solicitação ou se novos aplicativos estão solicitando uma sessão de rastreamento baseada em distância. Nesse caso, o adaptador GNSS calcula os novos parâmetros de sessão agregados necessários para multiplexar as diferentes sessões ativas e atualiza o driver GNSS com esses parâmetros.

O adaptador GNSS emite um comando stop fix para uma sessão de rastreamento baseada em distância se:

• A sessão de rastreamento foi transferida para outro motor de posicionamento que estava disponível no sistema.

• Os aplicativos que solicitaram a sessão de rastreamento cancelaram a solicitação.

A figura a seguir ilustra duas sessões de rastreamento baseadas em distância:

Sessão 1: O condutor GNSS recebeu parâmetros de precisão e limiar de movimento ao iniciar a sessão de seguimento. Após o comando start fix, o driver começa a enviar correções intermediárias até obter uma correção final ou uma correção que atenda ao requisito de precisão, momento em que essa correção é fornecida ao adaptador GNSS e o mecanismo GNSS iniciará o processo de rastreamento de distância. Enquanto a sessão está ativa, o adaptador GNSS envia uma solicitação para modificar os parâmetros da sessão às vezes T1 e T2. Após cada modificação de parâmetros, o driver GNSS enviará uma atualização de correção para o adaptador GNSS e retomará a sessão de rastreamento de distância com os novos parâmetros, até que o adaptador GNSS envie um comando stop fix.

Sessão 2: O processo de iniciação da sessão é semelhante à Sessão 1 acima, mas em um determinado ponto o mecanismo GNSS é incapaz de rastrear a posição. Após um tempo que depende da distância e da velocidade estimada do movimento, o condutor GNSS envia um erro. O motor GNSS continua a verificar a menor potência quando pode recuperar, e quando recupera indica-o ao adaptador GNSS enviando uma nova correção. A sessão é atualizada com novas correções, conforme necessário, até que o adaptador GNSS envie um comando stop fix.

O adaptador GNSS pode manter-se ativo ou mesmo iniciar sessões de rastreamento baseadas em distância enquanto o sistema está em modo de espera conectado, não apenas quando o sistema está ativo. Isso pode acontecer para satisfazer a necessidade de tarefas em segundo plano, serviços do sistema, rastreamento de cercas geográficas no processador do aplicativo ou outros casos. O condutor do GNSS deve poder transmitir estes pedidos de sessão ao dispositivo GNSS e satisfazer o pedido ou apresentar um erro ao adaptador GNSS.

Sessão de acompanhamento com base no tempo

As sessões de rastreamento com base no tempo podem ser usadas por aplicativos que exigem uma atualização de posição frequente e regular para atualizar a interface do usuário (por exemplo, mapas, aplicativos de navegação e assim por diante).

O adaptador GNSS iniciará sessões de rastreamento baseadas no tempo com o driver GNSS, somente se o último indicar que ele tem a capacidade SupportContinuousTracking.

Um pedido de fixação inicial ao driver para uma sessão de rastreamento baseada no tempo incluirá a precisão horizontal desejada e o intervalo de tempo preferido, durante o qual o driver GNSS deve fornecer uma atualização de localização. O motor GNSS pode fazer uso desses valores para entender a intenção da solicitação de aplicação e tomar decisões inteligentes, como adaptar a frequência na qual verificar a localização, começar a adquirir satélites alguns segundos antes do intervalo para fornecer uma atualização de posição oportunamente, e assim por diante.

Assim que uma solicitação de correção inicial é recebida pelo driver, ele deve começar a devolver quaisquer correções intermediárias geradas pelo mecanismo, até obter uma correção final. Esta será considerada a primeira posição da sessão. Depois disso, o motor GNSS deve começar a fornecer correções no intervalo exigido pelos parâmetros da sessão. Se o motor GNSS não for capaz de fornecer posições na frequência exigida pela aplicação, deve fornecer correções à taxa máxima possível.

Se o motor GNSS determinar que já não pode seguir a localização do dispositivo (por exemplo, se os satélites já não estiverem visíveis), deve devolver um erro ao adaptador GNSS para que a plataforma de localização possa recorrer a outros mecanismos para fornecer atualizações de posição à aplicação do utilizador final.

Se o motor GNSS forneceu um erro ao adaptador GNSS, mas o adaptador GNSS ainda não parou a sessão de seguimento, o motor GNSS deve continuar a verificar, de uma forma otimizada em termos de energia, se pode retomar a localização de seguimento.

O IHV pode usar otimizações para fazer essa deteção em baixa potência, conforme explicado na seção anterior. Uma vez que o motor GNSS é capaz de fornecer uma correção final novamente após uma condição de erro, ele deve enviar essa posição para o adaptador GNSS como uma indicação de que o rastreamento foi retomado com êxito.

O adaptador GNSS emite um comando modify fix para uma sessão de rastreamento baseada em tempo se um ou mais aplicativos que solicitaram a sessão de rastreamento cancelaram a solicitação ou se novos aplicativos estão solicitando uma sessão de rastreamento baseada em tempo. Nesse caso, o adaptador GNSS calcula os novos parâmetros de sessão agregados necessários para multiplexar as diferentes sessões ativas e atualiza o driver GNSS com esses parâmetros.

O adaptador GNSS emite um comando stop fix para uma sessão de rastreamento baseada em tempo se:

• A sessão de rastreamento foi entregue a outro motor de posicionamento disponível no sistema.

• Os aplicativos que solicitaram a sessão de rastreamento cancelaram a solicitação.

A figura a seguir ilustra duas sessões de rastreio baseadas no tempo.

Sessão 1: O condutor GNSS recebeu precisão e um parâmetro de intervalo preferido ao iniciar a sessão de seguimento. Após o comando start fix, o condutor deve começar a enviar correções intermédias até obter uma correção final ou uma correção que satisfaça o requisito de precisão, altura em que essa correção é fornecida ao adaptador GNSS e o motor GNSS inicia o processo de rastreio baseado no tempo. Enquanto a sessão está ativa, o adaptador GNSS envia uma solicitação para modificar os parâmetros da sessão às vezes T1 e T2. Após cada modificação de parâmetros, o driver GNSS enviará uma atualização de correção para o adaptador GNSS e retomará a sessão de rastreamento baseada no tempo, com os novos parâmetros, até que o adaptador GNSS envie um comando stop fix.

Sessão 2: O processo de iniciação da sessão é semelhante ao da Sessão 1 acima, mas em um determinado ponto o motor GNSS deixa de ser capaz de rastrear a posição. Quando o motor GNSS é incapaz de fornecer uma correção dentro de 15 segundos do intervalo exigido pelos parâmetros da sessão, o driver GNSS envia um erro. O motor GNSS continua a verificar a menor potência quando pode recuperar, e quando recupera indica-o ao adaptador GNSS enviando uma nova correção. A sessão é atualizada com novas correções, conforme necessário, até que o adaptador GNSS envie um comando para parar a correção.

O adaptador GNSS pode manter-se ativo ou até mesmo iniciar sessões de rastreamento baseadas no tempo enquanto o sistema está em modo de espera conectado, não apenas quando o sistema está ativo. Isso pode acontecer para satisfazer a necessidade de tarefas em segundo plano, serviços do sistema, rastreamento de cerca geográfica no processador do aplicativo ou outros casos. O condutor do GNSS deve poder transmitir estes pedidos de sessão ao dispositivo GNSS e satisfazer o pedido ou apresentar um erro ao adaptador GNSS.

Lidar com diferentes tipos de sessão de atualização simultaneamente

Alguns motores GNSS avançados podem ser capazes de lidar simultaneamente com uma sessão "Single Shot", juntamente com uma sessão de rastreamento Distance-Based e/ou Time-Based. Idealmente, sessões independentes não devem influenciar umas às outras, mas isso pode nem sempre ser possível, especialmente no caso de sessões simultâneas de Single Shot e Time Based Tracking. Esta seção fornece algumas diretrizes para a implementação do IHV no caso de compromissos que precisam ser feitos para lidar com sessões simultâneas de diferentes tipos.

Nesta secção, são utilizados os seguintes acrónimos:

• SS: Sessão Single Shot

• DBT: Sessão de Rastreamento Baseado em Distância

• TBT: Sessão de acompanhamento baseada no tempo

• TBF: Tempo entre correções

A tabela a seguir fornece alguns cenários para lidar simultaneamente com sessões de rastreamento de disparo único e baseadas no tempo.

Se houver simultaneamente uma sessão de rastreamento baseada no tempo e uma sessão baseada na distância, o rastreamento de precisão do motor GNSS pode ser configurado para funcionar com o menor dos dois. A tabela a seguir também fornece algumas diretrizes para o caso de valores díspares para a precisão necessária quando há sessões simultâneas de disparo único e rastreamento: