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

Descreve requisitos, suposições e restrições a serem considerados ao desenvolver um driver do Sistema Global de Navegação por Satélite (GNSS) para Windows 10.

Requisitos gerais

• Estrutura do driver: O driver GNSS deve ser escrito como um driver UMDF 2.0 com base nessa definição de interface, em oposição a um driver WDM bruto ou driver KMDF. Os drivers UMDF 1.0 também não são suportados. A definição da interface do driver GNSS ou os componentes do sistema operacional de alto nível (HLOS) da Microsoft, como o adaptador GNSS, não fazem distinção entre um driver WDF, KMDF GNSS e um driver UMDF 2.0, desde que o driver forneça a funcionalidade necessária de acordo com esse design de interface. UMDF 2.0 fornece maior estabilidade, simplicidade e flexibilidade para implementar recursos que requerem funcionalidade oferecida apenas no modo de usuário. Como regra geral, os IHVs devem preferir UMDF 2.0 a KMDF quando a estrutura anterior estiver disponível na plataforma.

 UMDF 2.0 está disponível em todas as plataformas e é fortemente recomendado que os IHVs utilizem o driver escrito em modo de utilizador.

• Várias sessões de aplicação: Uma sessão de aplicação é uma sessão de posicionamento proveniente de um componente HLOS interagindo diretamente com o driver GNSS. O driver GNSS pode optar por suportar nativamente várias sessões de aplicativos particionando suas variáveis de estado e funcionalidade em cada aplicativo. Esta é uma capacidade opcional do condutor e é indicada especificamente através de informações bem definidas sobre a capacidade do condutor GNSS. Para suportar esse comportamento opcional, o driver GNSS precisa acompanhar o identificador de arquivo que os aplicativos HLOS obtêm durante o CreateFile e associar todas as operações HLOS subsequentes ao identificador de arquivo específico da sessão do aplicativo. Este suporte nativo do driver GNSS permite que os componentes HLOS sejam mais flexíveis e menos restritivos quanto à exposição do driver ao resto da plataforma. Um driver GNSS que suporte esse recurso pode precisar particionar logicamente e manter informações de estado para cada sessão de aplicativo individual. Um driver GNSS que não suporta esse recurso só precisará manter o estado global para todas as sessões do aplicativo, em vez da partição lógica específica do aplicativo. Neste último modo, o driver GNSS ignora a presença de várias sessões de aplicativos paralelos e trata todas as solicitações do HLOS como se fossem originadas da mesma sessão de aplicativo.

  

  O suporte no driver GNSS para várias sessões de aplicação tem a vantagem de permitir que um aplicativo de teste no HLOS interaja diretamente com o driver GNSS ao mesmo tempo que o adaptador GNSS. A aplicação de teste e o adaptador GNSS são o que consideramos diferentes aplicações que podem solicitar a um único driver GNSS diferentes sessões simultaneamente. Se não houver suporte para várias sessões de aplicativos, o driver GNSS precisará ser testado através da Plataforma de Localização do SO ou, caso contrário, o serviço que hospeda a Plataforma de Localização do SO deve ser interrompido para evitar interferir com o aplicativo de teste.

• Sessão de fixação: O ato de obter informações de posicionamento do driver subjacente (tiro único ou rastreamento) é abstraído em uma noção de sessão de fixação. Os drivers precisam suportar pelo menos uma sessão de correção de cada tipo de sessão suportado. Os tipos de sessão são definidos na enumeração GNSS_FIXSESSIONTYPE.

  • No mínimo, os drivers GNSS devem suportar uma sessão de fixação única.

  • Os drivers que suportam sessões de correção de rastreamento com base em distância devem suportar simultaneamente uma sessão de correção de captura única e uma sessão de correção de rastreamento baseada em distância.

  • Os drivers que suportam sessões de correção de rastreamento com base no tempo devem suportar simultaneamente uma sessão de correção de captura única e uma sessão de correção de rastreamento baseada em tempo.

  • Os drivers que suportam sessões de correção de rastreamento com base em distância e sessões de correção de rastreamento com base no tempo devem suportar simultaneamente uma sessão de correção de captura única, uma sessão de correção de rastreamento baseada em distância e uma sessão de correção de rastreamento baseada em tempo.

  

  Se o driver suporta várias sessões de correção simultâneas ou não, é expresso por um parâmetro de capacidade de driver bem definido. Se um driver não suportar explicitamente várias sessões de correção paralelas, ele deverá falhar uma nova solicitação de sessão de correção se uma sessão do mesmo tipo de correção já estiver iniciada e ativa. Se o suporte a várias sessões de correção não estiver presente, o ônus recai sobre o componente HLOS para garantir que várias solicitações GNSS provenientes dos aplicativos de alto nível sejam multiplexadas e mapeadas em uma única solicitação de sessão de correção para o driver GNSS.

  O driver GNSS não é necessário para suportar várias sessões de correção paralelas do mesmo tipo. Na verdade, no Windows 10, o adaptador HLOS GNSS não suporta aproveitar a capacidade do driver GNSS para ter várias sessões de correção do mesmo tipo, portanto, os IHVs não são incentivados a investir nessa funcionalidade por enquanto. Em versões futuras, será considerado permitir que o adaptador GNSS inicie diretamente sessões com o driver GNSS para cada solicitação de correção obtida das camadas superiores da plataforma de localização, em vez de fazer a multiplexação de sessão em si. O suporte de multiplexação de sessões de correção no adaptador GNSS simplifica a implementação do driver, pois não requer que ele manipule várias sessões do mesmo tipo para um aplicativo ou implementação de multiplexação, reduz o uso de memória no driver e não requer que o adaptador GNSS lide com o caso do HLOS iniciar um número de sessões de correção maior do que o suportado pelo driver GNSS. Diferentes níveis de dispositivos e diferentes drivers suportariam um número diferente de sessões de correção simultâneas, portanto, este caso precisaria ser tratado, introduzindo complexidade no adaptador GNSS para lidar com todos os casos. Portanto, no Windows 10 o adaptador GNSS implementará apenas a sessão de correção única de cada tipo suportado e ignorará o suporte de sessão de correção múltipla pelo driver até que tenhamos uma necessidade para essa funcionalidade.

  Cada sessão de correção é stateful e deve seguir esta sequência bem definida:

  1. Iniciando uma sessão de correção

  2. Obter uma ou mais correções

  3. Modifique a sessão de ajuste, se necessário

  Isso é necessário pelo menos até que o adaptador GNSS lide com a multiplexação de sessões de correção do mesmo tipo e pode até ser necessário mais tarde para lidar com o caso de mais sessões de correção simultâneas ativas do que o número suportado pelo driver GNSS.

  1. Interrompendo a sessão de correção

  As sessões de correção são identificadas exclusivamente por um ID de sessão de correção. Nenhuma informação posicional pode ser recuperada pelo HLOS fora do contexto de uma sessão de correção. O driver GNSS deve permitir a modificação dos parâmetros da sessão em tempo real para facilitar a operação de multiplexação pelo componente HLOS, sem a necessidade de reiniciar a sessão de correção.

  

• Tipo de correção: O condutor GNSS deve, no mínimo, suportar a correção básica de tiro único. Além disso, o driver deve suportar nativamente tipos avançados de correção (como rastreamento). Como dito anteriormente, o suporte a tipos de correção adicionais implica que, mesmo que o driver não suporte várias sessões de correção do mesmo tipo, ele deve suportar simultaneamente pelo menos uma sessão de correção de um tipo de correção suportado. O componente HLOS não multiplexa diferentes tipos de correção em um único tipo.

• Interface do dispositivo e PnP: O driver GNSS deve anunciar uma interface de dispositivo definida pela Microsoft usando a API WdfDeviceCreateDeviceInterface para que o HLOS possa ser notificado sobre a chegada e partida do driver GNSS. Isso será necessário para lidar com um driver GNSS em uma configuração Plug and Play (PnP) e também nos casos em que ocorre o descarregamento inesperado do driver devido a uma falha de serviço ao nível do usuário, se for um driver UMDF 2.0. O driver GNSS deve garantir que a interface do dispositivo seja anunciada apenas quando o hardware por baixo for capaz de suportar as chamadas HLOS IOCTL e não antes disso.

• Política de energia do dispositivo: O driver GNSS deve gerenciar a política de energia de seu dispositivo e deve lidar com os eventos de gerenciamento de energia gerados pelo sistema operacional. O condutor deve registar-se para a WDF_PNPPOWER_EVENT_CALLBACKS. EvtDeviceD0Entry callback (gerado pelo WDF quando o sistema vai para o estado D0) e WDF_PNPPOWER_EVENT_CALLBACKS. EvtDeviceD0Exit callback (gerado pelo WDF quando o sistema sai do estado D0). O driver GNSS deve ser configurável para desativar opcionalmente o gerenciamento de energia.

  O gerenciamento exato de energia que precisa ser feito em um dispositivo GNSS nos diferentes estados de energia do sistema precisa ser adaptado de acordo com as capacidades do dispositivo GNSS (suporta operações descarregadas ou não), se há operações descarregadas reais ativas e como a comunicação entre o sistema e o dispositivo GNSS é feita. Em geral, as expectativas são as seguintes:

  • O dispositivo GNSS funcionará no modo de menor energia possível quando não houver sessões ativas ou operações descarregadas, independentemente do estado de energia do sistema.

  • Em caso de cenários descarregados, novamente independentemente do estado de energia do sistema, o dispositivo GNSS pode precisar verificar a posição em intervalos diferentes ou receber notificações e, portanto, o dispositivo GNSS pode precisar permanecer no estado D0 mesmo durante o modo de espera conectado (este é o estado de suspensão de tela desligado), mas ainda assim o hardware precisa reduzir o consumo de energia ao mínimo. Esse modelo funcionaria para dispositivos que usam DMA (Direct Memory Access) ou uma porta serial em um UART para se comunicar com o host, por exemplo. Mas será um desafio para os dispositivos GNSS conectados via barramento USB, caso em que muito provavelmente a função USB do dispositivo deve estar no estado de energia do dispositivo D2 (suspensão) durante o modo de espera conectado. Em geral, os dispositivos GNSS conectados via USB devem ser capazes de entrar em um estado D2 (suspensão) de baixa potência depois de não terem sessões de correção ou operações descarregadas em andamento e a interface do barramento USB entrar no estado de suspensão. Todas as transições de energia de suspensão e despertar devem ser sinalizadas através do barramento USB. Se o dispositivo GNSS tiver sessões de correção ativas ou operações descarregadas, o dispositivo deve ser capaz de usar a sinalização de retomada USB em banda para despertar o SoC ou o silício do núcleo do modo de espera conectado. O SoC ou o silício do núcleo deve ser capaz de despertar do seu estado de energia mais baixo em resposta à sinalização de retomada USB em banda do dispositivo GNSS.

  • Os dispositivos que não suportam o modo de espera conectado terão todas as operações descarregadas canceladas no momento em que o dispositivo entrar em modo de espera ou hibernação moderno. Isso inclui cercas geográficas descarregadas, rastreamento de distância ou sessões periódicas de rastreamento.

  • Os dispositivos que suportam o modo de espera ligado continuarão com todas as operações descarregadas ativas quando o dispositivo entrar em modo de espera ligado. Espera-se que os dispositivos GNSS continuem as operações de rastreamento da forma mais eficiente possível e forneçam notificações ao HLOS, caso uma condição de ativação de geofencing ou uma atualização de sessão de rastreamento seja pertinente. Se não houver operações descarregadas num dispositivo que suporte o modo de espera conectado, o dispositivo GNSS deve ir para o estado de menor consumo de energia possível, mas ainda ser capaz de aceitar solicitações de sessão de localização do HLOS. Em dispositivos que suportam SUPL, também deve ser possível que o dispositivo GNSS e a pilha SUPL acordem nas notificações da NI enquanto estão em espera conectada.

  Informações gerais sobre gerenciamento de energia para motoristas podem ser encontradas em Responsabilidades de gerenciamento de energia para motoristas.

• Consideração de energia: A pilha de drivers GNSS deve levar em conta a pegada de energia como um objetivo principal do projeto e minimizar o tempo em que o processador principal permanece ativo o máximo possível. Todo o suporte a funcionalidades avançadas (como diferentes tipos de correção) deve ser executado de forma eficiente em termos de energia, de modo que o processador principal do aplicativo não precisa estar ativo mais do que o necessário e a maioria do processamento pode ser descarregada para o chipset/processador de baixo consumo. Regra geral, salvo indicação em contrário do HLOS, o condutor do GNSS deve sempre considerar o consumo de energia como a restrição mais importante e deve ser concebido para executar as operações normais com uma pegada de energia mínima. A interface do driver GNSS é explicitamente projetada para permitir que o dispositivo móvel faça a transição para o modo de baixo consumo de energia sempre que possível, e para fornecer dicas necessárias relacionadas à energia para o driver GNSS para otimizar o uso de energia. Para rastreamento, cerca geográfica e outras funcionalidades que exigem monitoramento generalizado de posição de longa duração, o driver/motor GNSS deve tirar proveito de hardware/processadores de baixa potência. Se tal funcionalidade tiver que ser implementada usando um mecanismo de sondagem de força bruta no driver ou se precisar ser implementada no processador do aplicativo, o driver não deve se declarar como capaz de tais operações. Isso permitirá que o HLOS restrinja a exposição de tal funcionalidade ao resto da plataforma ou use uma implementação alternativa dessas funcionalidades com base em outros serviços/primitivos da plataforma.

• Linguagem de programação: A interface do driver GNSS é fornecida como um arquivo de cabeçalho de linguagem C que não usa nenhuma primitiva de linguagem específica do C++ (por exemplo, herança de estrutura). Isso permite que o IHV escolha entre C e C++. O arquivo de cabeçalho da interface GNSS deixa a decisão para os IHVs.

• Driver do filtro: A pilha de dispositivos GNSS não deve ser restringida de tal forma que impeça a adição de um driver de filtro futuro na pilha para suportar a funcionalidade estendida. O driver GNSS fornecido pelo IHV não deve incluir seu próprio driver de filtro na parte superior ou inferior da pilha de drivers.

• Notificações e eventos: Como um driver WDF não pode enviar notificações não solicitadas para o HLOS, sempre haverá pelo menos um IRP pendente iniciado a partir do HLOS que serve o propósito de receber qualquer notificação não solicitada da camada de driver. Isto inclui o caso em que o sistema está em modo de espera ligado. Para o driver GNSS, essas notificações não solicitadas incluem (mas não estão limitadas a) solicitações iniciadas pela rede, dados de assistência para suporte AGNSS, outras notificações específicas do fornecedor. O HLOS garantirá que uma solicitação de E/S pendente esteja sempre presente para lidar com essas notificações.

• Extensão IHV do modo de usuário: Os IHVs podem escrever componentes de modo de utilizador acessórios que interagem com o controlador GNSS através de IOCTLs privadas definidas por IHV. Isso é particularmente necessário se o driver GNSS estiver no modo kernel, caso em que ele não tem acesso à funcionalidade disponível exclusivamente no modo de usuário (por exemplo, verificação Wi-Fi, APIs do Connection Manager e assim por diante). Observe que com o UMDF 2.0 no Windows 10, um driver GNSS UMDF não precisa de um componente de modo de usuário separado, embora o IHV ainda possa implementar um componente de modo de usuário separado. Esses componentes de modo de usuário são tratados como uma mera extensão do driver GNSS e serão tratados como parte da queda do BSP entregue pelo IHV. Os componentes HLOS fornecidos pela Microsoft ignoram os detalhes exatos de implementação de tais componentes e o mecanismo de interação entre os componentes de modo de usuário/modo kernel IHV. Se o driver GNSS for escrito como um driver UMDF 2.0 utilizando extensões IHV de modo de utilizador, não é recomendado, porque este modelo provavelmente exigirá mais uso de memória.

  As extensões IHV de modo de usuário devem estar em conformidade com as seguintes regras:

  • A semântica e o comportamento dos IOCTLs do driver GNSS público devem permanecer inalterados e desobstruídos pela extensão IHV do modo de usuário e sua interação com o driver GNSS.

  • A extensão no modo de utilizador deve cumprir as políticas e princípios básicos de segurança, energia e plataforma impostas pela plataforma Windows 10.

  • A extensão de modo de usuário deve executar apenas as atividades autorizadas aprovadas pela Microsoft, sem que a plataforma do sistema operacional imponha / valide tal autorização em tempo de execução.

  A Microsoft ainda pode aplicar políticas de segurança e controlar o tempo de vida desses componentes. O ponto-chave aqui é que os componentes de modo de usuário IHV não devem contar com a plataforma para aplicar tais políticas, pois o componente de extensão é tratado como um componente de sistema operacional confiável.

  Os IHVs não adicionam funcionalidades arbitrárias nem usam serviços de sistema operacional não autorizados/recursos seguros.

Requisitos mínimos de apoio

Haverá uma grande variedade de dispositivos do Sistema Global de Navegação por Satélite (GNSS) que podem ser usados para plataformas Windows para satisfazer as necessidades de diversos níveis de dispositivos (baixo custo, high-end, diferentes tipos de dispositivos, etc.). Para habilitar um ecossistema tão rico e aumentar o número de tablets, laptops e outros tipos de dispositivos que podem incluir um chip GNSS a um custo mais baixo, a Microsoft não exige que todos os dispositivos GNSS suportem o conjunto completo de recursos descritos na referência do driver GNSS. A tabela a seguir fornece uma visão de alto nível da funcionalidade mínima necessária para diferentes tipos de dispositivos e qual funcionalidade é opcional ou recomendada.