Opsi zona waktu

Tampilan waktu yang akurat merupakan fitur inti yang diharapkan dari sistem infotainment otomotif. Meskipun hal ini tampak sederhana, terutama ketika ekspektasi terhadap pengelolaan waktu dan zona waktu rendah dan harus dipenuhi, waktu dengan cepat menjadi rumit ketika tanggal dan waktu yang akurat dan andal harus ditampilkan tanpa intervensi manual.

Semua jam waktu nyata yang biasanya digunakan dalam sistem pada chip (SoC) mengandung beberapa penyimpangan, yang terakumulasi seiring waktu dan dapat menyebabkan kesalahan yang signifikan jika tidak diperbaiki. Selain itu, karena tingginya ekspektasi agar waktu setempat ditampilkan secara akurat, penyesuaian yang benar dari Waktu Universal Terkoordinasi (UTC) harus dipertimbangkan.

Informasi zona waktu, serta penerapan Waktu Musim Panas (DST), diperkirakan dapat berubah selama masa pakai kendaraan. Misalnya, setelah bertahun-tahun menerapkan DST, Brasil memilih untuk tidak memulai jadwal DST pada tahun 2019.

Android menyediakan infrastruktur yang diperlukan untuk mengatasi kerumitan pengelolaan aturan zona waktu. Untuk detailnya, lihat Aturan zona waktu , yang memungkinkan OEM mengirimkan data aturan zona waktu yang diperbarui ke perangkat tanpa memerlukan pembaruan sistem. Mekanisme ini memungkinkan:

  • Pengguna akan menerima pembaruan tepat waktu (yang memperpanjang masa pakai perangkat Android).
  • OEM akan menguji pembaruan zona waktu secara independen dari pembaruan citra sistem.

Catatan: AAOS 10 tidak mendukung mekanisme pembaruan modul berbasis APEX yang disediakan dalam rilis Android 10 (dan lebih tinggi).

Catatan: Untuk menerapkan mekanisme ini, diperlukan reboot sistem.

Sumber informasi waktu (zona) di mobil

Perangkat Android mengelola waktu dalam waktu Unix di tingkat sistem, menerapkan offset zona waktu yang diinginkan, lalu mengonversi nilainya menjadi waktu lokal untuk ditampilkan kepada pengguna. ID zona pengguna saat ini (sering disebut sebagai ID Olson) disimpan sebagai pengaturan. Misalnya Eropa/London .

Sebagian besar mekanisme yang diuraikan di bawah ini menjelaskan informasi waktu. Maksud dari standar ini adalah untuk memberikan waktu saat ini kepada pengguna, bukan untuk menjelaskan aturan zona waktu yang berlaku. Untuk menentukan zona waktu sebenarnya, perangkat harus bekerja kembali dari faktor-faktor seperti negara, offset, dan offset DST sebelum mengatur ID zona.

Prosesnya bisa menjadi sebuah tantangan. Mengerjakan kembali berdasarkan informasi yang tersedia bisa jadi ambigu. Misalnya, aturan zona waktu Amerika/Denver menerapkan DST tetapi mengadopsi Waktu Musim Panas Pegunungan (MDT) selama musim panas sedangkan Amerika/Phoenix tetap mengakui MDT.

Radio seluler

Sistem informasi (SI) adalah aspek penting dari antarmuka udara Long-Term Evolution (LTE), yang ditransmisikan oleh stasiun pangkalan (BS) melalui saluran kontrol siaran (BCCH). 3GPP TS 36.331 menentukan SystemInformationBlockType16 (SIB16) yang berisi informasi terkait GPS dan Waktu Universal Terkoordinasi (UTC), offset waktu lokal, serta informasi DST.

Fungsi serupa dapat ditemukan di 2G dan 3G, di mana informasi identitas jaringan dan zona waktu (NITZ) dapat disiarkan (lihat 3GPP TS 22.042 untuk detailnya). Standar radio seluler lainnya memiliki fitur yang setara.

Sayangnya, kesamaan di antara sebagian besar standar adalah bahwa pengiriman informasi ini bersifat opsional, sehingga tidak tersedia secara universal di semua jaringan.

Kelebihan Kontra
  • Jika tersedia, berikan sebagian besar informasi yang diinginkan.
  • Kesederhanaannya, sudah didukung Android ketika radio seluler dihadirkan sebagai ponsel, tidak hanya sebagai modem data.
  • Tidak memerlukan konektivitas internet.

  • Tidak ada jaminan bahwa informasi tersebut disiarkan atau bahwa stasiun pangkalan dikonfigurasi dengan benar.

  • Di wilayah perbatasan, rawan mengambil menara seluler (roaming) dari negara tetangga dan berpotensi menyampaikan zona waktu yang salah.

  • Di beberapa lokasi, pembaruan memerlukan waktu berjam-jam, bahkan berhari-hari.

Protokol waktu jaringan

Network Time Protocol (NTP) sering digunakan untuk mendapatkan informasi waktu Unix yang relatif tepat. Android mendukung sinkronisasi waktu sistemnya dengan server NTP jika dapat diekspos ke klien RadioManager melalui metadata RadioTuner.getParameters() generik. NTP memperbarui waktu sistem ketika tidak sinkron dan operator belum memberikan pembaruan NITZ baru-baru ini. Jika pengguna mengaktifkan AUTO_TIME ketika NITZ tidak tersedia, sistem akan segera memeriksa waktu jaringan.

Kelebihan Kontra

Kesederhanaan, didukung oleh Android.

  • Tidak lengkap, NTP hanya menyediakan satu nilai yang dibutuhkan (waktu). Bahkan dalam skenario terbaik, NTP tidak dapat menyediakan zona waktu.

  • Membutuhkan konektivitas internet.

Penyetel radio siaran

Meskipun memanfaatkan tuner bawaan untuk mengambil informasi waktu dan zona waktu merupakan hal yang menarik, terdapat tantangan tersendiri. Banyak standar siaran radio yang menentukan pilihan untuk memaparkan informasi yang diinginkan. Secara umum, tuner radio siaran memberikan informasi yang sama seperti radio seluler.

ETSI EN 300 401 V1.4.1 (2006-06), bagian 8.1 menetapkan fitur informasi layanan yang memberikan informasi tambahan tentang layanan untuk program audio dan data untuk sistem Penyiaran Audio Digital (DAB). Bagian 8.1.3 mendefinisikan format waktu dan tanggal serta informasi untuk offset waktu negara dan lokal.

Demikian pula, untuk Sistem Data Radio (RDS) yang biasa diterapkan pada tuner FM, bagian 3.1.5.6 dari standar EN 50067 mendefinisikan format waktu jam dan data (ditransmisikan sekali per menit). Selain itu, kode negara yang diperluas (ECC) juga dapat diambil sebagai bagian dari identifikasi program yang dikirimkan.

Radio HD berisi opsi yang sesuai sebagai bagian dari Deskripsi Desain Antarmuka Udara Radio HD™ Spesifikasi Transportasi Layanan Informasi Stasiun dalam Pesan Parameter Layanan Informasi Stasiun (SIS) (MSG ID 0111). Bagian 5 dengan jelas menguraikan kata-kata peringatan yang harus diperhatikan ketika mencoba menggunakan dukungan jam siaran. Kebijaksanaan yang sama juga berlaku untuk sistem lain:

... data ini menggambarkan adat istiadat setempat di tempat penyiar, yang bisa sama atau tidak sama dengan adat setempat di tempat penerima. Mendekati batas zona waktu, konsumen dapat menerima beragam stasiun yang menyediakan data berbeda. Oleh karena itu, data ini diberikan hanya sebagai petunjuk, penafsiran dan pemanfaatannya harus dilakukan berdasarkan kebijaksanaan, dan tunduk pada kendali pelanggan. ... "

Selain itu, setidaknya untuk Radio HD, penyiaran informasi ini bersifat opsional dan tidak boleh diandalkan secara eksklusif.

Kelebihan Kontra
  • Biasanya tersedia di berbagai standar radio siaran regional.
  • Tidak memerlukan konektivitas internet.
  • Android tidak mendukung hal ini.
  • Memerlukan tuner untuk dihidupkan (setidaknya kadang-kadang di latar belakang) untuk mendeteksi informasi dengan andal.

  • Keandalan tergantung pada penyiarnya.

Kiat implementasi

Android mendukung sinkronisasi waktu sistemnya dengan server NTP jika dapat diekspos ke klien RadioManager . Solusi yang disarankan adalah memanfaatkan fitur ekstensi vendor. Implementasi fungsi ini harus terjadi di lapisan abstraksi perangkat keras (HAL), setelah itu dapat diekspos ke klien RadioManager melalui metode RadioTuner.getParameters() generik.

Agar solusi tetap kuat, konsumen ekstensi vendor ini harus menentukan bahwa HAL mendukung fitur tersebut (jangan berasumsi keberadaannya). String parameter untuk panggilan getParameters harus diatur dengan rapi agar penggunaan yang jelas di seluruh vendor. Misalnya, menggunakan namespace organisasi Anda dengan mengawalinya dengan domain yang sesuai, misalnya com.me.timezoneTuner.currenttimezone .

Mengingat sifat informasi yang didorong oleh peristiwa, akan bermanfaat jika menggunakan callback RadioTuner.Callback.onParametersUpdated() untuk menerima informasi ini. Jika fasilitas ini dapat dikonfigurasi, rancang serangkaian rutinitas khusus di atas setParameters . Misalnya:

com.me.timezoneTuner.currenttimezoneEvent.enable

Dengan sendirinya, Sistem Satelit Navigasi Global (GNSS) hanya dapat memberikan informasi waktu dan posisi yang akurat.

Geolokasi

Solusi atas ketidaknyamanan ini adalah dengan melakukan reverse-geocoding dan menentukan negara dan zona waktu dengan melakukan pencarian berdasarkan posisi. GNSS adalah pilihan informasi lokasi yang jelas (dan kualitas terbaik) di dalam kendaraan. API Zona Waktu Google menawarkan semua yang diperlukan untuk menjalankan konversi yang diperlukan. Tentu saja, konektivitas internet diperlukan. Memastikan privasi pengguna harus menjadi prioritas utama saat menerapkan solusi online! Izin pengguna untuk menerima biaya penggunaan data (atau tidak) diperlukan dan harus diminta.

Dimungkinkan untuk membuat solusi yang sesuai untuk penggunaan offline. Basis data peta lokal dengan resolusi yang memadai untuk menentukan negara dan zona waktu secara akurat dapat dimasukkan ke dalam penyimpanan kendaraan. Dengan hal ini dan strategi yang diterapkan sepenuhnya untuk memperbarui informasi zona waktu (dan negara) sesuai kebutuhan, seseorang dapat melakukan geokode balik negara/zona waktu berdasarkan posisi GNSS yang diperoleh dari subsistem Lokasi.

Kelebihan Kontra
  • Dapat dengan jelas menentukan zona waktu yang tepat.
  • Tidak memerlukan konektivitas internet (dalam kasus DB lokal).
  • Bekerja dengan andal untuk sebagian besar skenario berkendara.
  • Android tidak mendukung hal ini.
  • Jika kendaraan berada di dalam ruangan/area tertutup di mana penerimaan satelit GNSS yang baik tidak memungkinkan selama konfigurasi awal, maka mustahil mendapatkan informasi waktu, lokasi, dan zona waktu yang akurat.
  • Basis data lokal memerlukan mekanisme pembaruan.
  • Kompleksitas implementasi.

Ponsel terhubung melalui Bluetooth, Wi-Fi, atau USB

Beberapa teknologi dapat digunakan untuk memanfaatkan ponsel pengguna untuk memperoleh data waktu dan zona waktu. Untuk semua ponsel, sepasang aplikasi khusus dan aplikasi pendamping harus diinstal pada ponsel dan pada sistem Infotainment Dalam Kendaraan (IVI). Kemudian dimungkinkan untuk menyinkronkan waktu pada interval yang diinginkan. Misalnya, saat membuat sambungan dan saat ponsel mendeteksi zona waktu baru.

Beberapa ponsel yang mendukung Bluetooth Low Energy (BLE) menyediakan opsi untuk mengambil waktu melalui karakteristik GATT Current Time dan Current Time Service Profile Profile 1.1 . Namun, opsi ini tidak mencakup segmen pasar yang cukup besar untuk diandalkan secara eksklusif.

Kelebihan Kontra
  • Tidak memerlukan konektivitas internet.
  • Perubahan zona waktu yang terdeteksi oleh telepon dapat diteruskan ke head unit.
  • Android tidak mendukung hal ini.
  • Hanya berfungsi saat ponsel terhubung ke head unit.
  • Waktu sama baiknya atau buruknya dengan apa yang disediakan telepon.
  • Implementasinya rumit.
  • Tidak semua telepon mendukung profil Layanan Waktu Saat Ini BLE GATT.

Gunakan sumber

Setiap vendor perangkat harus menentukan seberapa tinggi standar yang harus ditetapkan dan perjalanan pengguna mana yang dianggap paling penting. Hanya dengan pemahaman yang jelas tentang pengalaman pengguna penting yang diinginkan, keputusan terbaik dapat diambil. Dalam kebanyakan kasus, vendor harus mempertimbangkan keseimbangan antara kenyamanan dan kompleksitas implementasi.

Setiap opsi yang dijelaskan di atas mempunyai kelebihan dan kekurangan. Misalnya, pilihan desain yang penting harus dibuat sehubungan dengan seberapa besar ketahanannya, dibandingkan dengan tampilan waktu yang buruk, yang dapat diterima dan bagaimana cara mengelola kelemahannya. Solusi yang sepenuhnya otomatis dan diharapkan dapat berfungsi dengan baik di semua skenario, namun harus didasarkan pada kombinasi beberapa sumber informasi. Tidak ada satu opsi pun yang dapat memberikan ketersediaan 100%.

Opsi konfigurasi manual sebagai cadangan sementara mudah dijalankan dan, dalam praktiknya, cukup bagi banyak pengguna.