グローバル ナビゲーション サテライト システム (GNS) ドライバーの要件

Windows 10 用のグローバル ナビゲーション サテライト システム (GNS) ドライバーを開発する際に考慮すべき要件、前提条件、および制約について説明します。

一般的な要件

• ドライバー フレームワーク: 未加工の WDM ドライバーまたは KMDF ドライバーではなく、このインターフェイス定義に基づいて、UUID ドライバーを UMDF 2.0 ドライバーとして記述する必要があります。 UMDF 1.0 ドライバーもサポートされていません。 このインターフェイス設計に従ってドライバーが必要な機能を提供する限り、UUID ドライバー インターフェイス定義または MICROSOFT の高レベル オペレーティング システム (HLOS) のGNSS コンポーネント (UUID アダプターなど) は、WDF、KMDF の 2.0 ドライバーと UMDF 2.0 ドライバーを区別しません。 UMDF 2.0 は、ユーザー モードでのみ提供される機能を必要とする機能を実装するための、より高い安定性、シンプルさ、柔軟性を提供します。 一般的なルールとして、以前のフレームワークがプラットフォームで使用できる場合、IHV は UMDF 2.0 を KMDF よりも優先する必要があります。

 UMDF 2.0 はすべてのプラットフォームで使用でき、ユーザー モードで記述されたドライバーを使用することを強くお勧めします。

• 複数のアプリケーション セッション: アプリケーション セッションは、直接、GPS ドライバーと対話する HLOS コンポーネントから来る配置セッションです。 状態変数と機能をアプリケーションごとにパーティション分割することで、複数のアプリケーション セッションをネイティブにサポートすることを選択できます。 これはドライバーの省略可能な機能であり、明確に定義されたGNSS ドライバー機能情報を使用して具体的に示されます。 このオプションの動作をサポートするには、GNS ドライバーは、 CreateFile 中に HLOS アプリケーションが取得するファイル ハンドルを追跡し、後続のすべての HLOS 操作をアプリケーション セッション固有のファイル ハンドルに関連付ける必要があります。 このGNSNドライバーからのネイティブサポートにより、HLOSコンポーネントは、プラットフォームの残りの部分にドライバを公開することについて、より柔軟で制限が少なくなります。 この機能をサポートするGNSS ドライバーは、個々のアプリケーション セッションの状態情報を論理的にパーティション分割して維持する必要がある場合があります。 この機能をサポートしていないGNSS ドライバーは、論理アプリ固有のパーティションではなく、すべてのアプリケーション セッションのグローバル状態を維持する必要があります。 この後者のモードでは、複数の並列アプリケーション セッションが存在する場合、GNS ドライバーは気を付けられません。HLOS からの要求はすべて、同じアプリケーション セッションから送信されたかのように扱われます。

  

  複数のアプリケーション セッションに対するGNSS ドライバーのサポートには、HLOS のテスト アプリケーションが、GNS アダプターと同時に直接、GNS ドライバーと対話できるようにするという利点があります。 テストアプリケーションとGNSRアダプタは、1つのGNSRドライバに同時に異なるセッションを要求することができる異なるアプリケーションを考慮したものです。 複数のアプリケーション セッションがサポートされていない場合は、GNSS ドライバーをOS Location Platformを介してテストするか、またはテスト アプリケーションに干渉しないように、OS Location Platform をホストしているサービスを停止する必要があります。

• セッションを修正します。 基になるドライバー (シングル ショットまたは追跡) から位置情報を取得する行為は、修正セッションの概念に抽象化されます。 ドライバーは、サポートされている各セッションの種類の少なくとも 1 つの修正セッションをサポートする必要があります。 セッションの種類は、 GNSS_FIXSESSIONTYPE 列挙型の下で定義されます。

  • GNSSドライバーは、最低でもシングルショット測位セッションをサポートする必要があります。

  • 距離ベースの追跡修正セッションをサポートするドライバーは、単一ショット修正セッションと距離ベースの追跡修正セッションを同時にサポートする必要があります。

  • 時間ベースの追跡修正セッションをサポートするドライバーは、単一ショット修正セッションと時間ベースの追跡修正セッションを同時にサポートする必要があります。

  • 距離ベースの追跡修正セッションと時間ベースの追跡修正セッションをサポートするドライバーは、1 回のショット修正セッション、距離ベースの追跡修正セッション、および時間ベースの追跡修正セッションを同時にサポートする必要があります。

  

  ドライバーが複数の同時修正セッションをサポートしているかどうかは、明確に定義されたドライバー機能パラメーターによって表されます。 ドライバーが複数の並列修正セッションを明示的にサポートしていない場合は、同じ修正プログラムの種類のセッションが既に開始され、アクティブな場合は、新しい修正セッション要求を失敗する必要があります。 複数の測位セッションのサポートが存在しない場合、上位レベルのアプリケーションから送信される複数のGNSS要求が多重化され、単一の測位セッション要求としてGNSSドライバーにマッピングされるようにする責任がHLOSコンポーネントにあります。

  同じ種類の複数の並列修正セッションをサポートするために、GNSS ドライバーは必要ありません。 実際、Windows 10 では、HLOS GNSS アダプターは、GNSS ドライバーの機能を利用して同じ種類の複数の位置情報セッションを持つことをサポートしていないため、IHV が当面この機能に投資することは推奨されません。 今後のリリースでは、セッションの多重化を行うのではなく、場所プラットフォームの上位層から取得されたすべての修正要求に対して、直接、GNSS ドライバーとのセッションを開始するために、GNS アダプターを有効にすることが検討されます。 GNSS アダプターによる修正セッションの多重化のサポートは、同じ種類の複数セッションをアプリケーションまたは多重化の実装で処理する必要がないため、ドライバーの実装を簡略化します。これにより、ドライバーのメモリ使用量が減少し、HLOS が GNSS ドライバーでサポートされている以上の数の修正セッションを開始する必要もなくなります。 デバイスのレベルが異なり、ドライバーによってサポートされる同時修正セッションの数が異なるので、このケースを処理する必要があるため、すべてのケースを処理するための複雑さが発生します。 そのため、Windows 10 では、サポートされている種類ごとに 1 つの修正セッションのみが実装され、この機能が必要になるまで、ドライバーによる複数の修正セッションのサポートは無視されます。

  各修正セッションはステートフルであり、この明確に定義されたシーケンスに従う必要があります。

  1. 修正セッションの開始

  2. 1つ以上のパッチを取得する

  3. 必要に応じて修正セッションを変更する

  これは、少なくとも同じ種類のフィックス セッションの多重化をGNSSアダプターが処理するまで必要です。また、後で、GNSSドライバーでサポートされている数よりも多くの同時フィックス セッションがアクティブになった場合、それを処理する必要があることもあります。

  1. 修正セッションの停止

  修正セッションは、修正セッション ID によって一意に識別されます。 HLOS が修正セッションのコンテキスト外で位置情報を取得することはできません。 GNSSドライバは、修正セッションを再開することなく、HLOSコンポーネントによる多重化操作を容易にするために、その場でセッションパラメーターの変更を許可する必要があります。

  

• 修正の種類: GNSS ドライバは、基本的なシングルショット修正を少なくともサポートする必要があります。 さらに、ドライバーは、高度な修正プログラムの種類 (追跡など) をネイティブでサポートする必要があります。 前述のように、追加の修正プログラムの種類をサポートすることは、ドライバーが同じ種類の複数の修正セッションをサポートしていない場合でも、サポートされている修正プログラムの種類の少なくとも 1 つの修正セッションを同時にサポートする必要があることを意味します。 HLOS コンポーネントは、異なる修正タイプを 1 つのタイプに多重化しません。

• デバイス インターフェイスと PnP: GNSV ドライバーは、 WdfDeviceCreateDeviceInterface API を使用して Microsoft が定義したデバイス インターフェイスをアドバタイズして、HLOS がGNS ドライバーの到着と出発に関する通知を受け取ることができるようにする必要があります。 これは、プラグ アンド プレイ (PnP) 設定で、また、ドライバーが UMDF 2.0 ドライバーの場合、ユーザー レベルのサービスのクラッシュが原因で予期しないドライバーのアンロードが発生した場合に処理する必要があります。 デバイス インターフェイスは、基礎となるハードウェアが HLOS IOCTL 呼び出しをサポートできる場合のみアドバタイズされ、それ以前にはアドバタイズされません。

• デバイスの電源ポリシー: デバイスの電源ポリシーを管理し、OS によって発生する電源管理イベントを処理する必要があります。 ドライバーは、WDF_PNPPOWER_EVENT_CALLBACKSに登録する必要があります 。EvtDeviceD0Entry コールバック (システムが D0 状態になったときに WDF によって発生) と WDF_PNPPOWER_EVENT_CALLBACKS。EvtDeviceD0Exit コールバック (システムが D0 状態から終了したときに WDF によって発生します)。 必要に応じて電源管理を無効にするように、GNSS ドライバーを構成する必要があります。

  さまざまなシステム電源状態のGNSCデバイスで実行する必要がある正確な電源管理は、(オフロードされた操作をサポートしているかどうか)、実際のオフロード操作がアクティブかどうか、およびシステムとGNSNデバイス間の通信がどのように行われるかに応じて調整する必要があります。 一般に、期待値は次のとおりです。

  • システムの電源状態に関係なく、アクティブなセッションやオフロードされた操作がない場合、デバイスは可能な限り最小の電力モードで動作します。

  • オフロードされたシナリオの場合は、システムの電源状態に関係なく、再び、別の間隔で位置を確認するか、通知を受信する必要があります。したがって、GNS デバイスはコネクト スタンバイ中でも D0 状態を維持する必要があります (これはスクリーンオフスリープ状態です)。ただし、ハードウェアは電力消費量を最小限に抑える必要があります。 このモデルは、たとえば、DMA (ダイレクト メモリ アクセス) または UART のシリアル ポートを使用してホストと通信するデバイスで機能します。 しかし、USB バスを介して接続されているこれらのGNSS デバイスにとって課題になります。その場合、デバイスの USB 機能は、コネクト スタンバイ中に D2 (中断) デバイスの電源状態になる可能性が最も高くなります。 一般に、USB で接続されているGNSSデバイスは、修正セッションやオフロード操作が行われていないとき、USBバスインターフェースが中断状態に入ると共に、低電力D2（スリープ）状態に入ることができる必要があります。 すべてのスリープとスリープ解除の電源遷移は、USB バス経由で通知する必要があります。 GNSS デバイスが固定セッションをアクティブにしたり、オフロード操作がある場合、デバイスは接続スタンバイ状態から SoC またはコア シリコンを復帰させるために、インバンド USB 再開信号を使用できる必要があります。 SoC またはコア シリコンは、GNSSデバイスからの帯域内USB再開信号に応答して、最低消費電力状態から復帰できる必要があります。

  • コネクト スタンバイをサポートしていないデバイスでは、デバイスが最新のスタンバイまたは休止状態になったときに、オフロードされたすべての操作が取り消されます。 これには、オフロードされたジオフェンス、距離追跡、または定期的な追跡セッションが含まれます。

  • コネクト スタンバイをサポートするデバイスは、デバイスがコネクト スタンバイに移行したときに、オフロードされたすべての操作をアクティブにし続けます。また、デバイスはできるだけ効率的に追跡操作を続行することが期待されます。ジオフェンス トリガー条件または追跡セッションの更新が関連している場合は、HLOS に通知を提供することが期待されます。 コネクト スタンバイをサポートするデバイスにオフロード操作がない場合、デバイスは可能な限り最も低い電源状態に移行することになっていますが、HLOS からの場所セッション要求をリッスンできます。 SUPLをサポートするデバイスでは、コネクトスタンバイ中にGNSEデバイスとSUPLスタックがNI通知でウェイクアップすることも可能である必要があります。

  ドライバーの電源管理に関する一般的な情報については、「ドライバーの 電源管理の責任」を参照してください。

• 電源の考慮事項: GNSS ドライバースタックは、電力消費を最小限に抑えることを重視し、メインプロセッサのスリープ状態からの復帰をできる限り最小限に抑えることを重要な設計目標とする必要があります。 すべての高度な機能サポート (異なる修正の種類など) は、メイン アプリ プロセッサが必要以上にアクティブである必要がないため、電力効率の高い方法で実行する必要があり、ほとんどの処理をチップセット/低電力プロセッサにオフロードできます。 一般的なルールとして、HLOS から特に指示がない限り、GNS ドライバーは常に電力消費量を最も重要な制約として扱う必要があり、最小の電力フットプリントで通常の操作を実行するように設計する必要があります。 BIOS ドライバー インターフェイスは、モバイル デバイスができるだけ頻繁に低電力モードに移行できるように明示的に設計されており、電力使用量を最適化するために必要な電力関連のヒントを、BIOS ドライバーに提供します。 実行時間の長い広範な位置の監視を必要とする追跡、ジオフェンシング、およびその他の機能の場合、GNSV ドライバー/エンジンは低電力ハードウェア/プロセッサを利用する必要があります。 このような機能をドライバーのブルート フォース ポーリング メカニズムを使用して実装する必要がある場合、またはアプリ プロセッサに実装する必要がある場合、ドライバーはそのような操作を実行できるものとして宣言しないでください。 これにより、HLOS は、このような機能の他のプラットフォームへの公開を制限するか、他のプラットフォーム サービス/プリミティブに基づいてそれらの機能の代替実装を使用することができます。

• プログラミング言語： GNSV ドライバー インターフェイスは、C++ 固有の言語プリミティブ (構造体の継承など) を使用しない C 言語ヘッダー ファイルとして配信されます。 これにより、IHV は C と C++ のどちらかを選択できます。 GNSVインターフェイスヘッダーファイルは、IHVに対して開かれた選択肢を残します。

• フィルター ドライバー: 拡張機能をサポートするためにスタックに将来のフィルター ドライバーを追加できないように、デバイス スタックを制限しないでください。 IHV で提供されるGNSV ドライバーには、ドライバー スタックの上部または下部に独自のフィルター ドライバーを含めてはなりません。

• 通知とイベント: WDF ドライバーは HLOS に未承諾の通知を送信できないため、ドライバー層からこのような未承諾の通知を受信する目的を果たす、HLOS から開始された保留中の IRP が常に少なくとも 1 つ存在します。 これには、システムがコネクト スタンバイになっている場合が含まれます。 NSG ドライバーの場合、このような要請されていない通知には、ネットワークによって開始された要求、AGNSS サポートの支援データ、その他のベンダー固有の通知が含まれます (ただし、これらに限定されません)。 HLOS は、このような通知を処理するために保留中の I/O 要求が常に存在することを保証します。

• ユーザー モード IHV 拡張機能: IHV は、IHV で定義されたプライベート IOCTL を介して、GNS ドライバーと対話するアクセサリ ユーザー モード コンポーネントを記述できます。 GNSS ドライバーがカーネルモードで動作する場合、特にこれは必要です。その場合、ユーザーモードでのみアクセス可能な機能（例えば、Wi-Fi スキャン、接続マネージャー API など）にアクセスできません。 Windows 10 の UMDF 2.0 では、UMDF の UUID ドライバーには別のユーザー モード コンポーネントは必要ありませんが、IHV では別のユーザー モード コンポーネントが実装されている可能性があることに注意してください。 これらのユーザー モード コンポーネントは、単なる拡張として、GNSV ドライバーとして扱われ、IHV で提供される BSP ドロップの一部として扱われます。 Microsoft が提供する HLOS コンポーネントは、このようなコンポーネントの正確な実装の詳細と、IHV ユーザー モード/カーネル モード コンポーネント間の相互作用メカニズムを認識しません。 ユーザーモードの IHV 拡張機能を使用して GNSS ドライバーが UMDF 2.0 ドライバーとして書かれている場合、このモデルはメモリ使用量が多くなる可能性があるため、推奨されません。

  ユーザー モード IHV 拡張機能は、次の規則に従う必要があります。

  • パブリックなGNSS ドライバー IOCTL のセマンティクスと動作は、影響を受けず、ユーザー モードの IHV 拡張機能と、そのGNSS ドライバーとの対話によって妨げられていない必要があります。

  • ユーザー モード拡張機能は、Windows 10 プラットフォームによって課されるセキュリティ、電源、およびその他のプラットフォームの基本とポリシーに準拠している必要があります。

  • ユーザー モード拡張機能は、実行時に OS プラットフォームでこのような承認を適用/検証することなく、Microsoft によって承認された承認されたアクティビティのみを実行する必要があります。

  Microsoft は引き続きセキュリティ ポリシーを適用し、そのようなコンポーネントの有効期間を制御できます。 ここでの重要なポイントは、拡張機能コンポーネントが信頼された OS コンポーネントとして扱われるので、IHV ユーザー モード コンポーネントがこのようなポリシーを適用するためにプラットフォームでカウントされないようにすることです。

  IHV は、任意の機能を追加したり、承認されていない OS サービスやセキュリティで保護されたリソースを使用したりすることはありません。

最小サポート要件

Windows プラットフォームには、さまざまなレベルのデバイス (低コスト、ハイエンド、さまざまなデバイスの種類など) のニーズを満たすために使用できる、さまざまなグローバル ナビゲーション サテライト システム (GNS) デバイスが存在します。 このような豊富なエコシステムを有効にし、より低コストでGNSSチップを含むことができるタブレット、ラップトップ、その他のデバイスタイプの数を増やすには、MICROSOFT では、すべてのGNSデバイスが GNSドライバーリファレンスで説明されている機能の完全なセットをサポートする必要はありません。 次の表は、さまざまなデバイスの種類に必要な最小限の機能と、オプションまたは推奨される機能の概要を示しています。