نمایش دقیق زمان یکی از ویژگی های اصلی مورد انتظار از سیستم اطلاعات سرگرمی خودرو است. در حالی که این ممکن است به طرز فریبنده ای ساده به نظر برسد، به ویژه زمانی که انتظارات مدیریت زمان و منطقه زمانی کم است و باید برآورده شود، زمانی که تاریخ و زمان دقیق و قابل اعتمادی باید بدون دخالت دستی نمایش داده شود، زمان به سرعت پیچیده می شود.
تمام ساعتهای بلادرنگ که معمولاً در سیستم روی تراشه (SoC) استفاده میشوند حاوی مقداری دریفت هستند که در طول زمان جمع میشود و در صورت عدم تصحیح میتواند منجر به خطای قابلتوجهی شود. علاوه بر این، به دلیل اینکه انتظارات برای نمایش دقیق زمان محلی زیاد است، باید افست صحیح از زمان هماهنگ جهانی (UTC) در نظر گرفته شود.
می توان انتظار داشت که اطلاعات منطقه زمانی و همچنین استفاده از ساعت تابستانی (DST) در طول عمر مورد انتظار یک وسیله نقلیه تغییر کند. برای مثال، پس از سالها اجرای DST، برزیل تصمیم گرفت برنامه DST را در سال 2019 شروع نکند.
اندروید زیرساخت مورد نیاز برای مذاکره در مورد عوارض مدیریت قوانین منطقه زمانی را فراهم می کند. برای جزئیات، به قوانین منطقه زمانی مراجعه کنید، که OEM ها را قادر می سازد تا داده های به روز شده قوانین منطقه زمانی را بدون نیاز به به روز رسانی سیستم به دستگاه ها منتقل کنند. این مکانیسم امکان:
- کاربران برای دریافت بهروزرسانیهای به موقع (که طول عمر مفید دستگاه اندرویدی را افزایش میدهد).
- OEM ها برای آزمایش به روز رسانی منطقه زمانی مستقل از به روز رسانی تصویر سیستم.
توجه: AAOS 10 از مکانیزم بهروزرسانی ماژول مبتنی بر APEX که در نسخههای Android 10 (و بالاتر) ارائه شده است، پشتیبانی نمیکند.
توجه: برای پیاده سازی این مکانیسم، راه اندازی مجدد سیستم مورد نیاز است.
منابع اطلاعاتی زمان (منطقه) در خودروها
دستگاه های اندرویدی زمان را در زمان یونیکس در سطح سیستم مدیریت می کنند، افست منطقه زمانی مورد نظر را اعمال می کنند و سپس مقدار را به زمان محلی برای نمایش به کاربران تبدیل می کنند. شناسه منطقه کاربر فعلی (اغلب با نام 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 مراجعه کنید). سایر استانداردهای رادیویی سلولی دارای ویژگی های مشابه هستند.
متأسفانه، وجه اشتراک بیشتر استانداردها این است که ارسال این اطلاعات اختیاری است، بنابراین در همه شبکه ها در دسترس نیست.
جوانب مثبت | منفی |
---|---|
|
|
پروتکل زمان شبکه
پروتکل زمان شبکه (NTP) اغلب برای به دست آوردن اطلاعات نسبتاً دقیق زمان یونیکس استفاده می شود. اگر بتواند از طریق فراداده عمومی RadioTuner.getParameters()
در معرض دید مشتریان RadioManager
قرار گیرد، اندروید از همگام سازی زمان سیستم خود با سرور NTP پشتیبانی می کند. NTP زمان سیستم را زمانی بهروزرسانی میکند که از همگامسازی خارج شود و شرکت مخابراتی اخیراً بهروزرسانی NITZ را ارائه نکرده است. اگر زمانی که NITZ در دسترس نیست، کاربر AUTO_TIME
فعال کند، سیستم فوراً زمان شبکه را بررسی میکند.
جوانب مثبت | منفی |
---|---|
Simplicity، توسط اندروید پشتیبانی می شود. |
|
تیونر رادیویی پخش
در حالی که استفاده از تیونر داخلی برای بازیابی اطلاعات زمان و منطقه زمانی جذاب است، چالش هایی نیز در این امر دخیل هستند. استانداردهای متعدد پخش رادیویی گزینه هایی را برای افشای اطلاعات مورد نظر تعریف می کنند. به طور کلی، یک تیونر رادیویی پخش همان اطلاعات رادیوی سلولی را ارائه می دهد.
ETSI EN 300 401 V1.4.1 (2006-06)، بخش 8.1 ویژگی های اطلاعات سرویس را مشخص می کند که اطلاعات تکمیلی را در مورد سرویس ها برای برنامه های صوتی و داده ها برای سیستم های پخش صوتی دیجیتال (DAB) ارائه می دهد. بخش 8.1.3 فرمت زمان و تاریخ و همچنین اطلاعات مربوط به زمان محلی و کشور را تعیین می کند.
به طور مشابه، برای سیستم دادههای رادیویی (RDS) که معمولاً در تیونرهای FM اجرا میشود، بخش 3.1.5.6 استاندارد EN 50067 فرمت ساعت و داده را تعریف میکند (یک بار در دقیقه ارسال میشود). علاوه بر این، کد کشور توسعه یافته (ECC) نیز می تواند به عنوان بخشی از شناسایی برنامه ارسال شده بازیابی شود.
رادیو HD شامل گزینههای مربوطه بهعنوان بخشی از طراحی رابط هوایی HD Radio™ است. شرح مشخصات حمل و نقل سرویس اطلاعات ایستگاه در پیام پارامتر سرویس اطلاعات ایستگاه (SIS) (MSG ID 0111). بخش 5 به وضوح کلمات احتیاطی را بیان می کند که هنگام تلاش برای استفاده از پشتیبانی ساعتی پخش باید به آنها توجه شود. همین حکمت در مورد سایر سیستم ها نیز صدق می کند:
... این داده ها عرف محلی را در محل پخش کننده توصیف می کنند، که ممکن است با عرف محلی در محل گیرنده یکسان باشد یا نباشد. نزدیک به مرزهای منطقه زمانی، مصرف کنندگان می توانند ایستگاه های متعددی را دریافت کنند که داده های متفاوتی را ارائه می دهند. بنابراین، این دادهها تنها بهعنوان نکاتی ارائه میشوند که تفسیر و استفاده از آنها باید اختیاری و مشروط به کنترل مشتری باشد. ..." |
علاوه بر این، حداقل برای رادیو HD، پخش این اطلاعات اختیاری است و نباید به طور انحصاری به آن اعتماد کرد.
- معمولاً در استانداردهای مختلف رادیویی پخش منطقه ای موجود است.
- نیازی به اتصال به اینترنت ندارد .
- Android از این خارج از جعبه پشتیبانی نمی کند.
- برای شناسایی مطمئن اطلاعات، نیاز به روشن شدن تیونر (حداقل گاهی اوقات در پسزمینه) دارد.
قابلیت اطمینان بستگی به پخش کننده دارد.
نکات اجرایی
Android از همگام سازی زمان سیستم خود با سرور NTP پشتیبانی می کند، اگر بتوان آن را در معرض مشتریانRadioManager
قرار داد. راه حل پیشنهادی استفاده از ویژگی افزونه فروشنده است. پیاده سازی این قابلیت باید در لایه انتزاعی سخت افزاری (HAL) اتفاق بیفتد، پس از آن اگر می توان از طریق روش عمومی RadioTuner.getParameters()
در معرض مشتریان RadioManager
قرار گرفت. برای اینکه راه حل قوی باقی بماند، مصرف کننده این افزونه فروشنده باید تعیین کند که HAL از این ویژگی پشتیبانی می کند (وجود آن را فرض نکنید). رشته های پارامتر برای فراخوانی getParameters
باید برای استفاده بدون ابهام در بین فروشندگان به طور تمیز سازماندهی شوند. به عنوان مثال، با استفاده از فضای نام سازمان خود با پیشوند آن با دامنه مناسب، به عنوان مثال، com.me.timezoneTuner.currenttimezone
.
با توجه به ماهیت رویداد محور اطلاعات، استفاده از callback RadioTuner.Callback.onParametersUpdated()
برای دریافت این اطلاعات می تواند مفید باشد. اگر این تسهیلات باید قابل تنظیم باشد، مجموعهای از روالهای سفارشی را در بالای setParameters
طراحی کنید. به عنوان مثال:
com.me.timezoneTuner.currenttimezoneEvent.enable
سیستم جهانی ناوبری ماهواره ای
سیستم جهانی ناوبری ماهواره ای (GNSS) به تنهایی می تواند اطلاعات دقیق زمانی و موقعیت را ارائه دهد.
موقعیت جغرافیایی
راه حل این ناراحتی، اجرای معکوس جغرافیایی و تعیین کشور و منطقه زمانی با انجام جستجو بر اساس موقعیت است. GNSS انتخاب واضح (و بهترین کیفیت) اطلاعات مکان در یک وسیله نقلیه است. Google's Time Zone API تمام آنچه برای اجرای تبدیل مورد نیاز است را ارائه می دهد. البته اتصال به اینترنت الزامی است. هنگام اجرای یک راه حل آنلاین، اطمینان از حریم خصوصی کاربر باید در اولویت قرار گیرد! اجازه کاربر برای پذیرش هزینه های استفاده از داده (یا نه) مورد نیاز است و باید درخواست شود.
ایجاد یک راه حل مناسب برای استفاده آفلاین امکان پذیر است. یک پایگاه داده نقشه محلی با وضوح کافی برای تعیین دقیق کشور و منطقه زمانی می تواند در فضای ذخیره سازی وسیله نقلیه قرار گیرد. با این و یک استراتژی کاملاً پیادهسازی شده برای بهروزرسانی اطلاعات منطقه زمانی (و کشور) در صورت نیاز، میتوان کشور/منطقه زمانی را بر اساس موقعیت GNSS بهدستآمده از زیرسیستم موقعیت جغرافیایی معکوس کرد.
جوانب مثبت | منفی |
---|---|
|
|
تلفن از طریق بلوتوث، Wi-Fi یا USB متصل می شود
چندین فناوری را می توان برای استفاده از تلفن کاربر برای به دست آوردن اطلاعات منطقه زمانی و زمانی استفاده کرد. برای همه تلفنها، یک جفت برنامه سفارشی و برنامه همراه باید روی تلفن و سیستم In-Vehicle Infotainment (IVI) نصب شود. سپس امکان همگام سازی زمان در بازه زمانی مورد نظر وجود دارد. به عنوان مثال، پس از برقراری اتصال و هنگامی که تلفن در منطقه زمانی جدید را شناسایی می کند.
برخی از تلفنهایی که از بلوتوث کم مصرف (BLE) پشتیبانی میکنند، امکان بازیابی زمان را از طریق مشخصه زمان فعلی GATT و مشخصات نمایه خدمات زمان فعلی 1.1 فراهم میکنند. با این حال، این گزینه به بخش بازار به اندازه کافی بزرگ که به طور انحصاری بر آن تکیه شود، نمی پردازد.
جوانب مثبت | منفی |
---|---|
|
|
از منابع استفاده کنید
هر فروشنده دستگاه باید تعیین کند که چه مقدار میله را تعیین کند و کدام سفر کاربر را حیاتیتر بداند. تنها با درک روشن از تجربیات حیاتی مورد نظر کاربر می توان بهترین تصمیم را گرفت. در بیشتر موارد، فروشندگان باید معاوضه بین راحتی و پیچیدگی اجرا را در نظر بگیرند.
هر گزینه ای که در بالا توضیح داده شد دارای مزایا و معایبی است. به عنوان مثال، یک انتخاب طراحی حیاتی باید با توجه به اینکه چقدر انعطاف پذیری در مقایسه با نمایش زمان ضعیف گاه به گاه، قابل قبول است و چگونه می توان جنبه های منفی را مدیریت کرد، انجام شود. یک راه حل کاملا خودکار که می توان انتظار داشت در همه سناریوها به خوبی عمل کند، باید بر اساس ترکیبی از چندین منبع اطلاعاتی باشد. هیچ گزینه واحدی نمی تواند 100٪ در دسترس بودن را فراهم کند.
یک گزینه پیکربندی دستی به عنوان یک بازگشت موقت به راحتی اجرا می شود و در عمل می تواند برای بسیاری از کاربران کافی باشد.