معماری

بیشتر تغییرات مورد نیاز برای پشتیبانی از VirtIO در AAOS شامل تغییراتی در سطح اجرای HAL و پایین تر در هسته مشترک Android است. چارچوب Android با یک HAL سخت‌افزاری عمومی با استفاده از درایورهای VirtIO در هسته VM مهمان AAOS ارتباط برقرار می‌کند که با استفاده از پروتکل‌های VirtIO با دستگاه‌های VirtIO در سمت میزبان ارتباط برقرار می‌کند. دستگاه‌های VirtIO در سمت میزبان می‌توانند با استفاده از درایورهای دستگاه مخصوص SoC به HW فیزیکی دسترسی داشته باشند.

ارتباط بین درایور VirtIO و دستگاه VirtIO با virtqueue انجام می شود که بافرهای حلقه مانند DMA از لیست های جمع آوری پراکنده هستند. چندین انتقال، مانند MMIO یا PCI را می توان برای تبادل پیام های VirtIO بین ماشین های مجازی استفاده کرد.

در برخی موارد، vsock برای ارتباطات بین VM استفاده شده است. ارتباطات HAL خودرو، کنترل صوتی و Dumpstate با استفاده از اتصال به یک عامل همتا در یک VM جداگانه از طریق یک رابط vsock پشتیبانی می‌شوند. GRPC-vsock برای دسترسی به این زیرسیستم های غیر استاندارد استفاده می شود. GRPC در درخت منبع Android برای کار با vsock با قالب آدرس vsock:CID:PORT_NUMBER اصلاح شده است.

معماری مجازی سازی
شکل 1. معماری مجازی سازی

صوتی

در AAOS مجازی شده، VM مهمان اندرویدی می تواند از virtio-snd برای دسترسی به صدا استفاده کند. virtio-snd دستگاه‌های PCM مجازی‌سازی‌شده را در اختیار ماشین مجازی اندروید قرار می‌دهد تا اجرای HAL صوتی بتواند با دستگاه‌های صوتی مجازی‌شده با کتابخانه TinyALSA تعامل داشته باشد.

اجرای پیش‌فرض HAL صوتی در AOSP در /device/google/trout/hal/audio/6.0 قرار دارد. OEM ها می توانند ro.vendor.trout.audiohal.{in,out}_period_{ms,count} برای پلتفرم خود تغییر دهند. OEM ها همچنین می توانند HAL صوتی خود را با نادیده گرفتن متغیرهای مرتبط با صدا در /device/google/trout/aosp_trout_common.mk.

کنترل صوتی HAL فوکوس صوتی را در AAOS مدیریت می کند. برای مثال، هنگامی که سیستم در حال پخش صداهای اضطراری است، ممکن است لازم باشد موسیقی در حال پخش در پس‌زمینه بی‌صدا شود. کنترل صوتی HAL به برنامه‌هایی که موسیقی پخش می‌کنند اطلاع می‌دهد که در این شرایط بی‌صدا شوند. در سیستم مجازی، صداها می توانند از ماشین های مجازی دیگر بیایند. در پیاده سازی مرجع، VM مهمان AAOS دارای یک سرور کنترل صدا در حال اجرا است که از GRPC-vsock برای دریافت درخواست های فوکوس صوتی از سایر ماشین های مجازی استفاده می کند. VM میزبان می‌تواند از device/google/trout/hal/audiocontrol/2.0/libandroid_audio_controller برای ارسال درخواست‌های کنترل صدا به AAOS استفاده کند. در حالی که libandroid_audio_controller فوکوس صدا را نگه می دارد، تا زمانی که فوکوس آزاد نشود، به ارسال ضربان قلب به AAOS ادامه می دهد.

معماری صوتی
شکل 5. معماری صوتی

بلوتوث

اجرای بلوتوث بر اساس طرحی است که در زیر نشان داده شده است.

معماری بلوتوث
شکل 5. معماری بلوتوث

نمایه هندزفری بلوتوث

برای فعال کردن نمایه هندزفری بلوتوث (HFP) در trout ، مشخصات دستگاه صدای VirtIO برای پشتیبانی از کنترل‌های صوتی گسترش یافته است. با استفاده از این رویکرد، یک دستگاه صدای VirtIO در سمت میزبان/هایپروایزر، این سه کنترل صوتی مربوط به HFP را فراهم می‌کند:

  • hfp_enable
  • hfp_set_sampling_rate
  • hfp_volume

وقتی AAOS به عنوان VM مهمان اجرا می شود، AAOS از TinyAlsa برای تنظیم این کنترل های صوتی استفاده می کند. برای فعال کردن مورد استفاده HFP، میزبان/هایپروایزر مسیریابی و کالیبراسیون خاص فروشنده را بر این اساس انجام می دهد.

اجرای بلوتوث بر اساس تصویر طراحی زیر است.

معماری بلوتوث
شکل 5. معماری بلوتوث

زباله دان

هنگام ایجاد گزارش اشکال برای AAOS مجازی، گنجاندن اطلاعات میزبان VM بسیار ارزشمند است تا توسعه دهندگان دید جامع تری از سیستم داشته باشند. برای انجام این کار، پیاده‌سازی مرجع trout IDumpstateDevice HAL را پیاده‌سازی می‌کند که اطلاعات 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-video استفاده می‌کند، به جریان ویدیو دسترسی پیدا کند.

حالت گاراژ

برای اطلاعات بیشتر، به حالت گاراژ مراجعه کنید.

ورود و خروج از حالت گاراژ توسط ویژگی های AP_POWER_STATE_REQ ارسال شده توسط Vehicle HAL فعال می شود. در حالت مجازی سازی، حالت Garage از سمت میزبان فعال می شود. VM میزبان باید روشن بماند تا دستگاه‌های مجازی را برای Android VM فراهم کند، تا زمانی که Android خاموش شود. سرور VHAL در VM میزبان سیگنال خاموش شدن را به VM مهمان AAOS می فرستد. با دریافت سیگنال مشتری VHAL، AAOS VM وارد حالت Garage می شود و شروع به ارسال سیگنال های ضربان قلب برای فعال نگه داشتن VM میزبان می کند.

سیستم ماهواره ای ناوبری جهانی (GNSS)

در trout 1.0، پشتیبانی از مجازی سازی GNSS بر روی virtio-console اضافه شده است. این پیاده سازی از تبادل اندازه گیری های خام و رفع موقعیت مکانی از میزبان به مهمان پشتیبانی می کند.

فرمت تبادل داده CSV است که توسط برنامه GnssLogger استفاده می شود. در پیاده‌سازی مرجع، چون درایور GNSS بومی در دسترس نیست، داده‌های ساختگی در دسترس است اما یک درایور بومی را می‌توان بدون هیچ تغییری در سمت مهمان پیاده‌سازی کرد. یک نمونه عامل میزبان ساختگی به عنوان بخشی از کد منبع trout ارائه شده است.

اجرای فعلی انتظار دارد که راه اندازی اولیه GNSS و GNSS کمکی (AGNSS) توسط محیط سیستم عامل میزبان مدیریت شود.

معماری GNSS
شکل 2. معماری GNSS

گرافیک

وقتی AAOS به‌عنوان یک VM مهمان در کنار سایر سیستم‌عامل‌های خودرو اجرا می‌شود، اندروید ممکن است دسترسی مستقیم به GPU یا کنترل‌کننده نمایشگر نداشته باشد. در این حالت می توان از Mesa یا goldfish-opengl و یک درایور virtio-gpu در VM مهمان اندروید و دستگاه virtio-gpu برای دسترسی به GPU استفاده کرد.

در VM مهمان Android، Mesa یا goldfish-opengl دستورات OpenGLES را به ترتیب در یک جریان گالیوم یا یک جریان GLES که به طور خودکار تولید می‌شود، رمزگذاری می‌کنند. درایور هسته virtio-gpu به عنوان یک انتقال استفاده می شود. در سمت میزبان، virglrenderer (برای Mesa) و vulkan-cereal (برای goldfish-opengl ) جریان فرمان رمزگشایی شده را در بالای درایور GPU موجود پخش می‌کنند. trout پلت فرم مرجع AAOS از OpenGL ES فقط با پشتیبانی Vulkan پشتیبانی می کند که در آینده پیش بینی می شود.

معماری گرافیک
شکل 3. معماری گرافیک

حسگرها

هنگامی که AAOS به عنوان یک VM مهمان در کنار سایر سیستم عامل‌های خودرو اجرا می‌شود، اندروید ممکن است دسترسی مستقیم به سنسورها نداشته باشد. در این حالت از درایور Virtio-SCMI در VM مهمان اندروید و دستگاه VirtIO-SCMI در Host VM برای دسترسی به سنسورها استفاده می شود. پلت فرم مرجع مجازی سازی AAOS یک سنسور HAL عمومی و HW-agnostic ارائه می دهد که می تواند برای SoC های مبتنی بر ARM برای دسترسی به حسگرها استفاده شود.

سنسور HAL با درایور IIO SCMI در زیر سیستم 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 ممکن است نیاز به تغییر داده‌های حسگر دریافتی از Host VM داشته باشد تا با سیستم مختصات سنسور خودرو Android مطابقت داشته باشد. طرح پیکربندی حسگر را می‌توانید در device/google/trout/hal/sensors/2.0/config/sensor_hal_configuration.xsd بیابید.

OEM ها می توانند پیکربندی حسگر مانند جهت گیری و مکان را در 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 وسیله نقلیه

پیاده سازی Vehicle HAL از دو جزء تشکیل شده است:

  • مشتری. API های مورد استفاده اندروید را در AAOS مجازی ارائه می دهد
  • سرور. به طور مستقیم با سخت افزار، مانند اتوبوس های وسیله نقلیه (یا شبیه ساز) ارتباط برقرار می کند.

در مجازی سازی، سرور VHAL روی VM میزبان اجرا می شود. کلاینت و سرور VHAL از طریق GRPC-vsock ارتباط برقرار می کنند (برای اطلاعات بیشتر، device/google/trout/hal/vehicle/2.0/proto/VehicleServer.proto ببینید). OEM ها می توانند با نادیده گرفتن API های ارتباطی از پروتکل انتقال متفاوتی غیر از GRPC استفاده کنند. برای مثال، device/google/trout/hal/vehicle/2.0/GrpcVehicle{Client,Server}.cpp ببینید.

زیرسیستم های دیگر

VirtIO قبلاً یک رابط کاملاً تعریف شده برای مؤلفه هایی مانند Block Storage، Network، Console، Input، Socket و Entropy ارائه می دهد. برای این زیرسیستم ها، AAOS از درایور همانطور که هست استفاده می کند، مانند virtio-blk ، virtio-input ، virtio-console و virtio-net .

در پلتفرم مرجع مجازی سازی شده AAOS، Wi-Fi با mac80211_hwsim پشتیبانی می شود تا یک شبکه بی سیم VirtWifi را فعال کند، که سپس از تونل virtio-net برای ارسال ترافیک شبکه به VM میزبان، که دسترسی مستقیم به شبکه Wi-Fi واقعی دارد، استفاده می کند.