ตัวเลือกเขตเวลา

การแสดงเวลาที่ถูกต้องเป็นฟีเจอร์หลักที่คาดหวังจากระบบสาระบันเทิงในรถยนต์ แม้ว่าอาจดูเหมือนง่าย แต่เวลาจะซับซ้อนขึ้นอย่างรวดเร็วเมื่อต้องแสดงวันที่และเวลาที่ถูกต้องอย่างน่าเชื่อถือโดยไม่ต้องมีการแทรกแซงด้วยตนเอง โดยเฉพาะอย่างยิ่งเมื่อความคาดหวังด้านการจัดการเวลาและเขตเวลาต่ำและต้องเป็นไปตามนั้น

โดยปกติแล้ว นาฬิกาแบบเรียลไทม์ทั้งหมดที่ใช้ในระบบบนชิป (SoC) จะมีการเลื่อนเวลา ซึ่งจะสะสมไปเรื่อยๆ เมื่อเวลาผ่านไป และอาจทำให้เกิดข้อผิดพลาดอย่างมากหากไม่ได้รับการแก้ไข นอกจากนี้ เนื่องจากผู้ใช้คาดหวังให้ระบบแสดงเวลาท้องถิ่นอย่างถูกต้อง คุณจึงต้องพิจารณาการชดเชยที่ถูกต้องจาก เวลาสากลเชิงพิกัด (UTC)

คาดว่าข้อมูลเขตเวลาและการใช้เวลาออมแสง (DST) จะมีการเปลี่ยนแปลงในช่วงอายุการใช้งานที่คาดไว้ของยานพาหนะ ตัวอย่างเช่น หลังจากใช้ DST มาหลายปี บราซิลเลือกที่จะไม่เริ่มกำหนดเวลา DST ในปี 2019

Android มีโครงสร้างพื้นฐานที่จำเป็นในการจัดการความซับซ้อนของกฎเขตเวลา ดูรายละเอียดได้ที่กฎเขตเวลา ซึ่งช่วยให้ OEM สามารถส่งข้อมูลกฎเขตเวลาที่อัปเดตแล้วไปยังอุปกรณ์ได้โดยไม่ต้องมีการอัปเดตระบบ กลไกนี้ช่วยให้ทำสิ่งต่อไปนี้ได้

  • ผู้ใช้จะได้รับการอัปเดตอย่างทันท่วงที (ซึ่งจะช่วยยืดอายุการใช้งานของอุปกรณ์ Android)
  • OEM ทดสอบการอัปเดตเขตเวลาโดยไม่ขึ้นอยู่กับการอัปเดตอิมเมจของระบบ

หมายเหตุ: AAOS 10 ไม่รองรับกลไกการอัปเดตโมดูลที่อิงตาม APEX ซึ่งมีให้ใน Android 10 (และสูงกว่า)

หมายเหตุ: ต้องรีบูตระบบเพื่อใช้กลไกนี้

แหล่งข้อมูลเวลา (เขต) ในรถยนต์

อุปกรณ์ Android จัดการเวลาในรูปแบบเวลา Unix ที่ระดับระบบ ใช้การชดเชยเขตเวลาที่ต้องการ แล้วแปลงค่าเป็นเวลาท้องถิ่นเพื่อแสดงต่อผู้ใช้ ระบบจะจัดเก็บรหัสโซนของผู้ใช้ปัจจุบัน (มักเรียกว่ารหัส Olson) เป็นการตั้งค่า เช่น Europe/London

กลไกส่วนใหญ่ที่ระบุไว้ด้านล่างอธิบายข้อมูลเวลา จุดประสงค์ของมาตรฐานเหล่านี้คือ เพื่อให้ผู้ใช้ทราบเวลาปัจจุบัน ไม่ใช่เพื่ออธิบายกฎเขตเวลาที่เกี่ยวข้อง หากต้องการระบุเขตเวลาจริง อุปกรณ์ต้องพิจารณาจากปัจจัยต่างๆ เช่น ประเทศ ออฟเซ็ต และออฟเซ็ต DST ก่อนที่จะตั้งค่ารหัสเขต

กระบวนการนี้อาจเป็นเรื่องท้าทาย การย้อนกลับตามข้อมูลที่มีอาจ ไม่ชัดเจน ตัวอย่างเช่น กฎเขตเวลาอเมริกา/เดนเวอร์จะใช้ DST แต่จะเปลี่ยนไปใช้เวลาออมแสงเมาน์เทน (MDT) ในช่วงฤดูร้อน ในขณะที่อเมริกา/ฟีนิกซ์จะยังคงใช้ MDT ต่อไป

วิทยุเซลลูลาร์

ข้อมูลระบบ (SI) เป็นส่วนสำคัญของอินเทอร์เฟซทางอากาศ Long-Term Evolution (LTE) ซึ่งสถานีฐาน (BS) จะส่งผ่านช่องควบคุมการออกอากาศ (BCCH) 3GPP TS 36.331 ระบุ SystemInformationBlockType16 (SIB16) ซึ่งมีข้อมูลที่เกี่ยวข้องกับ GPS และเวลาสากลเชิงพิกัด (UTC), ออฟเซ็ตเวลาท้องถิ่น รวมถึงข้อมูล DST

ฟังก์ชันการทำงานที่คล้ายกันนี้พบได้ใน 2G และ 3G ซึ่งสามารถออกอากาศข้อมูลระบุเครือข่ายและเขตเวลา (NITZ) (ดูรายละเอียดได้ที่ 3GPP TS 22.042) มาตรฐานวิทยุเครือข่ายมือถืออื่นๆ มี ฟีเจอร์ที่เทียบเท่ากัน

แต่ข้อเสียของมาตรฐานส่วนใหญ่คือการส่งข้อมูลนี้เป็นแบบ ไม่บังคับ จึงไม่ได้มีให้บริการในทุกเครือข่าย

ข้อดี ข้อเสีย
  • ให้ข้อมูลที่ต้องการส่วนใหญ่เมื่อมีข้อมูล
  • ความเรียบง่าย ซึ่ง Android รองรับอยู่แล้วเมื่อมีการเปิดเผยคลื่นวิทยุโทรศัพท์มือถือเป็นโทรศัพท์ ไม่ใช่แค่เป็นโมเด็มข้อมูล
  • ไม่ต้องมีการเชื่อมต่ออินเทอร์เน็ต
  • ไม่รับประกันว่าข้อมูลจะออกอากาศหรือสถานีฐานได้รับการกำหนดค่าอย่างถูกต้อง แล้ว

  • ในภูมิภาคชายแดน อุปกรณ์อาจจับสัญญาณเสาสัญญาณโทรศัพท์มือถือ (โรมมิ่ง) จากประเทศเพื่อนบ้าน และอาจแสดงเขตเวลาที่ไม่ถูกต้อง

  • ในบางพื้นที่ การอัปเดตอาจใช้เวลาหลายชั่วโมงหรือหลายวัน

โปรโตคอลเวลาเครือข่าย

มักใช้ Network Time Protocol (NTP) เพื่อรับข้อมูลเวลา Epoch ของ Unix ที่ค่อนข้างแม่นยำ Android รองรับการซิงค์เวลาของระบบกับเวลาของเซิร์ฟเวอร์ NTP หากสามารถแสดงต่อไคลเอ็นต์ของ RadioManager ผ่านข้อมูลเมตาRadioTuner.getParameters()ทั่วไป NTP จะอัปเดตเวลาของระบบเมื่อเวลาไม่ตรงกันและผู้ให้บริการไม่ได้อัปเดต NITZ เมื่อเร็วๆ นี้ หากผู้ใช้เปิดใช้ AUTO_TIME เมื่อ NITZ ไม่พร้อมใช้งาน ระบบจะตรวจสอบเวลาของเครือข่าย ทันที

ข้อดี ข้อเสีย

ความเรียบง่ายที่รองรับโดย Android

  • ไม่สมบูรณ์ NTP ให้ค่าที่จำเป็นเพียงค่าเดียว (เวลา) แม้ในกรณีที่ดีที่สุด NTP ก็ไม่สามารถระบุเขตเวลาได้

  • ต้องเชื่อมต่ออินเทอร์เน็ต

จูนเนอร์วิทยุกระจายเสียง

แม้ว่าการใช้ประโยชน์จากจูนเนอร์ในตัวเพื่อดึงข้อมูลเวลาและเขตเวลาจะเป็นเรื่องน่าสนใจ แต่ก็มีความท้าทายอยู่ มาตรฐานการออกอากาศทางวิทยุจำนวนมากกำหนดตัวเลือกสำหรับการแสดงข้อมูลที่ต้องการ โดยทั่วไปแล้ว จูนเนอร์วิทยุออกอากาศจะให้ข้อมูลเดียวกันกับวิทยุ เซลลูลาร์

ETSI EN 300 401 V1.4.1 (2006-06), section 8.1 ระบุฟีเจอร์ข้อมูลบริการ ที่ให้ข้อมูล เพิ่มเติมเกี่ยวกับบริการสำหรับทั้งรายการเสียงและข้อมูลสำหรับระบบการกระจายเสียงดิจิทัล (DAB) ส่วนที่ 8.1.3 ระบุรูปแบบสำหรับเวลาและวันที่ รวมถึง ข้อมูลสำหรับการชดเชยเวลาในประเทศและเวลาท้องถิ่น

ในทำนองเดียวกัน สำหรับระบบข้อมูลวิทยุ (RDS) ที่มักใช้ในจูนเนอร์ FM ส่วนที่ 3.1.5.6 ของมาตรฐาน EN 50067 จะกำหนดรูปแบบสำหรับเวลาและข้อมูล (ส่ง 1 ครั้งต่อนาที) นอกจากนี้ คุณยังดึงรหัสประเทศแบบขยาย (ECC) ได้ด้วย ซึ่งเป็นส่วนหนึ่งของการระบุรายการที่ออกอากาศ

HD Radio มีตัวเลือกที่เกี่ยวข้องเป็นส่วนหนึ่งของข้อกำหนดการออกแบบอินเทอร์เฟซทางอากาศของ HD Radio™ คำอธิบายการขนส่งบริการข้อมูลสถานีในข้อความพารามิเตอร์ของบริการข้อมูลสถานี (SIS) (MSG ID 0111) ส่วนที่ 5 ระบุคำเตือนอย่างชัดเจนซึ่ง ต้องคำนึงถึงเมื่อพยายามใช้การรองรับนาฬิกาของการออกอากาศ คำแนะนำเดียวกันนี้ใช้ได้กับระบบอื่นๆ ด้วย

... ข้อมูลเหล่านี้อธิบายถึงประเพณีท้องถิ่นในสถานที่ตั้งของผู้แพร่ภาพ ซึ่งอาจเหมือนหรือไม่เหมือนกับประเพณีท้องถิ่นในสถานที่ตั้งของผู้รับชม ผู้บริโภคที่อยู่ใกล้เขตแดนของเขตเวลา จะรับสถานีต่างๆ ที่ให้ข้อมูลที่แตกต่างกันได้ ดังนั้น เราจึงให้ข้อมูลเหล่านี้เป็นเพียงคำแนะนำเท่านั้น การตีความและการใช้ข้อมูลควรเป็นไปตามดุลยพินิจภายใต้การควบคุมของลูกค้า ..."

นอกจากนี้ สำหรับวิทยุ HD อย่างน้อย การออกอากาศข้อมูลนี้เป็นทางเลือกและไม่ควร ใช้ข้อมูลนี้แต่เพียงอย่างเดียว

ข้อดี ข้อเสีย
  • โดยปกติแล้วจะพร้อมให้บริการในมาตรฐานวิทยุออกอากาศระดับภูมิภาคต่างๆ
  • ไม่ต้องมีการเชื่อมต่ออินเทอร์เน็ต
  • Android ไม่รองรับการดำเนินการนี้โดยค่าเริ่มต้น
  • ต้องเปิดใช้จูนเนอร์ (อย่างน้อยเป็นครั้งคราวในเบื้องหลัง) เพื่อตรวจหาข้อมูลได้อย่างน่าเชื่อถือ
  • ความน่าเชื่อถือขึ้นอยู่กับผู้ออกอากาศ

เคล็ดลับการติดตั้งใช้งาน

Android รองรับการซิงค์เวลาของระบบกับเวลาของเซิร์ฟเวอร์ NTP หากสามารถแสดงต่อไคลเอ็นต์ของ RadioManager ได้ โซลูชันที่แนะนำคือการใช้ประโยชน์จากฟีเจอร์ส่วนขยายของผู้ให้บริการ การใช้งานฟังก์ชันนี้ต้องเกิดขึ้นใน Hardware Abstraction Layer (HAL) หลังจากนั้น จะแสดงต่อไคลเอ็นต์ของ RadioManager ผ่านเมธอด RadioTuner.getParameters() ทั่วไปได้

เพื่อให้โซลูชันยังคงมีประสิทธิภาพ ผู้ใช้ส่วนขยายของผู้ให้บริการรายนี้ต้องตรวจสอบว่า HAL รองรับฟีเจอร์นี้ (อย่าคิดว่ามีอยู่) ต้องจัดระเบียบสตริงพารามิเตอร์สำหรับการเรียก getParameters อย่างเป็นระเบียบเพื่อให้ผู้ให้บริการทุกรายใช้งานได้อย่างชัดเจน เช่น การใช้เนมสเปซขององค์กรโดยนำหน้าด้วยโดเมนที่เหมาะสม เช่น com.me.timezoneTuner.currenttimezone

เนื่องจากลักษณะของข้อมูลที่ขับเคลื่อนด้วยเหตุการณ์ การใช้RadioTuner.Callback.onParametersUpdated()การเรียกกลับเพื่อรับข้อมูลนี้จึงอาจเป็นประโยชน์ หากควรมีการกำหนดค่าสิ่งอำนวยความสะดวกนี้ ให้ออกแบบชุดกิจวัตรที่กำหนดเองบน setParameters เช่น

com.me.timezoneTuner.currenttimezoneEvent.enable

ระบบดาวเทียมนำทางทั่วโลก (GNSS) เพียงอย่างเดียวจะให้ข้อมูลเวลาและตำแหน่งที่ถูกต้องเท่านั้น

ตำแหน่งภูมิศาสตร์

วิธีแก้ปัญหาความไม่สะดวกนี้คือการดำเนินการ Geocoding แบบย้อนกลับ และกำหนดประเทศและ เขตเวลาโดยการค้นหาตามตำแหน่ง GNSS เป็นตัวเลือกที่ชัดเจน (และมีคุณภาพดีที่สุด) สำหรับ ข้อมูลตำแหน่งในยานพาหนะ Time Zone API ของ Google มีทุกสิ่งที่จำเป็นในการเรียกใช้การแปลงที่จำเป็น แน่นอนว่าคุณต้องเชื่อมต่ออินเทอร์เน็ต การรับประกันความเป็นส่วนตัวของผู้ใช้ต้องเป็นสิ่งสำคัญอันดับแรกเมื่อใช้โซลูชันออนไลน์ ต้องขอสิทธิ์จากผู้ใช้ในการยอมรับค่าใช้จ่ายในการใช้ข้อมูล (หรือไม่ยอมรับ)

การสร้างโซลูชันที่เหมาะสมสำหรับการใช้งานแบบออฟไลน์เป็นไปได้ ฐานข้อมูลแผนที่ท้องถิ่นที่มีความละเอียดเพียงพอที่จะระบุประเทศและเขตเวลาได้อย่างถูกต้องจะพอดีกับพื้นที่เก็บข้อมูลของยานพาหนะ เมื่อใช้กลยุทธ์ที่ใช้งานได้อย่างสมบูรณ์สำหรับการอัปเดตข้อมูลเขตเวลา (และประเทศ) ตามความจำเป็นแล้ว ผู้ใช้จะสามารถแปลงรหัสพิกัดภูมิศาสตร์ย้อนกลับของประเทศ/เขตเวลาตามตำแหน่ง GNSS ที่ได้รับจากระบบย่อยตำแหน่ง

ข้อดี ข้อเสีย
  • ระบุเขตเวลาที่ถูกต้องได้อย่างชัดเจน
  • ไม่ต้องเชื่อมต่ออินเทอร์เน็ต (ในกรณีของฐานข้อมูลในเครื่อง)
  • ทำงานได้อย่างน่าเชื่อถือในสถานการณ์การขับขี่ส่วนใหญ่
  • Android ไม่รองรับการดำเนินการนี้โดยค่าเริ่มต้น
  • หากยานพาหนะอยู่ในอาคาร/พื้นที่ที่มีหลังคาซึ่งรับสัญญาณดาวเทียม GNSS ได้ไม่ดี ในระหว่างการกำหนดค่าเริ่มต้น ระบบจะไม่สามารถรับข้อมูลเวลา สถานที่ และเขตเวลาที่ถูกต้องได้
  • ฐานข้อมูลในเครื่องต้องมีกลไกการอัปเดต
  • ความซับซ้อนของการนำไปใช้งาน

โทรศัพท์เชื่อมต่อผ่านบลูทูธ, Wi-Fi หรือ USB

คุณใช้เทคโนโลยีหลายอย่างเพื่อใช้ประโยชน์จากโทรศัพท์ของผู้ใช้ในการรับข้อมูลเวลาและเขตเวลาได้ สำหรับโทรศัพท์ทุกเครื่อง คุณต้องติดตั้งแอปที่กำหนดเองและแอปที่ใช้ร่วมกันในโทรศัพท์ และในระบบสาระบันเทิงในรถยนต์ (IVI) จากนั้นคุณจะซิงค์เวลาที่ ช่วงเวลาที่ต้องการได้ เช่น เมื่อสร้างการเชื่อมต่อและเมื่อโทรศัพท์ตรวจพบเขตเวลาใหม่

โทรศัพท์บางรุ่นที่รองรับบลูทูธพลังงานต่ำ (BLE) มีตัวเลือกในการดึงเวลาผ่านลักษณะเวลาปัจจุบันของ GATT และข้อกำหนดเฉพาะของโปรไฟล์บริการเวลาปัจจุบัน 1.1 อย่างไรก็ตาม ตัวเลือกนี้ ไม่ได้เจาะจงกลุ่มตลาดที่ใหญ่พอ ที่จะใช้เป็นแหล่งข้อมูลหลัก

ข้อดี ข้อเสีย
  • ไม่ต้องมีการเชื่อมต่ออินเทอร์เน็ต
  • โทรศัพท์จะส่งต่อการเปลี่ยนแปลงเขตเวลาที่ตรวจพบไปยังยูนิตหลักได้
  • Android ไม่รองรับการดำเนินการนี้โดยค่าเริ่มต้น
  • ใช้งานได้เฉพาะในขณะที่โทรศัพท์เชื่อมต่อกับยูนิตหลัก
  • เวลาจะดีหรือไม่ดีขึ้นอยู่กับสิ่งที่โทรศัพท์แสดง
  • การติดตั้งใช้งานมีความซับซ้อน
  • โทรศัพท์บางรุ่นไม่รองรับโปรไฟล์บริการเวลาปัจจุบันของ BLE GATT

ใช้แหล่งข้อมูล

ผู้ให้บริการอุปกรณ์ทุกรายต้องพิจารณาว่าควรตั้งเกณฑ์ไว้สูงเพียงใดและเส้นทางของผู้ใช้ใดที่ถือว่ามีความสำคัญมากที่สุด การทำความเข้าใจประสบการณ์ของผู้ใช้ที่สำคัญที่ต้องการอย่างชัดเจนเท่านั้นที่จะช่วยให้ตัดสินใจได้ดีที่สุด ในกรณีส่วนใหญ่ ผู้ให้บริการต้องพิจารณาข้อดีข้อเสียระหว่างความสะดวกกับ ความซับซ้อนในการติดตั้งใช้งาน

แต่ละตัวเลือกที่อธิบายไว้ข้างต้นมีทั้งข้อดีและข้อเสีย ตัวอย่างเช่น คุณต้องตัดสินใจเรื่องการออกแบบที่สำคัญ เกี่ยวกับระดับความยืดหยุ่นที่ยอมรับได้เมื่อเทียบกับการแสดงเวลาที่ไม่ดีเป็นครั้งคราว และวิธีจัดการข้อเสีย โซลูชันอัตโนมัติเต็มรูปแบบที่คาดว่าจะ ทํางานได้ดีในทุกสถานการณ์ แต่ต้องอิงตามการรวมแหล่งข้อมูลหลายแหล่ง ไม่มีตัวเลือกใดตัวเลือกหนึ่งที่ให้ความพร้อมใช้งานได้ 100%

ตัวเลือกการกำหนดค่าด้วยตนเองเป็นทางเลือกสำรองชั่วคราวที่ดำเนินการได้ง่าย และในทางปฏิบัติก็อาจเพียงพอสำหรับผู้ใช้หลายราย