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

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

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

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

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

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

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

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

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

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

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

กระบวนการนี้อาจเป็นเรื่องท้าทาย การพิจารณาย้อนกลับตามข้อมูลที่มีอยู่อาจไม่ชัดเจน ตัวอย่างเช่น กฎเขตเวลา America/Denver ใช้ DST แต่ปรับเป็นเวลาออมแสง Mountain (MDT) ในช่วงฤดูร้อน ในขณะที่ America/Phoenix ยังคงใช้ 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 epoch ที่ค่อนข้างแม่นยำ 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™ ในข้อความพารามิเตอร์บริการข้อมูลสถานี (SIS) (รหัสข้อความ 0111) ส่วนที่ 5 ระบุคำเตือนอย่างชัดเจนที่ต้องปฏิบัติตามเมื่อพยายามใช้การรองรับนาฬิกาของการออกอากาศ คำแนะนำเดียวกันนี้ใช้ได้กับระบบอื่นๆ ด้วย

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

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

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

เคล็ดลับการนำไปใช้

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

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

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

com.me.timezoneTuner.currenttimezoneEvent.enable

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

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

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

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

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

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

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

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

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

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

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

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

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