در وبینار «متدلوژی اتوسار، مسیر تحول نرم‌افزار در صنعت خودرو» چه گذشت؟

در وبینار «متدلوژی اتوسار، مسیر تحول نرم‌افزار در صنعت خودرو» چه گذشت؟

در نخستین نشست از سلسله نشست‌های تخصصی راهکارهای فناوری در صنعت خودرو که با عنوان کلی «کلینیک فناوری خودرو» توسط شرکت جتکو برنامه‌ریزی شده است موضوع «متدلوژی اتوسار، مسیر تحول نرم‌افزار در صنعت خودرو» همراه با اعلام دستاوردها و همچنین نیازهای فناورانه گروه صنعتی ایران‌خودرو در قالب یک وبینار مورد بحث و بررسی قرار گرفت. سخنرانان این وبینار مهندس سپهر سالور رییس اداره سیستم‌های الکترونیک خودرو در مرکز تحقیقات شرکت ایران‌خودرو و مهندس مهران ایزدی از همکاران پیشین شرکت جتکو و کارشناس شرکت CEVT سوئد بودند.

مهندس سپهر سالور نخستین سخنران این وبینار بود. وی ابتدا با ارائه مقدمه‌ای از اهمیت الکترونیک در صنعت خودرو گفت: سهم الکترونیک در خودروهای امروزی، همواره رو به رشد بوده است. در سال 1980 سهم الکترونیک در هزینه تمام شده خودرو یک درصد بود که در سال 2005 با رشد زیادی به 20 درصد و در سال 2015 به 40 درصد رسیده است و طبیعتا امروز این عدد بالاتر هم رفته است.  بیش از 90 درصد نوآوری‌های صنعت خودرو مربوط به حوزه الکترونیک خودرو بویژه نرم افزار است  و پیشرفتهای صنعت خودرو مثل خودروهای هوشمند یا خودران، خودروهای Connected، خودروهای برقی و … مرهون پیشرفت در حوزه الکترونیک خودرو و نرم افزار است.

مهندس سالور با بیان اینکه توسعه و پیشرفت با خودش مشکلات و چالش‌هایی هم به همراه می آورد گفت: ما روزانه با ادوات و تجهیزاتی کار میکنیم که بر پایه نرم‌افزار توسعه داده شده‌اند و به طور مثال در زمان استفاده از کامپیوتر یا تلفن همراه اگر با مشکلات نرم‌افزاری هم روبرو شویم گاهی با ر‌ی‌استارت، سیستم را به عملکرد عادی خود باز می‌گردانیم. اما از کنار باگ نرم‌افزاری در داخل سیستم خودرو نمی‌توانیم با بی‌تفاوتی عبور کنیم چون می‌تواند حوادث جبران ناپذیری ایجاد کند. به همین دلیل طی سالهای طولانی، خودروسازان و شرکت‌های همکار خودروسازان در بخش تامین قطعات الکترونیکی به طور مداوم در حال وضع استانداردها و قوانین و پروتکل‌هایی بودند که به کمک آنها بتوانند قابلیت سیستم‌های الکترونیکی را در خودرو بالاتر ببرند. به عنوان مثال پروتکل CAN که خاص ارتباط اجزای الکترونیکی و کنترل یونیت‌های الکترونیکی در خودرو تدوین شده و یا استاندارد اتوسار که موضوع امروز ماست. با توجه به ضرورت ایمنی عملکردی، استاندارد ISO26262 که خاص سیستمهای کنترلی الکترونیکی قابل برنامه ریزی در خودرو است تدوین شده  است و از سال 2011 به طور کامل در فازهای مختلف طراحی و توسعه سیستمهای الکترونیکی، در مرحله Concept، System Design، Software و Hardware دستورالعمل های بسیار دقیقی به منظور غلبه  بر چالش‌هایی که در نتیجه توسعه سیستمهای الکترونیکی در خودرو پدید می آید ارائه داده است.

وی در این زمینه به یکی از مشکلاتی که در سالهای گذشته برای خودروهای تویوتا رخ داد پرداخت و گفت: در سال 2000 ، حدود شش هزار و 200 شکایت روی محصولات تویوتا در آمریکا ثبت شد که طبق آن مشتری ادعا می کرد سرعت خودرو به طور ناگهانی زیاد شده و در همان بازه زمانی، حوادثی در پی داشته که حاصل آن 89 فوتی و 57 مورد صدمه بوده است. در یکی از این حوادث، سرعت یک خودروی لکسوس es350  به بالای 160 کیلومتر در ساعت رسیده بود و راننده که تماس اورژانسی هم گرفته بود نمی‌تواند خودرو را متوقف کند و چهار عضو یک خانواده در این حادثه کشته می شوند. همه این موارد باعث شد شرکت تویوتا با اعلام یک فراخوان اقدام به تعویض قطعات مرتبط با دریچه گاز و ECU کند و همچنین محکوم به پرداخت خسارات بالا شد. در این سیستم کنترل دریچه گاز توسط ECU  انجام می شود و ارتباط مستقیمی بین پدال گاز و دریچه گاز وجود ندارد بلکه سنسورهایی که متصل به پدال گاز هستند وضعیت دریچه گاز را برای ECU ارسال می‌کنند و با پردازش‌های نرم‌افزاری که داخل ECU کنترل موتور انجام می‌شود بسته به شرایط رانندگی دریچه گاز باز می‌شود و شتاب و گشتاور مورد نظر به موتور اعمال می‌شود. در آن زمان بررسی زیادی برای یافتن عامل بروز مشکل انجام شد و که عمده ی این مشکلات از ضعف‌های نرم‌افزاری داخل ECU ناشی می شد که این هشدار را به خودروسازان اعلام کرد که مقوله توسعه نرم‌افزار در سیستم های embedded مرتبط با خودرو کاملا می تواند متفاوت باشد و باید توجه ویژه‌ای به این موضوع شود که نتیجه آن، وضع استانداردهای جدید بود.

سیر تکامل های پلتفرم‌های برق و الکترونیک در ایران‌خودرو

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

وی افزود: اگر بخواهیم حوزه های الکترونیک خودرو را به چهار دسته الکترونیک بدنه، شاسی، پاورترین و تله ماتیک تقسیم کنیم، شبکه مالتی پلکس حوزه بادی را کاور می کرد . پروتکل CAN LOW SPEED با سرعت 125 کیلوبیت بر ثانیه برای آن در نظر گرفته شده بود که پنج یونیت کنترل الکترونیکی داخل آن شبکه وجود داشت که به عنوان اولین نسل سیستم‌های مالتی پلکس در سال 1389 روی خودروی سمند و بعد سورن به بهره برداری رسید.

مدل نرم‌افزاری که برای کنترل یونیت‌ها در آن زمان در نظر گرفته شده بود مدل VDX بود که در حقیقت استانداردی برای پیاده‌سازی نرم‌افزار در حوزه خودرو است که ابتدا توسط آلمانی‌ها طراحی شد و بعدها فرانسوی‌ها به این کنسرسیوم پیوستند و آن را تکمیل کردند. از سالهای 1389 تا 1399 ایران‌خودرو به عنوان بزرگترین خودروساز ایران و منطقه، نسل‌های متفاوتی از سیستمهای تحت شبکه و مالتی پلکس را تحت پلتفرم های برق و الکترونیک خودرو ارائه کرد و در توسعه های خود سایر حوزه های الکترونیک خودرو از جمله پاورترین و شاسی هم به شبکهHigh speed CAN  متصل کرد و این شبکه را توسعه داد. از سال 98 و 99، در راستای پیشرفت تکنولوژی و با تاسیس شرکت جتکو به عنوان یکی از شرکتهای زیرمجموعه گروه صنعتی ایران خودرو، استارت پروژه پلتفرم بومی برق و الکترونیک ایران‌خودرو زده شد و برای اولین بار طراحی پلتفرم برق و الکترونیک با استفاده از متدولوژی اتوسار که تکمیل شده همان مدل OSEC VDX بود شروع شد و در حال حاضر اولین کنترل یونیت الکترونیکی حوزه بدنه با نام BCM با کمک این متدولوژی توسعه داده شده و فازهای تست در حال گذراندن است و در آینده بسیار نزدیک وارد تولید انبوه می شود.

سیر تکاملی معماری الکتریکی خودروها  (Evolution of EE Architecture)

در ادامه، مهندس مهران ایزدی از متخصصان قدیمی جتکو و کارشناس شرکت CEVT سوئد، گفت: از سال 97 با شرکت جتکو شروع به همکاری کردم و روی توسعه پلتفرم بومی برق و الکترونیک ایران خودرو فعالیت خود را آغاز کردیم و مسئول تیم پیاده سازی اولین ECU تحت عنوان Body Control Module  بودم که در شرکت جتکو توسعه پیدا می کرد. قبل از این که از ایران خارج شوم یک رونمایی اولیه از اولین ECU مبتنی بر اتوسار در ایران داشتیم و با کمک همکاران، این فرآیند تکمیل شد و به زودی روی خودروهای تولید گروه صنعتی ایران‌خودرو استفاده خواهد شد. از سال گذشته وارد شرکت CEVT سوئد شدم که تکنولوژی آن متعلق به ولوو سوئد و مالکیت آن متعلق به شرکت چینی جیلی است و ما در حال طراحی پلتفرم برق و الکترونیک در این شرکت هستیم.

مهندس ایزدی در ادامه به تشریح سیر تکاملی معماری الکتریکی خودروها پرداخت و گفت: اولین معماری خودروها از زمانی که شبکه وارد خودروها شد   Gateway Architecture بود.در این معماری شبکه محدود و تعدادی ECU داریم که به ECU مرکزی متصل می شود که در دنیا تقریبا منسوخ شده است. چراکه با افزایش امکانات خودروها، جوابگوی نیازهای صنعت خودرو نبود و نسل بعدی با نام Domain Centralized Architecture   ایجاد شد. در این معماری حدود پنج Domain اصلی در خودرو وجود دارد که هر کدام مربوط به یک بخش است. یک ECU مرکزی در نظر گرفتند تا کل اطلاعات به آن برسد. با کمک این معماری مشکل پیچیدگی و نیاز به شبکه های اضافه به خاطر اضافه شدن فیچرهای جدیدتر تا حد زیادی رفع شد. اما با توجه به افزوده شدن فیچرهای جدید، باز هم مشکل را کامل حل نکرد و جوابگوی نیازها نبود. ضمن اینکه میخواستند همه را در ECU مرکزی جمع کنند.  پس به سراغ نسل جدیدی به نام Centralized Architecture رفتند که اکثر خودروهایی که در خیبانهای دنیا می بینید هنوز از آن استفاده می کنند. اما به مرور زمان مشخص شد این سیستم هم به خاطر نیازی که به Connected VEHICLE  و ADAS ایجاد شده بود پاسخگوی نیازها نیست و شرکتهای بزرگ به سراغ ساختار جدیدی منطبق بر این نیاز رفتند؛ یعنی   ZONAL Architecture. خودروسازان روز دنیا مثل تسلا و اغلب خودروسازان آلمانی چند سال است از این مماری استفاده می کنند. در این معماری همه ECUها به چند ZON محدود متصل می شوند و ECU ZON CONTROLER از طریق شبکه اینترنت به سوپر کامپیوتر متصل می شود. سعی کردند تا حد امکان، هوشمندی را از ECU ها به سوپر کامپیوتر مرکزی منتقل کنند و ECUهای کوچک هم هوشمندی بالایی ندارند و وظیفه گرفتن دیتا از سنسورها را بر عهده دارند. یکی از مزیتهای اصلی این معماری که شرکتهای بزرگ دنیا به سمت آن حرکت کردند این است که اضافه کردن فیچر جدید به خودرو را با سهولت بیشتری امکانپذیر می کند.  البته یکی از نقاط ضعف این معماری، این است که اگر پس از چند سال، سوپرکامپیوتر مرکزی خراب شود 20 درصد قیمت خودرو نو را باید برای جایگزینی آن هزینه کنید. اگرچه در ایران تعمیر خودروها مرسوم است اما در دنیا اینطور نیست و همین امر می تواند موجب تعویض خودرو شود.

معماری نرم افزار یا Classic AUTOSAR:

تمام ECU ها از یک معماری نرم افزار به نام Classic AUTOSAR استفاده می کنند. اما این معماری برای سوپرکامپیوتر مرکزی پاسخگو نیست وبرای این سوپر کامپیوترها از Adaptive AUTOSAR استفاده می کنند. در سال 2003 آلمانی ها به این نتیجه رسیدند که گرایش خودرو به شدت به سمت نرم افزار است، هزینه ها روز به روز افزایش می یابد، احتمال خطا بالا می رود و هماهنگی بین تیمها و تامین کنندگان سختتر می شود. پس باید استانداردی ایجاد شود که همه زیر چتر آن قرار گیرند تا هم هزینه ها مدیریت شود و هم هماهنگی بیشتری ایجاد شود. پس یک معماری به نام Classic AUTOSAR معرفی شد که تجربه بسیار موفقی بود و کل شرکتهای OEM  و تامین کنندگان دنیا به استثنای تسلا، از این استاندارد استفاده می کنند. اگر 150 ECU در یک خودرو وجود دارد کمتر از 20 عدد آن غیراتوساری است که در نسل بعدی، یقینا آن موارد محدود هم اتوساری خواهد شد.

اتوسار چهار قسمت کلی دارد. یکی راهنما برای تست. دوم، متدولوژی و پروسس؛ یعنی برای طراحی از ابتدا تا انتها باید از چه فازهایی عبور کرد و چه کارهایی باید انجام دهید. سوم،  Software Architecture و چهارم، فرمت تبادلی که خودروسازها و تامین کنندگان باید با استفاده از آن با هم در ارتباط باشند. یعنی خودروسازان سفارش محصول را با فرمت مشخصی به تامین کنندگان می دهند که همه ویژگی های موردنیاز در آن مشخص است و هیچ قسمت مبهمی باقی نمی ماند و کسی نگران از بین رفتن دیتا نیستند که نتیجه این زبان استاندارد ایجاد شده است. معماری نرم افزاری که اتوسار معرفی کرد نرم افزار را به دو بخش تقسیم کرد: اپلیکیشن و نرم افزار پایه(مثل درایورهای شبکه). نرم افزار پایه خود به بیش از 210 ماژول مختلف تقسیم می شود.

Classic AUTOSAR برای سیستمهای نهفته با پردازش پایین (فرکانس های پایین تا حداکثر 500 مگاهرتز) استفاده می شود. برای کاربردهایی مثل ADAS و موارد مشابه که به قدرت پردازشی بالاتری نیاز دارند، دیگر این معماری پاسخگو نیست و برای این موارد از معماری Adaptive AUTOSAR استفاده می شود.

کاربرد Adaptive AUTOSAR:

همانطور که اشاره شد Adaptive AUTOSAR برای مواردی که به سرعت و قدرت پردازشی بالایی (فرکانس کاری در حد گیگا هرتز) نیاز دارند مورد استفاده قرار می گیرد. از آنجایی که CPU کامیپوتر را نمی توان در خودرو استفاده کرد پس شرکتهای تراشه ساز از لاک استپ سخت افزاری استفاده کردند. این سخت افزار پردازش را به طور موازی دو تا سه بار در CPU انجام می دهد و در نهایت نتیجه پردازش ها با هم مقایسه می کند که اگر نتایج یکسان بود نشان می دهد پردازش ها به درستی انجام شده است. برای پردازش هایی با سطح بالا هیچ استانداردی برای خودرو نداشتیم و یک مورد بود که آن هم از سال 2021 حذف و Adaptive AUTOSAR ایجاد شد که شبیه کامیپوتر است و فایلهای مختلفی دارد. برعکس اتوسار کلاسیک، در Adaptive AUTOSAR ، لایه بیسیک ما فقط با OS درگیر می شود و ساختار، فیکس شده نیست. وی در ادامه به ویژگی ها و چالش‌های Adaptive AUTOSAR پرداخت.

فیلم کامل وبینار را در ذیل مشاهده فرمایید.

مشاهده فیلم وبینار