Requisitos del controlador del Sistema satélite de navegación global (GNSS)

Describe los requisitos, suposiciones y restricciones que se deben tener en cuenta al desarrollar un controlador del sistema de navegación por satélite global (GNSS) para Windows 10.

Requisitos generales

• Marco de trabajo del controlador: El controlador GNSS debe escribirse como un controlador UMDF 2.0 basado en esta definición de interfaz, en lugar de un controlador WDM sin formato o un controlador KMDF. Tampoco se admiten los controladores UMDF 1.0. La definición de la interfaz del controlador GNSS o los componentes GNSS del sistema operativo de alto nivel (HLOS) de Microsoft, como el adaptador GNSS, no distinguen entre un controlador WDF, un controlador GNSS de KMDF y un controlador UMDF 2.0, siempre y cuando el controlador proporcione la funcionalidad necesaria según este diseño de interfaz. UMDF 2.0 proporciona mayor estabilidad, simplicidad y flexibilidad para implementar características que requieren funcionalidades que solo se ofrecen en modo de usuario. Como regla general, los IHV deben preferir UMDF 2.0 a KMDF cuando el marco anterior está disponible en la plataforma.

 UMDF 2.0 está disponible en todas las plataformas y se recomienda encarecidamente usar el controlador escrito en modo de usuario.

• Varias sesiones de aplicación: Una sesión de aplicación es una sesión de posicionamiento procedente de un componente HLOS que interactúa directamente con el controlador GNSS. El controlador GNSS podría optar por admitir de forma nativa varias sesiones de aplicación mediante la creación de particiones de sus variables de estado y funcionalidad en cada aplicación. Se trata de una funcionalidad opcional del controlador y se indica específicamente a través de información de funcionalidad del controlador GNSS bien definida. Para admitir este comportamiento opcional, el controlador GNSS debe realizar un seguimiento del identificador de archivo que obtienen las aplicaciones HLOS durante CreateFile y asociar todas las operaciones HLOS posteriores al identificador de archivo específico de la sesión de la aplicación. Esta compatibilidad nativa del controlador GNSS permite que los componentes de HLOS sean más flexibles y menos restrictivos al exponer el controlador al resto de la plataforma. Un controlador GNSS que admita esta funcionalidad puede necesitar crear particiones lógicas y mantener información de estado para cada sesión de aplicación individual. Un controlador GNSS que no admita esta funcionalidad solo tendrá que mantener el estado global para todas las sesiones de aplicación en lugar de la partición específica de la aplicación lógica. En este último modo, el controlador GNSS es ombligo a la presencia de varias sesiones de aplicación paralelas y trata todas las solicitudes de HLOS como si se originen en la misma sesión de aplicación.

  

  La compatibilidad con el controlador GNSS para varias sesiones de aplicación tiene la ventaja de permitir que una aplicación de prueba en HLOS interactúe directamente con el controlador GNSS al mismo tiempo que el adaptador de GNSS. La aplicación de prueba y el adaptador de GNSS son lo que consideramos diferentes aplicaciones que pueden solicitar a un solo controlador GNSS sesiones diferentes simultáneamente. Si no se admiten varias sesiones de aplicación, el controlador GNSS debe probarse con a través de la plataforma de ubicación del sistema operativo o, de lo contrario, el servicio que hospeda la plataforma de ubicación del sistema operativo debe detenerse para evitar interferir con la aplicación de prueba.

• Corrección de la sesión: El acto de obtener información de posicionamiento del controlador subyacente (única toma o seguimiento) se abstrae en una noción de una sesión de corrección. Los controladores deben admitir al menos una sesión de corrección de cada tipo de sesión compatible. Los tipos de sesión se definen en la enumeración GNSS_FIXSESSIONTYPE .

  • Como mínimo, los controladores GNSS deben admitir una sesión de corrección de captura única.

  • Los controladores que admiten sesiones de corrección de seguimiento basadas en distancia deben admitir simultáneamente una sesión de corrección de captura única y una sesión de corrección de seguimiento basada en la distancia.

  • Los controladores que admiten sesiones de corrección de seguimiento basadas en el tiempo deben admitir simultáneamente una sesión de corrección de captura única y una sesión de corrección de seguimiento basada en el tiempo.

  • Los controladores que admiten sesiones de corrección de seguimiento basadas en distancia y sesiones de corrección de seguimiento basadas en tiempo deben admitir simultáneamente una sesión de corrección de captura única, una sesión de corrección de seguimiento basada en la distancia y una sesión de corrección de seguimiento basada en el tiempo.

  

  Si el controlador admite varias sesiones de corrección simultáneas o no se expresa mediante un parámetro de funcionalidad de controlador bien definido. Si un controlador no admite explícitamente varias sesiones de corrección paralelas, debe producir un error en una nueva solicitud de sesión de corrección si ya se ha iniciado y activo una sesión del mismo tipo de corrección. Si no hay compatibilidad con varias sesiones de corrección, el problema es el componente HLOS para asegurarse de que varias solicitudes GNSS procedentes de las aplicaciones de alto nivel se multiplexan y se asignan a una única solicitud de sesión de corrección al controlador GNSS.

  El controlador GNSS no es necesario para admitir varias sesiones de corrección paralelas del mismo tipo. De hecho, en Windows 10, el adaptador de GNSS HLOS no admite el aprovechamiento de la capacidad del controlador GNSS para tener varias sesiones de corrección del mismo tipo, por lo que no se recomienda que los IHD inviertan en esta funcionalidad por el momento. En futuras versiones, se considerará que el adaptador de GNSS inicie directamente las sesiones con el controlador GNSS para cada solicitud de corrección obtenida de las capas superiores de la plataforma de ubicación, en lugar de realizar la multiplexación de sesión. La compatibilidad con la multiplexación de sesiones de corrección en el adaptador de GNSS simplifica la implementación del controlador, ya que no requiere que controle varias sesiones del mismo tipo para una aplicación o implementación de multiplexación, reduce el uso de memoria en el controlador y no requiere que el adaptador de GNSS controle el caso de HLOS que inicia una serie de sesiones de corrección más grandes que las admitidas por el controlador GNSS. Diferentes niveles de dispositivos y controladores diferentes admitirían un número diferente de sesiones de corrección simultáneas, por lo que este caso tendría que controlarse, introduciendo complejidad en el adaptador de GNSS para controlar todos los casos. Por lo tanto, en Windows 10 el adaptador de GNSS solo implementará la sesión de corrección única de cada tipo admitido y omitirá la compatibilidad con varias sesiones de corrección por parte del controlador hasta que tengamos una necesidad de esta funcionalidad.

  Cada sesión de corrección tiene estado y debe seguir esta secuencia bien definida:

  1. Inicio de una sesión de corrección

  2. Obtención de una o varias correcciones

  3. Modificar la sesión de corrección si es necesario

  Esto es necesario al menos hasta que el adaptador GNSS controle la multiplexación de sesiones de corrección del mismo tipo y puede que incluso sea necesario más adelante para controlar el caso de sesiones de corrección más simultáneas activas que el número admitido por el controlador GNSS.

  1. Detener la sesión de corrección

  Las sesiones de corrección se identifican de forma única mediante un identificador de sesión de corrección. El HLOS no puede recuperar ninguna información posicional fuera del contexto de una sesión de corrección. El controlador GNSS debe permitir la modificación de los parámetros de sesión sobre la marcha para facilitar la operación de multiplexación por parte del componente HLOS, sin necesidad de reiniciar la sesión de corrección.

  

• Tipo de corrección: El controlador GNSS debe admitir como mínimo la corrección básica de disparo único. Además, el controlador debe admitir de forma nativa los tipos de corrección avanzados (como el seguimiento). Como se indicó anteriormente, admitir tipos de corrección adicionales implica que aunque el controlador no admita varias sesiones de corrección del mismo tipo, debe admitir simultáneamente al menos una sesión de corrección de un tipo de corrección compatible. El componente HLOS no multiplexa tipos de corrección diferentes en un solo tipo.

• Interfaz de dispositivo y PnP: El controlador GNSS debe anunciar una interfaz de dispositivo definida por Microsoft mediante la API WdfDeviceCreateDeviceInterface para que el HLOS pueda recibir una notificación sobre la llegada y salida del controlador GNSS. Esto será necesario para controlar un controlador GNSS en una configuración de Plug and Play (PnP) y también en los casos en los que se produzca una descarga inesperada del controlador debido a un bloqueo del servicio de nivel de usuario si el controlador es un controlador UMDF 2.0. El controlador GNSS debe asegurarse de que la interfaz del dispositivo solo se anuncia cuando el hardware subyacente es capaz de admitir las llamadas IOCTL de HLOS y no antes de eso.

• Directiva de alimentación del dispositivo: El controlador GNSS debe administrar la directiva de energía de su dispositivo y debe controlar los eventos de administración de energía generados por el sistema operativo. El controlador debe registrarse para el WDF_PNPPOWER_EVENT_CALLBACKS. Devolución de llamada EvtDeviceD0Entry (generada por WDF cuando el sistema pasa al estado D0) y WDF_PNPPOWER_EVENT_CALLBACKS. Devolución de llamada EvtDeviceD0Exit (generada por WDF cuando el sistema sale del estado D0). El controlador GNSS debe configurarse para deshabilitar opcionalmente la administración de energía.

  La administración exacta de energía que debe realizarse en un dispositivo GNSS en los diferentes estados de energía del sistema debe adaptarse según las capacidades del dispositivo GNSS (admite operaciones descargadas o no), si hay operaciones descargadas reales activas y cómo se realiza la comunicación entre el sistema y el dispositivo GNSS. En general, las expectativas son las siguientes:

  • El dispositivo GNSS funcionará en el modo de energía más bajo posible cuando no haya sesiones activas ni operaciones descargadas, independientemente del estado de alimentación del sistema.

  • En el caso de escenarios descargados, de nuevo independientemente del estado de alimentación del sistema, es posible que el dispositivo GNSS tenga que comprobar la posición en intervalos diferentes o recibir notificaciones y, por tanto, el dispositivo GNSS puede necesitar permanecer en estado D0 incluso durante el modo de espera conectado (este es el estado de suspensión de la pantalla), pero el hardware debe reducir el consumo de energía al mínimo. Este modelo funcionaría para esos dispositivos mediante DMA (acceso directo a memoria) o un puerto serie en un UART para comunicarse con el host, por ejemplo. Pero será un desafío para esos dispositivos GNSS conectados a través del bus USB, en cuyo caso la función USB del dispositivo probablemente debe estar en el estado de alimentación del dispositivo D2 (suspender) durante el modo de espera conectado. En general, los dispositivos GNSS conectados a través de USB deben poder entrar en un estado D2 de bajo consumo (suspensión) después de que no tengan sesiones de corrección ni operaciones descargadas en curso y la interfaz del bus USB entra en el estado de suspensión. Todas las transiciones de energía de suspensión y reactivación deben indicarse a través del bus USB. Si el dispositivo GNSS tiene sesiones activas o descargadas, el dispositivo debe poder usar señales de reanudación USB en banda para reactivar el soC o el silicio principal desde el modo de espera conectado. El soC o el silicio de núcleo deben ser capaces de reactivarse desde su estado de potencia más bajo en respuesta a la señal de reanudación USB en banda desde el dispositivo GNSS.

  • Los dispositivos que no admiten el modo de espera conectado tendrán todas las operaciones descargadas canceladas en el momento en que el dispositivo pasa a la hibernación o el modo de espera modernos. Esto incluye geovallas descargadas, seguimiento de distancia o sesiones de seguimiento periódicas.

  • Los dispositivos que admiten el modo de espera conectado seguirán teniendo activas todas las operaciones descargadas cuando el dispositivo vaya al modo de espera conectado y se espera que el dispositivo GNSS continúe con las operaciones de seguimiento lo más eficaz posible y se espera que proporcione notificaciones al HLOS en caso de que la condición de desencadenador de geovalla o una actualización de sesión de seguimiento sea pertinente. Si no hay ninguna operación descargada en un dispositivo que admita el modo de espera conectado, se supone que el dispositivo GNSS va al estado de energía más bajo posible, pero sigue siendo capaz de escuchar las solicitudes de sesión de ubicación desde el HLOS. En los dispositivos que admiten SUPL, también debe ser posible que el dispositivo GNSS y la pila SUPL se activen en las notificaciones de NI mientras están en espera conectada.

  Puede encontrar información general sobre la administración de energía para los conductores en Responsabilidades de administración de energía para controladores.

• Consideración de energía: La pila del controlador GNSS debe tener en cuenta la superficie de energía como objetivo de diseño principal y minimizar el mantenimiento del procesador principal tanto como sea posible. Toda la compatibilidad con la funcionalidad avanzada (por ejemplo, diferentes tipos de corrección) debe ejecutarse de una manera eficaz que el procesador de aplicaciones principal no necesita estar activo más de lo necesario y la mayoría del procesamiento se puede descargar en el chipset o procesador de bajo consumo. Como regla general, a menos que se indique lo contrario desde el HLOS, el controlador GNSS siempre debe tratar el consumo de energía como la restricción más importante y debe diseñarse para realizar las operaciones normales con una superficie de energía mínima. La interfaz del controlador GNSS está diseñada explícitamente para permitir que el dispositivo móvil pase al modo de bajo consumo con la mayor frecuencia posible y proporcionar sugerencias necesarias relacionadas con la alimentación al controlador GNSS para optimizar el uso de energía. Para el seguimiento, la geovalla y otras funcionalidades que requieren una supervisión de posición generalizada de larga duración, el controlador o motor GNSS debe aprovechar las ventajas de los procesadores o hardware de bajo consumo. Si dicha funcionalidad debe implementarse mediante un mecanismo de sondeo por fuerza bruta en el controlador o si debe implementarse en el procesador de la aplicación, el controlador no debe declararse como capaz de tales operaciones. Esto permitirá que los HLOS restrinjan la exposición de dicha funcionalidad al resto de la plataforma o usen una implementación alternativa de esas funcionalidades basadas en otros servicios o primitivos de la plataforma.

• Lenguaje de programación: La interfaz del controlador GNSS se entrega como un archivo de encabezado del lenguaje C que no usa primitivos de lenguaje específicos de C++ (por ejemplo, herencia de estructura). Esto permite que el IHV elija entre C y C++. El archivo de encabezado de interfaz GNSS deja la opción abierta a IHVs.

• Controlador de filtro: La pila de dispositivos GNSS no debe restringirse de tal manera que impida agregar un controlador de filtro futuro en la pila para admitir la funcionalidad extendida. El controlador GNSS entregado por IHV no debe incluir su propio controlador de filtro en la parte superior o en la parte inferior de la pila del controlador.

• Notificaciones y eventos: Dado que un controlador WDF no puede enviar una notificación no solicitada al HLOS, siempre habrá al menos un IRP pendiente iniciado desde el HLOS que sirva para recibir cualquier notificación no solicitada de la capa de controladores. Esto incluye el caso en el que el sistema está en espera conectado. Para el controlador GNSS, estas notificaciones no solicitadas incluyen (pero no se limitan a) solicitudes iniciadas por la red, datos de asistencia para la compatibilidad con AGNSS, otras notificaciones específicas del proveedor. El HLOS garantizará que una solicitud de E/S pendiente siempre esté presente para controlar dichas notificaciones.

• Extensión IHV en modo de usuario: Los IHV pueden escribir componente de modo usuario accesorio que interactúe con el controlador GNSS a través de IHV definidos por ioCTLs privados. Esto es especialmente necesario si el controlador GNSS está en modo kernel, en cuyo caso no tiene acceso a la funcionalidad exclusivamente disponible en modo de usuario (por ejemplo, Wi-Fi examen, Administrador de conexiones API, etc.). Tenga en cuenta que, con UMDF 2.0 en Windows 10, un controlador GNSS de UMDF no necesita un componente de modo de usuario independiente, aunque el IHV todavía puede implementar un componente de modo de usuario independiente. Estos componentes en modo de usuario se tratan como una mera extensión para el controlador GNSS y se tratarán como parte de la caída del BSP entregado por IHV. Los componentes HLOS proporcionados por Microsoft son ombligos a los detalles exactos de implementación de estos componentes y al mecanismo de interacción entre los componentes del modo de usuario/modo kernel de IHV. Si el controlador GNSS se escribe como controlador UMDF 2.0 mediante extensiones IHV en modo de usuario no se recomienda porque es probable que este modelo requiera más uso de memoria.

  Las extensiones IHV en modo de usuario deben cumplir las reglas siguientes:

  • La semántica y el comportamiento de las ICTLs del controlador GNSS público deben permanecer sin verse afectados y sin obstáculos por la extensión IHV en modo de usuario y su interacción con el controlador GNSS.

  • La extensión en modo de usuario debe cumplir los aspectos básicos y las directivas de seguridad, energía y otras plataformas impuestas por la plataforma Windows 10.

  • La extensión en modo de usuario solo debe realizar las actividades autorizadas aprobadas por Microsoft, sin tener que la plataforma del sistema operativo aplique o valide dicha autorización en tiempo de ejecución.

  Microsoft todavía puede aplicar directivas de seguridad y controlar la duración de estos componentes. El punto clave aquí es que los componentes del modo de usuario de IHV no deben contar con la plataforma para aplicar dichas directivas, como el componente de extensión, se trata como un componente de sistema operativo de confianza.

  Los IHVs no agregarán funcionalidad arbitraria ni usarán servicios de sistema operativo no autorizados o recursos seguros.

Requisitos mínimos de soporte técnico

Habrá una gran variedad de dispositivos del sistema de navegación global satélite (GNSS) que se pueden usar para las plataformas Windows para satisfacer las necesidades de diversos niveles de dispositivos (bajo costo, extremo alto, diferentes tipos de dispositivos, etc.). Para habilitar este ecosistema enriquecido y aumentar el número de tabletas, portátiles y otros tipos de dispositivos que pueden incluir un chip GNSS a un costo menor, Microsoft no requiere que todos los dispositivos GNSS admitan el conjunto completo de características descritas en la referencia del controlador GNSS. En la tabla siguiente se proporciona una vista de alto nivel de la funcionalidad mínima necesaria para diferentes tipos de dispositivos y qué funcionalidad es opcional o recomendada.

Funcionalidad	Requisito para todas las plataformas	Requisito específico para teléfonos	Notas
Informar con precisión del GNSS_DEVICE_CAPABILITIES	Mandatory		Requisito de funcionalidad mínima
Compatibilidad con MultipleFixSessions	Opcionales		No es compatible con el adaptador de GNSS
Compatibilidad con MultipleAppSessions	Recomendado
Soporte técnico de asistencia de GNSS (específico de IHV)	Recomendado	Mandatory
Obtención del soporte técnico de asistencia de GNSS a través de Microsoft (uso de los Agss_inject IOCTLs)	Recomendado
Compatibilidad con la estructura de GNSS_FixData completa	Mandatory
Sesión de captura única	Mandatory
Compatibilidad nativa con sesiones de seguimiento basado en tiempo	Opcionales		Si se admite, debe incluir compatibilidad para modificar los parámetros de sesión.
Compatibilidad nativa con sesiones de seguimiento a distancia	Opcionales		Si se admite, debe incluir compatibilidad para modificar los parámetros de sesión.
Última sesión conocida	Opcionales
Compatibilidad nativa con geovalla	Opcional	Recomendado	Solo se requieren geovallas circulares y se admiten
Proporcionar ChipsetInfo	Mandatory		Uso del GNSS_ChipsetInfo
Informes de errores	Recomendado		Uso del GNSS_ErrorInfo
Informes a través de NMEA	Opcionales
Compatibilidad con pruebas de fabricación (onda portadora o prueba automática)	Opcionales
Ubicación del plano de control con integración con MBB	Obligatorio solo si es necesario por el operador de telefonía móvil	Mandatory	Normalmente, los operadores móviles requieren en dispositivos con soporte de voz. Casi siempre es necesario para teléfonos.
SUPL 1.0	Obligatorio solo si es necesario por el operador de telefonía móvil		En general reemplazado por SUPL 2.0. Incluye la implementación de los requisitos completos del operador de telefonía móvil, la configuración a través de DDI, la generación de informes de eventos de NI al sistema operativo a través de DDI e integración con MBB.
SUPL 2.x	Obligatorio solo si es necesario por el operador de telefonía móvil	Mandatory	Normalmente, los operadores móviles requieren en dispositivos con soporte de voz. Casi siempre es necesario para teléfonos. Incluye la implementación de los requisitos completos del operador de telefonía móvil, la configuración a través de DDI, la generación de informes de eventos de NI al sistema operativo a través de DDI e integración con MBB.
UPL	Obligatorio solo si es necesario por el operador de telefonía móvil		Solo debe ser compatible con esos dispositivos JAILBREAK que se envían en China, si es necesario por el operador de telefonía móvil. Incluye la implementación de los requisitos completos del operador de telefonía móvil, la configuración a través de DDI, la generación de informes de eventos de NI al sistema operativo a través de DDI e integración con MBB.
comando GNSS_SetLocationServiceEnabled driver	Mandatory
Comando GNSS_SetLocationNIRequestAllowed driver	Obligatorio solo si el OPERADOR de telefonía móvil admite y requiere SUPL.		Ya no hay operadores móviles conocidos que requieran esto
Comando GNSS_ForceSatelliteSystem driver	Recomendado		Bueno para fines de prueba. Algunos operadores móviles o OEM pueden requerir esto para las pruebas.
Comando GNSS_ForceOperationMode driver	Obligatorio solo si se admite SUPL		Algunos operadores móviles pueden requerir para fines de prueba.
Comando GNSS_ResetEngine driver	Mandatory		Con fines de prueba
Comando GNSS_ClearAgnssData driver	Mandatory		Con fines de prueba
Comando GNSS_SetNMEALogging driver	Opcionales		Solo si los operadores de telefonía móvil o los OEM lo necesitan para fines de prueba
Comando GNSS_SetSuplVersion driver	Obligatorio solo si se admite SUPL		Obligatorio para SUPL
Comando GNSS_SetUplServerAccessInterval driver	Obligatorio solo si el OPERADOR de telefonía móvil admite y requiere SUPL.		Solo si es necesario por el operador de telefonía móvil
Comando del controlador de GNSS_SetNiTimeoutInterval	Obligatorio solo si el OPERADOR de telefonía móvil admite y requiere SUPL.		Solo si es necesario por el operador de telefonía móvil
Comando del controlador de GNSS_ResetGeofencesTracking	Obligatorio solo si se admite la geovalla
Comando del controlador de GNSS_CustomCommand	Opcionales