Bagikan melalui

Persyaratan pengemudi perangkat lunak Global Navigation Satellite System (GNSS)

Menjelaskan persyaratan, asumsi, dan batasan yang perlu dipertimbangkan saat mengembangkan driver Global Navigation Satellite System (GNSS) untuk Windows 10.

Persyaratan umum

  • Kerangka kerja driver: Driver GNSS harus ditulis sebagai driver UMDF 2.0 berdasarkan definisi antarmuka ini, dibandingkan dengan driver WDM mentah atau driver KMDF. Driver UMDF 1.0 juga tidak didukung. Definisi antarmuka driver GNSS atau komponen GNSS sistem operasi tingkat tinggi (HLOS) Microsoft seperti adaptor GNSS tidak membuat perbedaan antara driver WDF, KMDF GNSS, dan driver UMDF 2.0, selama driver menyediakan fungsionalitas yang diperlukan sesuai desain antarmuka ini. UMDF 2.0 memberikan stabilitas, kesederhanaan, dan fleksibilitas yang lebih tinggi untuk mengimplementasikan fitur yang memerlukan fungsionalitas yang hanya ditawarkan dalam mode pengguna. Sebagai aturan umum, IHV sebaiknya lebih memilih UMDF 2.0 daripada KMDF saat kerangka kerja ini tersedia di platform.

 UMDF 2.0 tersedia di semua platform dan IHV sangat disarankan untuk menggunakan driver yang ditulis dalam mode pengguna.

  • Beberapa sesi aplikasi: Sesi aplikasi adalah sesi posisi yang berasal dari komponen HLOS yang berinteraksi langsung dengan driver GNSS. Driver GNSS dapat memilih untuk secara asli mendukung beberapa sesi aplikasi dengan mempartisi variabel status dan fungsionalitasnya ke dalam basis per aplikasi. Ini adalah kemampuan opsional driver dan ditunjukkan secara khusus melalui informasi kemampuan driver GNSS yang terdefinisi dengan baik. Untuk mendukung perilaku opsional ini, driver GNSS perlu melacak handel file yang didapatkan aplikasi HLOS selama CreateFile, dan mengaitkan semua operasi HLOS berikutnya ke handel file khusus sesi aplikasi. Dukungan asli dari driver GNSS ini memungkinkan komponen HLOS menjadi lebih fleksibel dan kurang ketat tentang mengekspos driver ke platform lainnya. Driver GNSS yang mendukung kemampuan ini mungkin perlu mempartisi dan mempertahankan informasi status secara logis untuk setiap sesi aplikasi individu. Driver GNSS yang tidak mendukung kemampuan ini hanya perlu mempertahankan status global untuk semua sesi aplikasi alih-alih partisi khusus aplikasi logis. Dalam mode terakhir ini, driver GNSS tidak sadar dengan adanya beberapa sesi aplikasi paralel dan memperlakukan semua permintaan dari HLOS seolah-olah berasal dari sesi aplikasi yang sama.

    Dukungan driver GNSS untuk beberapa sesi aplikasi.

    Dukungan dalam driver GNSS untuk beberapa sesi aplikasi memiliki keuntungan mengaktifkan aplikasi pengujian di HLOS untuk berinteraksi langsung dengan driver GNSS pada saat yang sama dengan adaptor GNSS. Aplikasi pengujian dan adaptor GNSS adalah yang kami anggap sebagai aplikasi berbeda yang dapat meminta beberapa sesi ke satu driver GNSS secara bersamaan. Jika beberapa sesi aplikasi tidak didukung, driver GNSS perlu diuji melalui Platform Lokasi OS, atau jika tidak, layanan yang menghosting Platform Lokasi OS harus dihentikan untuk menghindari gangguan pada aplikasi pengujian.

  • Sesi penentuan posisi: Tindakan mendapatkan informasi penentuan posisi dari driver dasar (tunggal atau pelacakan) dianggap sebagai gagasan sesi penentuan posisi. Driver perlu mendukung setidaknya satu sesi perbaikan dari setiap jenis sesi yang didukung. Jenis sesi ditentukan di bawah enumerasi GNSS_FIXSESSIONTYPE .

    • Minimal, driver GNSS harus mendukung satu sesi perbaikan bidikan.

    • Driver yang mendukung sesi perbaikan pelacakan berbasis jarak harus mendukung secara bersamaan sesi perbaikan bidikan tunggal dan sesi perbaikan pelacakan berbasis jarak.

    • Driver yang mendukung sesi perbaikan pelacakan berbasis waktu harus dapat mendukung keduanya secara bersamaan, yaitu sesi perbaikan satu kali dan sesi perbaikan pelacakan berbasis waktu.

    • Driver yang mendukung sesi perbaikan pelacakan berbasis jarak dan sesi perbaikan pelacakan berbasis waktu harus mendukung secara bersamaan sesi perbaikan bidikan tunggal, sesi perbaikan pelacakan berbasis jarak dan sesi perbaikan pelacakan berbasis waktu.

    dukungan driver untuk beberapa sesi pembaruan simultan.

    Apakah driver mendukung beberapa sesi perbaikan simultan atau tidak dinyatakan oleh parameter kemampuan driver yang terdefinisi dengan baik. Jika driver tidak secara eksplisit mendukung beberapa sesi perbaikan paralel, driver harus gagal permintaan sesi perbaikan baru jika sesi dengan jenis perbaikan yang sama sudah dimulai dan aktif. Jika dukungan beberapa sesi fix tidak ada, tanggung jawab ada di komponen HLOS untuk memastikan bahwa beberapa permintaan GNSS yang berasal dari aplikasi tingkat tinggi dimultipleks dan dipetakan menjadi satu permintaan sesi fix ke driver GNSS.

    Driver GNSS tidak diperlukan untuk mendukung beberapa sesi perbaikan paralel dengan jenis yang sama. Bahkan di Windows 10, adaptor HLOS GNSS tidak mendukung pemanfaatan kemampuan driver GNSS untuk memiliki beberapa sesi perbaikan dengan jenis yang sama, sehingga IHV tidak didorong untuk berinvestasi pada fungsionalitas ini untuk saat ini. Dalam rilis mendatang akan dipertimbangkan untuk mengaktifkan adaptor GNSS untuk langsung memulai sesi dengan driver GNSS untuk setiap permintaan perbaikan yang diperoleh dari lapisan atas platform lokasi, daripada melakukan multipleks sesi itu sendiri. Dukungan multipleks sesi perbaikan dalam adaptor GNSS menyederhanakan implementasi driver karena tidak mengharuskannya untuk menangani beberapa sesi dengan jenis yang sama untuk aplikasi atau implementasi multipleks, ini mengurangi penggunaan memori dalam driver, dan tidak memerlukan adaptor GNSS untuk menangani kasus HLOS memulai sejumlah sesi perbaikan yang lebih besar dari apa yang didukung oleh driver GNSS. Tingkat perangkat yang berbeda dan driver yang berbeda akan mendukung sejumlah sesi perbaikan bersamaan yang berbeda, sehingga kasus ini perlu ditangani, memperkenalkan kompleksitas dalam adaptor GNSS untuk menangani semua kasus. Oleh karena itu, di Windows 10 adaptor GNSS hanya akan mengimplementasikan sesi perbaikan tunggal dari setiap jenis yang didukung dan akan mengabaikan dukungan beberapa sesi perbaikan oleh driver sampai kita membutuhkan fungsionalitas ini.

    Setiap sesi perbaikan bersifat stateful dan harus mengikuti urutan yang ditentukan dengan baik ini:

    1. Memulai sesi perbaikan

    2. Mendapatkan satu atau beberapa perbaikan

    3. Mengubah sesi perbaikan jika diperlukan

    Ini diperlukan setidaknya sampai adaptor GNSS menangani multipleksasi sesi pemfokusan dengan jenis yang sama dan bahkan mungkin diperlukan nanti untuk menangani kasus sesi pemfokusan yang aktif secara bersamaan lebih banyak daripada jumlah yang didukung oleh driver GNSS.

    1. Menghentikan sesi perbaikan

    Sesi perbaikan diidentifikasi secara unik oleh ID sesi perbaikan. Tidak ada informasi posisi yang dapat diambil oleh HLOS di luar konteks sesi penentuan lokasi. Driver GNSS harus memungkinkan modifikasi parameter sesi dengan cepat untuk memfasilitasi operasi multipleks oleh komponen HLOS, tanpa perlu memulai ulang sesi perbaikan.

    perbaiki komunikasi laporan antara driver gnss dan aplikasi.

  • Jenis perbaikan: Driver GNSS harus minimal mendukung perbaikan bidikan tunggal dasar. Selain itu driver harus secara bawaan mendukung fitur perbaikan tingkat lanjut (seperti pelacakan). Seperti yang dinyatakan sebelumnya, mendukung jenis perbaikan tambahan menyiratkan bahwa bahkan jika driver tidak mendukung beberapa sesi perbaikan dengan jenis yang sama, itu harus mendukung secara bersamaan setidaknya satu sesi perbaikan dari jenis perbaikan yang didukung. Komponen HLOS tidak menggabungkan jenis penentuan posisi yang berbeda ke dalam satu jenis.

  • Antarmuka perangkat dan PnP: Driver GNSS harus mengiklankan antarmuka perangkat yang ditentukan Microsoft menggunakan API WdfDeviceCreateDeviceInterface sehingga HLOS dapat mendapatkan pemberitahuan tentang kedatangan dan keberangkatan driver GNSS. Ini akan diperlukan untuk menangani driver GNSS baik dalam pengaturan Plug and Play (PnP) maupun jika driver adalah driver UMDF 2.0, dalam kasus di mana pembongkaran driver yang tidak terduga terjadi karena crash layanan tingkat pengguna. Driver GNSS harus memastikan bahwa antarmuka perangkat hanya diiklankan ketika perangkat keras di bawahnya mampu mendukung panggilan HLOS IOCTL dan tidak sebelum itu.

  • Kebijakan daya perangkat: Driver GNSS harus mengelola kebijakan daya perangkatnya dan harus menangani peristiwa manajemen daya yang diangkat oleh OS. Driver harus mendaftar untuk WDF_PNPPOWER_EVENT_CALLBACKS.EvtDeviceD0Entry callback (dipanggil oleh WDF ketika sistem masuk ke mode D0) dan WDF_PNPPOWER_EVENT_CALLBACKS.EvtDeviceD0Exit callback (dipanggil oleh WDF ketika sistem keluar dari mode D0). Driver GNSS harus dapat dikonfigurasi untuk menonaktifkan manajemen daya secara opsional.

    Manajemen daya yang tepat yang perlu dilakukan dalam perangkat GNSS dalam berbagai status daya sistem perlu disesuaikan sesuai dengan kemampuan perangkat GNSS (apakah mendukung operasi offload atau tidak), apakah ada operasi offload yang sebenarnya aktif, dan bagaimana komunikasi antara sistem dan perangkat GNSS dilakukan. Secara umum harapannya adalah sebagai berikut:

    • Perangkat GNSS akan bekerja dalam mode daya terendah yang mungkin ketika tidak ada sesi aktif atau operasi yang dilepaskan, terlepas dari status daya sistem.

    • Dalam kasus skenario offload, sekali lagi terlepas dari status daya sistem, perangkat GNSS mungkin perlu memeriksa posisi pada interval yang berbeda atau menerima pemberitahuan dan dengan demikian perangkat GNSS mungkin perlu tetap dalam status D0 bahkan selama siaga yang terhubung (ini adalah status tidur screen-off), tetapi masih perangkat keras perlu mengurangi konsumsi daya seminimal mungkin. Model ini akan berfungsi untuk perangkat tersebut menggunakan DMA (Akses Memori Langsung) atau port serial pada UART untuk berkomunikasi dengan host, misalnya. Tetapi akan menjadi tantangan bagi perangkat GNSS yang terhubung melalui bus USB, di mana kemungkinan besar fungsi USB perangkat harus berada dalam status daya perangkat D2 (ditangguhkan) selama siaga tersambung. Secara umum, perangkat GNSS yang terhubung melalui USB harus dapat memasuki status D2 berdaya rendah (ditangguhkan) setelah mereka tidak memiliki sesi perbaikan atau operasi offload yang sedang berlangsung dan antarmuka bus USB memasuki status ditangguhkan. Semua transisi daya tidur dan bangun harus disinyalir melalui bus USB. Jika perangkat GNSS memiliki sesi fix aktif atau operasi offload, perangkat harus dapat menggunakan sinyal resume USB in-band untuk membangunkan SoC atau inti silicon dari siaga terhubung. SoC atau silikon inti harus dapat beralih dari kondisi daya terendahnya sebagai respons terhadap sinyal pemulihan USB in-band dari perangkat GNSS.

    • Perangkat yang tidak mendukung siaga yang terhubung akan membatalkan semua operasi offload pada saat perangkat masuk ke siaga modern atau hibernasi. Ini termasuk geofence yang dilepaskan, pelacakan jarak, atau sesi pelacakan berkala.

    • Perangkat yang mendukung standby terhubung akan terus mengaktifkan semua operasi yang di-offload ketika perangkat masuk ke standby terhubung. Perangkat GNSS diharapkan melanjutkan operasi pelacakan seefisien mungkin dan diharapkan memberikan pemberitahuan kepada HLOS jika kondisi pemicu geofence atau pembaruan sesi pelacakan relevan. Jika tidak ada pemindahan beban kerja di perangkat yang mendukung siaga tersambung, perangkat GNSS seharusnya masuk ke kondisi daya terendah yang mungkin tetapi masih dapat menerima permintaan sesi lokasi dari HLOS. Dalam perangkat yang mendukung SUPL, perangkat GNSS dan tumpukan SUPL juga harus dimungkinkan untuk bangun pada pemberitahuan NI saat dalam siaga yang terhubung.

    Informasi umum tentang manajemen daya untuk driver dapat ditemukan di Tanggung Jawab Manajemen Daya untuk Driver.

  • Pertimbangan daya: Tumpukan driver GNSS harus memperhitungkan konsumsi daya sebagai tujuan desain utama dan meminimalkan waktu prosesor utama tetap aktif sebanyak mungkin. Semua dukungan fungsionalitas tingkat lanjut (seperti jenis perbaikan yang berbeda) harus dijalankan dengan cara yang hemat daya seperti prosesor aplikasi utama tidak perlu aktif lebih dari yang diperlukan dan sebagian besar pemrosesan dapat dilepaskan ke prosesor chipset/berdaya rendah. Sebagai aturan umum, kecuali dinyatakan lain dari HLOS, driver GNSS harus selalu memperlakukan konsumsi daya sebagai batasan yang paling penting, dan harus dirancang untuk melakukan operasi normal dengan jejak daya minimal. Antarmuka driver GNSS dirancang secara eksplisit untuk memungkinkan perangkat seluler beralih ke mode berdaya rendah sesering mungkin, dan untuk memberikan petunjuk terkait daya yang diperlukan kepada driver GNSS untuk mengoptimalkan penggunaan daya. Untuk pelacakan, geofencing, dan fungsionalitas lain yang memerlukan pemantauan posisi pervasif yang berjalan lama, driver/mesin GNSS harus memanfaatkan perangkat keras/prosesor berdaya rendah. Jika fungsionalitas tersebut harus diimplementasikan menggunakan mekanisme polling brute-force di driver atau jika perlu diimplementasikan dalam prosesor aplikasi, driver tidak boleh mendeklarasikan dirinya sebagai mampu melakukan operasi tersebut. Ini akan memungkinkan HLOS membatasi paparan fungsionalitas tersebut ke seluruh platform, atau menggunakan implementasi alternatif dari fungsionalitas tersebut berdasarkan layanan/primitif platform lainnya.

  • Bahasa pemrograman: Antarmuka driver GNSS dikirimkan sebagai file header bahasa C yang tidak menggunakan primitif bahasa tertentu C++ (misalnya, pewarisan struktur). Ini memungkinkan IHV untuk memilih antara C dan C++. File header antarmuka GNSS menyediakan kebebasan pilihan untuk IHV.

  • Driver filter: Tumpukan perangkat GNSS tidak boleh dibatasi sedemikian rupa sehingga mencegah penambahan driver filter di masa mendatang di tumpukan untuk mendukung fungsionalitas yang diperluas. Driver GNSS yang dikirim IHV tidak boleh menyertakan driver filternya sendiri baik di bagian atas atau di bagian bawah tumpukan driver.

  • Pemberitahuan dan peristiwa: Karena driver WDF tidak dapat mengirim pemberitahuan yang tidak diminta ke HLOS, akan selalu ada setidaknya satu IRP yang tertunda yang dimulai dari HLOS yang melayani tujuan menerima pemberitahuan yang tidak diminta tersebut dari lapisan driver. Ini termasuk kasus di mana sistem dalam siaga terhubung. Untuk penggerak GNSS, pemberitahuan tanpa permintaan tersebut termasuk (tetapi tidak terbatas pada) permintaan yang dimulai oleh jaringan, data bantuan untuk dukungan AGNSS, dan pemberitahuan lain yang spesifik untuk vendor. HLOS akan memastikan bahwa permintaan I/O yang tertunda selalu ada untuk menangani pemberitahuan tersebut.

  • Ekstensi IHV mode pengguna: IHV dapat menulis komponen mode pengguna aksesori yang berinteraksi dengan driver GNSS melalui IOCTL privat yang ditentukan IHV. Ini sangat diperlukan jika driver GNSS beroperasi dalam mode kernel, karena dalam situasi tersebut tidak memiliki akses ke fungsionalitas yang tersedia secara eksklusif dalam mode pengguna (misalnya, pemindaian Wi-Fi, API Pengelola Koneksi, dan sebagainya). Perhatikan bahwa dengan UMDF 2.0 di Windows 10, driver UMDF GNSS tidak memerlukan komponen mode pengguna terpisah, meskipun IHV mungkin masih menerapkan komponen mode pengguna terpisah. Komponen mode pengguna ini diperlakukan sebagai ekstensi belaka untuk driver GNSS dan akan diperlakukan sebagai bagian dari penurunan BSP yang dikirimkan IHV. Komponen HLOS yang disediakan Microsoft tidak sadar dengan detail implementasi yang tepat dari komponen tersebut dan mekanisme interaksi antara komponen mode pengguna/mode kernel IHV. Jika driver GNSS ditulis sebagai driver UMDF 2.0 menggunakan ekstensi IHV pada mode pengguna, hal tersebut tidak disarankan karena model ini kemungkinan akan memerlukan lebih banyak penggunaan memori.

    Ekstensi IHV mode pengguna harus mematuhi aturan berikut:

    • Semantik dan perilaku IOCTL driver GNSS publik harus tetap tidak terpengaruh dan tidak terhalang oleh ekstensi IHV mode pengguna dan interaksinya dengan driver GNSS.

    • Ekstensi mode pengguna harus mematuhi keamanan, daya, dan dasar-dasar dan kebijakan platform lainnya yang diberlakukan oleh platform Windows 10.

    • Ekstensi mode pengguna hanya boleh melakukan aktivitas resmi yang disetujui oleh Microsoft, tanpa meminta platform OS memberlakukan/memvalidasi otorisasi tersebut saat runtime.

    Microsoft masih dapat memberlakukan kebijakan keamanan dan mengontrol masa pakai komponen tersebut. Poin utama di sini adalah bahwa komponen mode pengguna IHV tidak boleh mengandalkan platform untuk memberlakukan kebijakan seperti komponen ekstensi diperlakukan sebagai komponen OS tepercaya.

    IHV tidak akan menambahkan fungsionalitas sewenang-wenang atau menggunakan layanan OS yang tidak sah/sumber daya aman.

Persyaratan dukungan minimum

Akan ada berbagai macam perangkat Global Navigation Satellite System (GNSS) yang dapat digunakan untuk platform Windows untuk memenuhi kebutuhan berbagai tingkat perangkat (berbiaya rendah, kelas atas, berbagai jenis perangkat, dan sebagainya). Untuk mengaktifkan ekosistem kaya tersebut dan meningkatkan jumlah tablet, laptop, dan jenis perangkat lain yang dapat menyertakan chip GNSS dengan biaya lebih rendah, Microsoft tidak memerlukan semua perangkat GNSS untuk mendukung serangkaian fitur lengkap yang dijelaskan dalam referensi driver GNSS. Tabel berikut ini menyediakan tampilan tingkat tinggi dari fungsionalitas minimal yang diperlukan untuk berbagai jenis perangkat dan fungsionalitas apa yang opsional atau direkomendasikan.

Fungsionalitas Persyaratan untuk semua platform Persyaratan khusus untuk ponsel Catatan
Pelaporan GNSS_DEVICE_CAPABILITIES dengan akurat Wajib Persyaratan fungsionalitas minimal
Dukungan untuk MultipleFixSessions Fakultatif Tidak didukung oleh adaptor GNSS
Dukungan untuk MultipleAppSessions Direkomendasikan
Dukungan Bantuan GNSS (khusus IHV) Direkomendasikan Wajib
Mendapatkan dukungan GNSS Assistance melalui Microsoft (utilisasi Agss_inject IOCTL) Direkomendasikan
Dukungan untuk struktur GNSS_FixData lengkap Wajib
Sesi bidikan tunggal Wajib
Dukungan bawaan untuk sesi pelacakan berbasis waktu Fakultatif Jika didukung, harus menyertakan dukungan untuk memodifikasi parameter sesi.
Dukungan bawaan untuk sesi pelacakan berbasis jarak Fakultatif Jika didukung, harus menyertakan dukungan untuk memodifikasi parameter sesi.
Sesi terakhir yang diketahui Fakultatif
Dukungan geofencing asli Fakultatif Direkomendasikan Hanya geofence melingkar yang diperlukan dan didukung
Menyediakan ChipsetInfo Wajib Menggunakan GNSS_ChipsetInfo
Melaporkan Kesalahan Direkomendasikan Menggunakan GNSS_ErrorInfo
Laporan melalui NMEA Fakultatif
Dukungan pengujian manufaktur (gelombang pembawa atau pengujian mandiri) Fakultatif
Lokasi bidang kontrol dengan integrasi MBB Wajib hanya jika diperlukan oleh operator seluler Wajib Biasanya diperlukan oleh operator seluler di perangkat dengan dukungan suara. Hampir selalu diperlukan untuk ponsel.
SUPL 1.0 Wajib hanya jika diperlukan oleh operator seluler Secara umum digantikan oleh SUPL 2.0.

Termasuk implementasi persyaratan pertemuan klien yang diatur oleh operator seluler, konfigurasi melalui DDI, pelaporan kejadian NI ke OS melalui DDI, dan integrasi dengan MBB.
SUPL 2.x Wajib hanya jika diperlukan oleh operator seluler Wajib Biasanya diperlukan oleh operator seluler di perangkat dengan dukungan suara. Hampir selalu diperlukan untuk ponsel.

Termasuk penerapan persyaratan operator seluler untuk pertemuan klien secara lengkap, konfigurasi melalui DDI, pelaporan event NI ke OS melalui DDI, dan integrasi dengan MBB.
UPL Wajib hanya jika diperlukan oleh operator seluler Hanya perlu didukung untuk pengiriman perangkat CDMA tersebut di Tiongkok, jika diperlukan oleh operator seluler.

Termasuk implementasi persyaratan operator seluler untuk rapat klien penuh, konfigurasi melalui DDI, pelaporan kejadian NI ke OS melalui DDI, dan integrasi dengan MBB.
Perintah driver untuk GNSS_SetLocationServiceEnabled Wajib
perintah pengandar GNSS_SetLocationNIRequestAllowed Wajib hanya jika SUPL didukung dan diperlukan oleh operator seluler Tidak ada operator seluler yang diketahui memerlukan ini lagi
perintah driver GNSS_ForceSatelliteSystem Direkomendasikan Bagus untuk tujuan pengujian. Beberapa operator seluler atau OEM mungkin memerlukan ini untuk pengujian.
perintah pengandar "GNSS_ForceOperationMode" Wajib hanya jika SUPL didukung Beberapa operator seluler mungkin memerlukan untuk tujuan pengujian.
perintah driver GNSS_ResetEngine Wajib Untuk tujuan pengujian
perintah pengandar GNSS_ClearAgnssData Wajib Untuk tujuan pengujian
perintah driver GNSS_SetNMEALogging Fakultatif Hanya jika diperlukan oleh operator seluler atau OEM membutuhkan ini untuk tujuan pengujian
perintah driver untuk GNSS_SetSuplVersion Wajib hanya jika SUPL didukung Diperlukan untuk SUPL
perintah driver "GNSS_SetUplServerAccessInterval" Wajib hanya jika SUPL didukung dan diperlukan oleh operator seluler Hanya jika diperlukan oleh operator seluler
perintah driver GNSS_SetNiTimeoutInterval Wajib hanya jika SUPL didukung dan diperlukan oleh operator seluler Hanya jika diperlukan oleh operator seluler
perintah pengandar GNSS_ResetGeofencesTracking Wajib hanya jika geofencing didukung
perintah GNSS_CustomCommand driver Fakultatif