다음을 통해 공유

GNSS(Global Navigation Satellite System) 테스트 지침

  • 아티클

이 문서에서는 Windows 8 및 Windows 8.1을 실행하는 컴퓨터에서 고품질의 경쟁력 있는 GPS 환경을 보장하기 위한 GPS(Global Positioning System) 구현 지침을 제공합니다. 이 문서의 지침은 OEM(Original Equipment Manufacturer), IHV(독립 하드웨어 공급업체) 및 기타 Microsoft 파트너(예: 소프트웨어 공급업체)에 적용됩니다. 이 문서에서는 GNSS(Global Navigation Satellite System) 디바이스를 Windows 8 시스템에 통합하는 것을 테스트하는 데 중점을 둡니다.

GPS 이외의 영역 테스트는 이 문서의 범위를 벗어납니다. 운영 체제 구성 요소 또는 GNSS 디바이스를 완전히 실행하는 것은 이 문서의 범위를 벗어납니다. IHV와 OEM은 독립적으로 시스템에 통합된 GNSS 디바이스를 철저히 테스트한다고 가정합니다. 상호 운용성 테스트는 위치 플랫폼 및 디바이스와 상호 작용하는 구성 요소로 제한됩니다. 이 테스트에는 Windows HLK(Windows Hardware Lab Kit) 테스트, 이 테스트 계획, 사전 운영자 평가판 테스트, GNSS 드라이버 및 GNSS 수신기용으로 특별히 개발된 내부 테스트의 성공적인 완료가 포함되어야 합니다.

참고 항목

이 문서에서는 GPS라는 용어가 GNSS와 혼용됩니다. 별도의 언급이 없는 한, GPS는 미국 정부가 배포하는 GPS 위성 시스템이 아닌 위치 공급자 솔루션으로써 위성 위치 정보를 의미합니다.

GPS/GNSS 위성이 수평선 위 위성 고도각 5도까지 위쪽 또는 주변 환경의 방해 없이 신호를 수신할 수 있으면 맑은 하늘 조건이라고 정의합니다. 모든 신호 수준은 지상에서 방해를 받지 않는 신호 수준과 일치해야 하며 -131dBm보다 낮지 않아야 합니다.

이 정보는 다음 운영 체제에 적용됩니다.

  • Windows 8

  • Windows 8.1

문서 내용:

파트너의 요구 사항

인증을 받으려면 Microsoft 파트너는 다음 요구 사항을 충족해야 합니다.

  • A-GPS(Assisted GPS) 테스트를 수행하고 디바이스를 콜드 스타트할 수 있도록 하려면 GNSS 드라이버가 SENSOR_PROPERTY_CLEAR_ASSISTANCE_DATA 속성을 지원해야 합니다. 데이터 보고서에서 NMEA(National Marine Electronics Association) 문장을 켜고 끄려면 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 값을 설정하면 시간, 위성력, 궤도력 및 마지막 위치를 비롯한 모든 지원 데이터를 지우라는 신호가 드라이버에 전송됩니다. 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 HLK(Windows Hardware Lab Kit) 테스트 외에도 비 Arm SoC(System on Chip) 시스템에 대한 선택적 Windows HLK Device.Input 테스트를 실행하여 통과해야 합니다. (이러한 테스트는 이미 Arm 시스템에서 필수입니다.)

  • OEM 및 IHV는 GPS 수용 테스트 매트릭스에 지정된 테스트를 실행하고 문서화해야만 시스템, 디바이스 또는 드라이버를 Microsoft에 제출할 수 있습니다.

  • IHV는 GPS 드라이버로 인해 발생한 문제에 대한 분석 섹션의 하드웨어 대시보드에서 보고된 오류를 검토하고 영향이 큰 오류를 모두 수정해야 합니다.

  • OEM의 안테나 요구 사항에는 안테나 성능 테스트에 나열된 항목이 포함되어야 합니다.

  • 동적 탐색 정확도 및 안테나 품질을 확인하려면 시스템에서 SENSOR_DATA_TYPE_NMEA_SENTENCE 속성을 지원해야 합니다.

  • 타사 서비스 또는 Win32 애플리케이션에 대한 종속성은 GPS 솔루션에 허용되지 않습니다. 타사 Win32 애플리케이션은 SoC 시스템에 대한 서명 요구 사항을 따르므로 허용되지 않습니다.

  • USB 연결 GPS 디바이스는 선택적 일시 중단을 지원해야 합니다.

  • 모바일 광대역 모듈의 GPS는 UEFI(Unified Extensible Firmware Interface)를 사용하여 업데이트해야 하며, 독립 실행형 GPS는 드라이버를 사용하여 업데이트해야 합니다.

  • GPS와 모바일 광대역이 동일한 물리적 칩에 있는 경우 GPS 디바이스는 USB 복합 디바이스의 일부로 노출되어야 하며 자체 USB 인터페이스가 있어야 합니다.

보고 및 결과 통신

Microsoft는 버그를 사용하는 파트너에게 모든 문제를 전달합니다. 버그에는 Windows HLK 로그, 추적, 드라이버 로그, 크래시 덤프, 관련 성능 결과 및 기준 성능 비교 데이터가 포함됩니다.

테스트 장비

다음 테스트 장비는 이 문서에 설명된 테스트를 수행하는 데 사용됩니다.

  • Spirent GSS6700 GNSS Simulator

  • 패러데이 케이지

  • RF 차폐함

  • 모바일 광대역 SIM

  • 참조 디바이스: Garmin Montana, Microsoft Signature를 사용하여 인증된 GP 디바이스가 있는 Windows 태블릿

  • 외부 안테나

기능 테스트

GNSS 디바이스에 적용되는 Windows HLK 테스트는 GPS 디바이스의 기본 기능을 확인하는 첫 번째 테스트 세트입니다. Windows HLK에는 GNSS 디바이스에 적용되는 GPS 센서, 라디오 관리자, 디바이스 기본 사항, 시스템 기본 사항 전원 관리에 대한 테스트와 USB 하드웨어 인증 테스트(USB 연결 디바이스용)가 포함되어 있습니다.

센서 범주, 형식, 속성 및 데이터 필드

설명: 디바이스는 올바른 센서 범주 및 형식을 보고하고, 필수 속성 및 데이터 필드를 지원하고, 정확한 데이터를 보고해야 합니다. Windows HLK에서 확인된 필수 센서 속성 외에도, 관리형 프로그램 시스템은 SENSOR_DATA_TYPE_NMEA_SENTENCE 속성을 지원해야 합니다.

실행 단계: DUT(Device Under Test)에서 보고하는 센서 범주, 형식, 속성 및 데이터 필드를 쿼리합니다. 보고된 데이터의 정확도를 확인합니다. WDK(Windows Driver Kit)의 SDT(센서 진단 도구)를 사용하여 이러한 항목을 테스트할 수 있습니다.

기대하는 결과: 필수 필드를 지원하고 정확한 데이터를 보고해야 합니다.

상태 전환

설명: 디바이스는 위치 센서 드라이버 작성에 설명된 대로 센서 상태의 변경 내용을 보고해야 합니다.

  • 디바이스가 SENSOR_STATE_READY 또는 SENSOR_STATE_INITIALIZING 상태에 도달한 후에만 데이터 보고서를 보고해야 합니다.

  • 위도 및 경도 정보가 없는 경우 디바이스에서 데이터를 보고하면 안 됩니다.

  • GPS 센서는 위치 수정 정보를 얻으려면 SENSOR_STATE_INITIALIZING 상태에서 시작해야 합니다.

  • GPS 센서는 위치 수정 정보를 계속 획득해야 하며 운영 체제에서 요청이 취소될 때까지 SENSOR_STATE_INITIALIZING 상태를 유지해야 합니다.

  • GPS 센서는 신호가 끊기고 더 이상 데이터가 없으면 SENSOR_STATE_INITIALIZING 상태로 전환되어야 합니다. 위치 수정 정보를 다시 받으면 SENSOR_STATE_READY 상태로 돌아가야 합니다.

실행 단계: 디바이스를 사용하지 않도록 설정했다가 다시 사용하도록 설정할 때 상태 전환 및 데이터 이벤트를 모니터링해야 합니다. GPS 신호를 받을 수 없는 영역(예: 패러데이 케이지)으로 이동하여 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% 이내여야 합니다.

Assisted GPS 테스트

처음 전원이 켜진 후 몇 초 이내에 GPS 디바이스는 A-GPS를 사용하여 대략적인 위치를 반환해야 합니다. GPS가 A-GPS를 사용하는 경우 센서는 위치 데이터를 제공해야 하며, 위치 데이터는 수백 미터에서 6자리 숫자까지 가능합니다. GPS 라디오가 여러 위성 잠금을 얻을 수 있는 경우 오차 범위가 3~30미터로 감소해야 합니다.

A-GPS

설명: A-GPS는 정확도가 더 높은 TTFF(Time to First Fix)를 빠르게 얻는 데 도움이 됩니다.

실행 단계: GPS 디바이스를 콜드 스타트합니다. SDT를 사용하여 위도, 경도 및 오차 범위 데이터 필드를 모니터링합니다.

다음 조건에서 테스트를 실행해야 합니다.

  • 맑은 하늘 조건(시뮬레이션된 조건 또는 실제)

  • 데이터 이벤트 구독

  • 보고 간격 1초

  • Wi-Fi 또는 셀룰러 베이스밴드가 있고 사용하도록 설정됨

기대하는 결과: 디바이스는 최대한 빨리 A-GPS의 위치를 반환해야 하며, 관련 오차 범위를 보고해야 합니다. 디바이스가 여러 위성 잠금을 얻을수록 높은 오차 범위(예: Wi-Fi를 사용할 수 있는 경우 300미터)가 3~30로 감소합니다. GPS는 지원 데이터 기반의 위치를 15초 이내에 보고해야 합니다.

위치 주입

GPS 드라이버는 센서 API(ISensorManager)를 사용하여 삼각 측량 센서의 데이터로 TTFF 속도를 향상할 수 있습니다. 드라이버를 사용하는 경우 다음 테스트가 적용됩니다.

  • 커넥트ion 시간

    설명: 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 검증 도구 제어 애플리케이션을 참조하세요.

애플리케이션 검증 도구(appverif.exe)는 Windows HLK 및 Windows 8.1 SDK에서 사용할 수 있습니다. 최소 기본 설정이 필요합니다.

드라이버 검증 도구, WDF 검증 도구 및 애플리케이션 검증 도구

설명: 테스트 시작 시 애플리케이션 검증 도구 및 드라이버 검증 도구를 사용하도록 설정합니다.

실행 단계: 드라이버 패키지의 모든 커널 모드 드라이버에서(있는 경우) 드라이버 검증 도구를 사용하도록 설정하고, GPS 드라이버가 종속된 커널 모드 드라이버를 사용하도록 설정합니다. %windir%\system32\WUDFHost.exe 및 GPS 드라이버가 종속된 기타 사용자 모드 이진 파일(예: wwanapi.dll)에 애플리케이션 검증 도구를 사용하도록 설정합니다.

기대하는 결과: 검증 도구 오류가 없습니다.

원격 분석 데이터

설명: GPS 드라이버에 대한 분석 섹션의 하드웨어 대시보드에서 원격 분석 데이터를 모니터링합니다.

실행 단계: GPS 드라이버에 대한 분석 섹션의 하드웨어 대시보드에서 원격 분석 데이터를 모니터링합니다. 드라이버 오류를 파악, 조사 및 수정합니다.

기대하는 결과: 디바이스가 모든 원격 분석 오류를 보고해야 합니다. 주요 문제를 심사, 조사 및 수정해야 합니다.

GPS 스트레스 테스트

다음 작업의 조합은 시뮬레이터 테스트, 보행 테스트 및 주행 테스트 중에 GPS 디바이스에서 동시에 수행됩니다.

  • 드라이버 검증 도구 사용

  • 애플리케이션 검증 도구 사용

  • 반복되는 Windows HLK 테스트 실행(GPS 센서, 라디오 관리자, 시스템 전원 관리)

  • 라디오 관리 운영

  • 연결된 대기 상태

  • GPS 디바이스 사용 안 함/다시 사용

  • Windows 위치 공급자 사용 안 함/다시 사용

  • 모바일 광대역 디바이스 사용 안 함/다시 사용

  • Wi-Fi 디바이스 사용 안 함/다시 사용

  • 모바일 광대역 라디오 끄기

  • Wi-Fi 라디오 끄기

  • 모바일 광대역 연결을 통해 대규모 다운로드

  • Wi-Fi 연결을 통해 대규모 다운로드

  • Bluetooth 활동

스트레스 테스트 전에 기본 확인 테스트를 수행합니다. 동일한 확인 테스트가 스트레스 테스트 전과 후에 모두 통과하고 오류가 관찰되지 않을 것으로 예상됩니다.

성능

GPS 디바이스 성능은 콜드 스타트 TTFF, 핫 스타트 TTFF, 획득 민감도, 추적 민감도, 다시 획득 시간, 정적 탐색 정확도 및 동적 탐색 정확도에 대해 테스트됩니다.

OTA 연결이 있는 GNNS 시뮬레이터를 성능 테스트에 사용할 수 있습니다.

콜드 스타트 TTFF

설명: 테스트 시간의 90% 동안 콜드 스타트 TTFF가 45초 이내에 달성되어야 합니다. 콜드 스타트는 다음 조건으로 설명됩니다.

  • 시간을 알 수 없음

  • 현재 궤도력을 알 수 없음

  • 위치를 알 수 없음

실행 단계: 콜드 스타트 테스트를 시작하기 전에 SDT를 사용하여 GPS 지원 데이터를 지울 수 있습니다. 위에서 설명한 콜드 스타트 조건을 충족해야 합니다. 맑은 하늘 조건(실제 또는 시뮬레이션된 조건)에서 TTFF를 모니터링합니다.

기대하는 결과: 테스트 시간의 90% 동안 디바이스가 GNSS 디바이스를 사용하여 45초 이내에 위치 수정 정보를 받아야 합니다.

획득 민감도

설명: 디바이스는 -150dBm 이하의 전원 수준에서 위치 수정 정보를 받아야 합니다.

실행 단계: 시뮬레이션된 랩 조건에서 안테나 커넥터에 액세스할 수 있을 때 직접 RF(무선 주파수) 연결을 사용하여 디바이스를 최대 -150dBm의 낮은 전력 수준에 노출합니다.

기대하는 결과: 디바이스가 -150dBm에서 수정 정보를 얻어야 합니다.

추적 민감도

설명: 디바이스는 -155dBm 이하의 전원 수준에서 위치 수정을 유지해야 합니다.

실행 단계: 시뮬레이션된 랩 조건에서 안테나 커넥터에 액세스할 수 있을 때 직접 RF 연결을 사용하여 디바이스가 위치 수정 정보를 얻은 후 전원 수준을 -155dBm로 낮춥니다.

기대하는 결과: 디바이스가 -155dBm에서 위치 수정을 유지해야 합니다.

다시 획득 시간

설명: 디바이스가 2초 후에 위치 수정 정보를 다시 얻을 수 있어야 합니다. 신호를 받을 수 있으면 맑은 하늘 조건이라고 가정합니다.

실행 단계: 시뮬레이션된 랩 조건에서 디바이스가 위치 수정 정보를 얻은 후, 디바이스가 수정 정보를 잃게 되는 수준까지 전원 수준을 낮춥니다. 그런 다음, 전원 수준을 높이고 다시 획득 시간을 모니터링합니다. 또는 주행 테스트 중에 터널을 통과해도 됩니다.

기대하는 결과: 디바이스가 2초 후에 위치 수정 정보를 다시 얻어야 합니다.

정적 탐색 정확도

설명: 디바이스가 정확한 위도, 경도 및 고도(지원되는 경우)를 보고해야 합니다.

실행 단계: 경도, 위도 및 고도(사용 가능한 경우)의 정확도를 신뢰할 수 있는 데이터 원본의 위치와 비교합니다. 신뢰할 수 있는 데이터 원본은 측량 마커, GNSS 시뮬레이터 또는 GPS가 있는 Microsoft Signature 인증 Windows 태블릿입니다.

기대하는 결과: 테스트 시간의 95% 동안 DUT가 15미터의 수평 정확도와 30미터의 수직 정확도를 보고해야 합니다.

동적 탐색 정확도

설명: DUT가 모바일인 경우 DUT는 위도, 경도 및 고도(지원되는 경우)를 정확하게 보고해야 합니다.

실행 단계: 시뮬레이션 또는 실제 디바이스/보행 테스트 중에 경도, 위도 및 고도(사용 가능한 경우)의 정확도를 신뢰할 수 있는 데이터 원본의 위치와 비교합니다. 신뢰할 수 있는 데이터 원본은 측량 마커, GNSS 시뮬레이터 또는 GPS가 있는 Microsoft Signature 인증 Windows 태블릿입니다.

기대하는 결과: 디바이스가 15미터의 수평 정확도와 100미터의 수직 정확도를 보고해야 합니다.

소비 전력 테스트

다음 다이어그램에서는 드라이버가 WDF 유휴 검색 StopIdle/ResumeIdle 메서드를 사용하여 D-States 간에 전환하는 방법을 보여줍니다.  이 섹션의 테스트 사례는 드라이버가 적시에 올바른 상태로 전환되는지 확인합니다.

<Fig1_ Fig1_stopidle_resumeidle의 아트 자리 표시자>

그림 1. StopIdle/ResumeIdle

USB 선택적 일시 중단

이 테스트는 USB 연결 디바이스에만 적용됩니다. 8초 이하의 보고 간격을 구독하는 클라이언트가 없는 GPS 디바이스는 버스의 모든 디바이스가 일시 중단 상태로 전환할 준비가 되면 선택적 일시 중단에 참여해야 합니다.

디바이스 관리자 및 ETW(Windows용 이벤트 추적) 이벤트는 USB 버스 상태 전환을 모니터링하는 데 사용됩니다.

절전 모드 평균 소비 전력

버스 연결 인터페이스를 포함한 GPS 디바이스의 절전 모드 평균 소비 전력이 1mW 미만이어야 합니다. 그렇지 않으면 D3(D3-Cold) 상태일 때 GPS 디바이스의 전원을 완전히 제거하는 기능을 디바이스에서 지원해야 합니다.

D3-Cold

D3cold를 지원하는 디바이스는 TTFF 성능이 6초 넘게 저하되면 안 됩니다. 예를 들어 디바이스가 핫 스타트 조건에서 2초 후에 위치 수정 정보를 얻을 수 있는 경우 디바이스가 D3cold에서 다시 시작될 때 8초 이내에 수정 정보를 받을 수 있어야 합니다. 디바이스가 이 요구 사항을 충족할 수 없는 경우 드라이버는 D3cold 상태 전환을 GPS 라디오를 사용하지 않을 때로 제한해야 합니다.

D3cold에 대한 자세한 내용은 드라이버에서 D3cold 지원을 참조하세요.

전원 관리 테스트

연결된 대기 상태

연결된 대기 상태 테스트에는 Windows HLK PowerState 테스트 및 IO 커버 테스트 시나리오를 사용하는 디바이스 기본 사항 테스트가 포함됩니다.

신호 수신 불가능 영역에서 다시 시작

설명: 활성 클라이언트가 있는 경우 시스템을 연결된 대기 상태로 전환합니다. 신호 수신 불가능 영역에서 다시 시작합니다. 디바이스가 위치 수정 정보를 얻고 SENSOR_STATE_INITIALIZING 상태로 전환하려고 시도해야 합니다.

실행 단계: 활성 클라이언트가 연결되면 디바이스를 연결된 대기 상태로 전환합니다. GPS 신호를 받을 수 없는 영역에서 연결된 대기 상태를 해제합니다.

기대하는 결과: 디바이스가 위치 수정 정보를 얻고 SENSOR_STATE_INITIALIZING 상태로 전환해야 합니다.

안테나 성능 테스트

OTA 연결을 사용하는 성능 테스트

케이블로 연결된 RF 연결을 통해 랩 환경에서 GNSS 수신기의 성능을 테스트하고, GPS 안테나 및 관련 회로를 우회하는 것이 일반적입니다. GPS 안테나 및 회로의 디바이스 성능과 문제로 인해 위치 기반 서비스 애플리케이션의 사용자 환경이 저하될 수 있습니다. 이러한 문제를 발견하려면 OTA 테스트 방법을 사용하여 관리형 시스템 디바이스의 GPS 성능을 테스트해야 합니다.

안테나 테스트는 다음과 같은 인증 요구 사항이 있습니다.

  • GPS 지원이 있는 시스템은 이동 스테이션 무선 성능에 대한 CTIA(셀룰러 통신 및 인터넷 협회) 테스트 계획, 방사형 무선 주파수(RF) 전원 및 수신기 성능 v3.0 이상 A-GPS에 대한 측정 방법에 따라 테스트를 통과해야 합니다. CTIA 테스트 실행에 대한 자세한 내용은 CTIA 인증 테스트를 참조하세요. 또한 TIS(총 등방성 민감도), UHIS(상반구 등방성 민감도) 및 PIGS(부분 등방성 GPS 민감도)를 측정해야 합니다. 결과를 검토할 수 있도록 OEM은 측정 결과를 Microsoft에 게시해야 합니다. 이러한 요구 사항은 모바일 광대역을 지원하는 시스템에 적용됩니다.

  • 시스템에는 GPS에 사용할 -140dBm 이상의 TIS 및 UHIS 여유 공간이 있어야 합니다. 모바일 광대역을 지원하는 시스템의 경우 측정값은 CTIA 3.x 테스트 계획의 Wi-Fi 전용 시스템 섹션에 대한 실행 지침의 안테나 성능에 정의된 테스트 방법론 및 테스트 매개 변수를 따라야 합니다.

  • GPS 안테나의 평균 게인은 -6dBi보다 높아야 합니다.

  • 일반적으로 손으로 들고 있는 위치에 디바이스가 있을 때 성능이 최소 허용 표준 아래로 떨어지지 않아야 합니다. 디바이스를 일반적인 위치로 쥐고 있을 때 무선(OTA) 추적 민감도가 -140dBm, OTA 추적 민감도가 -145dBm에서 유지되어야 합니다.

  • 키보드 또는 도킹 스테이션이 닫혀 있을 때 디바이스의 OTA 획득 민감도가 -140dBm, OTA 추적 민감도가 -145dBm에서 유지되어야 합니다.

  • GPS 안테나가 디바이스에서 예상되는 위치에 있을 때 안테나 및 방사 민감도 테스트를 수행해야 합니다.

  • 원하는 GPS 프로덕션 안테나가 EV(엔지니어링 검증) 시스템의 원하는 위치에 있어야 합니다. DV(설계 확인) 시스템에 대한 안테나 위치를 최종적으로 결정해야 합니다.

  • OEM은 안테나 성능 및 방사 민감도 테스트를 실행하고 EV 장치의 오류를 파악해야 합니다. DV 장치보다 먼저 테스트를 통과해야 합니다.

Wi-Fi 전용 시스템의 RF 민감도 테스트

GPS IHV는 NMEA 로깅 및 그리기 도구와 설명서를 제공할 수 있습니다.

동일한 위치, 동일한 조건에서 GPS RF 민감도가 우수한 참조 디바이스와 테스트 디바이스에서 SNR(Signal-to-Noise Ratio)를 비교합니다. IHV NMEA 로그를 사용하도록 설정하고 맑은 날씨에 디바이스를 갖고 나가 15분 이상 보행/주행 테스트를 수행합니다. IHV에서 제공하는 NMEA 그리기 도구를 사용하여 로그를 분석합니다. 디바이스의 평균 신호 강도를 비교합니다.

참고 항목

IHV의 NMEA 그리기 도구가 없는 경우 Microsoft Bing을 사용하면 됩니다.

사람의 간섭 테스트

안테나 위치 지정 시 사람의 간섭을 고려해야 합니다. 시스템이 일반적인 위치에 있을 때 GPS는 위치 수정 정보를 잃으면 안 되고, 오차 범위가 30%를 초과하여 증가하면 안 되고, OTA 획득 민감도는 -140dBm, OTA 추적 민감도는 -145dBm으로 유지해야 합니다.

슬레이트에 일반적으로 사용되는 상태는 다음과 같습니다.

  • 손으로 옆을 잡고, 가로 방향

  • 손으로 밑을 받치고, 가로 방향

  • 손으로 옆을 잡고, 세로 방향(왼쪽에서 시작)

  • 손으로 밑을 받치고, 세로 방향(왼쪽에서 시작)

  • 손으로 옆을 잡고, 세로 방향(오른쪽에서 시작)

  • 손으로 밑을 받치고, 세로 방향(오른쪽에서 시작)

사람의 간섭이 획득 및 추적 민감도에 미치는 영향

설명: 디바이스 획득 및 추적 민감도로 인해 디바이스가 지정된 핸드그립에 있을 때 성능이 최소 허용 표준 아래로 떨어지지 않아야 합니다.

실행 단계: 디바이스를 일반적인 손 위치로 잡습니다. 획득 민감도 및 추적 민감도를 확인합니다.

기대하는 결과: 디바이스의 특정 위치를 잡았을 때 추적 및 획득 민감도가 영향을 받으면 안 됩니다. 디바이스의 OTA 획득 민감도가 -140dBm, OTA 추적 민감도가 -145dBm으로 유지되어야 합니다.

상호 운용성 테스트

모바일 광대역, Wi-Fi 및 GPS 상호 운용성

설명: 모바일 광대역 또는 Wi-Fi 디바이스를 사용하지 않도록 설정해도 GPS가 작동해야 합니다. MB 또는 Wi-Fi 라디오를 꺼도 GPS가 위치 수정 정보를 받을 수 있어야 합니다.

실행 단계:

  • 모바일 광대역을 사용하지 않도록 설정하고 GPS가 여전히 위치 수정 정보를 받을 수 있는지 확인합니다. 모바일 광대역을 다시 사용하도록 설정합니다.

    참고 항목

    디바이스 서비스를 사용하는 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의 이벤트 로그를 모니터링합니다.

  • 5분 동안 NFC 데이터를 전송합니다(예: 사진 전송). 센서 상태, 오차 범위, 신호 강도 및 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 및 GLONASS(Globalnaya navigatsionnaya sputnikovaya sistema)

GPS 수용 테스트 매트릭스

  • OS 빌드 테스트는 다음에서 실행됩니다.

  • Windows HLK 버전:

  • 플랫폼 펌웨어 버전:

  • 플랫폼 테스트는 다음에서 실행됩니다.

테스트 수준 테스트 설명 확인 결과 설명

기본(수준 1)

드라이버는 IHV 인증서로 서명해야 합니다.

기본(수준 1)

디바이스 관리자/DISM(Deployment Image Servicing and Management)을 사용하여 드라이버를 설치해야 합니다.

기본(수준 1)

GPS.Test Descriptions.Robustness.Driver 검증 도구, WDF 검증 도구 및 애플리케이션 검증 도구

기본(수준 1)

위치 센서 WHLK 테스트: 위치 센서 System.Client.Sensor에 대한 Device.Input.Sensor.System 테스트

기본(수준 1)

라디오 관리 WHLK 테스트: System.Client.RadioManagement.

기본(수준 1)

필요한 WHLK 테스트 외에도, 위치 센서 WHLK 테스트: Device.Input.Sensor. 및 System.Client.Sensor.*를 실행해야 하며 비 Arm SoC 시스템에 대해 전달해야 합니다.

기본(수준 1)

디바이스 기본 사항 WHLK 테스트: Device.DevFund.

기본(수준 1)

USB WHLK 테스트(USB 연결된 디바이스만 해당): Device.Connectivity.UsbDevices.

기본(수준 1)

GPS.테스트 설명.기본 사항.센서 범주, 형식, 속성 및 데이터 필드 테스트

기본(수준 1)

GPS.테스트 설명.기능.상태 전환

기본(수준 1)

GPS.테스트 설명.기능.위도 및 경도의 정확도

기본(수준 1)

GPS.테스트 설명.기능.속도 테스트

기본(수준 1)

GPS.테스트 설명.기능.방향 데이터

기본(수준 1)

GPS.테스트 설명.Assisted GPS.A-GPS

기본(수준 1)

GPS.테스트 설명.Assisted GPS.위치 삽입 연결 유형

기본(수준 1)

GPS.테스트 설명.안테나 성능.OTA 연결. 디바이스는 외부 안테나 또는 기타 수정을 사용하지 않고 맑은 날 야외에서 위치 수정 정보를 있는 그대로 받아야 합니다.

기본(수준 1)

GPS.테스트 설명.상호 운용성.*(GPS는 모바일 광대역, Bluetooth, Wi-Fi 또는 카메라가 적극적으로 사용될 때 위치 수정 정보를 받을 수 있음)

기본(수준 1)

GPS.테스트 설명.기능.기타 센서 속성

기본(수준 1)

GPS.테스트 설명.Assisted GPS.위치 삽입 연결 시간

기본(수준 1)

GPS.테스트 설명.안테나 성능.사람의 간섭 테스트. 디바이스를 손으로 잡는 일반적인 위치에서, 디바이스는 외부 안테나 또는 기타 수정 없이 맑은 날 야외에서 위치 수정 정보를 있는 그대로 받아야 합니다.

스트레스(수준 2)

GPS.테스트 설명.견고성.

성능(수준 2)

GPS.Test Descriptions.Performance.

전원(수준 1)

GPS.테스트 설명.소비 전력.

전원(수준 1)

GPS.Test Descriptions.Power Management.

안테나 성능(OEM의 경우 수준 1)

GPS.테스트 설명.안테나 성능.

주행 테스트(수준 3)

GPS.Test Descriptions.Drive Tests.

시뮬레이터 테스트(수준 4)

GPS.테스트 설명.시뮬레이터 테스트.*

Windows 센서 및 위치 플랫폼

전원 및 성능에 대한 위치 드라이버 지침

위치 센서 드라이버 작성

데이터 필터링

센서 디바이스 테스트 필수 구성 요소