Requisitos de controlador do GNSS (Global Navigation Satellite System)

Descreve requisitos, suposições e restrições a serem considerados ao desenvolver um driver GNSS (Global Navigation Satellite System) 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. Também não há suporte para drivers UMDF 1.0. A definição da interface do driver GNSS ou os componentes GNSS do HLOS (sistema operacional de alto nível) 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 por esse design de interface. O UMDF 2.0 fornece maior estabilidade, simplicidade e flexibilidade para implementar recursos que exigem 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.

 O UMDF 2.0 está disponível em todas as plataformas e é altamente recomendável que os IHVs usem o driver escrito no modo de usuário.

• Várias sessões de aplicativo: Uma sessão de aplicativo é uma sessão de posicionamento proveniente de um componente HLOS interagindo diretamente com o driver GNSS. O driver GNSS pode optar por dar suporte nativo a várias sessões de aplicativo particionando suas variáveis de estado e funcionalidade em base por aplicativo. Essa é uma funcionalidade opcional do driver e é indicada especificamente por meio de informações de funcionalidade do driver GNSS bem definidas. Para dar suporte a esse comportamento opcional, o driver GNSS precisa controlar 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. Esse suporte nativo do driver GNSS permite que os componentes HLOS sejam mais flexíveis e menos restritivos em expor o driver ao restante da plataforma. Um driver GNSS que dê suporte a essa funcionalidade pode precisar particionar logicamente e manter informações de estado para cada sessão de aplicativo individual. Um driver GNSS que não dá suporte a essa funcionalidade só precisará manter o estado global para todas as sessões de aplicativo em vez da partição específica do aplicativo lógico. Neste último modo, o driver GNSS está alheio à presença de várias sessões de aplicativo paralelas 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 aplicativo tem a vantagem de habilitar um aplicativo de teste no HLOS para interagir diretamente com o driver GNSS ao mesmo tempo que o adaptador GNSS. O aplicativo de teste e o adaptador GNSS são o que consideramos diferentes aplicativos que podem solicitar a um único driver GNSS sessões diferentes simultaneamente. Se não houver suporte para várias sessões de aplicativo, o driver GNSS precisará ser testado por meio da Plataforma de Localização do sistema operacional ou, caso contrário, o serviço que hospeda a Plataforma de Localização do SISTEMA Operacional deverá ser interrompido para evitar interferir no aplicativo de teste.

• Sessão de fixação: O ato de obter informações de posicionamento do driver subjacente (disparo único ou rastreamento) é abstraído como uma noção de sessão de fixação. Os drivers precisam dar suporte a pelo menos uma sessão de correção de cada tipo de sessão com suporte. Os tipos de sessão são definidos pela enumeração GNSS_FIXSESSIONTYPE.

  • No mínimo, os drivers GNSS devem oferecer suporte a uma sessão de correção única.

  • Os drivers que dão suporte a sessões de correção de controle baseado em distância devem dar suporte simultaneamente a uma sessão de correção de tiro único e uma sessão de correção de rastreamento baseada em distância.

  • Os drivers que dão suporte a sessões de correção baseadas em tempo devem dar suporte simultaneamente a uma sessão de correção única e uma sessão de correção de rastreamento baseada em tempo.

  • Os drivers que dão suporte a sessões de correção baseadas em distância e sessões de correção de rastreamento baseadas em tempo devem dar suporte simultaneamente a uma sessão de correção ú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 dá suporte a várias sessões de correção simultâneas ou não é expresso por um parâmetro de funcionalidade de driver bem definido. Se um driver não der suporte explicitamente a várias sessões de correção paralela, ele deverá falhar em 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 sessões múltiplas de correção não estiver presente, o ônus estará no componente HLOS para garantir que várias solicitações GNSS geradas por 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 dar suporte a várias sessões de correção paralelas do mesmo tipo. Na verdade, no Windows 10, o adaptador HLOS GNSS não dá suporte ao aproveitamento da 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 futuras versões, será considerado dar permissão ao adaptador GNSS para iniciar diretamente as sessões com o driver GNSS a cada solicitação de correção de localização obtida das camadas superiores da plataforma de localização, ao invés de realizar a multiplexação de sessão ele próprio. O suporte à multiplexação de sessões fixas no adaptador GNSS simplifica a implementação de drivers, pois não requer que eles lidem com várias sessões do mesmo tipo para um aplicativo, nem a implementação de multiplexação. Isso reduz o uso de memória no driver e não requer que o adaptador GNSS lide com o caso de o HLOS iniciar um número de sessões fixas maior do que o suportado pelo driver GNSS. Diferentes camadas de dispositivos e drivers diferentes dão suporte a um número diferente de sessões de correção simultâneas, portanto, esse 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 com suporte e ignorará o suporte de sessão de correção múltipla pelo driver até que tenhamos a necessidade dessa funcionalidade.

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

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

  2. Obtendo uma ou mais correções

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

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

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

  As sessões de correção são identificadas exclusivamente por uma 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 de 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 fixação: O driver GNSS deve ao menos oferecer suporte à fixação instantânea básica. Além disso, o driver deve dar suporte nativo a tipos de correção avançados (como acompanhamento). Conforme indicado anteriormente, o suporte a tipos de correção adicionais implica que, mesmo que o driver não dê suporte a várias sessões de correção do mesmo tipo, ele deve dar suporte simultaneamente a pelo menos uma sessão de correção de um tipo de correção com suporte. O componente HLOS não multiplexa tipos de correção diferentes 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 saída do driver GNSS. Isso será necessário para lidar com um driver GNSS em uma configuração de Plug and Play (PnP). Também será necessário em casos onde o descarregamento inesperado do driver ocorre devido a uma falha no serviço no nível do usuário, se o driver for um UMDF 2.0. O driver GNSS deve garantir que a interface do dispositivo seja anunciada somente quando o hardware subjacente for capaz de dar suporte às chamadas de IOCTL do HLOS 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 driver deve registrar-se para o WDF_PNPPOWER_EVENT_CALLBACKS.EvtDeviceD0Entry callback, gerado pelo WDF quando o sistema vai para o estado D0, e o WDF_PNPPOWER_EVENT_CALLBACKS.EvtDeviceD0Exit callback, gerado pelo WDF quando o sistema sai do estado D0. O driver GNSS deve ser configurável para desabilitar 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 os recursos do dispositivo GNSS (ele dá suporte a 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 energia mais baixo possível quando não houver sessões ativas ou operações descarregadas, independentemente do estado de energia do sistema.

  • No caso de cenários transferidos, 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 a espera conectada (este é o estado de suspensão com a tela apagada), mas ainda assim o hardware precisa reduzir o consumo de energia ao mínimo. Esse modelo funcionaria para esses dispositivos usando DMA (Acesso direto à memória) 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 provavelmente a função USB do dispositivo deve estar no estado de energia do dispositivo D2 (suspend) durante a espera conectada. Em geral, os dispositivos GNSS conectados via USB devem ser capazes de entrar em um estado D2 de baixa potência (suspensão) depois que não tiverem 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 ativação 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 deverá ser capaz de usar a sinalização em banda USB para ativar o SoC ou o núcleo de silício do estado de espera conectado. O SoC ou o núcleo de silício deve ser capaz de acordar de seu estado de energia mais baixo em resposta à sinalização de retomada USB do dispositivo GNSS, em banda.

  • Os dispositivos que não dão suporte à espera conectada terão todas as operações descarregadas canceladas no momento em que o dispositivo for para espera ou hibernação moderna. Isso inclui cercas geográficas descarregadas, controle de distância ou sessões de acompanhamento periódico.

  • Os dispositivos que oferecem suporte a espera conectada continuarão com todas as operações descarregadas ativas quando entrarem em espera conectada, e é esperado que o dispositivo GNSS continue as operações de rastreamento da maneira mais eficiente possível, além de fornecer notificações ao HLOS caso ocorra uma condição de ativação de geofence ou uma atualização de sessão de rastreamento seja pertinente. Se não houver nenhuma operação descarregada em um dispositivo que suporte standby conectado, o dispositivo GNSS deverá entrar no estado de energia mais baixo possível, mas ainda será capaz de receber as solicitações de sessão de localização do HLOS. Em dispositivos que dão suporte ao SUPL, também deve ser possível que o dispositivo GNSS e a pilha SUPL ativem as notificações de NI enquanto estiverem em espera conectados.

  Informações gerais sobre o gerenciamento de energia para drivers podem ser encontradas nas Responsabilidades de Gerenciamento de Energia para Drivers.

• Consideração de energia: A pilha de driver GNSS deve levar em conta o consumo de energia como um objetivo de projeto principal 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, para que o processador principal do aplicativo não precise estar ativo mais do que o necessário e a maioria do processamento possa ser descarregada para o chipset/baixo consumo de energia. Como regra geral, a menos que indicado de outra forma do HLOS, o driver GNSS deve sempre tratar o consumo de energia como a restrição mais importante e deve ser projetado para executar as operações normais com volume de energia mínimo. A interface do driver GNSS foi explicitamente projetada para permitir que o dispositivo móvel faça a transição para o modo de baixa potência o mais frequentemente possível e forneça as dicas necessárias relacionadas à energia para o driver GNSS para otimizar o uso de energia. Para acompanhamento, geofencing e outras funcionalidades que exigem monitoramento de posição contínuo e abrangente, o driver/mecanismo GNSS deve tirar proveito de hardware/processadores de baixo consumo de energia. Se essa funcionalidade precisar 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 deverá se declarar como capaz dessas operações. Isso permitirá que o HLOS restrinja a exposição dessa funcionalidade ao restante da plataforma ou use uma implementação alternativa dessas funcionalidades com base em outros serviços/primitivos de plataforma.

• Linguagem de programação: A interface do driver GNSS é entregue como um arquivo de cabeçalho de linguagem C que não usa nenhum primitivo de linguagem específico 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 opção aberta para IHVs.

• Driver de filtro: A pilha de dispositivos GNSS não deve ser restringida de forma a impedir a adição de um driver de filtro futuro na pilha para dar suporte à funcionalidade estendida. O driver GNSS entregue pelo IHV não deve incluir seu próprio driver de filtro, seja na parte superior ou inferior da pilha de drivers.

• Notificações e eventos: Como um driver WDF não consegue enviar uma notificação não solicitada ao HLOS, sempre haverá pelo menos um IRP pendente iniciado a partir do HLOS que atenda à finalidade de receber qualquer notificação não solicitada da camada de driver. Isso inclui o caso em que o sistema está em standby conectado. 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 do 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 um componente do modo de usuário acessório que interage com o driver GNSS por meio de IOCTLs privados definidos por IHV. Isso é particularmente necessário se o driver GNSS estiver no modo kernel, nesse caso, ele não tem acesso à funcionalidade disponível exclusivamente no modo de usuário (por exemplo, verificação Wi-Fi, APIs do Gerenciador de Conexões e assim por diante). Observe que, com o UMDF 2.0 no Windows 10, um driver GNSS UMDF não precisa de um componente separado do modo de usuário, embora o IHV ainda possa implementar um componente de modo de usuário separado. Esses componentes do modo de usuário são tratados como uma mera extensão para o driver GNSS e serão tratados como parte da queda do BSP entregue por IHV. Os componentes HLOS fornecidos pela Microsoft estão alheios aos detalhes exatos de implementação desses componentes e ao mecanismo de interação entre os componentes do modo de usuário/kernel do IHV. Se o driver GNSS for escrito como um driver UMDF 2.0, usar extensões IHV para modo de usuário não é recomendado, porque esse modelo provavelmente exigirá mais consumo de memória.

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

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

  • A extensão de modo de usuário deve estar em conformidade com a segurança, a energia e outras políticas e noções básicas da 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 essa autorização em runtime.

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

  Os IHVs não adicionarão funcionalidade arbitrária nem usarão serviços de sistema operacional não autorizados/recursos seguros.

Requisitos mínimos de suporte

Haverá uma grande variedade de dispositivos GNSS (Global Navigation Satellite System) que podem ser usados para plataformas Windows para atender às necessidades de diversas camadas de dispositivos (baixo custo, high-end, diferentes tipos de dispositivo e assim por diante). Para habilitar esse ecossistema avançado e aumentar o número de tablets, laptops e outros tipos de dispositivo que podem incluir um chip GNSS a um custo menor, a Microsoft não exige que todos os dispositivos GNSS ofereçam suporte ao conjunto completo de recursos descritos na referência do driver GNSS. A tabela a seguir fornece uma exibição de alto nível da funcionalidade mínima necessária para diferentes tipos de dispositivo e qual funcionalidade é opcional ou recomendada.