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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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