هندسة معمارية

تتضمن معظم التغييرات اللازمة لدعم VirtIO في نظام التشغيل Android Automotive تغييرات في HAL. مستوى التنفيذ وأقل في النواة المشتركة لنظام التشغيل Android. إطار عمل Android يتصل بـ HAL عام غير مرتبط بالأجهزة باستخدام برامج تشغيل VirtIO في ضيف AAOS نواة الجهاز الافتراضي (VM) التي تتواصل مع أجهزة VirtIO على الجانب المضيف باستخدام بروتوكولات VirtIO يمكن لأجهزة VirtIO على الجهاز المضيف الوصول إلى الأجهزة الفعلية باستخدام برامج تشغيل الأجهزة الخاصة بمجال المنظومة على الرقاقة (SoC).

يتم الاتصال بين برنامج تشغيل VirtIO وجهاز VirtIO من خلال virtqueue، وهي مخازن دائرية تشبه DMA الذي يضم قوائم جمع مبعثر. عدة وسائل نقل، مثل MMIO أو منفذ الملحقات الإضافية (PCI) يمكن استخدامها لتبادل رسائل VirtIO بين الأجهزة الافتراضية.

وفي بعض الحالات، يمكن الاستفادة من vsock في التواصل بين الأجهزة الافتراضية. تتوفّر اتصالات HAL والتحكّم في الصوت وDumpstate في المركبة من خلال اتصال. إلى وكيل زميل على جهاز افتراضي منفصل عبر واجهة vsock. تُستخدم GRPC-vsock للوصول إلى هذه الأنظمة الفرعية غير الموحّدة. GRPC تم تعديل شجرة مصدر Android للعمل مع vsock بالعنوان بتنسيق vsock:CID:PORT_NUMBER.

بنية المحاكاة الافتراضية
الشكل 1. بنية المحاكاة الافتراضية

الصوت

في نظام التشغيل AAOS الافتراضي، يمكن للجهاز الافتراضي (VM) الخاص بالضيف من Android استخدام virtio-snd للوصول إلى الصوت. يوفّر virtio-snd أجهزة PCM الافتراضية لجهاز Android الافتراضي، يمكن لتطبيق HAL الصوتي أن يتفاعل مع الأجهزة الصوتية الظاهرية مكتبة TinyALSA.

يوجد تنفيذ HAL الصوتي الافتراضي في AOSP على /device/google/trout/hal/audio/6.0 يمكن للمصنّعين الأصليين للأجهزة تعديل ro.vendor.trout.audiohal.{in,out}_period_{ms,count} على منصتهم. يمكن للمصنّعين الأصليين تنفيذ طبقة تجريد الأجهزة (HAL) الصوتية الخاصة بها من خلال إلغاء متغيرات الصوت في /device/google/trout/aosp_trout_common.mk.

يدير عنصر التحكم في الصوت HAL تركيز الصوت في AAOS. على سبيل المثال، عند تشغيل النظام أصوات الطوارئ، أو الموسيقى التي يتم تشغيلها في الخلفية قد تحتاج إلى كتم الصوت. طبقة تجريد الأجهزة (HAL) للتحكم في الصوت لإرسال إشعار إلى التطبيقات التي تشغِّل الموسيقى لكتم الصوت في هذه الحالة. في النظام الافتراضي، يمكن أن تأتي الأصوات من الأجهزة الافتراضية الأخرى. عند تنفيذ المرجع، يتم استخدام جهاز افتراضي لضيف AAOS. يتضمّن برنامجًا خفيًا لخادم التحكّم في الصوت قيد التشغيل، يستخدم GRPC-vsock لتلقّي طلبات التركيز الصوتي من الأجهزة الافتراضية الأخرى يمكن للجهاز الافتراضي المضيف استخدام device/google/trout/hal/audiocontrol/2.0/libandroid_audio_controller لإرسال طلبات التحكّم في الصوت إلى نظام التشغيل Android Automotive (AAOS). بينما تحمل "libandroid_audio_controller" التركيز الصوتي، يستمر في إرسال نبضات القلب إلى AAOS حتى يتم تحرير التركيز.

بنية الصوت
الشكل 5. بنية الصوت

البلوتوث

يعتمد تنفيذ البلوتوث على التصميم الموضح أدناه.

بنية البلوتوث
الشكل 5. بنية البلوتوث

ملف تعريف البلوتوث بدون لمس الجهاز

لتفعيل ملف تعريف البلوتوث بدون لمس الجهاز (HFP) على trout، يجب استخدام جهاز الصوت VirtIO تم توسيع نطاق مواصفاتها لدعم عناصر التحكم في الصوت. يؤدي استخدام هذا النهج إلى إصدار صوت VirtIO الجهاز على جانب المضيف/جهاز العرض الأساسي عناصر التحكم في الصوت الثلاثة هذه المتعلقة بالفيديو HFP:

  • hfp_enable
  • hfp_set_sampling_rate
  • hfp_volume

عند تشغيل AAOS كجهاز افتراضي للضيوف، يستخدم نظام التشغيل AAOS تطبيق TinyAlsa لضبط عناصر التحكّم في الصوت هذه. لتفعيل HFP حالة الاستخدام، يقوم المضيف/المراقب النظامي بتنفيذ التوجيه والمعايرة الخاص بالمورّد وفقًا لذلك.

يعتمد تنفيذ البلوتوث على الرسم التوضيحي للتصميم أدناه.

بنية البلوتوث
الشكل 5. بنية البلوتوث

Dumpstate

عند إنشاء تقرير الأخطاء لنظام التشغيل Android Automotive (AAOS) الافتراضي، من المهم تضمين معلومات الجهاز الافتراضي (VM) الخاص بالمضيف حتى يحصل المطوّرون على رؤية أكثر شمولاً للنظام. لتحقيق ذلك، يؤدي تنفيذ مرجع trout إلى تنفيذ طبقة تجريد الأجهزة (HAL) IDumpstateDevice، والتي تجمع معلومات الجهاز الافتراضي (VM) المضيف من خلال GRPC-vsock. الجهاز الافتراضي (VM) الخاص بالمضيف "tar" باسم "dumpstate_board.bin" في تقرير الأخطاء أثناء معالجة سجلات التفريغ dumpstate_board.txt

لضبط الأوامر لتنفيذها:

  1. انسخ تفاصيل الإعدادات من الملف أدناه إلى ملف XML، على سبيل المثال، config.xml 
    <dumpstateHalConfiguration version="1.0">
    <services>
        <service name="coqos-virtio-blk"        command="/bin/journalctl --no-pager -t coqos-virtio-blk"/>
        <service name="coqos-virtio-net"        command="/bin/journalctl --no-pager -t coqos-virtio-net"/>
        <service name="coqos-virtio-video"      command="/bin/journalctl --no-pager -t coqos-virtio-video"/>
        <service name="coqos-virtio-console"    command="/bin/journalctl --no-pager -t coqos-virtio-console"/>
        <service name="coqos-virtio-rng"        command="/bin/journalctl --no-pager -t coqos-virtio-rng"/>
        <service name="coqos-virtio-vsock"      command="/bin/journalctl --no-pager -t coqos-virtio-vsock"/>
        <service name="coqos-virtio-gpu-virgl"  command="/bin/journalctl --no-pager -t coqos-virtio-gpu-virgl"/>
        <service name="coqos-virtio-scmi"       command="/bin/journalctl --no-pager -t coqos-virtio-scmi"/>
        <service name="coqos-virtio-input"      command="/bin/journalctl --no-pager -t coqos-virtio-input"/>
        <service name="coqos-virtio-snd"        command="/bin/journalctl --no-pager -t coqos-virtio-snd"/>
        <service name="dumpstate_grpc_server"   command="/bin/journalctl --no-pager -t dumpstate_grpc_server"/>
        <service name="systemd"                 command="/bin/journalctl --no-pager -t systemd"/>
        <service name="systemctl"               command="/bin/systemctl status"/>
        <service name="vehicle_hal_grpc_server" command="/bin/journalctl --no-pager -t vehicle_hal_grpc_server"/>
    </services>
    <systemLogs>
        <service name="dmesg" command="/bin/dmesg -kuPT"/>
    </systemLogs>
</dumpstateHalConfiguration>
  2. مرِّر مسار ملف XML الجديد إلى خادم dumpstate عند تشغيله. مثل: 
    --config_file my_config.xml

نظام العرض الممتد (EVS)

يُستخدم نظام العرض الممتد (EVS) لعرض الفيديو الذي تم التقاطه من خلال النظرة الخلفية كاميرات المراقبة المحيطية. في نظام التشغيل AAOS الافتراضي، يمكن لحزمة EVS الوصول إلى الفيديو المضمّن من جهاز البث V4L2 الافتراضي الذي يستخدم برنامج تشغيل الفيديو VirtIO.

وضع المرآب

لمزيد من المعلومات، يُرجى مراجعة وضع المرآب:

يتم تفعيل الدخول إلى وضع "المرآب" والخروج منه من خلال مواقع AP_POWER_STATE_REQ. التي تم إرسالها بواسطة طبقة تجريد الأجهزة (HAL) بالمركبة. في وضع المحاكاة الافتراضية، يتم تفعيل وضع Garage من جهة المضيف. يجب أن يظل الجهاز الافتراضي المضيف قيد التشغيل لتوفير الأجهزة الافتراضية لأجهزة Android الافتراضية، إلى أن تتم ترقية نظام التشغيل Android مُطفأ. يرسل خادم VHAL على الجهاز الافتراضي المضيف إشارة إيقاف التشغيل إلى الجهاز الافتراضي لضيف AAOS. عند تلقّي إشارة عميل VHAL، يدخل الجهاز الافتراضي AAOS في وضع "المرآب" ويبدأ في إرسال النبضات القلبية. لإبقاء الجهاز الافتراضي المضيف نشطًا.

نظام القمر الصناعي للتنقل العام (GNSS)

في الإصدار 1.0 من trout، تم توفير إمكانية المحاكاة الافتراضية لنظام GNSS من خلال virtio-console تمت إضافتها. يدعم التنفيذ تبادل القياسات الأولية وإصلاحات المواقع من المضيف إلى الضيف.

تنسيق تبادل البيانات هو ملف CSV الذي يستخدمه تطبيق GnssLogger. عند تنفيذ المرجع نظرًا لعدم توفر برنامج تشغيل GNSS الأصلي، تتوفر بيانات وهمية ولكن برنامج تشغيل أصلي ويمكن تنفيذها دون أي تغييرات من جانب الضيف. يتم توفير نموذج لوكيل مضيف تجريبي كجزء من رمز المصدر trout.

تتوقع عملية التنفيذ الحالية معالجة إعداد GNSS وGNSS المدعوم (AGNSS). بواسطة بيئة نظام التشغيل المضيف.

بنية GNSS
الشكل 2. بنية GNSS

الرسومات

عند تشغيل نظام التشغيل AAOS كجهاز افتراضي ضيف إلى جانب أنظمة التشغيل الأخرى للسيارات، قد لا يعمل Android لديهم حق الوصول المباشر إلى وحدة معالجة الرسومات أو وحدة التحكم في الشاشة. وفي هذه الحالة، Mesa أو goldfish-opengl وvirtio-gpu برنامج تشغيل على جهاز Android افتراضي للضيوف virtio-gpu يمكن استخدامها للوصول إلى وحدة GPU.

على الجهاز الافتراضي لضيف Android، يُرمّز Mesa أو goldfish-opengl أوامر OpenGLES إما إلى بث Gallium أو بث GLES تم إنشاؤه تلقائيًا، على التوالي. virtio-gpu يتم استخدام برنامج تشغيل kernel كنقل. من جانب المضيف، virglrenderer (لـ Mesa) تشغيل سلسلة الأوامر التي تم فك ترميزها من خلال vulkan-cereal (للمستخدم goldfish-opengl) على أعلى برنامج تشغيل وحدة معالجة الرسومات الحالي. يتوافق النظام الأساسي المرجعي AAOS trout مع OpenGL ES. فقط مع دعم Vulkan المتوقَّع في إصدار مستقبلي.

بنية الرسومات
الشكل 3. بنية الرسومات

أجهزة الاستشعار

عند تشغيل نظام التشغيل AAOS كجهاز افتراضي ضيف إلى جانب أنظمة التشغيل الأخرى للسيارات، قد لا يملك Android إذن الوصول المباشر إلى أجهزة الاستشعار. في هذه الحالة، لن يتمكن برنامج تشغيل Virtio-SCMI على يتم استخدام جهاز Android افتراضي لضيف Android وجهاز VirtIO-SCMI على الجهاز الافتراضي (Host) للوصول إلى أدوات الاستشعار. توفِّر المنصة المرجعية للمحاكاة الافتراضية لنظام التشغيل AAOS مجموعة مستشعرات HAL عامة وغير متوافقة مع HW. استخدام تقنيات المنظومة على الرقاقة (SoC) القائمة على معادن ARM للوصول إلى المستشعرات.

يتواصل جهاز الاستشعار HAL مع برنامج تشغيل SCMI IIO في النظام الفرعي لـ Linux Kernel IIO، الذي يستخدم بروتوكول إدارة مستشعر SCMI الذي يوفره ARM واجهة التحكّم في النظام وإدارته (SCMI) المواصفات لاكتشاف أجهزة الاستشعار وضبطها، وقراءة بيانات جهاز الاستشعار، وتلقّي إشعارات بشأن أجهزة الاستشعار التغييرات في القيم.

يستخدم برنامج تشغيل IIO SCMI برنامج تشغيل VirtIO SCMI، والذي يستخدم نقل VirtIO كما هو موضح في virtio-scmi مواصفات تبادل رسائل SCMI مع جهاز VirtIO SCMI على الجهاز الافتراضي (VM) المضيف. جهاز VirtIO يمتلك جهاز SCMI إمكانية الوصول المباشر إلى أجهزة الاستشعار من خلال برامج تشغيل المستشعرات الخاصة بمجال المنظومة على الرقاقة (SoC).

بنية أدوات الاستشعار
الشكل 4. بنية أدوات الاستشعار

الموقع الجغرافي لجهاز الاستشعار من HAL

يقع التنفيذ المرجعي لمستشعر HAL، والذي يستخدم VirtIO SCMI، في device/google/trout/hal/sensors

ضبط طبقة تجريد الأجهزة (HAL) أداة الاستشعار

قد تحتاج أداة الاستشعار HAL إلى تعديل بيانات جهاز الاستشعار المُستلَمة من الجهاز الافتراضي (VM) للمضيف لتتوافق مع نظام إحداثيات جهاز استشعار السيارة في Android يمكنك العثور على مخطط ضبط أداة الاستشعار في device/google/trout/hal/sensors/2.0/config/sensor_hal_configuration.xsd

يمكن للمصنّعين الأصليين للأجهزة توفير إعدادات أداة الاستشعار، مثل الاتجاه والموقع، sensor_hal_configuration.xml وانسخ الملف إلى /odm/etc/sensors/ أو /vendor/etc/sensors/. في ما يلي نموذج ضبط جهاز استشعار:

<sensorHalConfiguration version="1.0" xmlns:xi="http://www.w3.org/2001/XInclude">
    <modules>
        <module halName="android.hardware.sensors@2.0-Google-IIO-Subhal" halVersion="2.0">
            <sensors>
                <sensor name="scmi.iio.accel" type="1">
                    <configuration>
<!-- Attribute rotate denotes if HAL needs to modify the sensor data to comply with //
        the Android car sensor coordinate system -->
                        <orientation rotate="true">
               <!-- Attribute map denotes the indexes of data in sensor data received -->
               <!-- Attribute negate denotes if data needs to be negated -->
                            <x map="0" negate="false"/>
                            <y map="1" negate="true"/>
                            <z map="2" negate="true"/>
                        </orientation>
                        <location>
               <!-- Attribute x, y, z denotes location of the sensor placement -->
                            <x>10</x>
                            <y>15</y>
                            <z>20</z>
                        </location>
                    </configuration>
                </sensor>
         </sensors>
        </module>
    </modules>
</sensorHalConfiguration>

طبقة تجريد الأجهزة (HAL) في المركبة

يتألّف تنفيذ HAL للمركبة من مكوّنَين:

  • العميل: توفّر هذه السياسة واجهات برمجة التطبيقات التي يستخدمها Android في واجهات AAOS الافتراضية.
  • الخادم. يتصل مباشرةً بالأجهزة، مثل حافلات المركبات (أو محاكي).

في المحاكاة الافتراضية، يعمل خادم VHAL على الجهاز الافتراضي (VM) المضيف. يتصل عميل VHAL والخادم من خلال GRPC-vsock (لمزيد من المعلومات، يُرجى الاطّلاع على device/google/trout/hal/vehicle/2.0/proto/VehicleServer.proto). يمكن للمصنّعين الأصليين للأجهزة استخدام غير بروتوكول GRPC من خلال تجاوز واجهات برمجة تطبيقات الاتصال. على سبيل المثال، يمكنك الاطّلاع على device/google/trout/hal/vehicle/2.0/GrpcVehicle{Client,Server}.cpp.

الأنظمة الفرعية الأخرى

يوفر VirtIO حاليًا واجهة محددة جيدًا للمكونات مثل كتلة التخزين الشبكة، ووحدة التحكم، والإدخال، والمقبس، والإنتروبيا. بالنسبة لهذه الأنظمة الفرعية، يستخدم AAOS برنامج التشغيل كما هو، مثل virtio-blk وvirtio-input virtio-console، وvirtio-net.

في المنصة المرجعية الافتراضية لنظام التشغيل AAOS، تتوفّر شبكة Wi-Fi من خلال mac80211_hwsim. لتفعيل شبكة لاسلكية VirtWifi تستخدم بعد ذلك النفق virtio-net لإرسال حركة بيانات الشبكة إلى الجهاز الافتراضي (VM) المضيف، الذي لديه إمكانية الوصول المباشر إلى شبكة Wi-Fi الفعلية.