خيارات المنطقة الزمنية

إنّ عرض الوقت بدقة هو ميزة أساسية من المفترض أن يقدّمها نظام الترفيه والمعلومات في السيارة. قد يبدو ذلك بسيطًا بشكل مخادع، خاصةً عندما تكون توقعات إدارة وقت المنطقة الزمنية منخفضة ويجب استيفاؤها، ولكن سرعان ما يصبح الوقت معقّدًا عندما يجب عرض تاريخ ووقت دقيقَين بشكل موثوق بدون تدخل يدوي.

تحتوي جميع الساعات التي تعمل في الوقت الفعلي والتي يتم استخدامها عادةً في نظام على الرقاقة (SoC) على بعض الانحراف الذي يتراكم بمرور الوقت ويمكن أن يؤدي إلى خطأ كبير في حال عدم تصحيحه. بالإضافة إلى ذلك، بما أنّ المستخدمين يتوقعون أن يتم عرض التوقيت المحلي بدقة، يجب مراعاة الاختلاف الصحيح عن التوقيت العالمي المنسق (UTC).

من المتوقّع أن تتغيّر معلومات المنطقة الزمنية، بالإضافة إلى تطبيق التوقيت الصيفي (DST)، خلال فترة الاستخدام المتوقّعة للمركبة. على سبيل المثال، بعد عدة سنوات من تطبيق التوقيت الصيفي، اختارت البرازيل عدم بدء جدول زمني للتوقيت الصيفي في عام 2019.

يقدّم Android البنية الأساسية اللازمة للتعامل مع التعقيدات المتعلّقة بإدارة قواعد المنطقة الزمنية. لمعرفة التفاصيل، يُرجى الاطّلاع على قواعد المنطقة الزمنية التي تتيح لمصنّعي المعدّات الأصلية إرسال بيانات قواعد المنطقة الزمنية المعدَّلة إلى الأجهزة بدون الحاجة إلى تحديث النظام. تتيح هذه الآلية ما يلي:

  • حصول المستخدمين على تحديثات في الوقت المناسب (ما يؤدي إلى إطالة مدة استخدام جهاز Android)
  • على المصنّعين الأصليّين للأجهزة اختبار تعديلات المنطقة الزمنية بشكل مستقل عن تعديلات صور النظام.

ملاحظة: لا يتوافق الإصدار 10 من AAOS مع آلية تحديث الوحدات المستندة إلى APEX المقدَّمة في إصدارات Android 10 (والإصدارات الأحدث).

ملاحظة: لتنفيذ هذه الآلية، يجب إعادة تشغيل النظام.

مصادر معلومات الوقت (المنطقة الزمنية) في السيارات

تدير أجهزة Android الوقت بتنسيق Unix على مستوى النظام، وتطبّق القيمة المطلوبة للمنطقة الزمنية، ثم تحوّل القيمة إلى التوقيت المحلي لعرضها للمستخدمين. يتم تخزين رقم تعريف المنطقة للمستخدم الحالي (الذي يُشار إليه غالبًا باسم رقم تعريف Olson) كإعداد. على سبيل المثال، أوروبا/القاهرة.

توضّح الكثير من الآلية الموضّحة أدناه معلومات الوقت. الغرض من هذه المعايير هو تزويد المستخدمين بالوقت الحالي، وليس وصف قواعد المنطقة الزمنية السارية. لتحديد المنطقة الزمنية الفعلية، يجب أن يعمل الجهاز على التراجع من عوامل مثل البلد والفرق الزمني وفرق التوقيت الصيفي قبل ضبط رقم تعريف المنطقة.

قد تكون هذه العملية صعبة. قد يكون تحديد وقت حدوث المشكلة بالرجوع إلى المعلومات المتاحة غير واضح. على سبيل المثال، تلتزم منطقة أمريكا/دنفر بالتوقيت الصيفي، ولكنها تتّبع توقيت ‎Mountain Daylight Time (MDT) خلال فصل الصيف، في حين تستمر منطقة أمريكا/فينيكس في استخدام توقيت MDT.

راديو الجوال

معلومات النظام (SI) هي جانب أساسي من واجهة الهواء لتقنية الجيل الرابع (LTE)، التي تنقلّها المحطة الأساسية (BS) عبر قناة التحكّم في البث (BCCH). يحدّد معيار 3GPP TS 36.331 نوع 16 من مجموعات المعلومات النظامية (SIB16) الذي يحتوي على معلومات ذات صلة بنظام تحديد المواقع العالمي (GPS) والتوقيت العالمي المنسق (UTC) ووقت الاختلاف المحلي ومعلومات التوقيت الصيفي.

يمكن العثور على وظائف مشابهة في شبكات الجيل الثاني والجيل الثالث، حيث يمكن بث معلومات هوية الشبكة والمنطقة الزمنية (NITZ) (راجِع 3GPP TS 22.042 للاطّلاع على التفاصيل). تتضمّن معايير الراديو الخلوي الأخرى ميزات مماثلة.

إنّ القاسم المشترك بين معظم المعايير هو أنّ إرسال هذه المعلومات هو اختياري، لذا لا يتوفّر بشكل عام على جميع الشبكات.

الإيجابيات السلبيات
  • يوفّر معظم المعلومات المطلوبة، متى توفّرت.
  • البساطة، وهي ميزة تتوفّر حاليًا في Android عندما يتم عرض الراديو الخلوي كسمة هاتف، وليس فقط كمودم بيانات
  • لا تتطلّب اتصالاً بالإنترنت
  • لا يمكن ضمان بث المعلومات أو ضبط المحطة الأساسية بشكلٍ صحيح.

  • في المناطق الحدودية، قد يتم الاتصال ببرج خلوي (رحالة) في بلد مجاور، ما قد يؤدي إلى عرض المنطقة الزمنية غير الصحيحة.

  • في بعض المواقع الجغرافية، قد تستغرق التعديلات ساعات أو حتى أيامًا لكي تظهر.

بروتوكول وقت الشبكة

غالبًا ما يُستخدَم بروتوكول وقت الشبكة (NTP) للحصول على معلومات دقيقة نسبيًا عن وقت بداية حقبة يونكس. يتيح نظام التشغيل Android مزامنة وقت النظام مع وقت خادم NTP إذا كان يمكن عرضه لعملاء RadioManager من خلال البيانات الوصفية العامة RadioTuner.getParameters(). يعدّل بروتوكول NTP وقت النظام عندما ينقطع اتّصاله بأحد مزوّدي الخدمة ولم يقدّم مزوّد الخدمة تحديثًا لبروتوكول NITZ مؤخرًا. إذا فعّل المستخدم AUTO_TIME عندما لا يكون NITZ متاحًا، يتحقّق النظام على الفور من وقت الشبكة.

الإيجابيات السلبيات

بساطة متوافقة مع Android

  • غير مكتمل، يقدّم بروتوكول NTP قيمة واحدة مطلوبة فقط (الوقت). حتى في أفضل السيناريوهات، لا يمكن لبروتوكول NTP توفير المنطقة الزمنية.

  • يتطلب الاتصال بالإنترنت.

أداة ضبط البث الإذاعي

على الرغم من أنّ استخدام مُعدّل تردد داخلي لاسترداد معلومات الوقت والمنطقة الزمنية أمر جذاب، فإنه يتضمن تحديات. هناك العديد من معايير البث الإذاعي التي تحدّد خيارات عرض المعلومات المطلوبة. بشكل عام، يقدّم مُعدِّل بثّ الإذاعة المعلومات نفسها التي يوفّرها جهاز الإذاعة الخلوية.

تحدِّد ETSI EN 300 401 V1.4.1 (06-2006)، القسم 8.1 ميزات معلومات الخدمة التي تقدِّم معلومات إضافية عن خدمات كلّ من البرامج الصوتية والبيانات لأنظمة البث الرقمي للصوت (DAB). يحدِّد القسم 8.1.3 تنسيق الوقت والتاريخ بالإضافة إلى معلومات عن البلد ووقت الاختلاف المحلي.

وبالمثل، بالنسبة إلى نظام Radio Data System (RDS) الذي يتم تنفيذه عادةً في أجهزة ضبط FM، يحدِّد القسم 3.1.5.6 من معيار EN 50067 تنسيق الوقت على مدار الساعة والبيانات (يتم إرسالها مرة واحدة في الدقيقة). بالإضافة إلى ذلك، يمكن أيضًا استرجاع رمز البلد الموسّع (ECC) كجزء من معرّف البرنامج المُرسَل.

يحتوي HD Radio على خيارات مقابلة كجزء من مواصفات HD Radio™ Air Interface Design Description Station Information Service Transport في رسالة مَعلمات خدمة معلومات المحطة (SIS) (معرّف الرسالة 0111). يوضّح القسم 5 بوضوح الكلمات التحذيرية التي يجب مراعاتها عند محاولة استخدام ميزة الساعة في البث. تنطبق هذه النصيحة بالتساوي على الأنظمة الأخرى:

... تصف هذه البيانات العرف المحلي في موقع المُشغِّل، وقد يختلف عن العرف المحلي في موقع المُستلِم. بالقرب من حدود المناطق الزمنية، يمكن للمستهلكين تلقّي العديد من المحطات التي تقدّم بيانات مختلفة. وبالتالي، لا يتم تقديم هذه البيانات إلا كإشارات، ويجب تفسيرها واستخدامها بشكل اختياري، ويخضع ذلك للتحكّم من قِبل العميل. ‎..."

بالإضافة إلى ذلك، بالنسبة إلى "الراديو عالي الدقة" على الأقل، يكون بث هذه المعلومات اختياريًا ولا ينبغي الاعتماد عليه بشكل حصري.

الإيجابيات السلبيات
  • تتوفّر هذه الميزة عادةً وفقًا لمعايير مختلفة لبث الإذاعة الإقليمية.
  • لا تتطلّب اتصالاً بالإنترنت
  • لا يتيح نظام التشغيل Android هذه الميزة تلقائيًا.
  • يتطلب تفعيل المُعدِّل (في الخلفية من حين لآخر على الأقل) لرصد المعلومات بشكل موثوق.
  • تعتمد الموثوقية على المشغّل.

نصائح حول التنفيذ

يتيح نظام التشغيل Android مزامنة وقت النظام مع وقت خادم NTP إذا كان يمكن عرضه لعملاء RadioManager. الحلّ المقترَح هو الاستفادة من ميزة إضافة المورّد. يجب تنفيذ هذه الوظيفة في طبقة تجريد الأجهزة (HAL)، وبعد ذلك يمكن عرض if على عملاء RadioManager من خلال الأسلوب العام RadioTuner.getParameters().

لكي يظل الحلّ قويًا، على مستخدِم إضافة المورّد هذه التأكّد من أنّ ملف HAL يدعم الميزة (ولا تفترض وجوده). يجب أن تكون سلاسل المَعلمات لاستدعاء getParameters منظَّمة بوضوح لاستخدامها بشكل لا لبس فيه لدى جميع المورّدين. على سبيل المثال، استخدام مساحة اسم مؤسستك من خلال الإضافة إليها النطاق المناسب، على سبيل المثال، com.me.timezoneTuner.currenttimezone.

نظرًا لطبيعة المعلومات المستندة إلى الأحداث، قد يكون من المفيد استخدام أسلوب callback‏ RadioTuner.Callback.onParametersUpdated() لتلقّي هذه المعلومات. إذا كان ينبغي أن تكون هذه الميزة قابلة للضبط، يمكنك تصميم مجموعة من الإجراءات المخصّصة بالإضافة إلى setParameters. مثلاً:

com.me.timezoneTuner.currenttimezoneEvent.enable

لا يمكن لنظام تحديد المواقع العالمي عبر الأقمار الصناعية (GNSS) بمفرده تقديم سوى معلومات ودقيقة عن الوقت والموقع الجغرافي.

الموقع الجغرافي

لحلّ هذه المشكلة، يمكنك تنفيذ عملية ترميز جغرافي عكسي وتحديد البلد والمناطق الزمنية من خلال البحث استنادًا إلى الموقع الجغرافي. إنّ نظام تحديد المواقع العالمي (GNSS) هو الخيار الواضح (والأفضل جودة) للحصول على معلومات الموقع الجغرافي في المركبة. تقدّم واجهة برمجة التطبيقات Time Zone API من Google كل ما هو مطلوب لتنفيذ الإحالة الناجحة المطلوبة. يجب بالطبع أن يكون جهازك متصلاً بالإنترنت. يجب أن يكون ضمان خصوصية المستخدمين من أهم الأولويات عند تنفيذ أي حلّ على الإنترنت. يجب الحصول على إذن من المستخدم لقبول تكاليف استخدام البيانات (أو عدم قبولها).

من الممكن إنشاء حل مناسب للاستخدام بلا إنترنت. يمكن أن تتضمّن قاعدة بيانات الخرائط المحلية دقة كافية لتحديد البلد والمنطقة الزمنية بدقة، ويمكن تخزينها في ذاكرة السيارة. باستخدام هذا الإجراء واستراتيجية تم تنفيذها بالكامل لتعديل معلومات المنطقة الزمنية (والدولة) حسب الحاجة، يمكن فك ترميز الموقع الجغرافي للبلد أو المنطقة الزمنية استنادًا إلى موضع GNSS الذي تم الحصول عليه من النظام الفرعي للموقع الجغرافي.

الإيجابيات السلبيات
  • يمكنه تحديد المنطقة الزمنية الصحيحة بشكل لا لبس فيه.
  • لا تتطلّب اتصالاً بالإنترنت (في حال استخدام قاعدة بيانات محلية).
  • تعمل بشكل موثوق به في معظم سيناريوهات القيادة.
  • لا يتيح نظام التشغيل Android هذه الميزة تلقائيًا.
  • إذا كانت المركبة في مكان مغلق أو منطقة مسقوفة يتعذّر فيها استقبال إشارات الأقمار الصناعية لنظام تحديد المواقع العالمي (GNSS) بشكل جيد أثناء الضبط الأولي، سيكون من المستحيل الحصول على معلومات دقيقة عن الوقت والموقع الجغرافي والمنطقة الزمنية.
  • تحتاج قاعدة البيانات المحلية إلى آلية تعديل.
  • تعقيد التنفيذ

الهاتف متصل عبر البلوتوث أو Wi-Fi أو USB

يمكن استخدام عدة تقنيات للاستفادة من هاتف المستخدم للحصول على بيانات الوقت والمنطقة الزمنية. في جميع الهواتف، يجب تثبيت تطبيق مخصّص وتطبيق مصاحب على الهاتف وعلى نظام الترفيه والمعلومات داخل السيارة (IVI). بعد ذلك، يمكن مزامنة الوقت في الفاصل الزمني المطلوب. على سبيل المثال، عند إنشاء الاتصال وعند رصد الهاتف لمنطقة زمنية جديدة

توفّر بعض الهواتف التي تتوافق مع تقنية البلوتوث المنخفض الطاقة (BLE) خيار استرداد الوقت من خلال سمة "الوقت الحالي" في بروتوكول GATT ومواصفات الملف الشخصي لخدمة "الوقت الحالي" 1.1. ومع ذلك، لا يخاطب هذا الخيار شريحة سوق كبيرة بما يكفي للاعتماد عليها بشكل حصري.

الإيجابيات السلبيات
  • لا تتطلّب اتصالاً بالإنترنت
  • يمكن إرسال التغييرات في المنطقة الزمنية التي يرصدها الهاتف إلى وحدة التحكّم الرئيسية.
  • لا يتيح نظام التشغيل Android هذه الميزة تلقائيًا.
  • لا تعمل هذه الميزة إلا عندما يكون الهاتف متصلاً بوحدة التحكّم.
  • الوقت جيد أو سيئ حسب ما يقدّمه الهاتف.
  • عملية التنفيذ معقّدة.
  • لا تتوافق بعض الهواتف مع الملف الشخصي لبروتوكول BLE GATT Current Time Service.

استخدام المصادر

على كل مورّد أجهزة تحديد مستوى الأداء المطلوب وتجارب المستخدمين التي يراها الأكثر أهمية. لا يمكن اتخاذ أفضل قرار إلا من خلال فهم واضح لتجارب المستخدمين المهمة المطلوبة. في معظم الحالات، على المورّدين مراعاة المفاضلة بين السهولة وصعوبة التنفيذ.

لكل خيار من الخيارات الموضّحة أعلاه مزاياه وعيوبه. على سبيل المثال، يجب اتخاذ قرار مهم بشأن التصميم بخصوص مقدار المرونة المقبولة مقارنةً بعرض الوقت السيئ من حين لآخر، وكيفية إدارة الجوانب السلبية. حلّ تلقائي بالكامل يمكن توقّع أن يعمل بشكل جيد في جميع السيناريوهات، ولكن يجب أن يستند إلى مجموعة من مصادر المعلومات. لا يمكن لأي خيار واحد توفير مدى توفّر بنسبة% 100.

من السهل تنفيذ خيار الضبط اليدوي كخيار احتياطي مؤقت، ويمكن أن يكون يفي بالغرض في الواقع للعديد من المستخدمين.