صنعت خودرو در حال گذار از معماری متشکل از واحدهای محاسباتی غیرمتمرکز متعدد به معماریای است که چندین قابلیت را در قالب چند واحد محاسباتی متمرکز ترکیب میکند و ویژگیهای جدیدی مانند بهروزرسانیهای بیسیم را امکانپذیر میسازد.
AAOS SDV از سیستم و زیرساخت اندروید موجود برای ارائه یک راهکار استفاده میکند. علاوه بر این، تولیدکنندگان اصلی تجهیزات (OEM) به دنبال راهکارهایی هستند که بتوانند در فضای ابری نیز اجرا شوند، زیرا این امر توسعه اولیه را تسهیل کرده و امکان آزمایشهای جدید را فراهم میکند.
طراحی
شکل 1. معماری هسته SDV.
AAOS برای SDV Core (SDV Core) یک سیستم عامل مبتنی بر اندروید است. به دلیل ماهیت تعبیه شده آن، پشته JVM اندروید را پیاده سازی نمیکند، بلکه در عوض، تمام عملکردهای سیستم به صورت بومی توسعه داده شده است.
SDV Core در درجه اول برای یک محیط مجازی توسعه داده شده است و برخی از تصمیمات طراحی، این ادغام را در نظر میگیرند. با این وجود، میتوان SDV Core را به صورت بومی اجرا کرد، اما این کار در مقایسه با سایر نسخههای اندروید، به حجم بیشتری از کار ادغام نیاز دارد.
SDV Core برای یک سیستم توزیعشده محلی طراحی شده است، برای مثال، فرض میکند که چندین نمونه از SDV Core (یا مشتقات آن) در کنار یکدیگر یا روی یک تراشه یا در چندین سیستم اجرا میشوند و میتوانند از طریق اتصال شبکه با هم ارتباط برقرار کنند. بنابراین، یکی از جنبههای اصلی معماری سیستم، پیادهسازی عملکرد به عنوان سرویسهایی است که میتوانند روی هر یک از نمونهها میزبانی شوند.
هسته SDV حداقل مجموعه قابلیتها برای توسعه قابلیتهای درون خودرو است. یک سرویس معمولی چند سیگنال دریافت میکند، آنها را پردازش میکند و نتیجه را با سایر سرویسها به اشتراک میگذارد. این محدودیت دامنه عمدی است زیرا SDV Core را قادر میسازد تا طیف وسیعی از SoCها (سیستم روی تراشه) را که ممکن است حاوی موتورهای پیشرفته نباشند، اجرا کند و در هزینهها صرفهجویی کند.
طراحی دقیق
شکل ۲. معماری دقیق SDV Core.
SDV Core از اندروید مشتق شده است و بنابراین معماری آن سعی دارد تا حد امکان با اندروید هماهنگ باشد. اساساً، این بدان معناست که SDV Core همچنین از GKI، درایورها، HALها و کتابخانههای اصلی اندروید استفاده میکند و اجزای مورد نیاز برای معماری سرویس را نیز به آن اضافه میکند.
در بخشهای بعدی به تفصیل اجزای سیستم را بررسی خواهیم کرد.
محیط میزبان و مجازیسازی
SDV Core با این فرض توسعه داده شده است که در یک محیط مجازی اجرا خواهد شد، و بنابراین، ما فرضیاتی در مورد محیط میزبان در نظر میگیریم:
محیط میزبان یک هایپروایزر را اجرا میکند که از دستگاههای Virtio پشتیبانی میکند. علاوه بر این، هایپروایزر باید اترنت یا vsock، حالتهای برق و دستگاههای بلوک را پیادهسازی کند. علاوه بر این، هایپروایزر باید از اجرای اندروید/لینوکس پشتیبانی کند.
در مورد سختافزار، SDV Core فرض میکند که یک CPU و یک MMU از مجازیسازی سختافزاری پشتیبانی میکنند و سیستم از طریق اترنت متصل است. این سیستم نیازی به داشتن GPU، IPU، CSI، موتورهای رسانهای، نمایشگر یا سایر گذرگاههای ارتباطی خودرو (مانند CAN، LIN) ندارد.
پایه اندروید
هسته SDV مبتنی بر اندروید است، اما سیستم را به عملکردهای ضروری سیستم کاهش میدهد و محیط زمان اجرای SDV را اضافه میکند. این بدان معناست که SDV همچنین از GKI، سرویسهای سیستم بومی (به عنوان مثال، adbd و logd ) و عملکردهای سیستم استفاده میکند، اما شامل JVM و سرویسها یا برنامههای سیستمی مبتنی بر JVM و همچنین ویژگیهای پیادهسازی شده برای JVM نمیشود.
این همچنین به این معنی است که SDV استراتژی بهروزرسانی و طرحبندی پارتیشن اندروید را تطبیق خواهد داد. الزامات امنیتی مشابهی دارد، اما رابط کاربری گرافیکی (GUI) ندارد.
GKI، درایورها و HAL
کاربران SDV Core کرنل GKI اندروید را با کرنل اندروید ۶.۱ استفاده میکنند. مزیت استفاده از GKI این است که تغییرات اعمال شده در بالادست در نهایت در اندروید اعمال میشوند. علاوه بر این، اندروید از یک کرنل در سراسر ناوگان خود استفاده میکند. به عنوان مثال، پچها به جای اعمال روی کرنلهای چندین فروشنده، به صورت مرکزی اعمال میشوند.
این همچنین به SDV اجازه میدهد تا یک رابط هسته پایدار داشته باشد. برای مثال، میتوانید درایورها را به عنوان ماژولهایی کامپایل کنید که با GKI کار میکنند، حتی زمانی که یک هسته جدید با رفع مشکلات امنیتی، سیستم عامل را پیادهسازی کرده باشد.
هسته GKI یک جدول زمانی ثابت دارد، تغییرات فروشنده که باید بخشی از هسته بعدی GKI شوند، باید تا پایان سال به هسته لینوکس منتقل شوند.
با GKI، درایورهای دستگاه و ماژولهای غیر ضروری برای بوت شدن، به عنوان ماژولهای هسته کامپایل میشوند و در یک ramdisk که در طول بوت اولیه بارگذاری میشود، قرار میگیرند. پیکربندیهای بسیار اولیه دستگاه که نمیتوانند منتظر رابط ماژول هسته بمانند (مثلاً مقداردهی اولیه تصادفی) باید در درخت دستگاه انجام شوند. ماژولهای هسته نیازی به upstream شدن ندارند، اما باید در برابر رابطهای GKI کامپایل شوند.
از آنجا که SDV Core فرض میکند که بر روی یک هایپروایزر سازگار با Virtio ساخته شده است، درایورها در صورت پشتیبانی از این ویژگی، به عنوان ماژولهای هسته Virtio یا به عنوان یک استاندارد باز دیگر (به عنوان مثال، Open Profile برای DICE و درایور هسته open-dice برای اعتماد) ارائه میشوند.
این ترکیب Virtio (و استانداردهای باز) و یک hypervisor منجر به انتزاع سختافزار میشود. بنابراین، نیاز به HAL ها در SDV حداقل است، اما به دلیل عدم پشتیبانی Virtio، برخی از آنها هنوز مورد نیاز هستند. به عنوان مثال، KeyMint HAL برای رمزنگاری با پشتیبانی سختافزار و IRemotelyPrivisionedComponent HAL که ارتباط نزدیکی با آن دارد، برای تأیید اعتبار بین ماشینهای مجازی SDV.
پشته شبکه و ارتباطات
شکل 3. پشته شبکهسازی و ارتباطات هستهای SDV.
برای شبکهسازی، SDV Core فرض میکند که یا vsock یا Ethernet برای ارتباط بین ماشینهای مجازی در دسترس هستند، ارتباط داخلی ماشینهای مجازی همچنین میتواند از مکانیسمهای IPC مانند binder استفاده کند.
SDV فقط برای اهداف اشکالزدایی از ارتباط سریال پشتیبانی میکند.
شکل ۴. پشتیبانی سریال SDV Core برای اشکالزدایی
SDV در یک مهمان واحد، گزینههای متعددی را ارائه میدهد که به مدل ارتباطی و الزامات عملکرد بستگی دارد.
وساک
Vsock کانال ترجیحی برای ارتباط محلی بین چندین ماشین مجازی یا میزبان و ماشین مجازی است. ماشینهای مجازی باید از ارتباط مستقیم vsock بین یکدیگر استفاده کنند تا پیادهسازی بتواند تعداد کپیها را بهینه کند.
حافظه مشترک
حافظه مشترک فقط برای ارتباط با یک ماشین مجازی برای IPC (ارتباط بین فرآیندی) استفاده میشود، اما به عنوان یک کانال معمولی برای ارتباط بین چندین ماشین مجازی ارائه نمیشود. میزبان ممکن است از حافظه مشترک برای اشتراک اطلاعات با مهمان استفاده کند، اما برای ترافیک شبکه با فرکانس بالا برنامهریزی نشده است.
اترنت
اترنت برای ارتباط بین چندین SoC، یعنی برای ارتباطات درون خودرو، استفاده خواهد شد. این میتواند سیستمهای مجازی، سیستمهای بومی یا ECU های قدیمی باشد.
شبکه وسایل نقلیه به اندازه کافی کوچک است که فضای آدرس IPv4 برای شناسایی همه سیستمهای موجود کافی باشد. با این وجود، برای اطمینان از سازگاری سیستم با آپلینکهای بالقوه و توسعههای آینده، باید از IPv4 و IPv6 پشتیبانی شود.
ویلن
VLAN مکانیزمی برای ایجاد معماریهای شبکه مجازی است که امکان جداسازی زیرشبکههای مختلف و تشکیل شبکههای محلی را فراهم میکند. این میتواند برای ایجاد مناطق امنیتی مختلف مورد استفاده قرار گیرد و برای این منظور در خودروها استفاده میشود. پشتیبانی از VLAN الزامی است.
پروتکلها
TCP و UDP
بسته به مورد استفاده، سیستم به یک پروتکل ارتباطی قابل اعتماد یا غیرقابل اعتماد اما سریع نیاز دارد. بنابراین، TCP و UDP پشتیبانی خواهند شد.
تونل داده
تونل داده یک مکانیزم ارتباطی جدید برای SDV است که یک کانال ارتباطی سریع با پیروی از مدل pubsub ارائه میدهد، به عنوان مثال یک برنامه یک موضوع را منتشر میکند در حالی که یک یا چند برنامه میتوانند به آن گوش دهند. در داخل، یا از حافظه مشترک و FMQ (صفهای پیام سریع) در داخل VM استفاده میکند، یا از vsock یا Ethernet برای ارتباط بین VMها استفاده میکند.
(SDV) RPC
SDV RPC فراخوانیهای رویه از راه دور را برای SDV leveraged binder پیادهسازی میکند. این پروتکل از یک API از پیش تعریف شده برای فراخوانی یک رویه از راه دور استفاده میکند. مشابه Data Tunnel، این پروتکل یا از حافظه مشترک برای ارتباط درون ماشین مجازی یا از vsock یا Ethernet برای ارتباط بین ماشینهای مجازی استفاده میکند.
چارچوبها
سامآیپی
SOMEIP برای ارتباط با سیستمهای غیر SDV استفاده میشود. این پروتکل بر پایه TCP و UDP ساخته شده است و به سختافزار یا درایور خاصی نیاز ندارد. گوگل یک مرجع برای آن پیادهسازی خواهد کرد.
عامل کشف سرویس (عامل SD)
این سرویس، کشف سرویس، احراز هویت و مجوز را برای SDV فراهم میکند. برای ارتباط، ممکن است از هر یک از روشهای ذکر شده قبلی استفاده کند. برای احراز هویت و مجوز، نماینده SD به دسترسی به سختافزار امنیتی و یک زنجیره اعتماد کاری نیاز دارد.
میانافزار
SDV چارچوبی را برای سادهسازی استفاده از تمام آن پروتکلهای مختلف به نام میانافزار توسعه میدهد. همچنین یک منبع حقیقت برای همه سیگنالهای خودرو با زبان جدید VSIDL پیادهسازی میکند.
منطقه خنثی
برای ایزوله کردن بخشهایی از سیستم به منظور جلوگیری از حملات از سوی بخشهای کماعتمادتر سیستم (مثلاً IVI با برنامههای نصبشده سفارشی)، شبکه ممکن است مناطق مختلفی از جمله مناطق غیرنظامی را معرفی کند. در عمل، این بدان معناست که زیرشبکهها از نظر فیزیکی یا منطقی از هم جدا هستند و فقط ترافیک مجاز میتوانند از آن مرزها عبور کنند.
مدیر اتصال
در اندروید، محدود کردن تعداد برنامهها و سرویسهایی که میتوانند خودشان اتصالات سوکت را باز کنند، یک رویه رایج است. در عوض، یک نمونه مرکزی مسئول باز کردن و مدیریت اتصالات است. از آنجایی که اندروید این قابلیت را در یک سرویس جاوا پیادهسازی میکند، SDV مدیر اتصال خود را خواهد ساخت.
قابلیت بهروزرسانی
یکی از ویژگیهای کلیدی SDV قابلیت بهروزرسانی است. ویژگیهای جدید را میتوان در طول عمر SDV از طریق بهروزرسانیهای سیستم اندروید و بستههای APEX نصب کرد.
بهروزرسانیهای سیستم اندروید
اندروید از قبل مکانیزمی برای نصب بهروزرسانیها ارائه میدهد. در نسخههای اخیر از بهروزرسانیهای A/B و A/B مجازی استفاده میکند و SDV Core از این مکانیزم بهره خواهد برد. بهروزرسانیهای A/B هر پارتیشن را دو بار ایجاد میکنند که دو مزیت دارد: سیستم میتواند در پسزمینه بهروزرسانی شود و اگر بهروزرسانی با شکست مواجه شود، سیستم میتواند به آخرین نسخه شناخته شده برای کار بازگردد.
بستههای APEX
اندروید علاوه بر تقسیم سیستم به چندین پارتیشن و قابل بهروزرسانی کردن آنها، بستههای APEX را نیز ارائه میدهد، مکانیزمی برای قرار دادن برنامهها و کتابخانهها در بستههای کوچک که میتوانند مستقل از بهروزرسانیهای سیستم نصب و بهروزرسانی شوند.
SDV Core از کانتینرهای APEX برای نصب پویای سرویسها بر روی یک نمونه SDV استفاده میکند، و همچنین برای مدیریت استقرار چندین سرویس در یک فرآیند واحد: فقط سرویسهایی که در یک APEX یکسان قرار دارند و از یک گواهی یکسان استفاده میکنند، میتوانند در یک فایل باینری یکسان مستقر شوند تا خطرات امنیتی کاهش یابد.
مکانیزم اندروید برای نصب بستههای APEX از برخی کدهای جاوا برای مدیریت APK به منظور تأیید بستهها استفاده میکند. SDV Core باید یک جایگزین بومی پیادهسازی کند تا امکان نصب پویای بستههای APEX را فراهم کند.
مدیریت بهروزرسانی
نمونههای SDV واحدهای کاملاً مستقلی در خودرو نیستند و نیاز به هماهنگی با سایر نمونههای SDV و سرویسهای خودرو دارند. به عنوان مثال، برای نصب وابستگیهای سرویس یا اطمینان از اینکه بهروزرسانیها فقط در حالت سیستم امن نصب میشوند.
SDV استفاده از پارتیشنها در چندین ماشین مجازی را در نظر میگیرد. این امر مستلزم هماهنگی بین آن ماشینهای مجازی است، زیرا آنها وابستگی دادهای به یکدیگر دارند: باید یک ماشین مجازی اصلی برای بهروزرسانی آن پارتیشنها وجود داشته باشد و مکانیزمی برای اطلاعرسانی به سایر ماشینهای مجازی در مورد پارتیشن بهروزرسانیشده و همگامسازی برای بهروزرسانی همزمان همه ماشینهای مجازی وجود داشته باشد تا اطمینان حاصل شود که وضعیت کاری شناختهشده قبلی خراب نمیشود.
شروع به کار
راهنمای شروع به کار ما جزئیاتی در مورد کد منبع، ساخت و راهاندازی با Cuttlefish ارائه میدهد.