次の方法で共有

全地球航法衛星システム (GNSS) テストのガイダンス

  • [アーティクル]

この記事では、グローバル測位システム (GPS) の実装ガイドラインを提供して、Windows 8 および Windows 8.1 を実行しているコンピューターで、.高品質で競争力のある GPS エクスペリエンスを確保します。 この記事のガイドラインは、相手先ブランド供給 (OEM)、独立系ハードウェア ベンダー (IHV)、その他の Microsoft パートナー (ソフトウェア ベンダーなど) に適用されます。 この記事では、全地球航法衛星システム (GNSS) デバイスの Windows 8 システムへの統合のテストに焦点を当てています。

GPS 以外の領域のテストは、このドキュメントでは取り扱いません。 オペレーティング システム コンポーネントまたは GNSS デバイスの完全な使用方法は、このドキュメントでは取り扱いません。 IHV と OEM は、単体で、およびシステムに統合された形の両方で、GNSS デバイスを徹底的にテストすることが想定されています。 相互運用性テストは、位置プラットフォームおよびデバイスと相互に作用するコンポーネントに限定されます。 このテストには Windows Hardware Lab Kit (Windows HLK) テスト、このテスト計画、オペレーターの事前評価テスト、および GNSS ドライバーと GNSS レシーバー専用に開発された内部テストの正常な完了が含まれる必要があります。

Note

この記事では、GPS という用語を GNSS と同じ意味で使用します。 特に明記されていない限り、GPS では、衛星測位を、米国政府によって展開される GPS 衛星システムではなく、位置情報プロバイダー ソリューションと呼びます。

晴天条件とは、上または周囲の環境から水平線上 5 度の標高マスクまで、障害物のない信号を受信する GPS/GNSS 衛星として定義されます。 すべての信号レベルは、障害物のない地表面で、一貫して -131 dBm 以上である必要があります。

このドキュメントに記載された情報の対象となるオペレーティング システムは次のとおりです。

  • Windows 8

  • Windows 8.1

この記事の内容:

パートナーからの要件

Microsoft パートナーが認定を受けるには、次の要件を満たしている必要があります。

  • アシスト型 GPS (A-GPS) のテストおよびデバイスをコールドスタートできる機能を有効にするには、GNSS ドライバーで SENSOR_PROPERTY_CLEAR_ASSISTANCE_DATA プロパティをサポートしている必要があります。 データ レポートで National Marine Electronics Association (NMEA) センテンスをオンまたはオフにするには、GNSS ドライバーで SENSOR_PROPERTY_TURN_ON_OFF_NMEA をサポートしている必要があります。 既定では、NMEA ラインはデータ レポートに含まれていません。 この要件については、以下の場所で明示的に説明しています。

    //{e1e962f4-6e65-45f7-9c36-d487b7b1bd34}DEFINE_GUID(SENSOR_PROPERTY_TEST_GUID, 0XE1E962F4, 0X6E65, 0X45F7, 0X9C, 0X36, 0XD4, 0X87, 0XB7, 0XB1, 0XBD, 0X34);DEFINE_PROPERTYKEY(SENSOR_PROPERTY_CLEAR_ASSISTANCE_DATA, 0XE1E962F4, 0X6E65, 0X45F7, 0X9C, 0X36, 0XD4, 0X87, 0XB7, 0XB1, 0XBD, 0X34, 2); //[VT_UI4]

    DEFINE_PROPERTYKEY(SENSOR_PROPERTY_TURN_ON_OFF_NMEA, 0XE1E962F4, 0X6E65, 0X45F7, 0X9C, 0X36, 0XD4, 0X87, 0XB7, 0XB1, 0XBD, 0X34, 3); //[VT_UI4]

    #define GNSS_CLEAR_ALL_ASSISTANCE_DATA 0x00000001

    SENSOR_PROPERTY_ CLEAR_ASSISTANCE_DATA (PID = 2)

    VT_UI4. 書き込み。 アシスタンス データをクリアします。 GNSS_CLEAR_ALL_ASSISTANCE_DATA の値を設定すると、時刻 (time)、暦 (almanac)、天体暦 (ephemeris)、および最終位置 (last position) などのすべてのアシスタンス データをクリアするよう、ドライバーに通知が行われます。Windows HLK テストでは、この値を設定して、コールド スタート テストの前、A-GPS テストの前、または時間と場所がシミュレートされているシミュレーター テストを実行する前に独立して、アシスタンス データをクリアできます。 A-GPS 機能 (SUPL、LTO など) がサポートされている場合、ドライバーはこの操作の後にネットワーク接続を使用して機能を利用できます。 ただし、デバイスは、デバイスまたはシステムにアシスタンス データが保存されていない状態になっている必要があります。 すべてのアシスタンス データ要素が再度ダウンロードされます。

    SENSOR_PROPERTY_TURN_ON_OFF_NMEA (PID = 3)

    VT_UI4. 読み取り/書き込み。 TRUE に設定すると、NMEA センテンスがデータ レポートに含まれます。 False に設定すると、NMEA センテンスがデータ レポートに含まれません。 Windows HLK テストでは、このプロパティを使用して、データ レポートへの NMEA データの包含を開始または停止するよう、デバイスに指示することができます。

  • 必要な Windows Hardware Lab Kit (Windows HLK) テストに加えて、オプションの Windows HLK Device.Input テスト を実行し、Arm 以外のシステム オン チップ (SoC) システムに合格する必要があります。 (これらのテストは、Arm システムでは既に必須です)。

  • OEM と IHV は、システム、デバイス、またはドライバーを Microsoft に提出する前に、GPS 受け入れテスト マトリックスに指定されているテストを実行し、文書化する必要があります。

  • IHV は、GPS ドライバーが原因で発生した問題について、[ハードウェア ダッシュボード] から、[分析] セクションの下で、報告されたエラーを確認し、影響の大きいすべてのエラーを修正する必要があります。

  • OEM からのアンテナの要件には、アンテナ パフォーマンス テスト.に記載されている項目を含める必要があります。

  • 動的ナビゲーションの精度とアンテナの品質を確認するには、システムで SENSOR_DATA_TYPE_NMEA_SENTENCE プロパティがサポートされている必要があります。

  • GPS ソリューションは、サードパーティのサービスや Win32 アプリケーションに対する依存関係を伴うことはできません。 サードパーティの Win32 アプリケーションは、SoC システムでの署名要件の対象であるため、許可されません。

  • USB 接続された GPS デバイスは、セレクティブ サスペンドをサポートしている必要があります。

  • モバイル ブロードバンド モジュールの GPS はUnified Extensible Firmware Interface (UEFI) を使用して更新する必要があり、スタンドアロン GPS はドライバーを使用して更新する必要があります。

  • GPS とモバイル ブロードバンドが同じ物理チップに存在する場合、GPS デバイスは USB 複合デバイスの一部として公開され、独自の USB インターフェイスを備えている必要があります。

レポートと結果の通信

Microsoft は、バグを使用して、すべての問題をパートナーに伝えます。 バグには Windows HLK ログ、トレース、ドライバー ログ、クラッシュ ダンプ、および関連するパフォーマンスの結果とベースライン パフォーマンスの比較データが含まれます。

テスト機器

この記事で説明されているテストの実行には、次のテスト機器を使用します。

  • Spirent GSS6700 GNSS シミュレーター

  • Faraday ケージ

  • RF シールド ボックス

  • モバイル ブロードバンド SIM

  • 参照デバイス: Garmin Montana; Microsoft Signature を使用して認定されている GPS デバイスが備わっている Windows タブレット。

  • 外部アンテナ

機能テスト

GNSS デバイスに適用される Windows HLK テストは、GPS デバイスの基本的な機能を確認するための最初のテストセットです。 Windows HLK には、GPS センサーのテスト、無線マネージャーのテスト、Device Fundamentals のテスト、System Fundamentals 電力管理のテスト、および GNSS デバイスに適用される USB ハードウェア認定テスト (USB 接続デバイスの場合) が含まれています。

センサー カテゴリ、タイプ、プロパティ、およびデータ フィールド

説明: デバイスは、正しいセンサーのカテゴリとタイプを報告し、必須プロパティとデータ フィールドをサポートし、正確なデータを報告する必要があります。 Windows HLK で検証される必須のセンサー プロパティに加えて、マネージド プログラム システムは SENSOR_DATA_TYPE_NMEA_SENTENCE プロパティをサポートする必要があります。

実行ステップ: センサー カテゴリ、タイプ、プロパティ、およびテスト中のデバイス (DUT) が報告するデータ フィールドをクエリします。 報告されたデータの精度を確認します。 Windows Driver Kit (WDK) のセンサー診断ツール (SDT) を使用して、これらの項目をテストできます。

想定される結果: 必須フィールドがサポートされ、正確なデータを報告する必要があります。

状態遷移

説明: デバイスは、「位置センサー ドライバーの作成」に記載されているように、センサー状態の変化を報告する必要があります。

  • データ レポートは、デバイスが SENSOR_STATE_READY または SENSOR_STATE_INITIALIZING に達した後にのみ報告される必要があります。

  • 緯度と経度の情報がない場合、デバイスはデータを報告してはなりません。

  • GPS センサーは、測位を取得する前に、SENSOR_STATE_INITIALIZING 状態で起動する必要があります。

  • GPS センサーは、測位の取得を継続し、オペレーティング システムによって要求が取り消されるまで、SENSOR_STATE_INITIALIZING 状態に居続ける必要があります。

  • GPS センサーは、信号をロスしてデータがなくなったときに SENSOR_STATE_INITIALIZING 状態になる必要があります。 これは、測位を再取得するときに SENSOR_STATE_READY の状態に戻る必要があります。

実行ステップ: デバイスを無効にしてから再度有効にしている間は、状態遷移とデータ イベントを監視する必要があります。 GPS 信号のない領域 (Faraday ケージなど) に移動し、少なくとも 1 分間待機して、カバレッジがある領域にデバイスを戻します。

想定される結果: デバイスは、センサーの状態の遷移 (たとえば、SENSOR_STATE_INITIALIZING から SENSOR_STATE_READY へ) を報告する必要があります。また、データ レポートは、これらの状態に達した後でのみ報告する必要があります。 データは、緯度と経度の情報が使用可能な場合にのみ報告されます。 デバイスは、SENSOR_STATE_INITIALIZING 状態で起動する必要があります。また、測位が行われ、有効なエラー半径を取得するまでは、SENSOR_STATE_READY 状態に移行してはいけません。 デバイスを GPS 信号カバレッジ領域外に移動すると、デバイスは SENSOR_STATE_INITIALIZING 状態になり、カバレッジ領域内に戻ると SENSOR_STATE_READY に戻る必要があります。

緯度と経度の精度

説明: デバイスは、指定された誤差半径内で正確な緯度と経度の値を提供する必要があります。

実行手順: 静的なテスト中と車両内テスト中は、デバイス データは、GPS、サーベイ マーカー、およびシミュレーター　レポートを参照する緯度および経度のデータと比較されます。

想定される結果: デバイスが報告する緯度と経度の値と GPS レポートのリファレンス値との差は、誤差半径内にある必要があります。

速度データ

説明: デバイスでは、移動時に速度データをノット単位で報告する必要があります。

実行手順: シミュレートされた車両内のテストまたはドライブ テスト中にデバイスが報告する速度データを監視します。

想定される結果: デバイスでは、リファレンス GPS またはシミュレーターが報告する速度データの 15% 以内の精度の速度データを報告する必要があります。

進行方向データ

説明: デバイスでは、移動しているとき、真北からの相対角度で進行方向を報告する必要があります。

実行手順: シミュレートされた車両内のテスト中、手動歩行テスト中、ドライブ テスト中にデバイスによって報告された進行方向データを監視します。

想定される結果: デバイスでは、進行方向データを報告する必要があります。このデータはリファレンス GPS またはシミュレーターが報告する進行方向データの 15% 以内である必要があります。

その他のセンサーのプロパティ

説明: デバイスで他のセンサーのプロパティがサポートされている場合、そのプロパティでは有効で正確な値を報告する必要があります。

実行手順: デバイスがサポートしているプロパティを監視し、許容される精度範囲内の有効なデータが提供されていることを確認します。

想定される結果: あるデバイスが特定のセンサー プロパティをサポートしている場合、そのデバイスでは、リファレンス GPS またはシミュレーターによって報告された値の ±20% 以内の精度の値を報告する必要があります。

アシスト型 GPS のテスト

最初の電源オンから数秒以内に、GPS デバイスはアシスト型 GPS を使用して近似位置を返す必要があります。 GPS がアシスト型 GPS を使用する場合、センサーは位置データを提供する必要があります。これは、数百メートルから 6 桁の数値までのデータになる可能性があります。 GPS 受信機が複数のサテライト ロックを取得できる場合、誤差半径は 3 から 30 m の値に減少します。

アシスト型 GPS

説明: アシスト型 GPS は、より高い精度の初回測位時間 (TTFF) をより速く取得するのに役立ちます。

実行手順: GPS デバイスをコールドスタートします。 SDT を使用して、緯度、経度、および誤差半径データ フィールドを監視します。

テストは次の条件で実行する必要があります。

  • 晴天条件 (シミュレートまたは実際)

  • データ イベントについてサブスクライブ済み

  • 1 秒の報告間隔

  • Wi-Fi または携帯電話のベースバンドが存在し、有効になっている

想定される結果: デバイスは、できるだけ早くアシスト型 GPS からの位置を返し、関連する誤差半径を報告する必要があります。 大きい誤差半径 (たとえば、Wi-Fi 使用時の 300 メートル) が、デバイスが複数のサテライト ロックを取得すると、3 から 30 メートルに減少するはずです。 GPS は、アシスト データに基づく位置を 15 秒以内に報告する必要があります。

位置の挿入

GPS ドライバーは、その三角測量センサーからのデータを使用して、センサー API (ISensorManager) を使用して TTFF を高速化できます。 ドライバーが使用されている場合は、次のテストが適用されます。

  • 接続時間

    説明: GPS ドライバーは、位置を取得した直後に他のセンサーへの接続を閉じる必要があります。 15 秒後にタイムアウトし、位置が取得されない場合はセンサー API への接続を閉じる必要があります。

    実行手順: システム内のすべてのセンサーについて、アクティブなクライアントのカウントについてのセンサー API からのトレースを監視します。 GPS デバイスをコールドスタートし、システム内の他のセンサーについて、アクティブなクライアントのカウントの変化を監視します。

    想定される結果: 他のセンサーについてアクティブなクライアントのカウントがインクリメントされる場合、15 秒後に以前に記録された値に戻る必要があります。

  • 接続の種類

    説明: GPS ドライバーは ILocation をインスタンス化して他の場所のセンサーからのデータを取得してはいけません。 センサー API を使用して、三角測量センサー (SENSOR_TYPE_LOCATION_TRIANGULATION) のインスタンスへの接続を開くことができます。 GPS ドライバーは、同じ種類の位置センサーからデータを取得してはいけません。 たとえば、GPS センサーでは、GPS 型の他のセンサーからのデータを使用して、測位を高速化することはできません。

    実行手順: デバイスが報告しているセンサーの種類を検出します (例: SENSOR_TYPE_LOCATION_GPS)。 デバイスと同じ種類のセンサーを除くすべてのセンサーを無効にします。 システム内の有効になっているセンサーについて、アクティブなクライアントのカウントについてのセンサー API からのトレースを監視します。 GPS デバイスをコールドスタートします。 システム内のセンサーについて、アクティブなクライアントのカウントの変化を監視します。

    想定される結果: デバイスは、同じ種類のセンサーについて、アクティブなクライアントのカウントをインクリメントすべきではありません。

信頼性

ドライバー検証ツール、WDF 検証ツール、およびアプリケーション検証ツールは、位置情報プラットフォームと GPS デバイス スタックに対して有効にされ、システムでの GPS サポートの信頼性をテストします。

ドライバー検証ツールは、Windows オペレーティング システムの一部です。 次の設定を使用して、管理者特権をもつコマンド プロンプトから起動できます。

Verifier /standard /driver wudfpf.sys Wdf01000.sys Wdfldr.sys wudfrd.sys<any kernel mode driver>, <dependent kernel mode drivers>

ここで、<any kernel mode driver> は検証対象のドライバーであり、<dependent kernel mode drivers> は GPS ドライバーが依存するカーネル モード ドライバー (たとえば、wmbclass.sys など) です。

ドライバー検証ツールの詳細については、「ドライバー検証ツールについて」を参照してください。

WDF 検証ツールは、すべての WDF ドライバーについて既定で有効になっています。 WDK の WdfVerifier.exe ツールを使用して、ログ記録やデバッガー設定などの詳細度を制御できます。 WDF 検証ツールの詳細については 「WDF Verifier Control Application」を参照してください。

アプリケーション検証ツール(appverif.exe) は、Windows HLK と Windows 8.1SDK で使用できます。 最低限の基本設定が必要です。

ドライバー検証ツール、WDF 検証ツール、アプリケーション検証ツール

説明: テストの最初でアプリケーション検証ツールとドライバー検証ツールを有効にします。

実行手順: ドライバー パッケージ内のすべてのカーネル モード ドライバー (ある場合) についてドライバー検証ツールを有効にし、GPS ドライバーが依存するカーネル モード ドライバーを有効にします。 %windir%\system32\WUDFHost.exe と、GPS ドライバーが依存する他のユーザー モード バイナリ (wwanapi.dll など) について、アプリケーション検証ツールを有効にします。

想定される結果: 検証ツールのエラーはありません。

テレメトリ データ

説明: GPS ドライバーについて、[分析] セクションの下の [ハードウェア ダッシュボード] からテレメトリ データを監視します。

実行手順: GPS ドライバーについて、[分析] セクションの下の [ハードウェア ダッシュボード] からテレメトリ データを監視します。 ドライバーのエラーを特定、調査、修正します。

想定される結果: デバイスでは、すべてのテレメトリ エラーを報告する必要があります。主要な問題をトリアージ、調査、修正する必要があります。

GPS ストレス テスト

シミュレーターのテスト、ウォーク テスト、およびドライブ テスト中に、次の操作の組み合わせが GPS デバイスで同時に実行されます。

  • Enable Driver Verifier (ドライバーの検証ツールの有効化)

  • Enable application verifier (アプリケーション検証ツールの有効化)

  • Repeated Windows HLK test runs (GPS Sensor, Radio Manager, System Power Management) (Windows HLK テストの繰り返し実行 (GPS センサー、無線マネージャー、システム電力管理))

  • Radio management operations (無線管理操作)

  • Connected Standby (コネクテッド スタンバイ)

  • GPS device disable/re-enable (GPS デバイスの無効化/再有効化)

  • Windows Location Provider disable/re-enable (Windows ロケーション プロバイダーの無効化/再有効化)

  • Mobile Broadband device disable/re-enable (モバイル ブロードバンド デバイスの無効化/再有効化)

  • Wi-Fi device disable/re-enable (Wi-Fi デバイスの無効化/再有効化)

  • Turn off Mobile Broadband radio (モバイル ブロードバンド無線をオフ)

  • Turn off Wi-Fi Radio (Wi-Fi 無線をオフ)

  • Large download over Mobile Broadband connection (モバイル ブロードバンド接続を使用した大規模ダウンロード)

  • Large download over Wi-Fi connection (Wi-Fi 接続を使用した大規模ダウンロード)

  • Bluetooth activity (Bluetooth アクティビティ)

ストレス テストの前に基本的な検証テストを実行します。 同じ検証テストについて、ストレス テストの前と後の両方で合格し、障害が見られないことが想定されています。

パフォーマンス

GPS デバイスのパフォーマンスは、コールド スタート TTFF、ホット スタート TTFF、取得感度、追跡感度、再取得時間、静的ナビゲーション精度、動的ナビゲーション精度についてテストされます。

OTA 接続をもつ GNNS シミュレーターを、パフォーマンス テストに使用できます。

コールドスタート TTFF

説明: コールド スタート TTFF は、90% の時間で 45 秒未満で実現する必要があります。 コールドスタートの条件は、次のように説明されます。

  • 時刻は不明

  • 現在の ephemeris は不明

  • 位置は不明

実行手順: コールド スタート テストを開始する前に、SDT を使用して GPS アシスト データをクリアできます。 上記のコールドスタート条件が満たされていることを確認します。 晴天条件 (実際またはシミュレート) 下で TTFF を監視します。

想定される結果: デバイスは、GNSS デバイスを使用して、90% の時間で 45 秒以内に測位を取得する必要があります。

取得の感度

説明: デバイスは、-150 dBm 以下の電源レベルで測位を取得する必要があります。

実行手順: シミュレートされたラボの条件下で、アンテナ コネクタにアクセスできる場合に直接無線周波数 (RF) 接続を使用して、デバイスを -150 dBm までの低電力レベルに露出させます。

想定される結果: デバイスは -150 dBm で測位を取得する必要があります。

トラッキングの感度

説明: デバイスは、-155 dBm 以下の電力レベルで測位を維持する必要があります。

実行手順: シミュレートされたラボの条件下で、アンテナ コネクタにアクセスできる場合に直接 RF 接続を使用して、デバイスが測位を取得した後、電力電力レベルを -155 dBm に低下させます。

想定される結果: デバイスは、測位 -155 dBm を維持する必要があります。

再取得時間

説明: デバイスは、測位を 2 秒で再取得できる必要があります。 信号が使用可能な場合は、晴天条件であると仮定されます。

実行手順: シミュレートされたラボの条件下で、デバイスが測位を取得した後、デバイスが測位を失うまで電力レベルを下げます。 次に、電力レベルを上げ、再取得時間を監視します。 または、ドライブ テスト中にトンネルを通過する方法もあります。

想定される結果: デバイスは、測位を 2 秒で再取得できる必要があります。

静的ナビゲーションの精度

説明: デバイスは正確な緯度、経度、高度 (サポートされている場合) を報告する必要があります。

実行手順: 経度、緯度、高度 (使用可能な場合) の精度を、信頼できるデータ ソースからの位置と比較します。 信頼できるデータ ソースには、サーベイ マーカー、GNSS シミュレーター、または GPS を備えた Microsoft Signature 認定 Windows タブレットを使用できます。

想定される結果: DUT は 15 メートルの水平精度と 30 メートルの垂直精度を 95% の時間報告する必要があります。

動的ナビゲーションの精度

説明: DUT がモバイルの場合、DUT は、緯度、経度、高度 (サポートされている場合) を正確に報告する必要があります。

実行手順: シミュレートまたは実際のデバイス テスト/ウォーク テスト中に、経度、緯度、高度 (使用可能な場合) の精度を、信頼できるデータ ソースからの位置と比較します。 信頼できるデータ ソースには、サーベイ マーカー、GNSS シミュレーター、または GPS を備えた Microsoft Signature 認定 Windows タブレットを使用できます。

想定される結果: デバイスは 15 メートルの水平精度と 100 メートルの垂直精度を報告する必要があります。

電力消費テスト

次の図は、ドライバーが WDF アイドル検出 StopIdle/ResumeIdle メソッドを使用して D 状態間を移動する方法を示しています。  このセクションのテスト ケースでは、ドライバーが適切な時刻に正しい状態に戻ることを確認します。

< Art placeholder for Fig1_ Fig1_stopidle_resumeidle>

図 1. StopIdle/ResumeIdle

USB セレクティブ サスペンド

このテストは、USB に接続されたデバイスにのみ適用されます。 8 秒以下のレポート間隔でサブスクライブするクライアントがない GPS デバイスは、バス上のすべてのデバイスが Suspend 状態に入る準備ができたら、セレクティブ サスペンドに参加する必要があります。

デバイス マネージャーと Windows イベント トレーシング (ETW) イベントは、USB バスの状態遷移を監視するために使用されます。

平均スリープ電力消費量

GPS デバイスでは、バス接続インターフェイスを含め、スリープの平均電力消費量が 1mW 未満である必要があります。 そうではない場合、D3 (D3-Cold) にあるときは、デバイスは GPS デバイスへの完全な電力供給の停止をサポートする必要があります。

D3-Cold

D3cold をサポートするデバイスでは、6 秒を超える TTFF のパフォーマンス低下は発生してはいけません。 たとえば、デバイスがホットスタート条件下で 2 秒で測位を取得できる場合、D3cold からレジュームするときには 8 秒以下で測位を取得できる必要があります。 デバイスがこの要件を満たすことができない場合、ドライバーは GPS 受信機が無効になっているときには D3cold 状態への遷移を制限する必要があります。

D3cold の詳細については、「ドライバーでの D3cold のサポート」をご覧ください。

電力管理のテスト

コネクテッド スタンバイ

コネクテッド スタンバイ テストには、Windows HLK PowerState テストと IO カバー テスト シナリオのある Device Fundamentals テストが含まれています。

カバレッジのない領域でのレジューム

説明: アクティブなクライアントがあるときに、システムをコネクテッド スタンバイ状態にします。 カバレッジのない領域でレジュームします。 デバイスは測位の取得を試行して、SENSOR_STATE_INITIALIZING 状態に入ります。

実行手順: アクティブなクライアントが接続されている場合は、デバイスをコネクテッド スタンバイにします。 GPS 信号がない領域で、コネクテッド スタンバイから復帰します。

想定される結果: デバイスは測位を取得し SENSOR_STATE_INITIALIZING 状態に入る必要があります。

アンテナ パフォーマンス テスト

OTA 接続を使用するパフォーマンス テスト

ケーブル接続された RF 接続を使用してラボ環境で GNSS レシーバーをパフォーマンス テストし、GPS アンテナとその関連の回路をバイパスするのが一般的です。 GPS アンテナとその回路でのデバイスのパフォーマンスと問題は、ロケーションベースのサービス アプリケーションでのユーザー エクスペリエンスを損なう可能性があります。 こうした問題を検出するには、OTA テスト手法を使用して、マネージド システム デバイスで GPS パフォーマンスをテストする必要があります。

アンテナ テストには、認証に関する次の要件が含まれています。

  • GPS をサポートしているシステムでは、セルラー通信工業会 (CTIA) のモバイル ステーションの無線パフォーマンス テスト計画、無線周波数 (RF) パワーの測定方法、アシスト型 GPS のレシーバー パフォーマンス v3.0+ に従ってテストに合格する必要があります。 CTIA のテストの詳細については、「CTIA 認定テスト」を参照してください。 さらに、Total Is sensitivity (TIS)、Upper Hemisphere Is sensitivity (UHIS)、Partial Issphere GPS Sensitivity (PIGS) を測定する必要があります。OEM は、測定結果を Microsoft に提出してレビューを受ける必要があります。 これらの要件は、モバイル ブロードバンドをサポートしているシステムに適用されます。

  • システムでは、GPS について、TIS と UHIS のフリー スペースが -140 dBm 以上である必要があります。 モバイル ブロードバンドをサポートしているシステムの場合、測定は、CTIA 3.x テスト計画の「Wi-Fi 専用システムの実行ガイドラインのアンテナ パフォーマンス」セクションで定義されているテスト手法とテスト パラメーターに従う必要があります。

  • GPS アンテナの平均ゲインは-6dBi より優れた値である必要があります。

  • デバイスが一般的な保持位置にある場合、パフォーマンスが許容される最低限の標準を下回ってはいけません。 システムが一般的な保持位置にある場合、デバイスは無線 (OTA) 取得感度 -140 dBm、OTA 追跡感度 -145 dBm を維持する必要があります。

  • キーボードまたはドッキング ステーションが閉じているときに、デバイスは、 OTA 取得感度-140 dBm、OTA 追跡感度 -145 dBm を維持する必要があります。

  • GPS アンテナがデバイス内の想定される位置にあるときに、アンテナ テストと放射感度テストを実行する必要があります。

  • エンジニアリング検証 (EV) システムでは、意図した GPS 実稼働アンテナが、意図した位置にある必要があります。 設計検証 (DV) システムでは、アンテナの位置を最終的に決定する必要があります。

  • OEM は、アンテナのパフォーマンス テストと放射感度テストを実施し、EV ユニットの問題点を把握する必要があります。 テストは、DV ユニットの前に合格する必要があります。

Wi-Fi 専用システムの RF 感度テスト

GPS IHV では、NMEA のログ記録とプロット ツールとドキュメントを提供できます。

テスト デバイスと、同じ場所、同じ条件下で GPS RF 感度が良好なリファレンス デバイスで、信号対雑音比 (SNR) を比較します。 IHV NMEA ログを有効にし、晴天条件下でデバイスの 15 分以上のウォーク/ドライブ テストを行います。 IHV が提供する NMEA プロット ツールを使用してログを分析します。 デバイスの平均信号強度を比較します。

Note

IHV の NMEA プロット ツールがない場合は、Microsoft Bing を使用できます

人体の干渉テスト

アンテナの配置では、人体の干渉を考慮する必要があります。 システムが一般的な状態に保持されている場合、GPS は測位を失わず、誤差半径を 30% より大きくせず、OTA 取得感度 -140 dBm、OTA 追跡感度 -145 dBm を維持する必要があります。

タブレット型端末の一般的な使用状態:

  • 手が両サイドで横向き

  • 手が底面で横向き

  • 手が両サイドで縦向き (左から開始)

  • 手が底面で縦向き (左から開始)

  • 手が両サイドで縦向き (右から開始)

  • 手が底面で縦向き (右から開始)

取得感度と追跡感度に対する人体干渉の影響

説明: デバイスが指定されたハンドグリップで保持されているときに、デバイスの取得感度と追跡感度が、許容される最低限の標準を下回るパフォーマンスになってはいけません。

実行手順: デバイスを一般的な携帯位置に保持します。 取得感度と追跡感度を確認します。

想定される結果: デバイスが特定の位置に保持されているときに、追跡感度と取得感度に影響を与えてはいけません。 デバイスでは、OTA 取得感度 -140 dBm、OTA 追跡感度 -145 dBm を維持する必要があります。

相互運用性テスト

モバイル ブロードバンド、Wi-Fi、GPS の相互運用性

説明: モバイル ブロードバンドまたは Wi-Fi を無効にしても、GPS の機能を妨げてはいけません。 MB または Wi-Fi 無線をオフにしても、GPS の測位の取得が妨げられてはいけません。

実行手順:

  • モバイル ブロードバンドを無効にして、GPS で引き続き測位を受信できるかを確認します。 モバイル ブロードバンドを再び有効にします。

    Note

    デバイス サービスを使用する GPS デバイスは例外です。これらのデバイスでは、最初に SENSOR_STATE_INITIALIZING 状態になり、30 秒後にモバイル ブロードバンドが無効になっているときには SENSOR_STATE_NOT_AVAILABLE 状態になりる必要があります。

  • Wi-Fi を無効にして、GPS で引き続き測位を受信できるかを確認します。

  • モバイル ブロードバンド無線を無効にして、GPS で引き続き測位を受信できるかを確認します。

  • Wi-Fi 無線をオフにして、GPS で引き続き測位を受信できるかを確認します。

  • モバイル ブロードバンド SIM を取り外して、GPS で引き続き測位を受信できるかを確認します。

想定される結果: モバイル ブロードバンド デバイスまたは Wi-Fi デバイスで、無線の状態と SIM の状態によって GPS の機能が妨げられてはいけません。

モバイル ブロードバンド、Wi-Fi、Bluetooth、近距離無線通信 (NFC)、カメラの干渉

無線やシステム カメラなどの他のデバイスが GPS に干渉する可能性があります。 GPS デバイスは通常、モバイル ブロードバンド、Wi-Fi、 および Bluetooth と同じモジュールを共有します。 GPS 機能はこれらのデバイスの影響を受けてはいけません。

説明: モバイル ブロードバンド、Wi-Fi、Bluetooth、およびカメラの同時使用によって GPS デバイスのパフォーマンスと機能が低下してはいけません。その逆も同様です。

実行手順: モバイル ブロードバンド、Wi-Fi、Bluetooth、およびカメラについて、オンの状態で、およびアクティブに使用している状態で、基本的な機能テストを実行します。

  • GPS を使用しながらモバイル ブロードバンド接続を使用して大規模なダウンロードを実行します。 センサーの状態、誤差半径、信号強度、および SDT からのイベント ログを監視します。

  • GPS を使用しながら Wi-Fi 接続を使用して大規模なダウンロードを実行します。 センサーの状態、誤差半径、信号強度、および SDT からのイベント ログを監視します。

  • GPS を使用しながら Bluetooth ファイル転送を実行します。 センサーの状態、誤差半径、信号強度、および SDT からのイベント ログを監視します。

  • GPS を使用しながら Wi-Fi スキャンを実行します。 センサーの状態、誤差半径、信号強度、および SDT からのイベント ログを監視します。

  • GPS を使用しながらモバイル ブロードバンド スキャンを実行します。 センサーの状態、誤差半径、信号強度、および SDT からのイベント ログを監視します。

  • GPS を使用しながら Bluetooth スキャンを実行します。 センサーの状態、誤差半径、信号強度、および SDT からのイベント ログを監視します。

  • GPS を使用しながら動画を録画します。 センサーの状態、誤差半径、信号強度、および SDT からのイベント ログを監視します。

  • GPS を使用しながらインターネットの動画を視聴します。 センサーの状態、誤差半径、信号強度、および SDT からのイベント ログを監視します。

  • NFC データ転送 (写真の転送など) を 5 分間実行します。 センサーの状態、誤差半径、信号強度、および SDT からのイベント ログを監視します。

想定される結果: これらのデバイスが使用中でも、GPS は正常に動作する必要があります。 これらのデバイスの使用が、センサーの状態、誤差半径、信号の強度に悪影響を及ぼしてはいけません。

ドライブ テスト

手動によるドライブ テストは、トンネルや異なるマルチパスの影響のある領域が含まれる、あらかじめ定められたルートを使用して、システムをドライブに持ち出して行います。 ドライブ中に、システムの GPS データはテスト アプリケーションによってキャプチャされ、リファレンス GPS と比較されます。 システムによって報告される場所は、常時、リファレンス GPS によって報告される場所から誤差半径を超えて外れてはいけません。 平均誤差半径は、 <= 30 メートルである必要があります。

ドライブ テストは、動的ナビゲーションの精度、トンネルを通過した後の再取得、マルチパス信号の影響、および大気条件などの、現実の世界の条件で行います。

ドライブ テスト中に実行される機能テストは次のとおりです。

  • 状態遷移が監視され、リファレンス GPS と比較されます。

  • 緯度、経度、および標高 (使用可能な場合) が監視され、リファレンス GPS と比較されます。 簡単に比較できるよう、視覚的なマップ表現が使用されます。

  • 速度と進行方向のデータが監視され、リファレンス GPS と比較されます。

  • トンネル通過後の取得時間と再取得時間が測定され、リファレンス GPS と比較されます。

  • 追跡感度が、マルチパスの影響のある領域で監視されます。 データの報告の頻度と、データ報告の中断が監視されます。

  • 動的ナビゲーションの精度が監視され、視覚的なマップ表現を使用してリファレンス GPS と比較されます。

  • デバイスのプラグアンドプレイ (PnP) と無線マネージャーの状態遷移が、動的ナビゲーション中に実行されます。

  • 報告の頻度が監視され、リファレンス GPS と比較されます。

シミュレーター テスト

管理されたラボ条件を実現するには、GNSS シミュレーター (Spirent GSS6700) を使用します。 反復を目的として同じテストシナリオを再実行したり、衛星の状態をシミュレートしたり、さまざまな場所をシミュレートしたり、赤道の南の2年後の時間をシミュレートしたり、車内ナビゲーション、大気条件、マルチパス信号、およびエラー条件でシミュレートしたりします。 標準の Spirent GSS6700 シミュレーター テスト シナリオが実行されます。

OTA RF 接続で、元のアンテナとシールドを使用してシステムをテストします。 アンテナ コネクタにアクセスできる場合には、受信側テストで直接接続も使用できます。 シミュレーター テストでは、GNSS レシーバーのパフォーマンス特性と次のシナリオを含む、一般的なシミュレーター シナリオに重点を置いています。

  • コールドスタート TTFF

  • ホットスタート TTFF

  • 取得の感度

  • 再取得の感度

  • トラッキングの感度

  • 静的な位置の精度

  • 動的な位置の精度

  • マルチパス

  • GPS と Globalnaya navigatsionnaya sputnikovaya sistema (GLONASS)

GPS 受け入れテスト マトリックス

  • OS のビルド テストの実行日:

  • Windows HLK バージョン:

  • プラットフォーム ファームウェアのバージョン:

  • プラットフォーム テストの実行日:

テスト レベル テストの説明 確認の結果 説明

基本 (レベル 1)

ドライバーは IHV 証明書で署名されている必要がある

基本 (レベル 1)

デバイス マネージャーまたはデプロイ イメージのサービスと管理 (DISM) を使用してドライバーをインストールする必要がある

基本 (レベル 1)

GPS.Test Descriptions.Robustness.Driver Verifier、WDF 検証ツールおよびアプリケーション検証ツール

基本 (レベル 1)

位置センサー WHLK テスト: Device.Input.Sensor.位置センサーのシステム テスト: System.Client.Sensor.

基本 (レベル 1)

無線管理 WHLK テスト: System.Client.RadioManagement.

基本 (レベル 1)

必須の WHLK テストに加え、位置センサー WHLK テスト下のオプションの WHLK テストにある省略可能なテスト: Device.Input.Sensor. および System.Client.Sensor.* を実行し、Arm 以外の SoC システムに渡す必要があります

基本 (レベル 1)

デバイスの基本 WHLK テスト: Device.DevFund.

基本 (レベル 1)

USB WHLK テスト (USB 接続デバイスのみ): Device.Connectivity.UsbDevices.

基本 (レベル 1)

GPS.Test Descriptions.Functionality.Sensor category、タイプ、プロパティとデータ フィールド

基本 (レベル 1)

GPS.Test Descriptions.Functionality.State Transitions

基本 (レベル 1)

GPS.Test Descriptions.Functionality.Accuracy of Latitude and Longitude

基本 (レベル 1)

GPS.Test Descriptions.Functionality.Speed Data

基本 (レベル 1)

GPS.Test Descriptions.Functionality.Heading Data

基本 (レベル 1)

GPS.Test Descriptions.Assisted GPS.A-GPS

基本 (レベル 1)

GPS.Test Descriptions.Assisted GPS.Position Injection. 接続の種類

基本 (レベル 1)

GPS.Test Descriptions.Antenna Performance.OTA Connection. デバイスは、外部アンテナの使用や他の変更をすることなく、そのままの状態で、晴天の屋外で測位を取得する必要があります。

基本 (レベル 1)

GPS.Test Descriptions.Interoperability.* (GPS が、モバイル ブロードバンド、Bluetooth、Wi-Fi、またはカメラのアクティブな使用中に測位を取得可能であること)

基本 (レベル 1)

GPS.Test Descriptions.Functionality.Other Sensor Properties

基本 (レベル 1)

GPS.Test Descriptions.Assisted GPS.Position Injection. 接続時間

基本 (レベル 1)

GPS.Test Descriptions.Antenna Performance.HumanInterference Tests. デバイスは、一般的な手持ちのポジションに保持されている間、外部アンテナやその他の変更を必要とせずに、晴天の屋外で測位を取得する必要があります。

ストレス (レベル 2)

GPS.Test Descriptions.Robustness.

パフォーマンス (レベル 2)

GPS.Test Descriptions.Performance.

電力 (レベル 1)

GPS.Test Descriptions.Power Consumption.

電力 (レベル 1)

GPS.Test Descriptions.Power Management.

アンテナのパフォーマンス (OEM 向けレベル 1)

GPS.Test Descriptions.Antenna Performance.

ドライブ テスト (レベル 3)

GPS.Test Descriptions.Drive Tests.

シミュレーター テスト (レベル 4)

GPS.Test Descriptions.Simulator Tests.*

Windows センサーと位置プラットフォーム

電力とパフォーマンスに関する位置情報ドライバーのガイドライン

位置センサー ドライバーの作成

データのフィルター処理

センサー デバイスのテストの前提条件