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

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

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

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

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

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

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

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

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

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

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

กระบวนการนี้อาจเป็นเรื่องท้าทาย การย้อนกลับตามข้อมูลที่มีอยู่อาจไม่ชัดเจน ตัวอย่างเช่น กฎเขตเวลาอเมริกา/เดนเวอร์ใช้เขตเวลาออมแสง (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 รองรับอยู่แล้วเมื่อใช้วิทยุมือถือเป็นโทรศัพท์ ไม่ใช่แค่โมเด็มอินเทอร์เน็ต
  • ไม่ต้องใช้การเชื่อมต่ออินเทอร์เน็ต
  • ไม่มีการรับประกันว่ามีการออกอากาศข้อมูลหรือสถานีฐานได้รับการกำหนดค่าอย่างถูกต้อง

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

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

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

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

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

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

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

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

เครื่องรับสัญญาณวิทยุกระจายเสียง

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

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

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

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

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

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

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

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

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

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

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

com.me.timezoneTuner.currenttimezoneEvent.enable

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

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

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

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

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

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

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

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

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

ใช้แหล่งที่มา

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

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

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