Поделиться через

Требования к драйверу глобальной навигационной спутниковой системы (GNSS)

  • Статья

Описывает требования, допущения и ограничения, которые следует учитывать при разработке драйвера глобальной навигационной спутниковой системы (GNSS) для Windows 10.

Общие требования

  • Платформа драйверов: Драйвер GNSS должен быть записан как драйвер UMDF 2.0 на основе этого определения интерфейса, а не как необработанный драйвер WDM или драйвер KMDF. Драйверы UMDF 1.0 также не поддерживаются. Определение интерфейса драйвера GNSS или компоненты GNSS высокого уровня Майкрософт (HLOS), такие как адаптер GNSS, не делают различий между драйвером WDF, KMDF GNSS и драйвером UMDF 2.0, если драйвер предоставляет необходимые функциональные возможности для этого интерфейса. UMDF 2.0 обеспечивает более высокую стабильность, простоту и гибкость для реализации функций, требующих функциональности только в пользовательском режиме. Как правило, IHV следует предпочесть UMDF 2.0 KMDF, если предыдущая платформа доступна на платформе.

 UMDF 2.0 доступен на всех платформах, и IHV настоятельно рекомендуется использовать драйвер, написанный в пользовательском режиме.

  • Несколько сеансов приложения: Сеанс приложения — это сеанс позиционирования, исходящий из компонента HLOS, взаимодействующего непосредственно с драйвером GNSS. Драйвер GNSS может изначально поддерживать несколько сеансов приложений путем секционирования переменных состояния и функциональных возможностей на основе каждого приложения. Это необязательная возможность драйвера, указываемая специально с помощью четко определенных сведений о возможностях драйвера GNSS. Чтобы поддерживать это необязательное поведение, драйвер GNSS должен отслеживать дескриптор файла, который приложения HLOS получают во время CreateFile, и связать все последующие операции HLOS с дескриптором файла, зависящим от сеанса приложения. Эта встроенная поддержка драйвера GNSS позволяет компонентам HLOS быть более гибкими и менее строгими в отношении предоставления драйвера остальной части платформы. ДрайверУ GNSS, который поддерживает эту возможность, может потребоваться логически секционировать и поддерживать сведения о состоянии для каждого отдельного сеанса приложения. Драйвер GNSS, который не поддерживает эту возможность, должен поддерживать глобальное состояние только для всех сеансов приложения, а не для логического раздела приложения. В этом последнем режиме драйвер GNSS не замечает наличие нескольких параллельных сеансов приложения и обрабатывает все запросы от HLOS так, как если бы они были получены из одного сеанса приложения.

    Поддержка драйвера gnss для нескольких сеансов приложений.

    Поддержка нескольких сеансов приложений в драйвере GNSS позволяет тестового приложения в HLOS взаимодействовать непосредственно с драйвером GNSS одновременно с адаптером GNSS. Тестовое приложение и адаптер GNSS — это то, что мы рассмотрели разные приложения, которые могут одновременно запрашивать к одному драйверу GNSS разные сеансы. Если несколько сеансов приложений не поддерживаются, необходимо либо протестировать драйвер GNSS с помощью платформы расположения ОС, либо иным образом остановить службу, на котором размещена платформа расположения ОС, чтобы избежать вмешательства в работу тестового приложения.

  • Исправление сеанса: Процесс получения информации о расположении от базового драйвера (один снимок или отслеживание) абстрагируется в понятие сеанса фиксации. Драйверы должны поддерживать по крайней мере один сеанс исправления для каждого поддерживаемого типа сеанса. Типы сеансов определяются в перечислении GNSS_FIXSESSIONTYPE .

    • Как минимум, драйверы GNSS должны поддерживать один сеанс исправления.

    • Драйверы, поддерживающие сеансы исправления на основе расстояния, должны поддерживать одновременно один сеанс исправления выстрела и сеанс исправления на основе расстояния.

    • Драйверы, поддерживающие сеансы исправления отслеживания на основе времени, должны поддерживать одновременно один сеанс исправления выстрела и сеанс исправления на основе времени.

    • Драйверы, поддерживающие сеансы исправления отслеживания на основе расстояния и сеансы исправления на основе времени, должны поддерживать одновременно один сеанс исправления выстрела, сеанс исправления на основе расстояния и сеанс исправления на основе времени.

    поддержка нескольких одновременных сеансов исправления.

    Поддерживает ли драйвер несколько одновременных сеансов исправления, определяется четко определенным параметром возможностей драйвера. Если драйвер явно не поддерживает несколько параллельных сеансов исправления, он должен завершиться ошибкой нового запроса на исправление, если сеанс одного типа исправления уже запущен и активен. Если поддержка нескольких сеансов исправлений отсутствует, компонент HLOS отвечает за то, чтобы несколько запросов GNSS, поступающих от высокоуровневых приложений, мультиплексировались и сопоставлялись в одном запросе сеанса исправления с драйвером GNSS.

    Драйвер GNSS не требуется для поддержки нескольких параллельных сеансов исправления одного типа. На самом деле в Windows 10 адаптер HLOS GNSS не поддерживает использование возможности драйвера GNSS для нескольких сеансов исправления одного типа, поэтому IHV пока не рекомендуется инвестировать в эту функциональность. В будущих выпусках будет рассмотрено, что адаптер GNSS может напрямую запускать сеансы с драйвером GNSS для каждого запроса на исправление, полученного из верхних уровней платформы расположения, а не выполнять сам сеанс мультиплексирования. Поддержка мультиплексирования сеансов исправления в адаптере GNSS упрощает реализацию драйвера, так как она не требует обработки нескольких сеансов одного типа для приложения или реализации мультиплексирования, сокращает использование памяти в драйвере и не требует, чтобы адаптер GNSS обрабатывал случай, когда HLOS запускает несколько сеансов исправления, превышающих поддерживаемые драйвером GNSS. Разные уровни устройств и разные драйверы будут поддерживать разное количество одновременных сеансов исправления, поэтому этот случай необходимо будет обрабатывать, что усложняет адаптер GNSS для обработки всех случаев. Таким образом, в Windows 10 адаптер GNSS реализует только один сеанс исправления каждого поддерживаемого типа и игнорирует поддержку нескольких сеансов исправления драйвером, пока не потребуется эта функция.

    Каждый сеанс исправления работает с отслеживанием состояния и должен следовать следующей четко определенной последовательности:

    1. Запуск сеанса исправления

    2. Получение одного или нескольких исправлений

    3. При необходимости измените сеанс исправления

    Это требуется по крайней мере до тех пор, пока адаптер GNSS не обработает мультиплексирование сеансов исправления того же типа, и может даже потребоваться позже для обработки большего числа одновременных сеансов исправления, чем число поддерживаемых драйвером GNSS.

    1. Остановка сеанса исправления

    Сеансы исправления уникально идентифицируются идентификатором сеанса исправления. HLOS не может получить информацию о позиции вне контекста сеанса исправления. Драйвер GNSS должен разрешить изменение параметров сеанса на лету, чтобы упростить операцию мультиплексирования компонентом HLOS без необходимости перезапускать сеанс исправления.

    исправление обмена данными между драйвером gnss и приложением.

  • Тип исправления: Драйвер GNSS должен как минимум поддерживать базовое исправление одного выстрела. Кроме того, драйвер должен изначально поддерживать расширенные типы исправлений (например, отслеживание). Как упоминалось ранее, поддержка дополнительных типов исправлений подразумевает, что даже если драйвер не поддерживает несколько сеансов исправления одного типа, он должен поддерживать одновременно по крайней мере один сеанс исправления поддерживаемого типа. Компонент HLOS не мультиплексировать различные типы исправлений в один тип.

  • Интерфейс устройства и PnP: Драйвер GNSS должен объявить интерфейс устройства, определяемый Корпорацией Майкрософт, с помощью API WdfDeviceCreateDeviceInterface , чтобы HLOS могли получать уведомления о прибытии и отъезде драйвера GNSS. Это потребуется для обработки драйвера GNSS в параметре Plug and Play (PnP), а также в случаях, когда непредвиденная выгрузка драйвера происходит из-за сбоя службы на уровне пользователя, если драйвер является драйвером UMDF 2.0. Драйвер GNSS должен гарантировать, что интерфейс устройства объявляется только в том случае, если аппаратное обеспечение может поддерживать вызовы IOCTL HLOS, а не до этого.

  • Политика управления питанием устройств: Драйвер GNSS должен управлять политикой управления питанием своего устройства и обрабатывать события управления питанием, вызванные ОС. Драйвер должен зарегистрироваться для WDF_PNPPOWER_EVENT_CALLBACKS. Обратный вызов EvtDeviceD0Entry (вызывается WDF, когда система переходит в состояние D0) и WDF_PNPPOWER_EVENT_CALLBACKS. Обратный вызов EvtDeviceD0Exit (вызывается WDF при выходе системы из состояния D0). Драйвер GNSS должен быть настроен, чтобы при необходимости отключить управление питанием.

    Точное управление питанием, которое необходимо выполнить на устройстве GNSS в различных состояниях питания системы, должно быть адаптировано в соответствии с возможностями устройства GNSS (поддерживает ли оно операции разгрузки или нет), имеются ли фактические операции разгрузки активны и как осуществляется обмен данными между системой и устройством GNSS. Как правило, ожидания следующие:

    • Устройство GNSS будет работать в минимально возможном режиме питания, если нет активных сеансов или разгруженных операций, независимо от состояния питания системы.

    • В случае разгруженных сценариев, опять же, независимо от состояния питания системы, устройству GNSS может потребоваться проверка для положения с различными интервалами или получать уведомления, и, следовательно, устройству GNSS может потребоваться оставаться в состоянии D0 даже во время режима ожидания подключения (это состояние выключения экрана), но оборудование все равно должно уменьшить энергопотребление до минимума. Эта модель будет работать на тех устройствах, которые используют DMA (прямой доступ к памяти) или последовательный порт на UART для обмена данными с узлом, например. Но будет сложной задачей для этих устройств GNSS, подключенных через USB-шину. В этом случае, скорее всего, функция USB устройства должна находиться в состоянии питания устройства D2 (приостановка) во время режима ожидания подключения. Как правило, устройства GNSS, подключенные через USB, должны иметь возможность перейти в состояние с низким энергопотреблением D2 (приостановка) после того, как у них не будет сеансов исправления или разгруженных операций, а интерфейс USB-шины перейдет в состояние приостановки. Все переходы питания спящего режима и пробуждения должны быть переданы через USB-шину. Если на устройстве GNSS активные или разгруженные операции с сеансами исправления, устройство должно иметь возможность использовать сигнальную передачу возобновления через usb для пробуждения SoC или ядра из подключенного резерва. SoC или основной кремний должен иметь возможность пробуждения от самого низкого состояния питания в ответ на сигнальную передачу с устройства GNSS.

    • Устройства, которые не поддерживают подключенный режим ожидания, будут отменены все операции разгрузки в момент, когда устройство переходит в современный режим ожидания или гибернации. К ним относятся разгруженные геозоны, отслеживание расстояния или сеансы периодического отслеживания.

    • Устройства, поддерживающие подключенный режим ожидания, будут по-прежнему иметь все выгруженные операции активными, когда устройство переходит в режим ожидания подключения. Ожидается, что устройство GNSS продолжит операции отслеживания как можно эффективнее, а также должно предоставлять уведомления HLOS в случае, если условие триггера геозоны или обновление сеанса отслеживания имеет значение. Если на устройстве, поддерживающем подключенный режим ожидания, нет разгруженных операций, устройство GNSS должно перейти в минимально возможное состояние питания, но по-прежнему сможет прослушивать запросы сеанса расположения от HLOS. На устройствах, поддерживающих SUPL, устройство GNSS и стек SUPL также должны проснуться при уведомлениях NI в режиме ожидания с подключением.

    Общие сведения об управлении питанием для драйверов можно найти в разделе Обязанности по управлению питанием для водителей.

  • Рекомендации по энергопотреблению. Стек драйверов GNSS должен учитывать энергопотребление в качестве основной цели проектирования и свести к минимуму поддержание работоспособности процессора main насколько это возможно. Все расширенные функциональные возможности (например, различные типы исправлений) должны выполняться энергоэффективным способом, чтобы процессор приложений main не должен быть активен больше, чем требуется, и большую часть обработки можно выгрузить на микросхему или процессор с низким энергопотреблением. Как правило, если не указано иное в HLOS, драйвер GNSS всегда должен рассматривать энергопотребление как наиболее важное ограничение и должен быть разработан для выполнения обычных операций с минимальным объемом энергопотребления. Интерфейс драйвера GNSS явно разработан, чтобы позволить мобильному устройству как можно чаще переходить в режим низкого энергопотребления и предоставлять драйверу GNSS необходимые указания по энергопотреблению для оптимизации энергопотребления. Для отслеживания, геозон и других функций, требующих длительного мониторинга положения, драйвер или подсистема GNSS должны использовать преимущества оборудования и процессоров с низким энергопотреблением. Если такая функция должна быть реализована с помощью механизма опроса методом подбора в драйвере или если она должна быть реализована в обработчике приложений, драйвер не должен объявлять себя способным к таким операциям. Это позволит HLOS либо ограничить доступ к таким функциям для остальной части платформы, либо использовать альтернативную реализацию этих функций на основе других служб или примитивов платформы.

  • Язык программирования: Интерфейс драйвера GNSS предоставляется в виде файла заголовка языка C, который не использует примитивы языка C++ (например, наследование структуры). Это позволяет IHV выбирать между C и C++. Файл заголовка интерфейса GNSS оставляет выбор открытым для IHV.

  • Драйвер фильтра: Стек устройств GNSS не должен быть ограничен таким образом, чтобы предотвратить добавление в стек драйвера фильтра в будущем для поддержки расширенных функций. Драйвер GNSS, предоставляемый IHV, не должен содержать собственный драйвер фильтра ни в верхней, ни в нижней части стека драйверов.

  • Уведомления и события: Так как драйвер WDF не может отправить нежелательные уведомления в HLOS, всегда будет по крайней мере один ожидающий IRP, инициированный из HLOS, который служит для получения таких нежелательных уведомлений от уровня драйвера. Сюда входит случай, когда система находится в режиме ожидания подключения. Для драйвера GNSS такие нежелательные уведомления включают (но не ограничиваются ими) запросы, инициированные сетью, данные помощи для поддержки AGNSS, другие уведомления, относящиеся к поставщику. HLOS гарантирует, что ожидающий запрос ввода-вывода всегда присутствует для обработки таких уведомлений.

  • Расширение IHV в пользовательском режиме: IHV могут записывать компонент пользовательского режима, который взаимодействует с драйвером GNSS через частные ioCTL, определяемые IHV. Это особенно необходимо, если драйвер GNSS находится в режиме ядра. В этом случае он не имеет доступа к функциям, исключительно доступным в пользовательском режиме (например, Wi-Fi сканирования, API диспетчер подключений и т. д.). Обратите внимание, что при использовании UMDF 2.0 в Windows 10 драйверу UMDF GNSS не требуется отдельный компонент пользовательского режима, хотя IHV может по-прежнему реализовывать отдельный компонент пользовательского режима. Эти компоненты пользовательского режима рассматриваются как простое расширение драйвера GNSS и будут рассматриваться как часть доставляемого IHV сброса BSP. Предоставляемые корпорацией Майкрософт компоненты HLOS не заметив точные сведения о реализации таких компонентов и механизм взаимодействия между компонентами IHV в пользовательском режиме или режиме ядра. Если драйвер GNSS записывается как драйвер UMDF 2.0 с использованием расширений IHV в пользовательском режиме, не рекомендуется, так как эта модель, скорее всего, потребует больше использования памяти.

    Расширения IHV в пользовательском режиме должны соответствовать следующим правилам:

    • Семантика и поведение общедоступных ioCTL драйвера GNSS должны оставаться не затронутыми и не мешать расширению IHV в пользовательском режиме и его взаимодействию с драйвером GNSS.

    • Расширение пользовательского режима должно соответствовать основам безопасности, энергопотреблению и другим основам платформы и политикам, налагаемым платформой Windows 10.

    • Расширение пользовательского режима должно выполнять только авторизованные действия, утвержденные корпорацией Майкрософт, без принудительного применения и проверки такой авторизации платформой ОС во время выполнения.

    Корпорация Майкрософт по-прежнему может применять политики безопасности и контролировать время существования таких компонентов. Ключевым моментом здесь является то, что компоненты пользовательского режима IHV не должны рассчитывать на платформу для применения таких политик, так как компонент расширения рассматривается как доверенный компонент ОС.

    IHV не будут добавлять произвольные функциональные возможности или использовать несанкционированные службы ОС или защищенные ресурсы.

Минимальные требования к поддержке

Существует большое количество устройств глобальной навигационной спутниковой системы (GNSS), которые можно использовать для платформ Windows для удовлетворения потребностей различных уровней устройств (недорогие, высокопроизводительные, различные типы устройств и т. д.). Чтобы обеспечить такую богатую экосистему и увеличить количество планшетов, ноутбуков и других типов устройств, которые могут включать микросхему GNSS по более низкой цене, корпорация Майкрософт не требует, чтобы все устройства GNSS поддерживали полный набор функций, описанных в справочнике по драйверам GNSS. В следующей таблице представлено общее представление о минимальных функциональных возможностях, необходимых для различных типов устройств, и о том, какие функции являются необязательными или рекомендуемыми.

Функциональность Требования для всех платформ Особые требования для телефонов Примечания
Точное представление GNSS_DEVICE_CAPABILITIES Обязательный Требования к минимальной функциональности
Поддержка MultipleFixSessions Необязательно Не поддерживается адаптером GNSS
Поддержка MultipleAppSessions Рекомендуется
Поддержка GNSS Assistance (для IHV) Рекомендуется Обязательный
Получение поддержки GNSS через корпорацию Майкрософт (использование Agss_inject IOCTL) Рекомендуется
Поддержка полной структуры GNSS_FixData Обязательный
Сеанс одиночного выстрела Обязательный
Собственная поддержка сеанса отслеживания на основе времени Необязательно Если поддерживается, он должен включать поддержку изменения параметров сеанса.
Собственная поддержка сеанса отслеживания на основе расстояния Необязательно Если поддерживается, он должен включать поддержку изменения параметров сеанса.
Последний хорошо известный сеанс Необязательно
Встроенная поддержка геозон Необязательно Рекомендуется Требуются и поддерживаются только циклические геозоны
Предоставление набора микросхем Обязательный Использование GNSS_ChipsetInfo
Создание отчетов об ошибках Рекомендуется Использование GNSS_ErrorInfo
Отчеты через NMEA Необязательно
Поддержка производственных испытаний (несующая волна или самотест) Необязательно
Расположение уровня управления с интеграцией с MBB Обязательно, только если это требуется оператором мобильной связи Обязательный Обычно требуется мобильным операторам на устройствах с поддержкой голосовой связи. Почти всегда требуется для телефонов.
SUPL 1.0 Обязательно, только если это требуется оператором мобильной связи Как правило, заменено на SUPL 2.0.

Включает реализацию полного клиента, удовлетворяющего требованиям оператора мобильной связи, конфигурацию через DDI, отчеты о событиях NI в ОС через DDI и интеграцию с MBB.
SUPL 2.x Обязательно, только если это требуется оператором мобильной связи Обязательный Обычно требуется мобильным операторам на устройствах с поддержкой голосовой связи. Почти всегда требуется для телефонов.

Включает реализацию полного клиента, удовлетворяющего требованиям оператора мобильной связи, конфигурацию через DDI, отчеты о событиях NI в ОС через DDI и интеграцию с MBB.
UPL Обязательно, только если это требуется оператором мобильной связи Поддержка должна поддерживаться только для тех устройств CDMA, которые поставляемы в Китае, если это требуется оператором мобильной связи.

Включает реализацию полного клиента, удовлетворяющего требованиям оператора мобильной связи, конфигурацию через DDI, отчеты о событиях NI в ОС через DDI и интеграцию с MBB.
Команда драйвера GNSS_SetLocationServiceEnabled Обязательный
Команда драйвера GNSS_SetLocationNIRequestAllowed Обязательно, только если SUPL поддерживается и требуется оператором мобильной связи Ни один из известных операторов мобильной связи больше не требует этого
Команда драйвера GNSS_ForceSatelliteSystem Рекомендуется Хорошо подходит для тестовых целей. Некоторые мобильные операторы или изготовители оборудования могут потребовать этого для тестирования.
Команда драйвера GNSS_ForceOperationMode Обязательный, только если поддерживается SUPL Некоторые мобильные операторы могут требовать для тестирования.
Команда драйвера GNSS_ResetEngine Обязательный В целях тестирования
Команда драйвера GNSS_ClearAgnssData Обязательный В целях тестирования
Команда драйвера GNSS_SetNMEALogging Необязательно Только в том случае, если это требуется мобильным операторам или изготовителям оборудования для тестирования
Команда драйвера GNSS_SetSuplVersion Обязательный, только если поддерживается SUPL Требуется для SUPL
Команда драйвера GNSS_SetUplServerAccessInterval Обязательно, только если SUPL поддерживается и требуется оператором мобильной связи Только в том случае, если это требуется оператором мобильной связи
Команда драйвера GNSS_SetNiTimeoutInterval Обязательно, только если SUPL поддерживается и требуется оператором мобильной связи Только в том случае, если это требуется оператором мобильной связи
Команда драйвера GNSS_ResetGeofencesTracking Обязательно, только если геозона поддерживается
Команда драйвера GNSS_CustomCommand Необязательно