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

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

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

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

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

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

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

หมายเหตุ: หากต้องการใช้กลไกนี้ จำเป็นต้องรีบูตระบบ

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

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

กลไกส่วนใหญ่ที่อธิบายไว้ด้านล่างนี้อธิบายข้อมูลเวลา จุดประสงค์ของมาตรฐานเหล่านี้คือเพื่อให้ผู้ใช้ทราบเวลาปัจจุบัน ไม่ใช่เพื่ออธิบายกฎเขตเวลาที่เกี่ยวข้อง หากต้องการระบุเขตเวลาจริง อุปกรณ์จะต้องทำงานกลับจากปัจจัยต่างๆ เช่น ประเทศ ออฟเซ็ต และออฟเซ็ต 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) มักใช้เพื่อรับข้อมูลเวลา 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 ระบุคุณลักษณะข้อมูลบริการที่ให้ข้อมูลเพิ่มเติมเกี่ยวกับบริการสำหรับทั้งโปรแกรมเสียงและข้อมูลสำหรับระบบ Digital Audio Broadcasting (DAB) ส่วนที่ 8.1.3 กำหนดรูปแบบสำหรับเวลาและวันที่ตลอดจนข้อมูลสำหรับการชดเชยเวลาของประเทศและเวลาท้องถิ่น

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

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

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

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

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

• โดยทั่วไปจะมีให้บริการในมาตรฐานวิทยุกระจายเสียงระดับภูมิภาคต่างๆ
• ไม่ จำเป็นต้องเชื่อมต่ออินเทอร์เน็ต

• 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) สามารถให้ข้อมูลเวลาและตำแหน่งที่แม่นยำเท่านั้น

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

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

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

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

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

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

โทรศัพท์บางรุ่นที่รองรับ Bluetooth Low Energy (BLE) มีตัวเลือกในการดึงข้อมูลเวลาผ่าน คุณลักษณะ GATT Current Time และ Current Time Service Profile Specification 1.1 อย่างไรก็ตาม ตัวเลือกนี้ไม่ได้ระบุถึงกลุ่มตลาดที่ใหญ่พอที่จะพึ่งพาได้แต่เพียงผู้เดียว

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

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

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

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

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