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

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

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

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

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

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

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

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

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

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

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

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

راديو الجوال

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

يمكن العثور على وظائف مشابهة في شبكات الجيل الثاني والثالث، حيث يمكن بث معلومات هوية الشبكة والمنطقة الزمنية (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 تنسيق الوقت والبيانات (يتم إرسالها مرة واحدة في الدقيقة). بالإضافة إلى ذلك، يمكن أيضًا استرداد رمز البلد الموسّع (ECC) كجزء من تعريف البرنامج المرسَل.

يتضمّن نظام HD Radio خيارات مماثلة كجزء من مواصفات تصميم واجهة البث المباشر لنظام HD Radio™‎ وخدمة نقل معلومات المحطة في رسالة مَعلمات خدمة معلومات المحطة (SIS) (معرّف الرسالة 0111). توضّح الفقرة 5 بوضوح الكلمات التحذيرية التي يجب الانتباه إليها عند محاولة استخدام ميزة التزامن مع البث. وينطبق المبدأ نفسه على الأنظمة الأخرى:

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

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

الإيجابيات السلبيات
  • تتوفّر عادةً في مختلف معايير الراديو الإقليمية للبث.
  • لا يتطلّب اتصالاً بالإنترنت.
  • لا يتيح نظام التشغيل 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 كل ما يلزم لتنفيذ عملية التحويل المطلوبة. بالطبع، يجب توفّر اتصال بالإنترنت. يجب أن تكون ضمان خصوصية المستخدمين من أهم الأولويات عند تنفيذ حلّ على الإنترنت. يجب الحصول على إذن المستخدم لقبول تكاليف استخدام البيانات (أو عدم قبولها) ويجب طلب هذا الإذن.

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

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

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

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

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

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

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

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

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

إنّ خيار الإعداد اليدوي كحلّ احتياطي مؤقت سهل التنفيذ، ويمكن أن يكون عمليًا وكافيًا للعديد من المستخدمين.