Requisitos de driver 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 vez de 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 de GNSS do HLOS (sistema operacional de alto nível) da Microsoft, como o adaptador GNSS, não fazem uma 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 os IHVs são altamente recomendados para usar 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 que interage 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 funcionalidades 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 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 sobre a exposição do 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 paralelas do aplicativo 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.
Corrigir sessão: O ato de obter informações de posicionamento do driver subjacente (tiro único ou rastreamento) é abstraído em uma noção de uma sessão de correçã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 na enumeração GNSS_FIXSESSIONTYPE .
No mínimo, os drivers GNSS devem dar suporte a uma única sessão de correção de captura.
Os drivers que dão suporte a sessões de correção de rastreamento baseado em distância devem dar suporte simultaneamente a uma única sessão de correção de tiro e a uma sessão de correção de rastreamento baseada em distância.
Os drivers que dão suporte a sessões de correção de acompanhamento baseado em tempo devem dar suporte simultaneamente a uma única sessão de correção de captura e uma sessão de correção de rastreamento baseada em tempo.
Os drivers que dão suporte a sessões de correção de rastreamento baseado em distância e sessões de correção de rastreamento baseadas em tempo devem dar suporte simultaneamente a uma única sessão de correção de tiro, 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 não houver suporte a várias correções de sessão, o ônus estará no 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 dar suporte a várias sessões de correção paralelas do mesmo tipo. Na verdade, em Windows 10, o adaptador GNSS do HLOS 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 versões futuras, ele será considerado para permitir que o adaptador GNSS inicie sessões diretamente com o driver GNSS para cada solicitação de correção obtida das camadas superiores da plataforma de localização, em vez de fazer o multiplexação de sessão em si. O suporte à multiplexação de sessões de correção no adaptador GNSS simplifica a implementação do driver, pois não exige 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 exige que o adaptador GNSS lide com o caso do HLOS iniciando uma série de sessões de correção maiores do que o que é compatível com o 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, em 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:
Iniciando uma sessão de correção
Obtendo uma ou mais correções
Modificar a sessão de correção, se necessário
Isso é necessário pelo menos até que o adaptador GNSS manipule a multiplexação de sessões de correção do mesmo tipo e pode até ser necessário posteriormente para lidar com o caso de sessões de correção mais simultâneas ativas do que o número suportado pelo driver GNSS.
- 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 correção: O driver GNSS deve, no mínimo, dar suporte à correção básica de captura única. Além disso, o driver deve dar suporte nativo a tipos de correção avançados (como acompanhamento). Conforme mencionado 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) e também nos casos em que o descarregamento inesperado do driver ocorre devido a uma falha de serviço no nível do usuário se o driver for um driver UMDF 2.0. O driver GNSS deve garantir que a interface do dispositivo seja anunciada somente quando o hardware abaixo for capaz de dar suporte às chamadas 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 se registrar para o WDF_PNPPOWER_EVENT_CALLBACKS. Retorno de chamada EvtDeviceD0Entry (gerado pelo WDF quando o sistema vai para o estado D0) e WDF_PNPPOWER_EVENT_CALLBACKS. Retorno de chamada EvtDeviceD0Exit (gerado pelo WDF quando o sistema sai do estado D0). O driver GNSS deve ser configurável para, opcionalmente, desabilitar 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 descarregados, novamente, independentemente do estado de energia do sistema, o dispositivo GNSS pode precisar marcar para 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 (esse é o estado de suspensão da tela de suspensão), mas ainda assim o hardware precisa reduzir o consumo de energia para o 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 esses dispositivos GNSS conectados por meio do barramento USB, nesse caso, provavelmente, a função USB do dispositivo deve estar no estado de energia do dispositivo D2 (suspender) durante o modo de espera conectado. 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 sobre o barramento USB. Se o dispositivo GNSS tiver sessões de correção ativas ou descarregadas, o dispositivo deverá ser capaz de usar a sinalização em banda, retomar a sinalização USB para ativar o SoC ou o silício principal do modo de espera conectado. O SoC ou o silício principal deve ser capaz de acordar de seu estado de energia mais baixo em resposta à sinalização de retomada USB na banda do dispositivo GNSS.
Os dispositivos que não dão suporte ao modo de espera conectado terão todas as operações descarregadas canceladas no momento em que o dispositivo for para o modo de espera ou hibernação moderno. Isso inclui cercas geográficas descarregadas, acompanhamento de distância ou sessões periódicas de acompanhamento.
Os dispositivos que dão suporte ao modo de espera conectado continuarão tendo todas as operações descarregadas ativas quando o dispositivo for para o modo de espera conectado, e espera-se que o dispositivo GNSS continue as operações de rastreamento da maneira mais eficiente possível, e espera-se que ele forneça notificações ao HLOS caso a condição de gatilho de cerca geográfica ou uma atualização de sessão de acompanhamento seja pertinente. Se não houver nenhuma operação descarregada em um dispositivo que dê suporte ao modo de espera conectado, o dispositivo GNSS deverá ir para o estado de energia mais baixo possível, mas ainda poderá escutar 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 conectado.
Informações gerais sobre o gerenciamento de energia para drivers podem ser encontradas em Responsabilidades de Gerenciamento de Energia para Drivers.
Consideração de energia: A pilha de driver GNSS deve levar em conta o volume de energia como uma meta de design principal e minimizar a manutenção do processador main o máximo possível. Todo o suporte avançado à funcionalidade (como diferentes tipos de correção) deve ser executado de maneira eficiente, como o processador de aplicativos main não precisa estar ativo mais do que o necessário e a maioria dos processamentos pode ser descarregada para o processador de chipset/baixa potência. 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 projetada explicitamente 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, cerca geográfica e outras funcionalidades que exigem monitoramento de posição generalizada de longa execução, o driver/mecanismo GNSS deve aproveitar o hardware/processadores de baixa potência. 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 da 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 restrita de tal forma que impeça a adição de um driver de filtro futuro na pilha para dar suporte à funcionalidade estendida. O driver GNSS entregue por IHV não deve incluir seu próprio driver de filtro na parte superior ou na parte inferior da pilha de driver.
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 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 espera conectado. Para o driver GNSS, essas notificações não solicitadas incluem (mas não se limitam 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 gravar um componente do modo de usuário acessório que interage com o driver GNSS por meio de IOCTLs privados definidos por IHV. Isso é especialmente 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 Gerenciador de Conexões e assim por diante). Observe que, com o UMDF 2.0 em 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 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-mode do IHV. Se o driver GNSS for escrito como um driver UMDF 2.0 usando extensões IHV no modo de usuário, não será recomendável porque esse modelo provavelmente exigirá mais uso 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 das IOCTLs públicas do driver GNSS devem permanecer não afetados e desobstruídos pela extensão IHV do 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 as noções básicas e políticas de segurança, energia e outras plataformas 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 políticas como 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 so 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.
| Funcionalidade | Requisito para todas as plataformas | Requisito específico para telefones | Observações |
|---|---|---|---|
| Relatando com precisão o GNSS_DEVICE_CAPABILITIES | Obrigatório | Requisito mínimo de funcionalidade | |
| Suporte para MultipleFixSessions | Opcional | Sem suporte do adaptador GNSS | |
| Suporte para MultipleAppSessions | Recomendadas | ||
| Suporte à Assistência GNSS (específico do IHV) | Recomendadas | Obrigatório | |
| Obtendo suporte à Assistência GNSS por meio da Microsoft (uso do Agss_inject IOCTLs) | Recomendadas | ||
| Suporte para a estrutura de GNSS_FixData completa | Obrigatório | ||
| Sessão de captura única | Obrigatório | ||
| Suporte nativo da sessão de acompanhamento baseado em tempo | Opcional | Se houver suporte, ele deverá incluir suporte para modificar parâmetros de sessão. | |
| Suporte nativo da sessão de acompanhamento baseado em distância | Opcional | Se houver suporte, ele deverá incluir suporte para modificar parâmetros de sessão. | |
| Última sessão conhecida válida | Opcional | ||
| Suporte nativo de cerca geográfica | Opcional | Recomendado | Somente cercas geográficas circulares necessárias e com suporte |
| Fornecendo ChipsetInfo | Obrigatório | Usando o GNSS_ChipsetInfo | |
| Relatando erros | Recomendadas | Usando o GNSS_ErrorInfo | |
| Relatórios via NMEA | Opcional | ||
| Suporte ao teste de fabricação (onda de portador ou auto-teste) | Opcional | ||
| Local do painel de controle com integração com o MBB | Obrigatório somente se exigido pela operadora móvel | Obrigatório | Normalmente exigido por operadoras móveis em dispositivos com suporte de voz. Quase sempre necessário para telefones. |
| SUPL 1.0 | Obrigatório somente se exigido pela operadora móvel | Em geral substituído pelo SUPL 2.0. Inclui a implementação dos requisitos completos da operadora móvel de atendimento ao cliente, a configuração por meio da DDI, o relatório de eventos ni para o sistema operacional por meio da DDI e a integração com o MBB. |
|
| SUPL 2.x | Obrigatório somente se exigido pela operadora móvel | Obrigatório | Normalmente exigido por operadoras móveis em dispositivos com suporte de voz. Quase sempre necessário para telefones. Inclui a implementação dos requisitos completos da operadora móvel de atendimento ao cliente, a configuração por meio da DDI, o relatório de eventos ni para o sistema operacional por meio da DDI e a integração com o MBB. |
| UPI | Obrigatório somente se exigido pela operadora móvel | Só precisa ter suporte para esses dispositivos CDMA que são enviados na China, se exigido pela operadora móvel. Inclui a implementação dos requisitos completos da operadora móvel de atendimento ao cliente, a configuração por meio da DDI, o relatório de eventos ni para o sistema operacional por meio da DDI e a integração com o MBB. |
|
| comando do driver GNSS_SetLocationServiceEnabled | Obrigatório | ||
| Comando do driver GNSS_SetLocationNIRequestAllowed | Obrigatório somente se o SUPL tiver suporte e exigido pela operadora móvel | Nenhuma operadora móvel conhecida exige mais isso | |
| comando do driver GNSS_ForceSatelliteSystem | Recomendadas | Bom para fins de teste. Algumas operadoras móveis ou OEMs podem exigir isso para teste. | |
| comando do driver GNSS_ForceOperationMode | Obrigatório somente se houver suporte para SUPL | Algumas operadoras móveis podem exigir para fins de teste. | |
| Comando do driver GNSS_ResetEngine | Obrigatório | Para fins de teste | |
| Comando do driver GNSS_ClearAgnssData | Obrigatório | Para fins de teste | |
| Comando do driver GNSS_SetNMEALogging | Opcional | Somente se exigido por operadoras móveis ou OEMs precisar disso para fins de teste | |
| comando do driver GNSS_SetSuplVersion | Obrigatório somente se houver suporte para SUPL | Necessário para SUPL | |
| Comando do driver GNSS_SetUplServerAccessInterval | Obrigatório somente se o SUPL tiver suporte e exigido pela operadora móvel | Somente se exigido pela operadora móvel | |
| comando do driver GNSS_SetNiTimeoutInterval | Obrigatório somente se o SUPL tiver suporte e exigido pela operadora móvel | Somente se exigido pela operadora móvel | |
| comando do driver GNSS_ResetGeofencesTracking | Obrigatório somente se houver suporte para cerca geográfica | ||
| comando do driver GNSS_CustomCommand | Opcional |