فهرست مطالب
- خودرو نرمافزارمحور یا SDV چیست؟ چرا خودروها شبیه گوشی هوشمند می‌شوند؟
- SDV دقیقاً یعنی چه؟
- چرا می‌گویند خودروها شبیه گوشی هوشمند می‌شوند؟
- اما خودرو یک گوشی بزرگ نیست
- خودروهای قدیمی چه معماری الکترونیکی داشتند؟
- در SDV چه چیزی تغییر میکند؟
- معماری Zonal چیست؟
- ECUها کاملاً حذف می‌شوند؟
- نقش Vehicle OS در خودروهای SDV چیست؟
- جداسازی نرمافزار از سختافزار چه فایده‌ای دارد؟
- OTA چیست و چه ارتباطی با SDV دارد؟
- با OTA چه چیزهایی میتواند تغییر کند؟
- آپدیت خودرو چطور ایمن انجام می‌شود؟
- آیا SDV همان خودروی متصل است؟
- آیا SDV همان خودرو برقی است؟
- SDV با خودرو خودران چه تفاوتی دارد؟
- مقایسه خودروی سنتی و SDV
- SDV چه مزایایی برای راننده دارد؟
- دریافت قابلیتهای جدید
- رفع مشکل بدون مراجعه به تعمیرگاه
- بهبود قابلیتها
- شخصی‌سازی بیشتر
- آیا قابلیت خودرو میتواند بعداً خریداری شود؟
- آیا باید برای امکانات خودرو اشتراک پرداخت کنیم؟
- SDV چه مزیتی برای خودروساز دارد؟
- استفاده مجدد از نرمافزار
- توسعه سریع‌تر
- رفع خطا از راه دور
- توسعه خودرو بعد از فروش
- اما SDV چه مشکلات و ریسک‌هایی دارد؟
- 1. امنیت سایبری
- 2. باگ نرمافزاری
- 3. وابستگی بیشتر به سازنده
- 4. پایان پشتیبانی نرمافزاری
- 5. حریم خصوصی
- آیا تمام قابلیتهای SDV به اینترنت نیاز دارند؟
- داخل خودرو
- Cloud
- هوش مصنوعی چه نقشی در SDV دارد؟
- AUTOSAR چه ارتباطی با SDV دارد؟
- آیا خودروهای آینده بدون ECU خواهند بود؟
- یک مثال ساده از تفاوت خودروی معمولی و SDV
- خودرو سنتی
- خودرو SDV
- آیا با آپدیت میتوان هر قابلیتی به خودرو اضافه کرد؟
- خودرو SDV را چگونه تشخیص دهیم؟
- تفاوت Connected Car، SDV، EV و خودروی خودران
- آیا SDV آینده صنعت خودرو است؟
- در نهایت SDV چه تغییری در تعریف خودرو ایجاد میکند؟
خودرو نرمافزارمحور یا SDV چیست؟ چرا خودروها شبیه گوشی هوشمند می‌شوند؟
تا چند سال قبل، قابلیتهای یک خودرو تقریباً هنگام خروج از کارخانه مشخص می‌شدند.
اگر خودرو کروز کنترل نداشت، نمایشگر آن امکانات خاصی نداشت یا سیستم‌های الکترونیکی آن قابلیت مشخصی را پشتیبانی نمی‌کردند، معمولاً برای تغییر جدی باید قطعه‌ای تعویض یا سختافزار جدیدی نصب می‌شد.
اما صنعت خودرو در حال حرکت به سمت مدل متفاوتی است.
در نسل جدید خودروها، بخشی از قابلیتها نه فقط توسط قطعات مکانیکی و الکترونیکی، بلکه توسط نرمافزار تعریف می‌شوند.
به چنین خودروهایی معمولاً:
Software-Defined Vehicle
یا به اختصار:
SDV
گفته می‌شود.
Bosch تعریف SDV را بر جداسازی بیشتر سختافزار از نرمافزار، استفاده از کامپیوترهای مرکزی و کنترلرهای ناحیه‌ای و امکان تغییر قابلیتهای خودرو در طول عمر آن قرار می‌دهد. AUTOSAR نیز تحول صنعت را از طراحی مبتنی بر ECUهای مستقل به سمت معماری‌ها و نرم‌افزارهای قابل توسعه و بهروزرسانی دنبال میکند.
پاسخ سریع: در خودروی SDV، نرمافزار به یکی از اجزای اصلی تعریف‌کننده قابلیتهای خودرو تبدیل می‌شود. خودرو میتواند از طریق معماری پردازشی متمرکزتر، ارتباط شبکه‌ای و بهروزرسانی نرمافزاری، بعضی قابلیتها را حتی بعد از فروش دریافت کند یا بهبود دهد. به همین دلیل تجربه مالکیت آن از بعضی جهات به گوشی هوشمند نزدیک‌تر می‌شود.
SDV دقیقاً یعنی چه؟
برای SDV هنوز یک تعریف واحد و کاملاً یکسان در کل صنعت وجود ندارد.
Qualcomm نیز به نبود یک تعریف واحد اشاره میکند و یکی از ویژگی‌های اصلی SDV را ارائه و تکامل قابلیتها توسط نرمافزار در طول عمر خودرو و بعد از زمان فروش می‌داند.
به زبان ساده:
در یک خودروی سنتی، رابطه تقریباً این‌گونه است:
سختافزار ← قابلیت خودرو
اما در SDV بیشتر به این مدل نزدیک می‌شویم:
سختافزار + پلتفرم نرمافزاری + نرمافزار ← قابلیت خودرو
یعنی سختافزار همچنان بسیار مهم است، اما تعیین نمی‌کند که خودرو تا پایان عمر دقیقاً همان امکانات روز اول را داشته باشد.
چرا می‌گویند خودروها شبیه گوشی هوشمند می‌شوند؟
این مقایسه از یک جهت منطقی است.
وقتی یک گوشی جدید می‌خرید، سختافزار دستگاه از روز اول تقریباً ثابت است.
اما در ماه‌ها و سال‌های بعد ممکن است:
- سیستمعامل آپدیت شود
- قابلیت جدید اضافه شود
- رابط کاربری تغییر کند
- مشکلات نرمافزاری برطرف شوند
- امنیت دستگاه بهبود پیدا کند
- عملکرد بعضی قابلیتها بهتر شود
خودروهای نرمافزارمحور نیز می‌خواهند بخشی از همین الگو را وارد صنعت خودرو کنند.
یعنی خودرو بعد از خروج از کارخانه الزاماً یک محصول «تمام‌شده و بدون تغییر» نباشد.
اما خودرو یک گوشی بزرگ نیست
این قسمت بسیار مهم است.
شباهت SDV و گوشی بیشتر در مدل نرمافزاری و بهروزرسانی است، نه در سطح مسئولیت.
خرابی یک برنامه گوشی معمولاً نهایتاً باعث بسته شدن برنامه یا ری‌استارت دستگاه می‌شود.
اما نرمافزار خودرو ممکن است با سیستم‌هایی مانند:
- ترمز
- فرمان
- قوای محرکه
- سیستم‌های کمک‌راننده
- مدیریت باتری
- ایربگ
- سیستم‌های ایمنی
ارتباط داشته باشد.
به همین دلیل توسعه و بهروزرسانی نرمافزار خودرو نیازمند الزامات بسیار سخت‌گیرانه‌تری در زمینه ایمنی، امنیت سایبری و مدیریت بهروزرسانی است.
برای نمونه، مقررات UN R156 چارچوب مشخصی برای مدیریت بهروزرسانی نرمافزار خودرو تعیین میکند و شامل موضوعاتی مانند بررسی سازگاری، حفظ ایمنی هنگام آپدیت و مدیریت شکست احتمالی بهروزرسانی است.
خودروهای قدیمی چه معماری الکترونیکی داشتند؟
برای فهم SDV ابتدا باید معماری خودروهای متداول را بشناسیم.
با اضافه شدن تجهیزات الکترونیکی به خودروها، برای هر وظیفه یا مجموعه‌ای از وظایف واحدهای کنترل الکترونیکی مختلفی ایجاد شد.
این واحدها همان ECU یا Electronic Control Unit هستند.
مثلاً ممکن است خودرو ECU یا ماژول جداگانه‌ای برای موارد زیر داشته باشد:
- موتور
- گیربکس
- ABS
- ایربگ
- بدنه
- تهویه
- صندلی
- سیستم اطلاعات و سرگرمی
- سنسورهای پارک
- دوربین
- ADAS
در خودروهای پیچیده، تعداد این کنترلرها میتواند بسیار زیاد شود.
UNECE در توضیح تحول خودروهای متصل اشاره کرده بود که خودروهای مدرن می‌توانند تا حدود 150 ECU و حدود 100 میلیون خط کد نرمافزاری داشته باشند.
مشکل چیست؟
هرچه تعداد کنترلرهای مستقل بیشتر شود:
- ارتباط بین آنها پیچیده‌تر می‌شود
- سیم‌کشی افزایش می‌یابد
- توسعه نرمافزار دشوارتر می‌شود
- تست و نگهداری پیچیده‌تر می‌شود
- بهروزرسانی قابلیتهای مختلف سخت‌تر می‌شود
SDV یکی از پاسخ‌های صنعت خودرو به همین پیچیدگی است.
در SDV چه چیزی تغییر میکند؟
یکی از مهم‌ترین تغییرات، حرکت از تعداد زیادی ECU مستقل به سمت پردازش متمرکزتر است.
یعنی به‌جای اینکه برای هر وظیفه یک کامپیوتر نسبتاً مستقل داشته باشیم، تعدادی کامپیوتر قدرتمندتر می‌توانند چندین عملکرد را مدیریت کنند.
Bosch این روند را حرکت به سمت Central Vehicle Computers و Zone Controllers توصیف میکند.
Continental نیز یک نمونه عملی از High-Performance Computer چنددامنه‌ای را در خودرو پیاده‌سازی کرده که میتواند وظایفی از کابین تا برخی قابلیتهای رانندگی و کنترل حرکت را روی پلتفرمی متمرکزتر اجرا کند.
معماری Zonal چیست؟
یکی از اصطلاحاتی که همراه SDV زیاد دیده می‌شود، Zonal Architecture است.
در معماری سنتی، ECUها بیشتر براساس وظیفه تقسیم می‌شوند.
برای مثال:
- ECU موتور
- ECU بدنه
- ECU ترمز
- ECU سیستم سرگرمی
اما در معماری Zonal، بخشی از تجهیزات براساس موقعیت فیزیکی آنها در خودرو به کنترلرهای ناحیه‌ای متصل می‌شوند.
مثلاً ممکن است خودرو نواحی:
- جلو چپ
- جلو راست
- عقب چپ
- عقب راست
داشته باشد.
سنسورها و تجهیزات هر بخش ابتدا به Zone Controller آن ناحیه متصل می‌شوند و سپس کنترلرها با کامپیوتر مرکزی ارتباط دارند.
مدل ساده‌شده:
سنسورها و عملگرها
↓
Zone Controller
↓
کامپیوتر مرکزی
↓
نرمافزار و سرویسهای خودرو
این معماری میتواند به ساده‌تر شدن طراحی شبکه و فراهم شدن بستری مناسب‌تر برای نرم‌افزارهای قابل توسعه کمک کند.
ECUها کاملاً حذف می‌شوند؟
نه.
این برداشت که «SDV یعنی حذف همه ECUها و وجود یک کامپیوتر واحد» دقیق نیست.
خودرو همچنان دارای:
- کنترلرها
- میکروکنترلرها
- سنسورها
- عملگرها
- ماژول‌های ایمنی
خواهد بود.
تغییر اصلی در نحوه توزیع پردازش و معماری نرمافزار است.
برخی وظایف متمرکز می‌شوند، برخی روی Zone Controllerها باقی می‌مانند و بعضی عملکردهای بسیار حساس ممکن است همچنان کنترلرهای اختصاصی خود را داشته باشند.
نقش Vehicle OS در خودروهای SDV چیست؟
اصطلاح دیگری که زیاد شنیده می‌شود:
Vehicle OS
یا «سیستمعامل خودرو» است.
اما Vehicle OS الزاماً یک سیستمعامل واحد شبیه Windows یا Android نیست که همه چیز خودرو را مستقیماً کنترل کند.
در عمل ممکن است شامل چند لایه باشد:
Application Layer قابلیت‌هایی که راننده یا سایر سیستم‌ها استفاده می‌کنند.
Middleware لایه‌ای برای ارتباط بین نرم‌افزارها و سرویس‌ها.
Operating System
Hardware Abstraction
ECU / HPC / Controllers
Sensors & Actuators
یکی از اهداف این معماری این است که نرمافزار تا جای ممکن از جزئیات سختافزار جدا شود.
جداسازی نرمافزار از سختافزار چه فایده‌ای دارد؟
فرض کنید یک قابلیت خودرو مستقیماً برای یک ECU خاص نوشته شده باشد.
اگر سختافزار تغییر کند، ممکن است بخش بزرگی از نرمافزار هم نیازمند تغییر باشد.
اما با لایه‌های استانداردشده میتوان ارتباط میان نرمافزار و سختافزار را کمتر وابسته کرد.
در دنیای برنامه‌نویسی میتوان آن را تقریباً شبیه این تصور کرد:
به‌جای اینکه هر برنامه مستقیماً با سختافزار صحبت کند، از:
API + Middleware + Platform
استفاده میکند.
AUTOSAR دقیقاً در همین حوزه روی استانداردسازی رابط‌ها، پلتفرم‌های نرمافزاری و انتقال‌پذیری قابلیتها فعالیت میکند. این سازمان هدف خود را افزایش امکان توسعه، بهروزرسانی و انتقال قابلیتهای نرمافزاری در معماری خودرو اعلام کرده است.
OTA چیست و چه ارتباطی با SDV دارد؟
یکی از مهم‌ترین قابلیتهای SDV:
OTA = Over-the-Air Update
است.
یعنی نرمافزار خودرو بدون مراجعه مستقیم به تعمیرگاه یا اتصال فیزیکی دستگاه برنامهریزی، از طریق شبکه دریافت و نصب شود.
تقریباً مشابه آپدیتی که برای تلفن همراه دریافت می‌کنید.
با OTA چه چیزهایی میتواند تغییر کند؟
بسته به طراحی خودرو، OTA میتواند برای موارد مختلف استفاده شود؛ مثلاً:
- رفع باگ نرمافزاری
- بهبود رابط کاربری
- بهروزرسانی سیستم اطلاعات و سرگرمی
- بهبود مدیریت انرژی
- آپدیت نقشه
- اصلاح عملکرد بعضی سیستم‌ها
- بهبود برخی قابلیتهای کمک‌راننده
- بهروزرسانی امنیتی
اما اینکه هر خودرو دقیقاً چه چیزی را OTA آپدیت کند به معماری و سیاست سازنده بستگی دارد.
وجود نمایشگر بزرگ یا اتصال اینترنت به تنهایی خودرو را SDV نمی‌کند.
آپدیت خودرو چطور ایمن انجام می‌شود؟
اینجا تفاوت گوشی با خودرو دوباره مشخص می‌شود.
تصور کنید نرمافزار مربوط به یک سیستم مهم خودرو در حین آپدیت خراب شود.
این موضوع نمی‌تواند مثل خراب شدن یک اپلیکیشن ساده مدیریت شود.
در مقررات UN R156 برای بهروزرسانی OTA موضوعاتی مانند موارد زیر مطرح شده‌اند:
- بررسی سازگار بودن خودرو با آپدیت
- حفظ اصالت و یکپارچگی فایل
- تشخیص نرمافزار نصب‌شده
- اطلاع‌رسانی به مالک
- ایمن بودن شرایط نصب
- وجود شرایط کافی مانند توان الکتریکی مناسب
- مدیریت شکست آپدیت
یعنی OTA در صنعت خودرو باید فرآیند مهندسی‌شده و کنترل‌شده باشد.
آیا SDV همان خودروی متصل است؟
خیر.
دو مفهوم به هم مرتبط‌اند، اما یکسان نیستند.
Connected Car یعنی خودرویی که میتواند با شبکه، سرور، گوشی یا سرویسهای دیگر ارتباط داشته باشد.
اما SDV مفهوم گسترده‌تری دارد.
ممکن است یک خودرو اینترنت داشته باشد و اطلاعات ترافیک یا موسیقی آنلاین دریافت کند، اما معماری اصلی قابلیتهای آن همچنان سخت‌افزارمحور باشد.
بنابراین:
اتصال به اینترنت ≠ SDV
ولی Connectivity یکی از اجزای بسیار مهم اکوسیستم SDV است.
نرمافزارمحور بودن ارتباط مستقیمی با نوع قوای محرکه ندارد؛ یک خودروی برقی، هیبریدی یا حتی خودروی EREV با سیستم بردافزا میتواند از معماری SDV استفاده کند.
آیا SDV همان خودرو برقی است؟
خیر.
SDV به معماری نرمافزار و الکترونیک خودرو مربوط است.
EV به نوع قوای محرکه مربوط می‌شود.
از نظر تئوری یک خودرو میتواند:
- بنزینی و SDV باشد
- هیبریدی و SDV باشد
- EREV و SDV باشد
- برقی و SDV باشد
البته خودروهای برقی جدید بستر مناسبی برای توسعه معماری‌های نرمافزارمحور هستند؛ چون بسیاری از آنها از ابتدا با معماری الکترونیکی جدید طراحی می‌شوند.
برقی بودن خودرو نیز به‌تنهایی آن را SDV نمی‌کند؛ حتی یک پروژه برقی میتواند از معماری الکترونیکی نسبتاً سنتی استفاده کند. نمونه‌ای از پروژه‌های داخلی را در بررسی پراید برقی توضیح داده‌ایم.
SDV با خودرو خودران چه تفاوتی دارد؟
این دو نیز یکی نیستند.
SDV: درباره معماری نرمافزارمحور خودرو است.
Autonomous Vehicle: درباره میزان توانایی خودرو برای انجام وظایف رانندگی بدون دخالت انسان است.
یک خودرو میتواند SDV باشد ولی کاملاً خودران نباشد.
در مقابل، توسعه سیستم‌های پیشرفته ADAS و خودران به توان پردازشی و معماری نرمافزاری قدرتمند نیاز دارد؛ بنابراین این دو فناوری ارتباط نزدیکی پیدا می‌کنند.
مقایسه خودروی سنتی و SDV
| ویژگی | خودروی سنتی | خودروی SDV |
|---|---|---|
| مرکز اصلی قابلیتها | سختافزار + ECUهای متعدد | نرمافزار + سختافزار قابل‌برنامه‌ریزی |
| معماری پردازشی | تعداد زیادی ECU مستقل | پردازش متمرکزتر و Zonal |
| افزودن قابلیت بعد از فروش | محدود | در برخی موارد امکان‌پذیر |
| OTA | محدود یا وجود ندارد |
SDV چه مزایایی برای راننده دارد؟
مزایای واقعی SDV زمانی مشخص می‌شوند که نرمافزار خودرو پس از فروش هم قابل توسعه باشد.
دریافت قابلیتهای جدید
در بعضی خودروها ممکن است بدون تغییر فیزیکی سختافزار، قابلیت جدیدی از طریق نرمافزار فعال شود.
البته فقط در صورتی که سختافزار لازم از ابتدا روی خودرو وجود داشته باشد.
رفع مشکل بدون مراجعه به تعمیرگاه
اگر ایراد صرفاً نرمافزاری باشد، OTA میتواند در برخی موارد مراجعه فیزیکی برای برنامهریزی ECU را حذف کند.
بهبود قابلیتها
نرمافزار یک سیستم ممکن است طی زمان بهینه شود.
مثلاً:
- مدیریت انرژی
- رابط کاربری
- پاسخ سیستم
- عملکرد برخی ADASها
میتواند با نسخه‌های بعدی تغییر کند.
شخصی‌سازی بیشتر
Bosch یکی از ظرفیت‌های معماری نرمافزارمحور را تنظیم دقیق‌تر قابلیتها متناسب با راننده می‌داند؛ از تنظیمات کابین تا مدیریت انرژی و رفتار برخی سیستم‌های خودرو.
در آینده ممکن است پروفایل راننده موارد بیشتری را ذخیره کند:
- وضعیت صندلی
- تهویه
- تنظیمات نمایشگر
- حالت رانندگی
- تنظیمات سیستم‌های کمکی
- مسیرها و سرویسهای مورد استفاده
آیا قابلیت خودرو میتواند بعداً خریداری شود؟
از نظر فنی بله؛ SDV بستری را ایجاد میکند که برخی قابلیتهای نرمافزاری بعداً فعال شوند.
فرض کنید سختافزار لازم از ابتدا نصب شده باشد ولی یک قابلیت نرمافزاری غیرفعال باشد.
سازنده میتواند آن را بعداً:
- رایگان
- پولی
- اشتراکی
فعال کند.
اینجا یکی از بحث‌برانگیزترین ابعاد SDV شروع می‌شود.
آیا باید برای امکانات خودرو اشتراک پرداخت کنیم؟
SDV امکان ایجاد مدل‌های درآمدی جدید را فراهم میکند.
اما از نظر کاربر سؤال مهمی ایجاد می‌شود:
اگر سختافزار داخل خودرویی که خریده‌ام نصب شده، آیا باید برای استفاده از آن دوباره پول پرداخت کنم؟
پاسخ فنی مشخصی ندارد و به مدل تجاری سازنده بستگی دارد.
ممکن است بعضی خدمات منطقی باشند، مثل سرویس ابری که دائماً هزینه سرور و ارتباط دارد.
اما دریافت هزینه مستمر برای فعال کردن قابلیت سخت‌افزاری از قبل نصب‌شده، موضوع متفاوتی است.
بنابراین SDV فقط یک تحول فنی نیست؛ مدل مالکیت خودرو را هم میتواند تغییر دهد.
SDV چه مزیتی برای خودروساز دارد؟
مزایا فقط برای راننده نیست.
برای شرکت‌های خودروسازی نیز مزایای بزرگی وجود دارد.
استفاده مجدد از نرمافزار
یک پلتفرم میتواند در چند مدل خودرو استفاده شود.
توسعه سریع‌تر
به‌جای ساخت نرمافزار کاملاً مستقل برای هر ECU و خودرو، بخش بیشتری از پلتفرم قابل استفاده مجدد خواهد بود.
رفع خطا از راه دور
بعضی مشکلات نرمافزاری می‌توانند بدون فراخوان سنتی برطرف شوند.
توسعه خودرو بعد از فروش
رابطه سازنده و خودرو با تحویل خودرو به مشتری پایان نمی‌یابد.
AUTOSAR نیز مقیاس‌پذیری، قابلیت استفاده مجدد، امکان upgrade/update و کاهش پیچیدگی سیستم‌های E/E را از اهداف این تحول می‌داند.
اما SDV چه مشکلات و ریسک‌هایی دارد؟
این فناوری فقط مزیت نیست.
1. امنیت سایبری
وقتی خودرو:
- به اینترنت متصل است
- نرمافزار دانلود میکند
- با Cloud ارتباط دارد
- از API استفاده میکند
سطح حمله دیجیتال هم بزرگ‌تر می‌شود.
به همین دلیل امنیت سایبری دیگر یک قابلیت جانبی نیست.
UN Regulation No. 155 چارچوبی برای مدیریت امنیت سایبری خودرو ایجاد کرده و از خودروسازان می‌خواهد فرآیندی برای شناسایی، مدیریت و پایش تهدیدهای سایبری داشته باشند.
2. باگ نرمافزاری
هرچه نرمافزار بزرگ‌تر شود، احتمال خطا هم بیشتر می‌شود.
اما در خودرو اثر یک باگ میتواند بسیار مهم‌تر از یک باگ موبایل باشد.
به همین دلیل نرم‌افزارهای مرتبط با ایمنی باید تحت فرآیندهای سخت‌گیرانه توسعه و تست شوند.
3. وابستگی بیشتر به سازنده
در خودروی مکانیکی قدیمی، بخش زیادی از تعمیرات مستقل از شرکت سازنده انجام می‌شد.
در SDV موارد بیشتری ممکن است به:
- نرمافزار اختصاصی
- سرور شرکت
- مجوز دیجیتال
- ابزار تشخیصی
- حساب کاربری
وابسته شوند.
این موضوع میتواند بحث حق تعمیر یا Right to Repair را مهم‌تر کند.
4. پایان پشتیبانی نرمافزاری
یک سؤال مهم آینده این است:
خودروی 15 ساله SDV هنوز آپدیت دریافت خواهد کرد؟
گوشی را ممکن است بعد از چند سال تعویض کنیم، ولی عمر خودرو معمولاً بسیار بیشتر است.
اگر شرکت سازنده:
- پشتیبانی را متوقف کند
- سرورها را خاموش کند
- ورشکسته شود
- سرویس خاصی را حذف کند
باید مشخص باشد چه اتفاقی برای قابلیتهای خودرو می‌افتد.
5. حریم خصوصی
خودروی متصل میتواند حجم زیادی از اطلاعات تولید کند.
برای مثال:
- اطلاعات فنی خودرو
- محل حرکت
- شرایط رانندگی
- عملکرد سیستم‌ها
- استفاده از قابلیتها
بنابراین اینکه چه داده‌ای جمع می‌شود، کجا ذخیره می‌شود و چه کسی به آن دسترسی دارد اهمیت بیشتری پیدا میکند.
آیا تمام قابلیتهای SDV به اینترنت نیاز دارند؟
خیر.
این تصور نیز صحیح نیست.
قابلیتهای حیاتی خودرو نباید برای عملکرد لحظه‌ای خود کاملاً به اینترنت وابسته باشند.
برای مثال خودرو نمی‌تواند برای اجرای یک فرمان حساس منتظر پاسخ Cloud بماند.
معماری معمولاً به این شکل است:
داخل خودرو
وظایف:
- Real-time
- Safety Critical
- کنترل سنسورها و عملگرها
Cloud
وظایفی مانند:
- دریافت آپدیت
- تحلیل داده
- مدیریت ناوگان
- توسعه سرویس
- برخی قابلیتهای متصل
یعنی Cloud مکمل سیستم داخل خودرو است، نه جایگزین همه پردازش‌های داخلی.
هوش مصنوعی چه نقشی در SDV دارد؟
در نسل بعدی خودروها، AI قرار است لایه دیگری روی معماری نرمافزارمحور ایجاد کند.
مثلاً:
- دستیار داخل خودرو
- تشخیص راننده
- شخصی‌سازی
- پایش وضعیت خودرو
- تحلیل محیط
- ADAS
- مدیریت هوشمند انرژی
در 2026 حتی اصطلاح AI-Defined Vehicle یا AIDV بیشتر مطرح شده است. Qualcomm آن را مرحله‌ای می‌داند که قابلیتها و تعامل خودرو بیش از گذشته توسط مدل‌های AI و پردازش داده شکل می‌گیرند؛ AUTOSAR نیز در کنفرانس 2026 خود SDV و AIDV را در کنار معماری چنددامنه‌ای و توسعه Adaptive Platform بررسی کرده است.
اما AIDV جایگزین فوری SDV نیست.
بلکه میتوان آن را تقریباً چنین دید:
Connected Vehicle
↓
Software-Defined Vehicle
↓
AI-Enhanced / AI-Defined Vehicle
AUTOSAR چه ارتباطی با SDV دارد؟
اگر درباره خودرو نرمافزارمحور تحقیق کنید، احتمال زیادی دارد که نام AUTOSAR را ببینید.
AUTOSAR مخفف:
AUTomotive Open System ARchitecture
است.
این مجموعه از سال 2003 با مشارکت شرکت‌های صنعت خودرو، الکترونیک و نرمافزار روی استانداردهای معماری نرمافزاری خودرو کار میکند.
دو مفهوم شناخته‌شده آن:
AUTOSAR Classic Platform
و
AUTOSAR Adaptive Platform
هستند.
Adaptive Platform برای بخشی از کاربردهای نسل جدید با پردازش قدرتمندتر و معماری سرویس‌محور اهمیت زیادی دارد.
در 2026 نیز AUTOSAR پروژه CAPI یا Common Adaptive Platform Implementation را به‌عنوان پیاده‌سازی کدمحور Adaptive Platform و پایه‌ای برای توسعه SDV پیش برده است.
آیا خودروهای آینده بدون ECU خواهند بود؟
خیر.
اما احتمالاً شکل معماری تغییر میکند.
مسیر کلی را میتوان تقریباً چنین خلاصه کرد:
ECUهای متعدد مستقل
↓
Domain Controllers
↓
Zonal Controllers + High Performance Computers
↓
Centralized Computing Architecture
هدف، حذف کامل کنترلرها نیست.
هدف این است که تعداد بیشتری از قابلیتها روی زیرساخت مشترک اجرا شوند و نرمافزار امکان توسعه بیشتری پیدا کند.
یک مثال ساده از تفاوت خودروی معمولی و SDV
فرض کنید دو خودرو سیستم دوربین 360 درجه دارند.
خودرو سنتی
قابلیت دوربین به یک ECU مشخص و نرمافزار همان ماژول وابسته است.
بعد از فروش خودرو قابلیت آن تقریباً ثابت می‌ماند.
خودرو SDV
دوربین‌ها بخشی از پلتفرم گسترده‌تری هستند.
داده دوربین ممکن است در یک کامپیوتر قدرتمند پردازش شود.
بعداً یک آپدیت نرمافزاری میتواند مثلاً:
- رابط نمایش تصویر را تغییر دهد
- الگوریتم تشخیص مانع را بهبود دهد
- قابلیت جدیدی برای پارک اضافه کند
البته فقط در محدوده‌ای که سختافزار و الزامات ایمنی اجازه دهند.
اینجاست که معنی Software-Defined Vehicle روشن‌تر می‌شود.
آیا با آپدیت میتوان هر قابلیتی به خودرو اضافه کرد؟
خیر.
این یکی از بزرگ‌ترین سوءبرداشت‌ها درباره SDV است.
نرمافزار نمی‌تواند محدودیت فیزیکی سختافزار را حذف کند.
اگر خودرو:
- رادار ندارد
- دوربین مناسب ندارد
- موتور صندلی ندارد
- سنسور لازم ندارد
- سختافزار پردازشی کافی ندارد
با یک آپدیت ساده نمی‌توان آن قابلیت را ایجاد کرد.
پس:
SDV یعنی استفاده منعطف‌تر از سختافزار، نه حذف نیاز به سختافزار.
خودرو SDV را چگونه تشخیص دهیم؟
وجود نمایشگر بزرگ معیار خوبی نیست.
هنگام بررسی یک خودرو بهتر است درباره این موارد تحقیق کنیم:
- آیا OTA واقعی برای بخش‌های مختلف دارد؟
- فقط Infotainment آپدیت می‌شود یا ECUهای دیگر هم قابل آپدیت‌اند؟
- معماری Central/Domain/Zonal دارد؟
- سازنده برای خودرو پلتفرم نرمافزاری مشخصی معرفی کرده؟
- قابلیتها بعد از فروش قابل توسعه‌اند؟
- سیاست پشتیبانی نرمافزاری چندساله چیست؟
- آپدیت‌های امنیتی چگونه ارائه می‌شوند؟
این اطلاعات بسیار مهم‌تر از اندازه نمایشگر هستند.
تفاوت Connected Car، SDV، EV و خودروی خودران
| فناوری | موضوع اصلی |
|---|---|
| Connected Car | اتصال خودرو به شبکه و سرویس‌ها |
| SDV | تعریف و توسعه قابلیتها توسط نرمافزار |
| EV | استفاده از قوای محرکه الکتریکی |
| Hybrid | ترکیب موتور درونسوز و الکتریکی |
| EREV | قوای محرکه برقی همراه موتور بردافزا |
| Autonomous Vehicle | انجام بخشی یا تمام وظایف رانندگی به‌صورت خودکار |
یک خودرو میتواند چند مورد از این ویژگی‌ها را هم‌زمان داشته باشد.
آیا SDV آینده صنعت خودرو است؟
جهت حرکت صنعت نشان می‌دهد نرمافزار نقش بسیار بزرگ‌تری در خودروها پیدا کرده است.
هم‌زمان شاهد توسعه:
- High-Performance Computing
- معماری Zonal
- OTA
- AUTOSAR Adaptive
- Vehicle API
- Cloud Integration
- AI داخل خودرو
هستیم.
AUTOSAR در 2026 نیز توسعه SDV، معماری‌های چنددامنه‌ای و انتقال به پلتفرم‌های نرمافزاری قابل‌پیاده‌سازی‌تر را از موضوعات اصلی فعالیت خود قرار داده است.
اما این تغییر یک‌شبه اتفاق نمی‌افتد.
برای سال‌ها خودروهایی خواهیم داشت که ترکیبی از:
معماری سنتی + ECUهای معمولی + Domain Controller + بخش‌هایی از SDV
هستند.
در نهایت SDV چه تغییری در تعریف خودرو ایجاد میکند؟
در خودروهای قدیمی تقریباً می‌توانستیم بگوییم:
خودرویی که امروز تحویل می‌گیری، از نظر قابلیتها تقریباً همان خودرویی است که چند سال دیگر خواهی داشت.
SDV این فرض را تغییر می‌دهد.
خودرو به پلتفرمی تبدیل می‌شود که سختافزار آن هنگام تولید ساخته شده، اما بخشی از قابلیت‌هایش توسط نرمافزار در طول زمان شکل می‌گیرد.
همین موضوع دلیل شباهت آن به گوشی هوشمند است.
اما تفاوت بنیادی همچنان باقی می‌ماند:
خودرو یک سیستم ایمنی‌حیاتی است.
بنابراین امکان آپدیت و توسعه نرمافزاری باید در کنار:
- ایمنی
- امنیت سایبری
- پایداری
- حریم خصوصی
- پشتیبانی بلندمدت
قرار گیرد.
آینده خودرو فقط برقی شدن نیست.
یکی از تغییرات مهم‌تر این است که نرمافزار دارد از یک قطعه جانبی خودرو به یکی از اجزای اصلی تعریف‌کننده خود خودرو تبدیل می‌شود.
سؤالات متداول
Vehicle OS چیست؟
Vehicle OS اصطلاحی برای مجموعه زیرساخت نرمافزاری خودرو است که میتواند شامل سیستمعامل، Middleware، APIها، سرویسهای خودرو و ابزارهای مدیریت برنامهها باشد.
آیا SDV همان خودروی خودران است؟
خیر. SDV معماری نرمافزاری خودرو را توصیف میکند، در حالی که خودران بودن درباره میزان اتوماسیون وظایف رانندگی است.
آیا آپدیت نرمافزاری خودرو خطرناک است؟
اگر بهدرستی طراحی و مدیریت شود، OTA امکان رفع مشکلات و بهبود خودرو را فراهم میکند. به همین دلیل مقرراتی مانند UN R156 الزاماتی برای امنیت و ایمنی فرآیند آپدیت تعیین کردهاند.
