معماری منطقی

AAOS SDV یک معماری سرویس‌گرا و داده‌محور ارائه می‌دهد. کاربران از طریق کتابخانه کلاینت میان‌افزار، با کمک زبان تعریف رابط سرویس‌های خودرو (VSIDL)، با سیستم تعامل می‌کنند. این امر جزئیات زیرساخت سطح پایین را پنهان می‌کند و به توسعه‌دهندگان اجازه می‌دهد تا بر ارتباطات سطح بالا و نهادهای استقرار تمرکز کنند.

مدل‌های ارتباطی

ارتباط منطقی در SDV توسط موضوعات و کانال‌ها تعریف می‌شود.

مباحث

موضوعات برای ارتباطات داده‌محور (انتشار/اشتراک) استفاده می‌شوند. کاربران به جای کشف ناشران خاص، با پیام‌های منتشر شده در موضوعات نامگذاری شده تعامل می‌کنند.

  • شناسه: یک موضوع با یک رشته منحصر به فرد شناسایی می‌شود.
  • نوع داده: پیام‌های منتشر شده در یک موضوع با استفاده از protobuf تعریف می‌شوند.
  • جداسازی: مشترکین به نوع پیام و نام موضوع اهمیت می‌دهند، نه هویت یا مکان ناشر. چندین ناشر می‌توانند در یک موضوع واحد مطلب منتشر کنند و ارتباط چند به چند را امکان‌پذیر سازند.

کانال‌ها

کانال‌ها برای ارتباط بر اساس فراخوانی‌های رویه از راه دور (RPC) استفاده می‌شوند. کاربران بدون نیاز به دانستن اینکه کدام سرور درخواست را مدیریت می‌کند، متدهای سرویس را در یک کانال خاص فراخوانی می‌کنند.

  • شناسه: یک کانال با یک نام منحصر به فرد (مثلاً main-control ) شناسایی می‌شود.
  • نوع سرویس: سرویس‌های RPC با نام سرویس protobuf کاملاً واجد شرایط خود شناسایی می‌شوند.
  • انتزاع: میان‌افزار، یافتن نمونه سرور مناسب برای یک سرویس و کانال مشخص را مدیریت می‌کند.

استقرار و چرخه حیات

موجودیت‌های این بخش، نحوه‌ی بسته‌بندی، مجوزدهی و نمونه‌سازی نرم‌افزار در محیط SDV را تعریف می‌کنند.

بسته خدماتی

یک بسته خدماتی، گروهی از منطق‌های تجاری مرتبط است که دو نقش اصلی را ایفا می‌کنند:

  1. واحد استقرار: بسته‌های خدماتی به عنوان بخشی از یک بسته SDV مستقر می‌شوند که یک فایل APEX و کوچکترین واحد قابلیت به‌روزرسانی نرم‌افزار است.
    • هر بسته سرویس به طور منحصر به فرد در زمان اجرا به یک فرآیند لینوکس واحد روی یک ماشین مجازی SDV نگاشت می‌شود و به عنوان یک نمونه بسته سرویس شناخته می‌شود.
    • بسته‌های سرویس در مانیفست بسته SDV ارجاع داده می‌شوند که شامل فراداده‌هایی از جمله نام و سیاست‌های مجوزدهی است.
  2. واحد مجوز: مجوزها به کل بسته خدمات اعطا می‌شوند. یک بسته خدمات برای موارد زیر مجاز است:
    • انتشار یا اشتراک در موضوعات خاص (برای یک نوع پیام مشخص).
    • به کانال‌های خاصی (برای یک نوع سرویس مشخص) خدمات ارائه دهید یا با آنها تماس بگیرید.

نمونه بسته خدمات

یک نمونه بسته سرویس، نمونه‌ای از یک بسته سرویس است که در زمان اجرا بارگذاری می‌شود.

  • هر نمونه بسته خدماتی به صورت جداگانه توسط مدیر چرخه عمر SDV (LCM) ردیابی و شناسایی می‌شود.
  • شروع نمونه‌های بسته‌ی سرویس توسط SDV Orchestrator آغاز شده و توسط SDV LCM آغاز و ردیابی می‌شود.

بسته SDV

یک بسته SDV کوچکترین واحد قابلیت به‌روزرسانی نرم‌افزار است و:

  • یک فایل اندروید پونی اکسپرس (APEX) .
  • شامل یک یا چند بسته خدماتی است.
  • به طور همزمان به‌روزرسانی می‌شود، به این معنی که تمام بسته‌های خدماتی در یک بسته SDV به طور همزمان به‌روزرسانی می‌شوند.

تمام کدهای موجود در یک بسته SDV از یک منبع اعتماد (یک ناشر نرم‌افزار) می‌آیند.

نسخه‌های مختلفی از یک بسته SDV یکسان می‌توانند در ماشین‌های مجازی SDV مختلف وجود داشته باشند.

جزئیات پیاده‌سازی

بخش‌های زیر جزئیات پیاده‌سازی لایه انتقال SDV را شرح می‌دهند.

پیشینه: واحدهای خدماتی

در حالی که توسعه‌دهندگان در درجه اول با موضوعات و کانال‌ها تعامل دارند، واحدهای سرویس همچنان سازوکار اساسی برای ثبت و کشف در پشته ارتباطات SDV هستند.

یک واحد سرویس، یک نقطه پایانی واحد، مانند یک سرور RPC یا یک ناشر را نشان می‌دهد. کتابخانه کلاینت میان‌افزار ( mw::clientlib ) ثبت و کشف این واحدهای سرویس را در پشت صحنه مدیریت می‌کند.