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 satélite de navegación 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 procesar o un controlador KMDF. Tampoco se admiten controladores UMDF 1.0. La definición de la interfaz del controlador GNSS o los componentes de 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 funcionalidad que solo se ofrece en modo de usuario. Como regla general, los VHI deberían preferir UMDF 2.0 a KMDF cuando dicho framework esté disponible en la plataforma.

 UMDF 2.0 está disponible en todas las plataformas y se recomienda encarecidamente a los IHV usar el controlador escrito en modo 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 sobre la exposición del controlador al resto de la plataforma. Es posible que un controlador GNSS que admita esta funcionalidad tenga que crear particiones lógicamente 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 lógica específica de la aplicación. En este último modo, el controlador GNSS es ajeno 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 GNSS. La aplicación de prueba y el adaptador 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, se debe detener el servicio que hospeda la plataforma de ubicación del sistema operativo para evitar interferir con la aplicación de prueba.

• Sesión de fijación: El acto de obtener información de posicionamiento del controlador subyacente (captura única o seguimiento) se abstrae en el concepto de una sesión de fijació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 de GNSS deben admitir una sola sesión de corrección de capturas.

  • Los controladores que soportan sesiones de corrección de seguimiento basadas en distancia deben admitir simultáneamente una sesión de corrección puntual y una sesión de corrección de seguimiento basada en distancia.

  • Los controladores que admiten sesiones de corrección basadas en seguimiento por tiempo deben admitir simultáneamente una sola sesión de corrección puntual y una sesión de corrección basada en seguimiento por 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 puntual, una sesión de corrección de seguimiento basada en distancia y una sesión de corrección de seguimiento basada en 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 componente HLOS se encarga de asegurarse de que las múltiples solicitudes de GNSS 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 de 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á habilitar el adaptador de GNSS para iniciar 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 en sí. La compatibilidad con la multiplexación de sesiones de corrección en el adaptador 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 GNSS controle el caso de HLOS iniciando una serie de sesiones de corrección más grandes que lo que admite 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. Iniciar 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 de GNSS controla la multiplexación de sesiones de corrección del mismo tipo y puede incluso requerirse más adelante para controlar el caso de más sesiones de corrección simultáneas activas que el número admitido por el controlador GNSS.

  1. Detener la sesión de reparació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 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 captura única. Además, el controlador del sistema debe admitir tipos de corrección avanzados de manera nativa (como el seguimiento). Como se indicó anteriormente, admitir tipos de corrección adicionales implica que incluso si el controlador no admite 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 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 energía 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 necesite 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 estado de espera conectado (este es el estado de suspensión de pantalla desactivada), pero el hardware debe reducir el consumo de energía al mínimo. Este modelo funcionaría para esos dispositivos que usan DMA (acceso directo a memoria) o un puerto serie en un UART para comunicarse con el host, por ejemplo. Será un desafío para aquellos dispositivos GNSS conectados a través del bus USB, en cuyo caso, lo más probable es que la función USB del dispositivo deba estar en el estado de alimentación del dispositivo D2 (suspender) durante la espera conectada. En general, los dispositivos GNSS conectados a través de USB deben poder entrar en un estado D2 de baja potencia (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 alimentación de suspensión y reactivación deben indicarse a través del bus USB. Si el dispositivo GNSS tiene sesiones de fijación activas o operaciones descargadas, el dispositivo debe poder usar la señalización de reanudación USB dentro de banda para reactivar el SoC o núcleo de silicio desde el modo de espera conectado. El SoC o núcleo de silicio debe ser capaz de reactivarse desde su estado de menor consumo energético en respuesta a la señalización de reanudación USB en canal desde el dispositivo GNSS.

  • Los dispositivos que no admiten el modo de espera conectado tendrán todas las operaciones delegadas canceladas en el momento en que el dispositivo pasa al modo de espera moderno o hibernación. Esto incluye geocercas descargadas, seguimiento de distancias, o sesiones de rastreo periódicas.

  • Los dispositivos que admiten el modo de espera conectado seguirán teniendo activas todas las operaciones descargadas cuando el dispositivo entre en el modo de espera conectado. Se espera que el dispositivo GNSS continúe las operaciones de seguimiento de la manera más eficiente posible y proporcione notificaciones al HLOS en caso de que la condición de activación de la geovalla o una actualización de la 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 al recibir notificaciones de NI mientras están en modo de espera conectado.

  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 de controladores GNSS debe tener en cuenta el consumo de energía como objetivo de diseño principal y minimizar que el procesador principal se mantenga activo tanto como sea posible. Toda la compatibilidad con funcionalidades avanzadas (como tipos de corrección diferentes) debe ejecutarse de manera eficiente en términos de energía, de modo que el procesador de aplicaciones principal no necesite estar activo más de lo necesario y la mayoría del procesamiento se pueda descargar en el chipset o el procesador de bajo consumo. Como regla general, a menos que se indique lo contrario desde 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 baja potencia con la mayor frecuencia posible y proporcionar sugerencias necesarias relacionadas con la energía al controlador GNSS para optimizar el uso de energía. Para el seguimiento, la geovalla y otras funciones que requieren supervisión de posición generalizada de larga duración, el controlador o motor de GNSS debe aprovechar las ventajas de los procesadores o hardware de baja potencia. Si dicha funcionalidad debe implementarse mediante un mecanismo de sondeo por fuerza bruta en el controlador o si necesita implementarse en el procesador de la aplicación, el controlador no debe declararse como capaz de estas operaciones. Esto permitirá que el HLOS restrinja la exposición de dicha funcionalidad al resto de la plataforma o use una implementación alternativa de esas funcionalidades basadas en otros servicios de plataforma o primitivos.

• 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 cabecera de la interfaz GNSS deja la opción abierta a los 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 de controladores.

• 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 sirve para recibir cualquier notificación no solicitada de la capa de controlador. Esto incluye el caso en el que el sistema está en espera conectado. Para el controlador GNSS, estas notificaciones no solicitadas incluyen solicitudes iniciadas por la red (pero no están limitadas a), 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 del modo de usuario: Los IHV pueden escribir un componente accesorio de modo de usuario que interactúe con el controlador GNSS a través de IOCTLs privadas definidas por IHV. Esto es especialmente necesario si el controlador GNSS está en modo núcleo, en cuyo caso no tiene acceso a la funcionalidad disponible exclusivamente en modo de usuario (por ejemplo, escaneo Wi-Fi, API de Connection Manager, etc.). Tenga en cuenta que con UMDF 2.0 en Windows 10, un controlador GNSS de UMDF no necesita un componente independiente en modo de usuario, aunque el IHV puede seguir implementando un componente de modo de usuario independiente. Estos componentes en modo de usuario se consideran como una mera extensión del controlador GNSS y se tratarán como parte del paquete BSP proporcionado por el IHV. Los componentes HLOS proporcionados por Microsoft no conocen los detalles exactos de implementación de dichos componentes ni el mecanismo de interacción entre los componentes del modo de usuario y los del modo kernel de IHV. Si el controlador GNSS se escribe como un controlador UMDF 2.0 utilizando 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 siguientes reglas:

  • La semántica y el comportamiento de los IOCTL del controlador GNSS públicos deben permanecer sin afectarse ni ser obstruidos 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 con la seguridad, la potencia y otras directivas y aspectos básicos de la plataforma impuestas por la plataforma Windows 10.

  • La extensión en modo de usuario solo debe realizar las actividades autorizadas aprobadas por Microsoft, sin 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, ya que el componente de extensión se considera un componente confiable del sistema operativo.

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

Requisitos mínimos de soporte técnico

Habrá una gran variedad de dispositivos de sistema satélite de navegación global (GNSS) que se pueden usar para 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 dispositivo y qué funcionalidad es opcional o recomendada.