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

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

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

تصميم

SDV Core Arch

الشكل 1: بنية SDV Core

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

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

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

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

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

SDV Core Detailed Arch

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

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

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

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

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

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

في ما يتعلق بالأجهزة، يفترض SDV Core أنّ وحدة المعالجة المركزية (CPU) ووحدة إدارة الذاكرة (MMU) تتضمّنان ميزة المحاكاة الافتراضية للأجهزة وأنّ النظام متصل عبر شبكة إيثرنت. ولا يُشترط أن يحتوي النظام على وحدة معالجة رسومات أو وحدة معالجة صور أو واجهة CSI أو محرّكات وسائط أو شاشة أو نواقل اتصالات أخرى خاصة بالسيارات (مثل 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 إذا كانت الميزة متاحة، أو كمعيار مفتوح آخر (على سبيل المثال، Open Profile for DICE وبرنامج تشغيل نواة open-dice للثقة).

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

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

حزمة الشبكات والاتصالات الأساسية في SDV

الشكل 3: SDV Core Networking and Communication Stack.

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

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

إتاحة المنفذ التسلسلي في SDV Core لتصحيح الأخطاء

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

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

Vsock

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

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

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

إيثرنت

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

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

شبكة LAN افتراضية (VLAN)

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

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

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

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

Data Tunnel

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

(SDV) RPC

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

إطارات عمل

SOMEIP

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

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

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

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

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

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

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

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

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

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

من الميزات الرئيسية لمركبات SDV هي إمكانية تحديثها. ويمكن تثبيت الميزات الجديدة طوال عمر SDV من خلال تحديثات نظام Android وحزم APEX.

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

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

حِزم APEX

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

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

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

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

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

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

البدء

يوفّر دليل البدء تفاصيل حول الرمز المصدر وإنشاء Cuttlefish وتشغيله.