GNSS(전역 탐색 위성 시스템) 드라이버 요구 사항

Windows 10 대한 GNSS(전역 탐색 위성 시스템) 드라이버를 개발할 때 고려해야 할 요구 사항, 가정 및 제약 조건에 대해 설명합니다.

일반 요구 사항

• 드라이버 프레임워크: GNSS 드라이버는 원시 WDM 드라이버 또는 KMDF 드라이버와 달리 이 인터페이스 정의를 기반으로 하여 UMDF 2.0 드라이버로 작성되어야 합니다. UMDF 1.0 드라이버도 지원되지 않습니다. 드라이버가 이 인터페이스 디자인에 필요한 기능을 제공하는 한 GNSS 드라이버 인터페이스 정의 또는 GNSS 어댑터와 같은 Microsoft HLOS(High level Operating system) GNSS 구성 요소는 WDF, KMDF GNSS 드라이버 및 UMDF 2.0 드라이버를 구분하지 않습니다. UMDF 2.0은 사용자 모드에서만 제공되는 기능이 필요한 기능을 구현하는 더 높은 안정성, 단순성 및 유연성을 제공합니다. 일반적으로 IHV는 플랫폼에서 이전 프레임워크를 사용할 수 있는 경우 KMDF에 UMDF 2.0을 선호해야 합니다.

 UMDF 2.0은 모든 플랫폼에서 사용할 수 있으며 IHV는 사용자 모드로 작성된 드라이버를 사용하는 것이 좋습니다.

• 여러 애플리케이션 세션: 애플리케이션 세션은 GNSS 드라이버와 직접 상호 작용하는 HLOS 구성 요소에서 오는 위치 지정 세션입니다. GNSS 드라이버는 상태 변수 및 기능을 애플리케이션별로 분할하여 기본적으로 여러 애플리케이션 세션을 지원하도록 선택할 수 있습니다. 이는 드라이버의 선택적 기능이며 잘 정의된 GNSS 드라이버 기능 정보를 통해 구체적으로 표시됩니다. 이 선택적 동작을 지원하려면 GNSS 드라이버는 CreateFile 중에 HLOS 애플리케이션이 가져오는 파일 핸들을 추적하고 모든 후속 HLOS 작업을 애플리케이션 세션 특정 파일 핸들에 연결해야 합니다. GNSS 드라이버의 이 기본 지원을 통해 HLOS 구성 요소는 드라이버를 플랫폼의 나머지 부분에 노출하는 것에 대해 더 유연하고 덜 제한적일 수 있습니다. 이 기능을 지원하는 GNSS 드라이버는 각 개별 애플리케이션 세션에 대한 상태 정보를 논리적으로 분할하고 유지 관리해야 할 수 있습니다. 이 기능을 지원하지 않는 GNSS 드라이버는 논리적 앱별 파티션 대신 모든 애플리케이션 세션에 대한 전역 상태만 유지 관리하면 됩니다. 이 후자 모드에서 GNSS 드라이버는 여러 병렬 애플리케이션 세션이 있는지 모르고 HLOS의 모든 요청을 동일한 애플리케이션 세션에서 시작된 것처럼 처리합니다.

  

  여러 애플리케이션 세션에 대한 GNSS 드라이버의 지원은 HLOS의 테스트 애플리케이션이 GNSS 어댑터와 동시에 GNSS 드라이버와 직접 상호 작용할 수 있도록 하는 이점이 있습니다. 테스트 애플리케이션 및 GNSS 어댑터는 단일 GNSS 드라이버에 동시에 다른 세션을 요청할 수 있는 다양한 애플리케이션으로 간주되었습니다. 여러 애플리케이션 세션이 지원되지 않는 경우 GNSS 드라이버는 OS 위치 플랫폼을 통해 테스트해야 합니다. 그렇지 않으면 테스트 애플리케이션을 방해하지 않도록 OS 위치 플랫폼을 호스트하는 서비스를 중지해야 합니다.

• 세션 수정: 기본 드라이버(단일 샷 또는 추적)에서 위치 지정 정보를 가져오는 행위는 수정 세션의 개념으로 추상화됩니다. 드라이버는 지원되는 각 세션 유형의 수정 세션을 하나 이상 지원해야 합니다. 세션 형식은 GNSS_FIXSESSIONTYPE 열거형 아래에 정의됩니다.

  • 최소한 GNSS 드라이버는 단일 샷 수정 세션을 지원해야 합니다.

  • 거리 기반 추적 수정 세션을 지원하는 드라이버는 단일 샷 수정 세션과 거리 기반 추적 수정 세션을 동시에 지원해야 합니다.

  • 시간 기반 추적 수정 세션을 지원하는 드라이버는 단일 샷 수정 세션과 시간 기반 추적 수정 세션을 동시에 지원해야 합니다.

  • 거리 기반 추적 수정 세션 및 시간 기반 추적 수정 세션을 지원하는 드라이버는 단일 샷 수정 세션, 거리 기반 추적 수정 세션 및 시간 기반 추적 수정 세션을 동시에 지원해야 합니다.

  

  드라이버가 여러 동시 수정 세션을 지원하는지 여부는 잘 정의된 드라이버 기능 매개 변수로 표현됩니다. 드라이버가 여러 병렬 수정 세션을 명시적으로 지원하지 않는 경우 동일한 수정 유형의 세션이 이미 시작되고 활성 상태인 경우 새 수정 세션 요청에 실패해야 합니다. 여러 수정 세션 지원이 없는 경우 상위 수준 애플리케이션에서 들어오는 여러 GNSS 요청이 멀티플렉싱되고 단일 수정 세션 요청에 GNSS 드라이버에 매핑되도록 하기 위해 ONUS가 HLOS 구성 요소에 있습니다.

  GNSS 드라이버는 동일한 유형의 여러 병렬 수정 세션을 지원할 필요가 없습니다. 실제로 Windows 10 HLOS GNSS 어댑터는 동일한 유형의 여러 수정 세션을 갖도록 GNSS 드라이버 기능을 활용하는 것을 지원하지 않으므로 IHV는 당분간 이 기능에 투자하지 않는 것이 좋습니다. 향후 릴리스에서는 GNSS 어댑터가 세션 멀티플렉싱 자체를 수행하는 대신 위치 플랫폼의 상층에서 가져온 모든 수정 요청에 대해 GNSS 드라이버로 세션을 직접 시작할 수 있도록 하는 것으로 간주됩니다. GNSS 어댑터에서 수정 세션의 멀티플렉싱을 지원하면 애플리케이션 또는 멀티플렉싱 구현에 대해 동일한 유형의 여러 세션을 처리할 필요가 없으므로 드라이버 구현이 간소화되고, 드라이버의 메모리 사용량이 줄어들며, HLOS가 GNSS 드라이버에서 지원하는 것보다 더 큰 수정 세션을 시작하는 경우를 처리하기 위해 GNSS 어댑터가 필요하지 않습니다. 디바이스와 드라이버의 계층이 다르면 여러 동시 수정 세션이 지원되므로 이 경우를 처리해야 하므로 모든 사례를 처리하기 위해 GNSS 어댑터의 복잡성이 발생합니다. 따라서 Windows 10 GNSS 어댑터는 지원되는 각 유형의 단일 수정 세션만 구현하며 이 기능이 필요할 때까지 드라이버의 여러 수정 세션 지원을 무시합니다.

  각 수정 세션은 상태 저장이며 잘 정의된 이 시퀀스를 따라야 합니다.

  1. 수정 세션 시작

  2. 하나 이상의 수정 사항 가져오기

  3. 필요한 경우 수정 세션 수정

  이는 적어도 GNSS 어댑터가 동일한 유형의 수정 세션의 멀티플렉싱을 처리할 때까지 필요하며 나중에 GNSS 드라이버에서 지원하는 수보다 더 많은 동시 수정 세션의 경우를 처리해야 할 수도 있습니다.

  1. 수정 세션 중지

  수정 세션은 수정 세션 ID로 고유하게 식별됩니다. 수정 세션의 컨텍스트 외부에서 HLOS에서 위치 정보를 검색할 수 없습니다. GNSS 드라이버는 수정 세션을 다시 시작할 필요 없이 HLOS 구성 요소의 멀티플렉싱 작업을 용이하게 하려면 즉시 세션 매개 변수를 수정할 수 있어야 합니다.

  

• 수정 유형: GNSS 드라이버는 최소한 기본 단일 샷 수정을 지원해야 합니다. 또한 드라이버는 기본적으로 고급 수정 유형(예: 추적)을 지원해야 합니다. 앞에서 설명한 것처럼 추가 수정 유형을 지원한다는 것은 드라이버가 동일한 형식의 여러 수정 세션을 지원하지 않더라도 지원되는 수정 유형의 수정 세션을 하나 이상 동시에 지원해야 한다는 것을 의미합니다. HLOS 구성 요소는 다른 수정 유형을 단일 형식으로 멀티플렉싱하지 않습니다.

• 디바이스 인터페이스 및 PnP: HLOS가 GNSS 드라이버의 도착 및 출발에 대한 알림을 받을 수 있도록 GNSS 드라이버는 WdfDeviceCreateDeviceInterface API를 사용하여 Microsoft 정의 디바이스 인터페이스를 보급해야 합니다. 이는 PnP(플러그 앤 플레이) 설정에서 GNSS 드라이버를 처리하는 데 필요하며, 드라이버가 UMDF 2.0 드라이버인 경우 사용자 수준 서비스 충돌로 인해 예기치 않은 드라이버 언로드가 발생하는 경우에도 필요합니다. GNSS 드라이버는 아래 하드웨어가 HLOS IOCTL 호출을 지원할 수 있는 경우에만 디바이스 인터페이스가 보급되도록 해야 합니다.

• 디바이스 전원 정책: GNSS 드라이버는 디바이스의 전원 정책을 관리해야 하며 OS에서 발생하는 전원 관리 이벤트를 처리해야 합니다. 드라이버는 WDF_PNPPOWER_EVENT_CALLBACKS 등록해야 합니다 . EvtDeviceD0Entry 콜백(시스템이 D0 상태로 이동하면 WDF에서 발생) 및 WDF_PNPPOWER_EVENT_CALLBACKS. EvtDeviceD0Exit 콜백(시스템이 D0 상태에서 종료될 때 WDF에 의해 발생). 선택적으로 전원 관리를 사용하지 않도록 하려면 GNSS 드라이버를 구성할 수 있어야 합니다.

  다른 시스템 전원 상태의 GNSS 디바이스에서 수행해야 하는 정확한 전원 관리는 GNSS 디바이스의 기능(오프로드된 작업을 지원하는지 여부), 실제 오프로드된 작업이 활성 상태인지 여부 및 시스템과 GNSS 디바이스 간의 통신이 수행되는 방식에 따라 조정되어야 합니다. 일반적으로 기대치는 다음과 같습니다.

  • GNSS 디바이스는 시스템 전원 상태에 관계없이 활성 세션 또는 오프로드된 작업이 없는 경우 가능한 가장 낮은 전원 모드에서 작동합니다.

  • 오프로드된 시나리오의 경우 시스템 전원 상태에 관계없이 GNSS 디바이스는 서로 다른 간격으로 위치를 검사 알림을 받아야 할 수 있으므로 연결된 대기 중(화면 해제 절전 상태임)에도 GNSS 디바이스가 D0 상태를 유지해야 할 수 있지만 하드웨어는 전력 소비를 최소한으로 줄여야 합니다. 이 모델은 DMA(직접 메모리 액세스) 또는 UART의 직렬 포트를 사용하여 호스트와 통신하는 디바이스에서 작동합니다. 그러나 USB 버스를 통해 연결된 GNSS 디바이스의 경우 문제가 될 수 있으며, 이 경우 디바이스의 USB 기능이 연결된 대기 중에 D2(일시 중단) 디바이스 전원 상태에 있어야 할 가능성이 큽니다. 일반적으로 USB를 통해 연결된 GNSS 디바이스는 수정 세션이나 오프로드된 작업이 진행 중이 아니고 USB 버스 인터페이스가 일시 중단 상태로 전환된 후 저전력 D2(일시 중단) 상태를 입력할 수 있어야 합니다. 모든 절전 모드 및 절전 모드 해제 전원 전환 신호는 USB 버스를 통해 보내야 합니다. GNSS 디바이스에 활성 또는 오프로드된 세션 수정 작업이 있는 경우 디바이스는 대역 내 USB 다시 시작 신호를 사용하여 SoC 또는 코어 실리콘을 연결된 대기 상태에서 절전 모드 해제할 수 있어야 합니다. SoC 또는 코어 실리콘은 GNSS 디바이스에서 대역 내 USB 다시 시작 신호에 대응하여 가장 낮은 전원 상태에서 절전 모드를 해제할 수 있어야 합니다.

  • 연결된 대기를 지원하지 않는 디바이스는 디바이스가 최신 대기 또는 최대 절전 모드로 전환될 때 모든 오프로드된 작업이 취소됩니다. 여기에는 오프로드된 지오펜스, 거리 추적 또는 주기적인 추적 세션이 포함됩니다.

  • 연결된 대기를 지원하는 디바이스는 디바이스가 연결된 대기 상태로 전환될 때 오프로드된 모든 작업이 계속 활성화되고, GNSS 디바이스는 추적 작업을 가능한 한 효율적으로 계속할 것으로 예상되며, 지오펜스 트리거 조건 또는 추적 세션 업데이트가 관련된 경우 HLOS에 알림을 제공할 것으로 예상됩니다. 연결된 대기를 지원하는 디바이스에 오프로드된 작업이 없는 경우 GNSS 디바이스는 가능한 가장 낮은 전원 상태로 이동해야 하지만 HLOS의 위치 세션 요청을 계속 수신 대기할 수 있습니다. SUPL을 지원하는 디바이스에서는 연결된 대기 상태에서 GNSS 디바이스 및 SUPL 스택이 NI 알림을 해제할 수도 있어야 합니다.

  드라이버의 전원 관리에 대한 일반적인 정보는 드라이버에 대한 전원 관리 책임에서 찾을 수 있습니다.

• 전원 고려 사항: GNSS 드라이버 스택은 기본 설계 목표로 전력 공간을 고려하여 기본 프로세서를 최대한 절전 모드로 유지하는 것을 최소화해야 합니다. 모든 고급 기능 지원(예: 다른 수정 유형)은 기본 앱 프로세서가 필요 이상으로 활성화될 필요가 없고 대부분의 처리가 칩셋/저전력 프로세서로 오프로드될 수 있는 것과 같은 전원 효율적인 방식으로 실행되어야 합니다. 일반적으로 HLOS에서 달리 명시되지 않는 한 GNSS 드라이버는 항상 전력 소비를 가장 중요한 제약 조건으로 처리해야 하며 최소한의 전력 공간으로 정상적인 작업을 수행하도록 설계되어야 합니다. GNSS 드라이버 인터페이스는 모바일 디바이스가 가능한 한 자주 저전력 모드로 전환하고 전원 사용량을 최적화하는 데 필요한 전원 관련 힌트를 GNSS 드라이버에 제공하도록 명시적으로 설계되었습니다. 추적, 지오펜싱 및 장기 실행의 만연한 위치 모니터링이 필요한 기타 기능을 위해 GNSS 드라이버/엔진은 저전력 하드웨어/프로세서를 활용해야 합니다. 드라이버에서 무차별 암호 대입 폴링 메커니즘을 사용하여 이러한 기능을 구현해야 하거나 앱 프로세서에서 구현해야 하는 경우 드라이버는 이러한 작업을 수행할 수 있는 것으로 선언해서는 안 됩니다. 이렇게 하면 HLOS가 이러한 기능의 노출을 플랫폼의 나머지 부분에 제한하거나 다른 플랫폼 서비스/기본 형식을 기반으로 해당 기능의 대체 구현을 사용할 수 있습니다.

• 프로그래밍 언어: GNSS 드라이버 인터페이스는 C++ 특정 언어 기본 형식(예: 구조 상속)을 사용하지 않는 C 언어 헤더 파일로 제공됩니다. 이렇게 하면 IHV가 C와 C++중에서 선택할 수 있습니다. GNSS 인터페이스 헤더 파일은 선택 항목을 IHV에 열어 둡니다.

• 필터 드라이버: 확장 기능을 지원하기 위해 스택에 향후 필터 드라이버를 추가하지 못하도록 GNSS 디바이스 스택을 제한해서는 안 됩니다. IHV 제공 GNSS 드라이버는 드라이버 스택의 맨 위 또는 아래쪽에 자체 필터 드라이버를 포함해서는 안 됩니다.

• 알림 및 이벤트: WDF 드라이버는 HLOS에 원치 않는 알림을 보낼 수 없으므로 항상 드라이버 계층에서 이러한 원치 않는 알림을 수신하기 위해 HLOS에서 시작된 보류 중인 IRP가 하나 이상 있습니다. 여기에는 시스템이 연결된 대기 상태인 경우가 포함됩니다. GNSS 드라이버의 경우 이러한 원치 않는 알림에는 네트워크 시작 요청, AGNSS 지원을 위한 지원 데이터, 기타 공급업체별 알림이 포함됩니다(이에 국한되지 않음). HLOS는 이러한 알림을 처리하기 위해 보류 중인 I/O 요청이 항상 있는지 확인합니다.

• 사용자 모드 IHV 확장: IHV는 IHV 정의 프라이빗 IOCTL을 통해 GNSS 드라이버와 상호 작용하는 액세서리 사용자 모드 구성 요소를 작성할 수 있습니다. 특히 GNSS 드라이버가 커널 모드에 있는 경우 사용자 모드에서만 사용할 수 있는 기능(예: Wi-Fi 검사, 연결 관리자 API 등)에 액세스할 수 없는 경우에 필요합니다. Windows 10 UMDF 2.0에서는 IHV가 여전히 별도의 사용자 모드 구성 요소를 구현할 수 있지만 UMDF GNSS 드라이버에는 별도의 사용자 모드 구성 요소가 필요하지 않습니다. 이러한 사용자 모드 구성 요소는 GNSS 드라이버에 대한 단순한 확장으로 처리되며 IHV 제공 BSP 드롭의 일부로 처리됩니다. Microsoft에서 제공하는 HLOS 구성 요소는 이러한 구성 요소의 정확한 구현 세부 정보와 IHV 사용자 모드/커널 모드 구성 요소 간의 상호 작용 메커니즘을 알지 못합니다. GNSS 드라이버가 사용자 모드 IHV 확장을 사용하여 UMDF 2.0 드라이버로 작성된 경우 이 모델에 더 많은 메모리 사용이 필요할 수 있으므로 권장되지 않습니다.

  사용자 모드 IHV 확장은 다음 규칙을 준수해야 합니다.

  • 공용 GNSS 드라이버 IOCTL의 의미 체계와 동작은 사용자 모드 IHV 확장 및 GNSS 드라이버와의 상호 작용에 영향을 받지 않고 방해받지 않아야 합니다.

  • 사용자 모드 확장은 Windows 10 플랫폼에서 적용되는 보안, 전원 및 기타 플랫폼 기본 사항 및 정책을 준수해야 합니다.

  • 사용자 모드 확장은 OS 플랫폼이 런타임에 이러한 권한 부여를 적용/유효성 검사하지 않고 Microsoft에서 승인한 권한 있는 활동만 수행해야 합니다.

  Microsoft는 여전히 보안 정책을 적용하고 이러한 구성 요소의 수명을 제어할 수 있습니다. 여기서 핵심은 IHV 사용자 모드 구성 요소가 확장 구성 요소가 신뢰할 수 있는 OS 구성 요소로 처리되는 것과 같은 정책을 적용하기 위해 플랫폼에 의존해서는 안 된다는 것입니다.

  IHV는 임의 기능을 추가하거나 권한이 없는 OS 서비스/보안 리소스를 사용하지 않습니다.

최소 지원 요구 사항

다양한 디바이스 계층(저렴한 비용, 고급, 다양한 디바이스 유형 등)의 요구를 충족하기 위해 Windows 플랫폼에 사용할 수 있는 다양한 GNSS(전역 탐색 위성 시스템) 디바이스가 있습니다. 이러한 풍부한 에코시스템을 활성화하고 저렴한 비용으로 GNSS 칩을 포함할 수 있는 태블릿, 노트북 및 기타 디바이스 유형의 수를 늘리기 위해 Microsoft는 GNSS 드라이버 참조에 설명된 전체 기능 집합을 지원하기 위해 모든 GNSS 디바이스를 요구하지 않습니다. 다음 표에서는 다양한 디바이스 유형에 필요한 최소한의 기능과 선택적 또는 권장되는 기능을 개략적으로 설명합니다.