لایه انتزاعی پلت فرم HAR

از رندرکننده با قابلیت دسترسی بالا (HAR) برای نمایش اطلاعات خودرو که اندروید نمی‌تواند نمایش دهد استفاده کنید. این امر می‌تواند به دلیل مسائلی مانند راه‌اندازی، در دسترس بودن، ایمنی یا مقررات رخ دهد. HAR یک برنامه قابل حمل و داخلی است که با زبان Rust نوشته شده است.

HAR که به آن چارچوب HAR نیز گفته می‌شود، شامل کدی است که برای ساخت برنامه‌ها استفاده می‌کنید. برنامه‌ای که با HAR ساخته شده است، یک برنامه مبتنی بر HAR است. چارچوب HAR دارای بخش‌های کد برای پلتفرم‌های مختلف است. به عنوان مثال، در یک سیستم لینوکس، از کتابخانه‌هایی مانند tinyalsa برای صداها استفاده می‌کنید. QNX کتابخانه‌های صوتی منحصر به فرد خود را دارد.

یک پلتفرم شامل سخت‌افزار، سیستم عامل، کتابخانه‌های سیستم و سایر عوامل است. کد مختص هر پلتفرم دارای بخش‌هایی به نام زیرسیستم است. هر زیرسیستم یک ویژگی پلتفرم مانند صدا، دوربین‌های EVS یا داده‌های خودرو را مدیریت می‌کند. برای پشتیبانی از یک پلتفرم، چارچوب HAR به پیاده‌سازی تمام زیرسیستم‌های آن نیاز دارد.

کد زیرسیستم مختص پلتفرم ممکن است در همان فرآیندی که برنامه مبتنی بر HAR اجرا می‌شود یا در یک فرآیند جداگانه اجرا شود. وقتی این کد جداگانه باشد، ارتباط بین فرآیندی (IPC) را مدیریت می‌کند تا به تأیید پشتیبانی پلتفرم از برنامه کمک کند. مکانیسم‌های پیچیده IPC باید بخشی از کد مختص پلتفرم باشند.

مجموعه تست HAR تست‌هایی را روی تمام زیرسیستم‌های پیاده‌سازی شده برای یک پلتفرم اجرا می‌کند. از این مجموعه برای بررسی اینکه آیا پلتفرم‌ها الزامات HAR را برآورده می‌کنند و یافتن هرگونه مشکل جدید استفاده کنید.

اصطلاحات

این شرایط در این صفحه آمده است:

برنامه مبتنی بر HAR
یک برنامه OEM یا برنامه‌ای با عملکرد خاص که با چارچوب HAR ساخته شده است. برنامه‌ها از نظر وضعیت برنامه و سایر جنبه‌های قابل تنظیم متفاوت هستند.
چارچوب HAR
مجموعه‌ای از ابزارهای اصلی مورد استفاده برای ساخت برنامه‌ها را ارائه می‌دهد.
انتزاع پلتفرم HAR
بخشی از چارچوب HAR که یک API شناخته‌شده ارائه می‌دهد که همه پلتفرم‌های هدف باید آن را پیاده‌سازی کنند.
مجموعه تست HAR
مجموعه‌ای از آزمایش‌های شناخته‌شده روی پیاده‌سازی‌های پلتفرم، که به تأیید پشتیبانی پیاده‌سازی‌های پلتفرم از چارچوب HAR در یک پلتفرم مشخص کمک می‌کند.

خارج از محدوده

HAR به موارد زیر نمی‌پردازد:

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

  • موارد آزمون: موارد آزمون خاص برای همه رابط‌ها. در عوض، این صفحه توابع فردی برای رابط‌ها از جمله آرگومان‌ها، مقادیر بازگشتی، رفتارهای مورد انتظار و عوارض جانبی مورد انتظار را شرح می‌دهد. این صفحه مجموعه آزمونی را که می‌توانید در آن موارد آزمون را پیاده‌سازی و اجرا کنید، شرح می‌دهد.

انتزاع پلتفرم، ساختار جعبه‌ای سطح بالا

پروژه‌های Rust از جعبه‌ها تشکیل شده‌اند. شکل 1 ساختار جعبه را برای لایه انتزاعی پلتفرم HAR نشان می‌دهد. لایه انتزاعی پلتفرم بر دو یا چند جعبه Rust تأثیر می‌گذارد:

  • انتزاعات (توضیحات trait Rust) در چارچوب HAR قرار دارند.

  • پیاده‌سازی‌ها برای یک پلتفرم توسط یک جعبه جداگانه har-platform-x انجام می‌شود. برای مثال، har-platform-linux یا har-platform-android .

شما نمی‌توانید جعبه HAR را بدون پیاده‌سازی پلتفرم مشخص، بسازید یا آزمایش کنید. این عمدی است زیرا چارچوب HAR یک چارچوب است.

برنامه‌ای که یک پلتفرم را مشخص می‌کند، باید با این چارچوب ساخته شود تا بتواند کار کند و آزمایش شود. ارتباط بین چارچوب HAR و پلتفرم در این نمودار آمده است:

جعبه HAR

شکل ۱. جعبه HAR.

ساختار کلی در ایمنی نمایشگر

این طرح مجموعه‌ای از جعبه‌های جدید را به مخزن display_safety اضافه می‌کند، همانطور که در شکل 2 نشان داده شده است:

جعبه، چارچوب و برنامه HAR

شکل ۲. ماژول‌های انتزاعی.

یک مجموعه تست از نظر ساختاری شبیه به یک برنامه است، اما فقط به یک چارچوب پیاده‌سازی پلتفرم مشخص متکی است. مجموعه تست باید به ویژگی‌ها و ساختارهای تعریف‌شده در چارچوب HAR اشاره کند، اما نباید به پیاده‌سازی‌های پیچیده‌تر اشاره کند.

لایه انتزاع پلتفرم، توضیحات سطح بالا

این جدول زیرسیستم‌های مختص پلتفرم را که توسط لایه انتزاعی پلتفرم HAR تعریف شده‌اند، شرح می‌دهد.

نام انتزاعی عملکرد مرتبط توضیحات یادداشت‌ها
OpenGL رندر دوبعدی قابلیت‌های رندر OpenGLES 2.0/3.0 را برای فریم‌ورک HAR فراهم می‌کند.
Audio رندر صوتی رابط کاربری شبیه به SoundPool اندروید را برای مدیریت و پخش صدای سیستم ارائه می‌دهد.
Camera نمایشگر دوربین خودرو رابط کاربری EVS HAL مانندی برای مدیریت و نمایش اطلاعات دوربین خودرو ارائه می‌دهد.
Looper حلقه اصلی برنامه و پیکربندی صفحه نمایش رابط کاربری شبیه به Looper اندروید را برای مدیریت حلقه‌های اصلی برنامه مختص پلتفرم و پیکربندی نمایش ارائه می‌دهد.
UserInput لمس، صفحه کلید، فرمان یا کنترلر چرخشی و سایر ورودی‌های مخصوص پلتفرم رابطی برای ارائه ورودی لمسی و کیبورد به برنامه‌های مبتنی بر HAR فراهم می‌کند. پیاده‌سازی مرجع مبتنی بر Linux evdev در har-user-input-evdev .
VehicleData ورودی وضعیت خودرو رابطی را برای ارائه جریانی از داده‌های دلخواه خودرو مانند آنچه توسط Android VHAL یا گذرگاه CAN ارائه می‌شود، به برنامه‌های مبتنی بر HAR ارائه می‌دهد.
ResourceManager سند طراحی ذخیره شده مخصوص برنامه یک حافظه پنهان (cache) در حافظه برای منابع لازم برای راه‌اندازی HAR، مانند تصاویر ذخیره‌شده و اسناد طراحی، فراهم می‌کند. هنوز هیچ حافظه پنهان دیسکی پیاده‌سازی نشده است.
Logging ثبت وقایع سیستم و تله‌متری با استفاده از سیستم ردیابی، پشتیبانی از ثبت وقایع مختص پلتفرم را ارائه می‌دهد. این امر امکان جمع‌آوری تله‌متری را در صورت نیاز پلتفرم فراهم می‌کند.
Tracing ردیابی سیستم انتزاعی برای ادغام با سیستم‌های ردیابی و پروفایلینگ فراهم می‌کند.
Monitoring نظارت بر سیستم جعبه ابزاری برای نظارت بر عملکرد و تأخیرها در چارچوب HAR.
Commlib داده‌های خودرو یک پیاده‌سازی مرجع با استفاده از سریال‌سازی protobuf. منسوخ شده: از APIهای تعریف‌شده در reference/harry-control-api و پیاده‌سازی‌های harry-grpcio-server و harry-tonic-server (پیاده‌سازی مرجع) استفاده کنید.
TestSupport تست قلاب‌های پشتیبانی از ساخت و تجزیه موارد تست، تولید رویدادهای تست و ایجاد مصنوعات تست پشتیبانی می‌کند. به عنوان مثال، تولید رویدادهای لمسی شبیه‌سازی شده برای تست UserInput و تولید اسکرین‌شات برای تجزیه و تحلیل. این ویژگی توسط Rust قفل شده است تا از گنجاندن آن در نسخه‌های نهایی جلوگیری شود.

قراردادهای نامگذاری و ساختارهای چارچوب

این جدول این نام‌ها و ساختارها را ارائه می‌دهد:

  • نمونه‌های مورد انتظار trait زیرسیستم که توسط چارچوب HAR ارائه شده‌اند. هر trait نشان‌دهنده یک زیرسیستم خاص پلتفرم است که باید پیاده‌سازی شود.

  • نام‌های مورد انتظار برای پیاده‌سازی زیرسیستم‌های مختص پلتفرم در هر جعبه پلتفرم. برنامه‌های مبتنی بر HAR انتظار دارند که این نام‌های خاص پیاده‌سازی شوند.

  • نمونه‌های enum و struct مرتبط با چارچوب HAR که معمولاً برای انتقال اطلاعات از پیاده‌سازی‌های مرتبط با پلتفرم به چارچوب HAR استفاده می‌شوند.

نام صفات نام‌های پیاده‌سازی enumها و structهای چارچوب HAR
GlContextFactory OpenGL trait harry::Renderer
harry::DisplayRotation
AudioApiFactory Audio harry::AudioApi
harry::AudioDevice
harry::VolumeMillibel
ICameraManager Camera harry::ICameraDevice
harry::CameraDescriptor
Looper Looper harry::LooperMessage
harry::LooperOptions
harry::DisplayId
PlatformVehicleData VehicleData harry::VehicleDataType
harry::VehicleDataListener
ResourceManager (ساختار) ResourceManager harry::ResourceManagerMessage
harry::ResourceToken
harry::RawImageData
PlatformTracing Tracing ناموجود
HarPerformanceMonitor Monitoring harry::Renderer
harry::ResolveLatencyToken
PlatformTestSupport TestSupport harry::TestConfig
harry::TestDisplayConfig

خطاها و مدیریت خطاها

APIهای پیشنهادی از نوع Rust Result<> استفاده می‌کنند. Rust از شما می‌خواهد که انواع Result که حاوی خطا هستند را بررسی کنید. در غیر این صورت، کامپایلر یک هشدار یا خطا ایجاد می‌کند. بررسی زمان ساخت، بررسی خطا را از کد مخصوص پلتفرم اعمال می‌کند.

خطاهایی که توسط پیاده‌سازی‌های پلتفرم برگردانده می‌شوند از نوع harry::error::Error هستند. برای تأیید اینکه انواع خطاهای پلتفرم به کد برنامه نشت نمی‌کنند، از نوع خطای استاندارد ارائه شده توسط چارچوب HAR استفاده کنید.

نوع harry::error::Error گسترش می‌یابد تا خطاهای خاص را برای همه زیرسیستم‌ها در بر بگیرد:

// This is Rust
pub enum Error {
  Msg(String), // A generic message string
  // Legacy error type, likely to be removed or merged into Msg
  Audio(String),
}

خطاهای غیرقابل بازیابی عمدتاً از طریق رابط‌ها و فراخوانی‌های تعریف‌شده بازگردانده می‌شوند.

طراحی دقیق مجموعه تست

این بخش، طراحی مجموعه آزمون را شرح می‌دهد که پیاده‌سازی‌های خاص پلتفرم از انتزاع‌ها را تأیید می‌کند.

ساخت مجموعه تست‌ها

برای نسخه‌های Soong (که توسط فایل‌های Android.bp تعریف شده‌اند)، تست‌ها به عنوان بخشی از سیستم ساخت پلتفرم اندروید کامپایل می‌شوند و اجرای آنها توسط atest مدیریت می‌شود.

اجرای مجموعه تست

برای آزمایش یک پلتفرم خاص:

از دستور atest به همراه هدف تست مربوطه استفاده کنید (برای مثال، atest <module_name> ). این دستور تست‌ها را روی یک دستگاه یا شبیه‌ساز اندروید مستقر و اجرا می‌کند.