صنعت خودرو درحال حرکت از معماری متشکل از چندین واحد محاسباتی غیرمتمرکز به معماری‌ای است که چندین عملکرد را در چند واحد محاسباتی متمرکز ترکیب می‌کند و ویژگی‌های جدیدی مانند به‌روزرسانی‌های بی‌سیم را ممکن می‌سازد.
AAOS SDV از سیستم و زیرساخت Android موجود برای ارائه راه‌حل استفاده می‌کند. علاوه‌براین، سازندگان اصلی تجهیزات به‌دنبال راه‌حل‌هایی هستند که بتوانند در فضای ابری نیز اجرا شوند، زیرا این امر توسعه اولیه را تسهیل می‌کند و امکانات جدیدی برای آزمایش فراهم می‌آورد.
طراحی
شکل ۱. معماری SDV Core.
AAOS برای SDV Core (SDV Core) سیستم‌عاملی است که براساس Android ساخته شده است. به‌دلیل ماهیت جاسازی‌شده آن، پشته JVM مربوط به Android را پیاده‌سازی نمی‌کند، اما درعوض، همه عملکردهای سیستم به‌صورت بومی توسعه یافته است.
SDV Core دراصل برای محیط مجازی‌سازی‌شده توسعه یافته است و برخی‌از تصمیمات طراحی این ادغام را فرض می‌کنند. بااین‌حال، امکان اجرای SDV Core به‌صورت بومی وجود دارد، اما این کار درمقایسه با سایر نسخه‌های Android به کار ادغام بیشتری نیاز دارد.
SDV Core برای سیستم توزیع‌شده محلی طراحی شده است، برای مثال فرض می‌کند که چندین نمونه از SDV Core (یا مشتقات آن) درکنار یکدیگر روی یک تراشه یا در چندین سیستم اجرا می‌شوند و می‌توانند ازطریق اتصال شبکه با یکدیگر ارتباط برقرار کنند. بنابراین، جنبه اصلی معماری سیستم، پیاده‌سازی عملکرد به‌عنوان سرویس‌هایی است که می‌توانند در هریک از نمونه‌ها میزبانی شوند.
«هسته خودروی نرم‌افزارمحور» حداقل مجموعه عملکردها برای توسعه عملکرد درون خودرو است. یک سرویس معمولی چند سیگنال دریافت می‌کند، آن‌ها را پردازش می‌کند، و نتیجه را با سرویس‌های دیگر هم‌رسانی می‌کند. این محدودیت دامنه هدفمند است زیرا به SDV Core امکان می‌دهد انواع مختلفی از «سیستم روی تراشه» (SoC) را اجرا کند که ممکن است فاقد موتورهای پیشرفته باشند و در هزینه‌ها صرفه‌جویی شود.
طراحی با جزئیات
شکل ۲. معماری دقیق هسته SDV.
SDV Core از Android مشتق شده است و بنابراین معماری آن تلاش می‌کند تا حد امکان با Android همسو شود. اساساً، این یعنی SDV Core از GKI، درایورها، HAL، و کتابخانه‌های اصلی Android نیز استفاده می‌کند و مؤلفه‌های موردنیاز برای معماری سرویس را اضافه می‌کند.
بخش‌های زیر اجزای سیستم را به‌طور مفصل پوشش می‌دهند.
محیط میزبان و مجازی‌سازی
SDV Core با این فرض توسعه یافته است که در محیطی مجازی اجرا خواهد شد، بنابراین، ما چند فرض درباره محیط میزبان درنظر می‌گیریم:
محیط میزبان یک هایپروایزر را اجرا می‌کند که از دستگاه‌های Virtio پشتیبانی می‌کند. علاوه‌براین، هایپروایزر باید اترنت یا vsock، حالت‌های مصرف برق، و دستگاه‌های بلوکی را پیاده‌سازی کند. علاوه‌براین، هایپروایزر باید از اجرای Android/Linux پشتیبانی کند.
ازنظر سخت‌افزار، SDV Core فرض می‌کند که واحد پردازش مرکزی (CPU) و واحد مدیریت حافظه (MMU) از مجازی‌سازی سخت‌افزاری پشتیبانی می‌کنند و سیستم ازطریق اترنت متصل است. سیستم نیازی به داشتن GPU، IPU، CSI، موتورهای رسانه، نمایشگر، یا دیگر گذرگاه‌های ارتباطی خودرو (مثل CAN، LIN) ندارد.
Android Base
SDV Core مبتنی بر Android است، اما سیستم را به عملکردهای ضروری سیستم کاهش می‌دهد و محیط زمان اجرای SDV را اضافه می‌کند. این یعنی SDV از GKI، خدمات سیستم بومی (برای مثال، adbd و logd)، و عملکرد سیستم نیز استفاده می‌کند، اما شامل JVM، و خدمات مبتنی بر JVM یا برنامه‌های سیستم، یا ویژگی‌های پیاده‌سازی‌شده برای JVM نمی‌شود.
این همچنین به این معنی است که SDV با استراتژی به‌روزرسانی و چیدمان پارتیشن Android سازگار خواهد شد. این نسخه الزامات امنیتی مشابهی دارد، اما فاقد واسط گرافیکی کاربر است.
تصویر هسته عمومی، درایورها، و لایه انتزاع سخت‌افزار
«خودروی نرم‌افزارمحور» از هسته GKI Android با هسته 6.1 Android استفاده می‌کند. مزیت استفاده از GKI این است که تغییراتی که در بالادست اعمال می‌شوند درنهایت در Android اعمال می‌شوند. علاوه‌براین، Android از یک هسته در سراسر ناوگان استفاده می‌کند. برای مثال، وصله‌ها به‌جای چندین هسته فروشنده، به‌صورت مرکزی اعمال می‌شوند.
این کار همچنین به «خودروی نرم‌افزارمحور» امکان می‌دهد میانای هسته پایداری داشته باشد. برای مثال، می‌توانید درایورها را به‌عنوان ماژول‌هایی کامپایل کنید که با GKI کار می‌کنند، حتی زمانی که هسته جدیدی با اصلاحات امنیتی مستقر شده باشد.
هسته GKI دارای یک خط زمانی ثابت است، تغییرات فروشنده که باید بخشی از هسته GKI بعدی شوند باید تا پایان سال به هسته Linux بالادستی شوند.
با GKI، درایورهای دستگاه و پیمانه‌هایی که برای بوت شدن لازم نیستند به‌عنوان پیمانه‌های هسته کامپایل می‌شوند و در دیسک RAM که درطول بوت اولیه بار می‌شود قرار می‌گیرند. پیکربندی‌های بسیار اولیه دستگاه که نمی‌توانند منتظر میانای پیمانه هسته بمانند (مثلاً مقداردهی اولیه تصادفی) باید در ساختار درختی دستگاه انجام شوند. نیازی نیست واحدهای هسته بالادستی شوند، اما باید درمقابل میاناهای GKI کامپایل شوند.
Because of SDV Core assuming that it is built on top of a Virtio-compatible hypervisor, drivers are delivered as Virtio kernel modules if the feature is supported, or as another open standard (for example, Open Profile for DICE and the open-dice kernel driver for trust).
این ترکیب Virtio (و استانداردهای باز) و یک هایپروایزر منجر به انتزاع سخت‌افزار می‌شود. بنابراین، نیاز به HAL در «خودرو نرم‌افزارمحور» حداقل است، اما برخی‌از آن‌ها به‌دلیل عدم پشتیبانی از Virtio همچنان موردنیاز هستند. برای مثال، KeyMint HAL برای رمزنگاری با پشتیبانی سخت‌افزاری و IRemotelyPrivisionedComponent HAL که ارتباط نزدیکی با آن دارد برای گواهی در میان ماشین‌های مجازی SDV.
پشته شبکه و ارتباطات
شکل ۳. پشته ارتباطات و شبکه اصلی SDV.
برای شبکه‌سازی، SDV Core فرض می‌کند که vsock یا اترنت برای برقراری ارتباط بین ماشین‌های مجازی دردسترس است، ارتباط داخلی ماشین مجازی نیز می‌تواند از سازوکارهای IPC مانند binder استفاده کند.
«خودروی نرم‌افزارمحور» از ارتباط سریال فقط برای اهداف اشکال‌زدایی پشتیبانی می‌کند.
شکل ۴. پشتیبانی سریال SDV Core برای اشکال‌زدایی.
در یک مهمان واحد، SDV گزینه‌های متعددی را ارائه می‌دهد که به مدل ارتباطی و الزامات عملکرد بستگی دارد.
Vsock
Vsock کانال ترجیحی برای ارتباط محلی بین چند VM یا میزبان و VM است. ماشین‌های مجازی باید از ارتباط مستقیم vsock بین یکدیگر استفاده کنند تا پیاده‌سازی بتواند تعداد کپی‌ها را بهینه‌سازی کند.
حافظه مشترک
حافظه مشترک فقط برای برقراری ارتباط با VM برای IPC (ارتباط بین فرایندی) استفاده می‌شود، اما به‌عنوان کانال معمولی برای برقراری ارتباط بین چندین VM ارائه نمی‌شود. میزبان ممکن است از حافظه مشترک برای هم‌رسانی اطلاعات با مهمان استفاده کند، اما این کار برای ترافیک شبکه با فرکانس بالا برنامه‌ریزی نشده است.
اترنت
اترنت برای ارتباط بین چند SoC، یعنی برای ارتباط درون خودرو، استفاده می‌شود. این سیستم‌ها می‌توانند سیستم‌های مجازی‌سازی‌شده باشند، اما همچنین می‌توانند سیستم‌های بومی یا ECU قدیمی باشند.
شبکه خودرو به‌اندازه کافی کوچک است که فضای نشانی IPv4 برای شناسایی همه سیستم‌های دردسترس کافی باشد. بااین‌حال، برای اطمینان از اینکه سیستم با پیوندهای بالادستی بالقوه و توسعه آینده سازگار است، IPv4 و IPv6 باید پشتیبانی شوند.
VLAN
VLAN سازوکاری برای ایجاد معماری‌های شبکه مجازی است که امکان جداسازی زیرشبکه‌های مختلف و تشکیل شبکه‌های محلی را فراهم می‌کند. از این ویژگی می‌توان برای ایجاد مناطق امنیتی مختلف استفاده کرد و در خودروها برای همین منظور استفاده می‌شود. پشتیبانی VLAN الزامی است.
پروتکل‌ها
TCP و UDP
بسته به مورد استفاده، سیستم به پروتکل ارتباطی قابل‌اعتماد یا غیرقابل‌اعتماد اما سریع نیاز دارد. بنابراین، TCP و UDP پشتیبانی خواهند شد.
تونل داده‌ها
Data Tunnel یک سازوکار ارتباطی جدید برای SDV است که یک کانال ارتباطی سریع را براساس مدل pubsub ارائه می‌دهد، برای مثال یک برنامه موضوعی را منتشر می‌کند درحالی‌که یک یا چند برنامه می‌توانند به آن گوش دهند. در داخل، از حافظه مشترک و FMQ (صف‌های پیام سریع) در VM استفاده می‌کند، یا از vsock یا اترنت برای برقراری ارتباط بین VMها استفاده می‌کند.
(SDV) RPC
SDV RPC فراخوانی‌های رویه ازراه‌دور را برای SDV بااستفاده از binder پیاده‌سازی می‌کند. این روش از یک میانای برنامه‌سازی کاربردی ازپیش تعریف‌شده برای فراخوانی رویه ازراه‌دور استفاده می‌کند. مشابه Data Tunnel، این پروتکل یا از حافظه مشترک برای ارتباط درون VM استفاده می‌کند یا از vsock یا Ethernet برای ارتباط بین VMها.
چارچوب
SOMEIP
از SOMEIP برای برقراری ارتباط با سیستم‌های غیرخودروی نرم‌افزارمحور استفاده می‌شود. این پروتکل بر روی TCP و UDP ساخته شده است و به سخت‌افزار یا درایورهای خاصی نیاز ندارد. Google مرجعی را پیاده‌سازی خواهد کرد.
عامل کشف سرویس (عامل SD)
این سرویس، کشف سرویس، اصالت‌سنجی، و صدور مجوز را برای «خودروی نرم‌افزارمحور» ارائه می‌دهد. برای برقراری ارتباط، ممکن است از هریک از روش‌های ذکرشده در بالا استفاده کند. برای اصالت‌سنجی و صدور مجوز، «عامل SD» به دسترسی به سخت‌افزار امنیتی و زنجیره اعتماد فعال نیاز دارد.
میان‌افزار
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 بسته‌بندی شده‌اند و از یک گواهی استفاده می‌کنند می‌توانند در یک باینری مستقر شوند تا خطرات امنیتی کاهش یابد.
سازوکار Android برای نصب بسته‌های APEX از برخی کدهای Java برای مدیریت APK جهت تأیید بسته‌ها استفاده می‌کند. SDV Core باید جایگزین بومی را پیاده‌سازی کند تا نصب بسته‌های APEX به‌صورت پویا امکان‌پذیر شود.
مدیریت به‌روزرسانی
نمونه‌های SDV واحدهای کاملاً مستقلی در خودرو نیستند و به هماهنگی با دیگر نمونه‌های SDV و سرویس‌های خودرو نیاز دارند. برای مثال، برای نصب وابستگی‌های سرویس یا برای اطمینان از اینکه به‌روزرسانی‌ها فقط در وضعیت ایمن سیستم نصب می‌شوند.
SDV استفاده از پارتیشن‌ها را در چندین VM درنظر می‌گیرد. این کار مستلزم هماهنگی بین آن ماشین‌های مجازی است، زیرا آن‌ها وابستگی داده‌ای به یکدیگر دارند: باید یک ماشین مجازی اصلی برای به‌روزرسانی آن پارتیشن‌ها وجود داشته باشد، و مکانیزمی برای اطلاع‌رسانی به سایر ماشین‌های مجازی درباره پارتیشن به‌روزرسانی‌شده و همگام‌سازی برای به‌روزرسانی هم‌زمان همه ماشین‌های مجازی وجود داشته باشد تا اطمینان حاصل شود که وضعیت کاری شناخته‌شده قبلی شکسته نمی‌شود.
شروع به کار
راهنمای شروع به کار ما جزئیاتی درباره کد منبع، ساخت، و راه‌اندازی با Cuttlefish ارائه می‌دهد.