آیا خودرو دیگر با نرم‌افزار تعریف می‌شود؟ معماری دامنه و تحول SDV

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

این صفحه را به اشتراک بگذارید

بله: رفتار، ویژگی‌ها و کاراکتر عملکردی خودروی مدرن اکنون در درجه نخست با نرم‌افزار تعریف می‌شود. این تحول که خودروی نرم‌افزار-محور (SDV) نامیده می‌شود، با انتقال معماری الکترونیکی خودرو از انبوه ECUها به کنترلرهای دامین و زونال، سخت‌افزار را از نرم‌افزار جدا می‌کند و همه چیز را از وزن دسته‌سیم تا به‌روزرسانی‌های OTA بازطراحی می‌کند.

نکات برجسته

  • خودروهای امروزی 100 و بیشتر واحد کنترل می‌توانند داشته باشند؛ معماری‌های جدید هدف دارند این تعداد را تا 20 درصد کاهش دهند.
  • معماری دامین بر اساس عملکرد و معماری زونال بر اساس موقعیت فیزیکی سازمان‌دهی می‌شود.
  • در توپولوژی زونال از ستون‌فقرات‌های پهن‌باند مانند CAN XL (تا 20 مگابیت بر ثانیه) و اترنت گیگابیتی استفاده می‌شود.
  • به‌روزرسانی OTA یک قابلیت بنیادین SDV است که به لطف جدایی سخت‌افزار از نرم‌افزار ممکن شده است.
  • گذار تدریجی است: نخستین حوزه، دامین بدنه (body) است؛ ADAS، پاورترین و شاسی می‌توانند مدت طولانی‌تری در ساختار موجود باقی بمانند.

خودروی نرم‌افزار-محور دقیقاً چیست؟

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

معماری‌های E/E امروزی از 100 واحد کنترل و بیشتر تشکیل شده‌اند؛ ساختارهای نسل جدید تا 20 درصد در تعداد واحدهای کنترل و تا 10 درصد در مواد و سخت‌افزار صرفه‌جویی ایجاد می‌کنند.
Bosch Mobility، ارزیابی معماری E/E

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

از ECUها به معماری دامین: گروه‌بندی بر اساس عملکرد

دوره‌ای که در آن هر عملکرد کوچک خودرو یک واحد کنترل الکترونیکی (ECU) جداگانه داشت، دسته‌سیم‌ها را غیرقابل مدیریت کرد. معماری دامین نخستین پاسخ نظام‌مند به این مسئله بود: الکترونیک خودرو را بر اساس حوزه‌های عملکردی بزرگ مانند ADAS، اینفوتینمنت، انتقال قدرت (پاورترین)، الکترونیک بدنه، شاسی و ایمنی سازمان‌دهی می‌کند. هر دامین معمولاً پردازنده، پشته نرم‌افزاری، رابط ارتباطی، سنسورها و اکچویتورهای خود را دارد و توسط یک کنترلر دامین مدیریت می‌شود.

این ساختار در مقایسه با هرج‌ومرج ECUها ساده‌سازی چشمگیری فراهم کرد. اما با بزرگ‌تر شدن هدف SDV، محدودیت‌های معماری دامین آشکار شد. به‌ویژه داده‌های سنسوری تولیدشده توسط عملکردهای خودران، پهنای باند شبکه‌های کلاسیک CAN را تا مرزهای آن پیش برد. همچنین این که هر دامین منابع پردازشی خود را حمل می‌کرد، دسته‌سیم را پیچیده باقی می‌گذاشت و مقیاس‌پذیری نرم‌افزار در سراسر خودرو را دشوار می‌ساخت.

معماری زونال: سازماندهی از عملکرد به موقعیت مکانی تغییر می‌کند

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

ویژگیمعماری دامنه‌ای (Domain)معماری زونال (Zonal)
اصل سازماندهیبر اساس عملکرد (پاورترین، ADAS، بدنه...)بر اساس موقعیت فیزیکی (جلو چپ، عقب راست...)
منابع پردازشیپردازش اختصاصی دامنه‌ایپردازش مرکزی/توزیع‌شده یکپارچه
سیم‌کشیدسته سیم پیچیده و طولانیکاهش سیم‌کشی و وزن
تعداد ECUتعداد زیاد ECUتعداد کم کنترلر زونال + رایانه مرکزی
انعطاف‌پذیری نرم‌افزاریمقیاس‌پذیری دشوار برای SDVانعطاف‌پذیری نرم‌افزاری بالا

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

کنترلر زونال چه وظیفه‌ای دارد؟ تقسیم وظایف و ارتباط با سخت‌افزار

Zonal mimaride kablolar kısaldıkça araç hafifler, sigortalar yerini yarı iletken anahtarlara bırakır ve güç artık bölge bölge yönetilir.

کلید معماری زونال، کنترلر زونال است که مسئول اتصال تعداد زیادی عملگر و سنسور به ECU پردازش مرکزی می‌باشد. این کنترلر صرفاً یک جعبه جمع‌آوری داده نیست؛ می‌تواند حلقه‌های کنترل بلادرنگ را روی خود اجرا کند، دستگاه‌های ناحیه خود را مدیریت کند و ترافیک فیلترشده و اولویت‌بندی‌شده به ستون فقرات ارسال کند. بر اساس ارزیابی مهندسی Ti، MCU ماژول زونال باید عملکرد بلادرنگ بالا، حافظه گسترده، پشتیبانی از مجازی‌سازی برای سطوح مختلف ASIL، ارتباط پرسرعت با ستون فقرات و تعداد زیادی رابط طرف متصل کم‌هزینه مانند CAN FD و LIN را ارائه دهد.

توزیع توان چگونه غیرمتمرکز می‌شود؟

در معماری دامنه‌ای، توان از جعبه‌های توزیع توان مرکزی حاوی فیوزها و رله‌ها توزیع می‌شود. در ساختار زونال، توزیع غیرمتمرکز می‌شود: یک دسته توان واحد از باتری به ناحیه کشیده می‌شود و ماژول زون توان را بین ماژول‌های آن ناحیه تقسیم می‌کند. کابل‌های توان کوتاه مستقیماً به معنای صرفه‌جویی در وزن و هزینه است. همچنین فیوزها جای خود را به فیوزهای هوشمند نیمه‌هادی می‌دهند؛ کلیدهای سمت بالا با مشخصه I²t، تغییرات کمتر فیوز و مقاطع سیم بهینه‌تر را فراهم می‌کنند. جعبه توزیع توان هوشمند متشکل از MCU، کلیدهای سمت بالا و ترنسیورها، به واحدی تبدیل می‌شود که پیکربندی آن با نرم‌افزار انجام می‌شود: یک جعبه یکسان در هر ناحیه با تطبیق بر اساس بار قابل استفاده است.

جدایی ورودی/خروجی فیزیکی و منطقی

ماژول ناحیه‌ای (Zonal) با تجمیع توابع منطقی ورودی/خروجی چندین ECU در یک نقطه، پیچیدگی سیم‌کشی را کاهش می‌دهد؛ در حالی که موقعیت فیزیکی حسگرها و عملگرها حفظ می‌شود. در گامی فراتر، دستگاه‌های انتهایی «هوشمند» می‌شوند: مدار محلی، اطلاعات وضعیت را نگه می‌دارد و عیب‌یابی را اجرا می‌کند. پروتکل‌های ساده‌شده‌ای مانند CAN FD Light حتی می‌توانند نیاز به یک MCU جداگانه را در برخی گره‌های انتهایی از بین ببرند. این جداسازی که در آن سخت‌افزار ثابت می‌ماند و وظیفه با نرم‌افزار تعریف می‌شود، ستون فقرات مهندسی SDV است.

گذرگاه داده در خودروی ناحیه‌ای: پهنای باند، زمان‌بندی و امنیت سایبری

ادغام حسگرها و بارهای کاری هوش مصنوعی، ناحیه‌بندی توپولوژی را بر اساس ستون‌های فقرات با پهنای باند بالا اجباری می‌کند: PCIe، تا 20 مگابیت بر ثانیه CAN XL با نرخ داده و سازگاری با CAN موجود و اترنت گیگابیتی. چالش اصلی فراتر از پهنای باند، زمان‌بندی است؛ پیام‌های کنترلی کوتاه، داده حسگرهای ADAS و ترافیک سیستم سرگرمی و اطلاعات، نیازمندی‌های تأخیر، جیتر و همگام‌سازی بسیار متفاوتی دارند. معیارهای کلی چنین است: برای صدا هدف تأخیر در حد میلی‌ثانیه و برای انتقال قدرت و کنترل شاسی هدف تأخیر در حد میکروثانیه معتبر است.

برای انتقال این کلاس‌های متفاوت ترافیک در یک شبکه واحد، شبکه‌سازی حساس به زمان (TSN) مبتنی بر اترنت به عنوان راه‌حل مطرح می‌شود. استانداردهایی مانند همگام‌سازی زمان (IEEE 802.1AS)، شکل‌دهی ترافیک حساس به زمان (802.1Qbv)، ترافیک سریع (802.3br)، تصاحب پیش از موعد فریم (802.1Qbu) و افزونگی (802.1CB)، تضمین تأخیر قطعی برای داده‌های حیاتی فراهم می‌کنند. در سمت ایمنی، پشتیبانی از ISO 26262، مسیرهای ارتباطی افزونه، جداسازی ایمنی و تشخیص خطا؛ و در سمت امنیت سایبری، استاندارد ISO/SAE 21434، مقررات UNECE و مکانیسم‌های رمزنگاری-احراز هویت سطح پایین مانند MACsec تعیین‌کننده هستند. از آنجا که معماری ناحیه‌ای شبکه‌ها را متمرکز می‌کند، روش‌های حمله مبتنی بر اترنت نیز قابل اجرا می‌شوند؛ فروپاشی مفهوم جداسازی ورودی/خروجی-پردازش در صورت نقض امنیت، ریسکی است که باید به‌صورت جداگانه ارزیابی شود.

جداسازی سخت‌افزار و نرم‌افزار چگونه به‌روزرسانی OTA را ممکن می‌کند؟

به‌روزرسانی OTA در بیشتر بحث‌های SDV نخستین ویژگی‌ای است که به ذهن می‌رسد، اما به‌تنهایی یک قابلیت نیست؛ بلکه نتیجه یک معماری است. نرم‌افزار بدون آنکه از طریق لایه انتزاع سخت‌افزار (HAL) از تراشه‌های خاص جدا نشود و توابع خودرو بدون تقسیم به خدمات مستقل، قابل استفاده مجدد و با اتصال سست (معماری سرویس‌گرا، SOA) تقسیم نشود، به‌روزرسانی یکپارچه ممکن نیست. این جداسازی شامل ایزوله شدن نرم‌افزارهای با سطوح ایمنی متفاوت از یکدیگر نیز می‌شود.

معنای ملموس آن این است: معماری zone، به‌روزرسانی‌های OTA/FOTA و اتصال دائمی ابری، کنترل نگهداری نرم‌افزار سطح بالا را به خودروساز می‌سپارد و در عین حال می‌تواند حلقه‌های کنترل بلادرنگ را به ماژول‌های zone منتقل کند. تنظیمات ظریفی مانند تقویت توان ماژول‌های استفاده‌نشده در خودروهای برقی نیز در این ساختار آسان‌تر می‌شود. در نهایت، نرم‌افزار خودروی برقی فراتر از یک کانال به‌روزرسانی، لایه تعریف‌کننده‌ای است که ویژگی‌ها، سیستم‌های ایمنی و شخصیت عملکردی خودرو را مشخص می‌کند. خودرو به مرکز داده‌ای توزیع‌شده بر چرخ‌ها شبیه می‌شود؛ زنجیره ارزش بر نرم‌افزار، توان پردازش و معماری سیستم تکیه می‌کند.

این گذار چقدر سریع خواهد بود و آیا معماری زونال به‌تنهایی کافی است؟

این گذار تدریجی خواهد بود. دامین بدنه (body) به دلیل داشتن تعداد زیادی ECU اکتوواتور و حسگر توزیع‌شده، نخستین حوزه‌ای است که به معماری zone مهاجرت می‌کند؛ گذار ADAS، powertrain و کنترل شاسی اما به ماهیت ایمنی-بحرانی خود ممکن است زمان بیشتری بگیرد. تکامل رخ‌داده در لایه‌های MCAL، BSW و کاربردی از سال 2017 نشان می‌دهد که این یک پروژه فنی نیست، بلکه تغییری ذهنیتی در سطح کل صنعت است.

خوانش متعادلی هم لازم است. معماری زونال خودرو را از نظر فیزیکی بازسازماندهی می‌کند؛ سمت منطقی و نرم‌افزاری (SOA، HAL، امنیت سایبری) نیز باید جداگانه حل شود - صرفاً بازآرایی کابل‌ها، خودرو را نرم‌افزار-تعریف‌شده نمی‌کند. برآوردهای اندازه بازار نیز بسته به تعاریف دامنه به‌طور جدی تغییر می‌کنند؛ ارقام متفاوت مربوط به بازار معماری E/E ناشی از آن است که بازار بر اساس اینکه چه چیزهایی (فقط پلتفرم‌های پردازش یا کل الکترونیک توزیع‌شده) شمرده می‌شود، به شیوه‌های متفاوتی اندازه‌گیری می‌شود. همچنین نباید فراموش کرد که نیمه‌هادی‌ها و ارائه‌دهندگان راه‌حل که طرف‌های این گذار هستند، به‌طور طبیعی ذی‌نفع این تحول‌اند.

نتیجه، یک توازن مهندسی روشن است: تعریف خودرو با نرم‌افزار تنها زمانی ممکن است که یک پروژه نرم‌افزاری منفرد نباشد و هم‌زمان یک سازماندهی جدید سخت‌افزاری مبتنی بر کنترلرهای دامین و زون، لایه‌های نرم‌افزاری مجزا، و یک ستون فقرات داده قطعی و ایمن وجود داشته باشد. به‌روزرسانی OTA بارزترین ثمره این ساختار یکپارچه است؛ انقلاب واقعی در آن است که سخت‌افزار خودرو شرح وظایف خود را به نرم‌افزار می‌سپارد.

منابع