دليل دمج "السمات المحدودة" الأساسية

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

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

تصميم

الشكل 1: بنية SDV الأساسية

‫Android Automotive OS for SDV Core (SDV Core) هو نظام تشغيل يستند إلى Android. وبسبب طبيعتها المضمّنة، لا تستخدم هذه الميزة حزمة JVM في Android، بل يتم تطوير جميع وظائف النظام بشكل أصلي.

تم تطوير SDV Core في المقام الأول لبيئة محاكاة افتراضية، وتفترض بعض قرارات التصميم هذا الدمج. ومع ذلك، يمكن تشغيل SDV Core بشكل أصلي، ولكن يتطلّب ذلك قدرًا أكبر من عمليات الدمج مقارنةً بإصدارات Android الأخرى.

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

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

التصميم التفصيلي

الشكل 2: البنية التفصيلية لـ SDV Core

إنّ حزمة SDV Core مشتقة من Android، وبالتالي تحاول بنيتها أن تتوافق مع Android قدر الإمكان. يعني ذلك بشكل أساسي أنّ SDV Core تستخدم أيضًا GKI وبرامج التشغيل وطبقات HAL والمكتبات الأساسية من Android، وتضيف المكوّنات المطلوبة لبنية الخدمة.

ستتناول الأقسام التالية مكونات النظام بالتفصيل.

بيئة المضيف والمحاكاة الافتراضية

تم تطوير SDV Core على افتراض أنّه سيتم تشغيله في بيئة افتراضية، وبالتالي، نضع بعض الافتراضات حول بيئة المضيف:

تشغّل بيئة المضيف برنامجًا للإشراف على الأجهزة الافتراضية يتوافق مع أجهزة Virtio. بالإضافة إلى ذلك، يجب أن تنفّذ أداة الإشراف Ethernet أو vsock وحالات الطاقة وأجهزة الحظر. بالإضافة إلى ذلك، يجب أن يكون برنامج Hypervisor متوافقًا مع تشغيل Android/Linux.

في ما يتعلق بالأجهزة، تفترض SDV Core توفّر وحدة معالجة مركزية (CPU) ووحدة إدارة الذاكرة (MMU) تتوافقان مع المحاكاة الافتراضية للأجهزة، وأنّ النظام متصل عبر شبكة إيثرنت. لا يشترط أن يتضمّن النظام وحدة معالجة الرسومات أو وحدة معالجة الصور أو واجهة الكاميرا التسلسلية أو محركات الوسائط أو الشاشة أو غيرها من ناقلات الاتصال الخاصة بالسيارات (مثل CAN وLIN).

Android Base

يستند SDV Core إلى نظام التشغيل Android، ولكنّه يقلّل من وظائف النظام إلى الوظائف الأساسية فقط، ويضيف بيئة وقت تشغيل SDV. وهذا يعني أنّ SDV تستخدم أيضًا GKI وخدمات النظام الأصلية (مثل adbd وlogd) ووظائف النظام، ولكنّها لا تتضمّن JVM والخدمات أو تطبيقات النظام المستندة إلى JVM، ولا الميزات التي تم تنفيذها لـ JVM.

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

نواة GKI وبرامج التشغيل وطبقة تجريد الأجهزة (HAL)

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

يسمح ذلك أيضًا لـ SDV بالحصول على واجهة نواة ثابتة. على سبيل المثال، يمكنك تجميع برامج التشغيل كوحدات تعمل مع GKI حتى عند نشر نواة جديدة تتضمّن إصلاحات أمان.

يحتوي نواة GKI على جدول زمني ثابت، ويجب نقل تغييرات المورّد التي من المفترض أن تصبح جزءًا من نواة GKI التالية إلى نواة Linux حتى نهاية العام.

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

بما أنّ SDV Core تفترض أنّها تستند إلى برنامج مراقبة الأجهزة الافتراضية المتوافق مع Virtio، يتم توفير برامج التشغيل كوحدات Virtio kernel إذا كانت الميزة متوافقة، أو كمعيار مفتوح آخر (على سبيل المثال، Open Profile for DICE وبرنامج تشغيل Open-dice kernel للثقة).

يؤدي هذا المزيج من Virtio (والمعايير المفتوحة) وبرنامج مراقبة الأجهزة الافتراضية إلى تجريد الأجهزة. لذلك، فإنّ الحاجة إلى طبقة تجريد الأجهزة (HAL) في SDV تكون في حدّها الأدنى، ولكن بعضها لا يزال مطلوبًا بسبب عدم توفّر دعم Virtio. على سبيل المثال، KeyMint HAL للتشفير المستند إلى الأجهزة وIRemotelyPrivisionedComponent HAL المرتبط به بشكل وثيق للتصديق بين الأجهزة الافتراضية للمركبات المحدّدة بالبرامج.

حزمة الاتصال والشبكات

الشكل 3: حزمة التواصل والشبكات الأساسية في المركبات المحدّدة بالبرامج

بالنسبة إلى الشبكات، يفترض SDV Core أنّ vsock أو الإيثرنت متاحان للتواصل بين الأجهزة الافتراضية، ويمكن أيضًا استخدام آليات IPC، مثل binder، للتواصل داخل الجهاز الافتراضي.

تتيح أداة SDV الاتصال التسلسلي لأغراض تصحيح الأخطاء فقط.

الشكل 4. إتاحة استخدام SDV Core التسلسلي لتصحيح الأخطاء

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

Vsock

‫Vsock هي القناة المفضّلة للتواصل المحلي بين أجهزة افتراضية متعددة أو بين المضيف والجهاز الافتراضي. يجب أن تستخدم الآلات الافتراضية اتصال vsock مباشرًا بين بعضها البعض للسماح بتنفيذ عملية تحسين عدد النسخ.

الذاكرة المشتركة

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

إيثرنت

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

شبكة المركبة صغيرة بما يكفي لكي تكون مساحة عناوين الإصدار 4 من بروتوكول الإنترنت كافية لتحديد جميع الأنظمة المتاحة. ومع ذلك، لضمان توافق النظام مع عمليات الربط المحتملة والتطوير المستقبلي، يجب أن يكون النظام متوافقًا مع IPv4 وIPv6.

شبكة VLAN

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

البروتوكولات

بروتوكولا TCP وUDP

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

نفق البيانات

‫Data Tunnel هي آلية تواصل تم تطويرها حديثًا في إطار مبادرة SDV، وتوفّر قناة تواصل سريعة تتّبع نموذج النشر والاشتراك، على سبيل المثال، ينشر تطبيق موضوعًا بينما يمكن لتطبيق واحد أو أكثر الاستماع إليه. داخليًا، تستخدم إما الذاكرة المشتركة وقوائم انتظار الرسائل السريعة (FMQ) داخل الجهاز الظاهري، أو vsock أو Ethernet للتواصل بين الأجهزة الظاهرية.

متوسط عائد النقرة (SDV)

تنفِّذ واجهة SDV RPC عمليات استدعاء الإجراء عن بُعد في SDV باستخدام Binder. تستخدم هذه الطريقة واجهة برمجة تطبيقات محددة مسبقًا لاستدعاء إجراء عن بُعد. وعلى غرار Data Tunnel، تستخدم هذه الميزة إما الذاكرة المشتركة للتواصل داخل الجهاز الافتراضي، أو vsock أو إيثرنت للتواصل بين الأجهزة الافتراضية.

إطارات عمل

SOMEIP

يتم استخدام SOMEIP للتواصل مع الأنظمة غير التابعة لمركبات SDV. ويستند إلى بروتوكولَي TCP وUDP، ولا يتطلّب أجهزة أو برامج تشغيل خاصة. ستنفّذ Google مرجعًا.

وكيل اكتشاف الخدمات (SD Agent)

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

البرامج الوسيطة

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

المنطقة المحايدة

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

مدير إمكانية الاتصال

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

قابلية التحديث

من الميزات الرئيسية في "أجهزة العرض الديناميكية" إمكانية تعديلها. يمكن تثبيت ميزات جديدة خلال دورة حياة المركبة المحدّدة بالبرامج (SDV) من خلال تحديثات نظام Android وحِزم APEX.

تحديثات نظام Android

يوفر Android حاليًا آلية لتثبيت التحديثات. تستخدم هذه الميزة تحديثات A/B وA/B الافتراضية في الإصدارات الحديثة، وستستفيد حزمة SDV Core من هذه الآلية. تنشئ تحديثات A/B كل قسم مرتين، ما يوفّر ميزتَين: يمكن تحديث النظام في الخلفية، وإذا تعذّر التحديث، يمكن للنظام العودة إلى الحالة السابقة لآخر إصدار معروف ليعمل.

حِزم APEX

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

سيستخدم SDV Core حِزم APEX لتثبيت الخدمات بشكل ديناميكي على آلة افتراضية SDV، ولكن أيضًا لإدارة تفعيل خدمات متعددة في عملية واحدة: يمكن تفعيل الخدمات المجمّعة في حزمة APEX نفسها والتي تستخدم الشهادة نفسها في برنامج ثنائي واحد للحد من المخاطر الأمنية.

تستفيد آلية تثبيت حِزم APEX في Android من بعض رموز Java البرمجية لإدارة حِزم APK والتحقّق منها. يجب أن تنفّذ حزمة SDV Core بديلاً أصليًا للسماح بتثبيت حِزم APEX بشكل ديناميكي.

إدارة التحديثات

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

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

البدء

يقدّم دليل البدء تفاصيل حول رمز المصدر وعملية الإنشاء والإطلاق باستخدام Cuttlefish.