مقدمات و مفاهیم پایه سیستم های الکتریکی و الکترونیکی (EE) خودرو

همانگونه که در مطلب پیشین بیان گردید خودروهای امروزی به منظور افزایش ایمنی راننده، سرنشینان و عابرین پیاده، سازگاری بیشتر با استانداردهای زیست محیطی و فراهم نمودن امکانات رفاهی و آسایشی بیشتر، به تجهیزات و سیستم های الکتریکی و الکترونیکی پیشرفته ای مجهز شده اند. پیاده سازی و اجرای چنین سیستم های پیشرفته ای بدون استفاده از کنترلرهای خاصی موسوم به «واحد کنترل الکترونیکی یا به اختصار ECU» امکان پذیر نمی باشد. در این بخش، نخست این المان کاربردی به عنوان زیربنای سیستم های الکتریکی و الکترونیکی خودرو معرفی می شود و سپس دو پروتکل ارتباطی CAN و K-Line که به صورت گسترده در ساختار EE خودروهای موجود در بازار کشور مورد استفاده قرار می گیرند، تشریح می شوند.

در یک تعریف کلی، ECU به هرگونه کنترل کننده الکتریکی یا الکترونیکی که به صورت سفارشی جهت کنترل بخشی از اجزاء یا سیستم های الکتریکی و الکترونیکی یک خودرو طراحی و ساخته شده است، اطلاق می گردد. این کنترلر با دریافت تعدادی ورودی از طریق انواع سنسورها و سوئیچها به صورت دیجیتال و آنالوگ، طبق برنامه نوشته شده در حافظه آن، خروجی های مورد نیاز برای عملکرد شیرها، محرکها، عملگرها و سایر خروجیهای موردنیاز برای کنترل تجهیز مدنظر را تولید می نماید. هر ECU، از یک بخش سخت افزاری متشکل از مدارات مجتمع الکترونیکی و یک بخش نرم افزاری متشکل از انواع متفاوتی از برنامه ها و داده ها که روی حافظه آن بارگذاری می گردند، تشکیل شده است که این دو بخش با دو کد به ترتیب به نام های کد مرجع سخت افزاری و کد مرجع نرم افزاری شناسایی می گردند. بخش سخت افزاری ECU، برای خودروسازان قابل سفارشی سازی نیست اما بخش نرم افزاری آن توسط سازنده به صورت یک برنامه عمومی برای طیف وسیعی از کاربردها نوشته و ارائه می گردد و تنظیمات سفارشی بسته به مشخصات و نوع خودرو، توسط خودروساز انجام و به آن دانلود می گردد. امروزه فناوری طراحی و ساخت ECUها در انحصار تعداد محدودی شرکت در سرتاسر جهان قرار دارد که از آن جمله میتوان به شرکت های مطرح DENSO ،Delphi ،Continental ،Pektron و Hitachi اشاره نمود. از دیگر شرکت های بزرگ این حوزه که در بازار خودروهای داخل کشور بخوبی شناخته شده اند می توان به شرکت هایی همچون بوش (Bosch)، کانتیننتال (Continental) و زیمنس (Siemens) اشاره نمود. ذکر این نکته لازم است که پیچیدگی های سخت افزاری طراحی مدارات الکترونیکی یک ECU دلیل انحصاری بودن فناوری ساخت آن در دست چند سازنده بزرگ نیست بلکه برنامه نویسی پروسه های پیچیده برخی از ECUها و اطمینان از عملکرد صحیح و مطمئن ECU در کلیه شرایط، دلیل مهمتری برای این امر به شمار می رود. در شکل زیر یک نمونه ECU از برند بوش نشان داده شده است.

امروزه طیف وسیعی از انواع ECUها بسته به کاربردهای مختلف توسط شرکت های صاحب این فناوری طراحی و به بازار عرضه شده است. خودروسازان برای این ECUها بسته به کاربرد مدنظر، اسامی متفاوتی بکار می‌برند. به عنوان نمونه برای ECU موتور که وظیفه کنترل پروسه احتراق در موتورهای بنزینی انژکتوری را برعهده دارد، نام هایی همچون ECU (مخفف عبارت انگلیسی Engine Control Unit) یا ECM (مخفف عبارت انگلیسی Engine Control Module) یا CMM (مخفف عبارت فرانسوی Calculateur Moteur Multifonctions) بکار می رود. یا به عنوان نمونه ای دیگر برای ECU سیستم ایربگ خودرو که وظیفه کنترل مدارات ایمنی و عملکرد ایربگ های خودرو را برعهده دارد، عموماً از نام ACU (مخفف عبارت Airbag Control Unit) و برای ECU کنترل کننده مدارات هیدرولیکی گیربکس های اتوماتیک از نام TCU (مخفف عبارت انگلیسی Transmission Control Unit) استفاده می گردد. امروزه خودروهایی با بیش از ۵۰ عدد ECU در ساختار الکتریکی و الکترونیکی خودرو نیز طراحی و ساخته شده است. در کشور ما نیز امروزه اکثر خودروها دارای ECU موتور، ECU ایربگ، ECU سیستم ترمز ABS خودرو، ECU گیربکس اتوماتیک و ECU سیستم ضدسرقت (به انگلیسی : Immobilizer) می باشند.

همانگونه که بیان گردید سازندگان ECU، این کنترلر کننده را به همراه یک برنامه عمومی به بازار عرضه می نمایند و هر خودروساز به تناسب محصول تولیدی خود، اقدام به سفارشی سازی پارامترها و کالیبره کردن مقادیر، اضافه نمودن برنامه های سفارشی و… می نماید. به بیان دقیق تر، پس از اتمام مونتاژ قطعات مختلف خودرو در خطوط تولید کارخانه، لازم است تا انواع مختلفی از داده ها به ECUها و تجهیزات الکترونیکی بخش های مختلف خودرو دانلود شود و سپس اطمینان حاصل گردد که این عملیات به درستی صورت پذیرفته است. بدیهی است که بدون انجام این کار، خودرو قابل روشن نمودن نبوده و اکثر بخش های خودرو، عملکردی نخواهند داشت. به طور کلی بسته به نوع ECU، می توان انواع داده های قابل دانلود به ECUها و تجهیزات EE خودرو را در ۵ گروه ذیل دسته بندی نمود :

• برنامه (به انگلیسی : Software)

این نوع داده، یک زیر برنامه سفارشی است که متناسب با شرایط مختلف توسط خودروساز به دلخواه برنامه نویسی می گردد. عموماً تنها کنترل کننده مرکزی خودرو موسوم به BCM (مخفف عبارت انگلیسی : Body Control Module) قادر به دریافت و ذخیره سازی این نوع از داده ها می باشد. به عنوان نمونه، مدت زمان روشن ماندن تعدادی از چراغ های خودرو پس از پارک (آپشن Follow me home) یک نمونه برنامه سفارشی است که توسط خودروساز نوشته و به BCM دانلود می شود.

• داده های کالیبراسیون (به انگلیسی : Cal Data)

داده های کالیبراسیون بسته به ECUها و تجهیزات الکترونیکی مختلف خودرو مفهوم و کارکرد متفاوتی دارند. به عنوان مثال، تنظیم موقعیت صفر زاویه فرمان در سیستم های فرمان برقی یا کالیبراسیون دوربین های چند منظوره خودرو، نمونه هایی از داده های کالیبراسیون می باشند.

• اطلاعات انکدینگ (به انگلیسی : Dote Data)

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

• اطلاعات پیکره بندی (به انگلیسی : Config Data)

همانگونه که در ادامه این بخش بیان می گردد، بخشی از اطلاعات عملکردی و پروسه ای هر ECU در ساختار EE خودرو، توسط ECUهای دیگر مورد استفاده قرار می گیرد. به عنوان نمونه، اطلاعاتی همچون دور موتور و سرعت خودرو که در ECUهای موتور و سیستم ترمز ABS قرار دارند برای عملکرد مناسب TCU مورد نیاز می باشند، از این رو لازم است تا این ECUها با یکدیگر تبادل داده نمایند. امروزه تبادل داده مابین ECUهای مختلف از طریق پروتکل های شبکه صورت می پذیرد و اطلاعات پیکره بندی، چگونگی برقراری ارتباط ECUهای بخش های مختلف خودرو را تحت پروتکل های متفاوت شبکه تعریف می نمایند.

• داده های لِرن و جفت سازی (به انگلیسی : Pairing and Learning Data)

این داده ها، وظیفه عملیات لِرن و جفت شدن تجهیزات با یکدیگر را بر عهده دارند. به عنوان نمونه، لِرن شدن سوئیچ یا ریموت های خودرو با سیستم ایموبلایزر یا جفت شدن BCM ،ECM و TCU از طریق نوشتن یک کد امنیتی یکسان در آن ها به منظور افزایش ایمنی خودرو به هنگام سرقت نمونه هایی از این نوع داده ها می باشند.

امروزه تعداد قابل توجهی ECU و تجهیزات EE در معماری هر خودرو وجود دارد تا امکانات و آپشن هایی همچون گیربکس اتوماتیک، فرمان برقی، سیستم پارک، ترمز ضد قفل، سیستم کنترل پایداری، تله ماتیک و… در دسترس راننده و سرنشینان خودرو قرار گیرد. به عنوان نمونه در شکل زیر، ساختار EE خودروی سیتروئن C3 نشان داده شده است. در این ساختار، مستطیل های نشان داده شده نمایانگر ECU ها یا سایر تجهیزات برنامه پذیر داخل خودروی سیتروئن C3 می باشد. بدیهی است که این تجهیزات به منظور عملکرد مناسب نیازمند تبادل اطلاعات با یکدیگر می باشد و بدون این امر، امکان عملکرد بخش عمده ای از این تجهیزات وجود نخواهد داشت. از سوی دیگر، همانگونه که بیان گردید لازم است تا پس از اتمام مونتاژ به هرکدام از تجهیزات فوق، انواع مختلفی از داده ها دانلود شود تا برای محصول نهایی آماده به کار شوند. با توجه به این مطالب، امروزه انواع مختلفی از شبکه های خودرویی طراحی و در عمل بکار گرفته شده اند. ایجاد شبکه مابین ECUها و تجهیزات EE موجود در ساختار خودرو مزایایی مختلفی را برای خودروهای امروزی به ارمغان آورده است که از آن جمله میتوان به کاهش هزینه ها و کاهش وزن خودرو ناشی از حذف تعداد زیادی دسته سیم، افزایش سرعت و کارایی در تبادل اطلاعات مابین تجهیزات، افزایش قابلیت ها و امکانات قابل دسترس، انعطاف پذیری بیشتر، امکان دانلود برنامه و خطایابی ECUها تنها از طریق اتصال به یک کنترل کننده مرکزی اشاره نمود.

خودروسازان بزرگ جهان جهت برقراری ارتباط ECUها و تجهیزات EE بخش های مختلف خودرو و همچنین برقراری ارتباط این تجهیزات با دستگاه عیب یاب (به انگلیسی : Diag) طیف وسیعی از پروتکل ها را ابداع نموده اند. در یک دسته بندی کلی، این پروتکل ها را می توان در دو گروه «پروتکل های ارتباطی شبکه» و «پروتکل های خطایابی» دسته بندی نمود. «پروتکل CAN» به عنوان پرکاربردترین پروتکل ارتباطی در معماری خودروهای امروزی شناخته می شود که بسته به حجم داده و سرعت موردنیاز به دو شکل «CAN سرعت بالا» و «CAN سرعت پایین» در معماری خودرو مورد استفاده قرار می گیرد. برای کاربردهای با اهمیت پایین تر، به منظور برقراری ارتباط بین تجهیزات EE از «پروتکل LIN» نیز استفاده می شود که هزینه پیاده سازی پایین تری نسبت به پروتکل CAN دارد. علاوه بر این دو پروتکل ارتباطی، از پروتکل های «KWP2000» و «UDS» نیز به منظور برقراری ارتباط ابزار خطایابی با شبکه خودرو استفاده می گردد. پروتکل UDS، پروتکل جدیدتری است و امروزه جایگزین پروتکل KWP شده است، با این وجود همچنان KWP از کاربرد محدودی در انجام پروسه های EE برخوردار است. در ادامه این پروتکل ها با جزئیات بیشتری تشریح می شوند.

پروتکل های ارتباطی مابین تجهیزات EE در ساختار خودرو :

• پروتکل (The Controller Area Network (CAN
• پروتکل (Local Interconnect Network (LIN

پروتکل های بارگذاری برنامه و خطایابی :

• پروتکل Key Word Protocol (KWP) 2000
• پروتکل Key Word Protocol (KWP) On CAN
• پروتکل (Unified Diagnostic Services (UDS

پروتکل CAN، یک باس استاندارد به منظور برقراری ارتباط مابین ECUهای مختلف موجود در معماری یک خودرو می باشد که امکان تبادل داده مابین تجهیزات مختلف را از طریق واسط های فیزیکی همچون کابل TP، فیبر نوری، امواج بی سیم و … با حداکثر سرعت ۱Mbps فراهم می نماید. این پروتکل، اولین بار در سال ۱۹۸۳ میلادی توسط رابرت بوش به عنوان راهکاری جهت کاهش حجم دسته سیم های معمولی به درخواست شرکت مرسدس بنز ابداع گردید و کاهش وزن خودرو، افزایش کارایی و بهبود عملکرد سیستم کنترل در خودرو را به ارمغان آورد اما امروزه در کاربردهای دیگری نیز از آن استفاده می گردد. پروتکل CAN، یک پروتکل Real time است و دریافت داده توسط مقصد در زمان مدنظر را تضمین می نماید. بطور کلی قابلیت اطمینان بالا، مقاومت در برابر نویز، دسترسی آسان و مقیاس پذیری در مقابل قیمت مناسب از مهمترین مزایا و دلایل استقبال از پروتکل CAN به شمار می رود. حداکثر سرعت شبکه CAN با توجه به طول شبکه در جدول زیر ارائه شده است.

بر اساس مدل ISO/OSI، پروتکل ارتباطی CAN تنها از دو لایه فیزیکی و لایه پیوند داده استفاده می نماید. در لایه فیزیکی، دو انتهای کابل اصلی شبکه که Trunk نامیده می شود با مقاومت میراکننده محدود می شود و نودهای مختلف به این کابل دو رشته ای متصل می گردند. درصورتیکه یک نود به هر دلیل از مدار خارج شود، کل شبکه از کار نمی افتد و تنها نود معیوب از آن خارج می گردد. دیاگرام ساده ای از شبکه ارتباطی CAN در شکل زیر نشان داده شده است.

لازم به ذکر است کابل شبکه CAN عموماً از دو رشته سیم به نام های CAN-H و CAN-L تشکیل شده است و ارتباط تجهیزات مختلف از طریق این دو رشته سیم برقرار می گردد. شکل موج ولتاژ در رشته سیم CAN-H همواره در جهت مثبت و شکل موج ولتاژ در رشته سیم CAN-L همواره در جهت منفی تغییر می نماید. به بیان دقیق تر، سطح ولتاژ دو رشته سیم فوق در حالت صفر منطقی برابر با ۲.۵ ولت می باشد که این وضعیت اصطلاحاً وضعیت «Recessive» شبکه نامیده می شود. در مقابل وضعیت یک منطقی با افزایش ۱.۲۵ ولتی در CAN-H و کاهش ۱.۲۵ ولتی در CAN-L ایجاد می گردد. این وضعیت اصطلاحاً، وضعیت «Dominant» شبکه نامیده می شود. بدیهی است که استفاده از این شیوه انتقال داده ها، تأثیر اعمال نویز به سیگنال و خراب نمودن داده ها را به حداقل کاهش می دهد، چرا که قرارگرفتن هرگونه نویز روی شبکه، به مقدار برابر روی هر دو رشته سیم رخ می دهد و نتیجتاً اختلاف ولتاژ دو رشته سیم در دو وضعیت بیان شده همواره برابر مقدار پیشفرض خواهد بود. شکل موج سیگنال های CAN-H و CAN-L به صورت نمادین در شکل زیر نشان داده شده است.

شمای کلی اجزاء و ساختار دو تجهیز روی شبکه CAN به همراه مقاومت های میرا کننده (عمدتاً ۱۲۰ اهم) در دو انتهای شبکه جهت جلوگیری از بازتاب سیگنال داده ها در شکل  زیر نشان داده شده است. مطابق این شکل، هر تجهیز CAN به منظور کارکرد روی شبکه می بایست دارای یک بخش به نام کنترل کننده (به انگلیسی : CAN Controller) و یک بخش به نام تبادل کننده (به انگلیسی : CAN Transceiver) باشد. تبادل کننده، وظیفه ارسال و دریافت داده ها روی دو رشته سیم شبکه را برعهده دارد. این بخش در سمت ارسال، داده ها را به سیگنال های الکتریکی تبدیل و روی شبکه ارسال می نماید و در بخش دریافت، سیگنال های الکتریکی را از بستر فیزیکی شبکه خوانده و آن ها را به اعداد صفر و یک ترجمه می کند. بخش دیگر موسوم به کنترل کننده، وظیفه پردازش داده های ارسالی و دریافت شده را طبق منطق برنامه موجود در حافظه بر عهده دارد. شمای کلی اجزاء نودها و ساختار شبکه CAN در شکل زیر نشان داده شده است.

به طور کلی مراحل انتقال داده ها در شبکه CAN شامل پنج گام فراهم نمودن داده، ارسال داده، دریافت داده، بررسی داده و پذیرش داده می باشد. در گام نخست هر نود CAN، داده های موردنیاز جهت انتقال را فراهم و آن ها را در اختیار CAN Controller قرار می دهد. در گام دوم، تبادل کننده داده های دریافتی از کنترل کننده را به سیگنال های الکتریکی تبدیل و آن ها را روی بستر شبکه ارسال می نماید. در گام سوم تمامی نودهای شبکه، سیگنال موجود روی کابل شبکه را دریافت می نمایند و این داده های دریافتی را مورد بررسی قرار می دهند تا مشخص شود آیا داده های دریافتی متعلق به آن هاست یا خیر. نهایتاً درصورتیکه نتیجه بررسی مثبت تشخیص داده شود داده ها پذیرش می شوند و درصورتیکه نتیجه منفی باشد، از داده ها صرفه نظر می گردد. این مراحل به صورت نمادین در شکل زیر نشان داده شده است.

در پروتکل CAN به منظور تبادل داده ها، از چهار نوع فریم متفاوت به نام های فریم داده، فریم ریموت، فریم خطا و فریم اضافه بار استفاده می گردد. بخشی از اجزای تشکیل دهنده این چهار نوع فریم یکسان هستند و برخی تنها در یک نوع فریم وجود دارند. در ادامه، اجزای تشکیل دهنده فریم داده مطابق شکل زیر که از کاربرد بیشتری در پروتکل CAN برخودار است با ذکر جزئیات تشریح می گردد.

با توجه به ساختار نشان داده شده در شکل فوق، فیلد آغازین (به انگلیسی : (Start Field (SF) اولین بخش یک فریم داده را تشکیل می‌دهد. این فیلد که دارای طولی برابر یک بیت است، در صورت Dominant بودن، ابتدای فریم داده را مشخص نموده و سایر نودهای شبکه، خود را با این سیگنال سنکرون می نمایند. دومین بخش فریم که اصطلاحاً فیلد داوری (به انگلیسی : Arbitration) نامیده می شود، مشخصه پیام (ID) را تعریف می کند. لازم به ذکر است که برای ارسال داده ها در شبکه CAN، دو فرمت استاندارد متفاوت برای تعریف ID به نام های ۲.0A و ۲.0B وجود دارد. تفاوت اصلی این دو فرمت در اندازه حروف مشخصه (ID) است، بگونه ای که شبکه CAN نسخه ۲.0A یا CAN استاندارد، از ۱۱ بیت به عنوان حروف مشخصه در Arbitration Field استفاده می نماید، درحالیکه نسخه ۲.0B یا CAN توسعه یافته (Extended)، از ۲۹ بیت در این بخش بهره می برد که از این ۲۹ بیت، ۱۱ بیت به عنوان حروف مشخصه پایه (مشابه نسخه ۲.0A) و ۱۸ بیت به عنوان حروف مشخصه توسعه یافته مورد استفاده قرار می گیرند. ذکر این نکته نیز لازم است که نسخه ۲.0B به علت کاهش پهنای باند، کاهش قابلیت اطمینان و کاهش سرعت انتقال داده کمتر در عمل مورد استفاده قرار می گیرد. مشخصه پیام یا فیلد داوری، اولویت داده را تعریف می نماید، بدین معنا که اگر دو نود CAN به صورت همزمان اقدام به ارسال داده نمایند این نود با اولویت بالاتر است که قادر به ارسال پیام خواهد بود. طریق اولویت بندی حروف مشخصه بدین شکل است که هرچه مقدار بیتی این فیلد، کوچکتر باشد، اولویت پیام بالاتر است. جهت درک بهتر کاربرد فیلد داوری شکل زیر را با ID سه نود متفاوت در نظر بگیرید.

مطابق شکل فوق که چگونگی تبادل داده توسط نودهای مختلف در شبکه CAN را نشان می دهد، ID نودهای نشان داده شده ۱۱ بیتی می باشند که در این شکل به صورت بیت به بیت با یکدیگر مقایسه میشوند. سه بیت نخست IDها، مقادیر یکسانی دارند اما از آنجا که مقدار بیت چهارم در نود شماره چهار، از بیت نظیر دو نود دیگر بزرگتر است، اولویت پایین تری داشته و در این مرحله از سیکل خارج می شود. به همین ترتیب بیت هشتم نود شماره دو، اولویت پایین تری نسبت به بیت نظیر نود شماره یک دارد و لذا آن هم در این مرحله از سیکل خارج می شود. بدین ترتیب نود اول، باس شبکه را در اختیار گرفته و اقدام به ارسال داده خواهد نمود. به این شیوه دسترسی به شبکه،  «دسترسی چندگانه از طریق شنود سیگنال حامل با قابلیت تشخیص تصادم (به انگلیسی : (Carrier Sense Multiple Access with Collision Detection (CSMA/CD)» گفته می شود. لازم به ذکر است که از فیلد داوری علاوه بر کاربرد فوق، در تعیین نوع داده ها نیز برای هر نود استفاده می گردد. بخش سوم فریم داده که به فیلد چک (به انگلیسی : Check Field) معروف است، طول بسته های اطلاعاتی موجود در فیلد داده را نمایش میدهد. این فیلد، این امکان را برای دریافت کننده فراهم می نماید تا طول داده های دریافت شده را با مقدار مرجع مقایسه نموده و از دریافت کامل داده های ارسال شده اطمینان حاصل نماید. بخش چهارم فریم موسوم به فیلد داده، حاوی بسته های داده می باشد. بخش پنجم موسوم به فیلد ایمنی یا چک سیکلی افزونگی (به انگلیسی : Cyclic Redundancy Check (CRC) or Safety Field)، از یک کد چک افزونگی با طول ۱۵ بیت به همراه یک بیت Recessive Delimiter تشکیل شده است که به منظور تشخیص خطاهای رخ داده به هنگام انتقال مورد استفاده قرار می گیرد. در این روش تمامی بیت های Dominant موجود در بسته داده شمارش شده و مقدار مجموع در فیلد ایمنی قرار می گیرد. در سمت گیرنده نیز عملیات مشابهی انجام می شود و مقدار حاصلجمعِ دو بخش ارسال و دریافت مقایسه می شوند. در صورت وجود تفاوت در دو مقدار، پیام خطا ایجاد و ارسال خواهد شد. بخش ششم موسوم به فیلد تأیید (به انگلیسی : (Confirmation  or Acknowledge Field (ACK)، به منظور ارسال تأییدیه از سوی دریافت کننده به ارسال کننده مبنی بر دریافت صحیح یا عدم دریافت صحیح داده ها مورد استفاده قرار می گیرد. بدیهی است دریافت کد خطا توسط فرستنده و یا عدم دریافت هیچ پیامی از سوی گیرنده، به معنای وجود خطا در ارسال داده تلقی خواهد گردید و در این حالت، فریم داده مجدداً توسط فرستنده ارسال خواهد شد.

بخش هفتم فریم داده، فیلد پایانی (به انگلیسی : (End Frame (EF) است که انتهای فریم را مشخص می نماید. این بخش، آخرین امکان برای آشکارسازی خطاهایی است که منجر به تکرار انتقال داده ها می گردد. با توجه به مطالب بیان شده، چگونگی ارسال داده در شبکه CAN بدین شکل است که زمانیکه یک نود قصد ارسال داده روی شبکه را داشته باشد، نخست وضعیت شبکه را بررسی می نماید. در صورت مشغول نبودن شبکه، فریم پیام توسط این نود روی شبکه نوشته خواهد شد. همانگونه که بیان گردید فریم پیام های ارسالی حاوی آدرس نود مقصد نبوده و بجای این آدرس، یک Arbitration ID در فریم پیام قرار دارد و این ID در کل شبکه یکتا است. تمامی نودهای شبکه، پیام را دریافت می نمایند و بسته به مقدار Arbitration ID، هر نود روی شبکه تصمیم می گیرد که این پیام را بپذیرد و یا از آن صرفه نظر نماید. درصورتیکه چندین نود به صورت همزمان اقدام به ارسال داده روی شبکه نمایند، نودی که دارای بالاترین اولویت (کمترین مقدار Arbitration ID) باشد به صورت خودکار، باس را در اختیار می گیرد و نودهای با اولویت پایینتر تا زمان آزاد شدن مجدد باس منتظر می مانند. در جدول زیر، مثالی از چگونگی ارسال اطلاعات دمای آب رادیاتور موتور در شبکه در سه حالت به کمک ۱، ۲ و ۳ بیت نشان داده شده است. از اطلاعات این جدول می توان دریافت که به ترتیب با ۱ ، ۲ و ۳ بیت، امکان ارسال ۲، ۴ و ۸ مقدار متفاوت فراهم می گردد. بدیهی است هرچه تعداد بیت ها بیشتر شود، امکان ارسال دقیقتر مقادیر فراهم خواهد گردید.

پروتکل LIN، با هدف ایجاد یک پروتکل ارزان قیمت برای کاربردهای سطح پایین در خودرو همچون سنسور باران و روشنایی، برف پاکن، کنترل تجهیزات صندلی ها، درب ها و پنجره های خودرو و… در سال ۲۰۰۲ ابداع شد. این پروتکل از بستر فیزیکی یک رشته سیم مسی و تکنیک دسترسی رئیس و مرئوس استفاده می نماید و حداکثر سرعت ۲۰Kbps را بدست می دهد. این پروتکل در مقابل هزینه پایین، مقاومت مناسبی در مقابل نویز دارد. در جدول زیر، برخی از پارامترهای پروتکل LIN با پروتکل CAN مقایسه شده است.

در شکل زیر نیز شمای کلی شبکه های LIN و CAN با یکدیگر مقایسه شده اند.

پروتکل خطایابی KWP2000، یک پروتکل نرم افزاری برای برقراری ارتباط و خطایابی تجهیزات الکترونیکی سیستم کنترل در یک خودرو است. این پروتکل ارتباطی، بر مبنای دو بستر فیزیکی قابل پیاده سازی و بهره برداری است. حالت نخست برقراری ارتباط ECU و دستگاه خطایاب از طریق دو رشته سیم به نام های K-Line و I-line می باشد که در این حالت از رشته سیم I-Line تنها به منظور بیدارسازی شبکه و مقدار دهی اولیه استفاده می شود و تبادل داده از طریق رشته سیم K-Line به صورت یک ارتباط سریال دوطرفه برقرار می گردد. در شکل زیر، مدل توپولوژی باس پروتکل KWP نشان داده شده است.

در پروتکل KWP، ارتباط دستگاه خطایاب و ECU به صورت نقطه به نقطه برقرار می گردد اما این ارتباط ممکن است به صورت مستقیم مابین یک ECU و دستگاه خطایاب برقرار شود و یا آنکه از طریق یک Gateway این ارتباط به صورت غیرمستقیم ایجاد شود. ساختار کلی خطایابی خودرو در پروتکل KWP در شکل زیر نشان داده شده است.

در پروتکل KWP در حالت نخست که اصطلاحاً (KWP2000 on the K-Line (ISO 14230 نامیده می شود، پیش از اولین درخواست دستگاه خطایاب نیازی به برقراری هیچگونه ارتباط پیوسته ای نمی باشد. این امر بدان معناست که دستگاه خطایاب، ابتدا پنج بایت را از طریق رشته های K-Line و L-Line به ECU منتقل می نماید. پس از آن، دستگاه خطایاب وضعیت رشته L-Line را در وضعیت High حفظ می کند. این مراحل، اصطلاحاً مراحل بیدارسازی شبکه نامیده می شود و پس از این مرحله، کلیه ECU های مقداردهی شده می بایست از سرعت ۱۰.۴Kbps برای مقداردهی و برقراری ارتباط استفاده نمایند. مراحل بیدارسازی شبکه در پروتکل KWP2000 on the K-Line در شکل زیر نشان داده شده است.

دومین حالت پروتکل KWP، استفاده از بستر فیزیکی شبکه CAN است که اصطلاحاً KWP2000 on CAN نامیده می شود و امروزه از کاربرد بیشتری در دستگاه های خطایابی برخوردار می باشد.

پروتکل UDS، یک پروتکل ارتباطی است که بر پایه پروتکل KWP2000 و طبق استاندارد ISO14229 توسعه یافته است تا ملزومات لازم برای خطایابی تحت پروتکل CAN را محقق سازد. پروتکل UDS را می توان ترکیبی از دو پروتکل KWP2000 و CAN به شمار آورد که در لایه فیزیکی آن، از لایه فیزیکی پروتکل CAN استفاده شده است و عملاً این پروتکل تنها از لایه کاربردی مدل ISO/OSI تشکیل شده است. بطورکلی در پروتکل UDS از دو نوع فریم پیام به نام های «فریم یکتا (به انگلیسی : Single Frame)» و «فریم سگمنت بندی شده متوالی (به انگلیسی : Consecutive Segmented Frame or Multi Frame)» بسته به طول سرویس و داده استفاده می شود. فریم یکتا از یک فریم مستقل تشکیل شده است که در ساده ترین شیوه تبادل داده به منظور انتقال حجم کوچکی از داده ها از آن استفاده می گردد. شمای ظاهری این فریم در شکل زیر نشان داده شده است.

اولین بخش این فریم از مشخصه فریم CAN که با عبارت «Ident» در شکل فوق نشان داده شده، تشکیل شده است. این بخش که به دو بایت یا ۱۱ بیت فضا جهت ذخیره سازی نیاز دارد. بخش دوم یا داده که دارای طول ۵ بایت می باشد، خود از زیربخش هایی تشکیل شده است. اولین زیربخش، نوع فریم را با یک یا ۴ بیت فضا مشخص می نماید و مقدار آن برای فریم یکتا، صفر است. دومین زیربخش، سایز بخش داده را به کمک ماکزیمم ۷ بیت تعریف می نماید. سومین و چهارمین بخش به ترتیب، شماره سرویس و زیرسرویس مدنظر را از پروتکل UDS در خود جای می دهند. سرویس به یک بایت فضا و زیرسرویس به یک یا چند بایت فضا نیاز دارد. نهایتاً در آخرین زیربخش، داده ها و اطلاعات مدنظر جهت تبادل جای می گیرند که طول این زیربخش بسته به نوع سرویس متغیر است. لازم به ذکر است حداکثر حجم داده های قابل انتقال با این فریم، ۷ بایت می باشد. درصورتیکه حجم داده ها بزرگتر از ۷ بایت باشد و امکان انتقال آنها به کمک یک فریم یکتا میسر نباشد، از فریم های سگمنت بندی شده استفاده می گردد. در این شیوه، نخست یک فریم به نام «فریم آغازین (به انگلیسی : (First Frame (FF)» از سمت فرستنده به گیرنده مطابق شکل زیر ارسال می شود. فریم آغازین دارای ساختار مشابهی با فریم یکتا می باشد، با این تفاوت که بخش Type در آن از ۴ بیت تشکیل گردیده و مقدار نوع برای فریم آغازین برابر عدد ۱می باشد.

گیرنده پس از دریافت فریم آغازین در پاسخ، فریم دیگری موسوم به «فریم کنترل (به انگلیسی : (Flow Control (FC)» را با ساختار نشان داده شده در شکل زیر به فرستنده ارسال می نماید تا شیوه و چگونگی ارسال داده ها توسط فرستنده تعریف گردد. مشابه فریم یکتا، این فریم نیز از دو بخش Ident و Data تشکیل شده است. در بخش Data، زیر بخش های Type، FS، BS و STmin قرار دارند. اولین زیربخش یا Type، نوع فریم را با چهار بیت فضا معین مینماید که مقدار آن برای فریم کنترل برابر عدد ۳ می باشد. زیر بخش دوم، وضعیت فریم کنترل (FS) را با ۴ بیت تعیین می نماید. عمدتاً در این بخش یکی از سه وضعیت شروع ارسال (به انگلیسی : Start To Transmit)، انتظار برای ارسال (به انگلیسی : Wait For Transmission Until CTS Transmitted) و سرریز بافر گیرنده (به انگلیسی : Overflow Of Received Buffer) تعریف می گردد. زیر بخش سوم (BS)، اندازه بلوک داده را با یک بایت مشخص می نماید و نهایتاً زیربخش چهارم (STmin)، حداقل فواصل زمانی مابین ارسال بسته های اطلاعاتی مختلف را تعیین می نماید و فرستنده جهت ارسال فریم های متوالی به گیرنده می بایست حتماً این حداقل فاصله زمانی را رعایت نماید.

پس از دریافت فریم کنترل توسط فرستنده، پروسه ارسال بسته های اطلاعاتی در قالب فریم هایی موسوم به «فریم های متوالی (به انگلیسی : (Consecutive Frame (CF)» آغاز می گردد. ساختار تشکیل دهنده این فریم های داده در شکل زیر نشان داده شده است. اولین بخش این فریم یا Ident، نمایانگر مشخصه فریم CAN می باشد که این بخش به دو بایت یا ۱۱ بیت فضا جهت ذخیره سازی نیاز دارد. بخش دوم یا داده از زیربخش هایی تشکیل شده است. اولین زیربخش، نوع فریم را با ۴ بیت فضا مشخص نموده و مقدار آن برای فریم متوالی برابر ۲ است. دومین زیربخش، تعداد فریم های متوالی داده را به کمک ۴ بیت تعریف می نماید و سومین بخش بسته های داده را در خود جای می دهد. (ماکزیمم ۷ بایت)

نکته ای که می بایست بدان توجه شود آن است که زمانیکه پیامی از فرستنده به گیرنده ارسال می گردد، نتیجه میتواند به صورت یک پاسخ مثبت یا یک پاسخ منفی از گیرنده به فرستنده ارسال شود. پاسخ نیز از دو فریم کلی پیام تبعیت می نماید و میتواند در قالب فریم یکتا یا فریم سگمنت بندی شده متوالی ارسال گردد اما همواره در فریم پاسخ در بخش شماره سرویس، مقدار ۴۰ هگزادسیمال به مقدار سرویس در پاسخ های مثبت افزوده می شود. به عنوان مثال اگر شماره سرویس پیام، مقدار ۱۰ هگزادسیمال باشد پاسخ مثبت به این سرویس دارای ID با مقدار ۵۰ هگز خواهد بود. در مقابل هر سرویس برای پاسخ های منفی دارای یک یا چند کد به نام NACKs می باشد اما به طور کلی مقدار 0X7F برای تمامی پاسخ های منفی مورد استفاده قرار می گیرد.

مثالی از انواع فریم های داده در پروتکل UDS مابین دو تجهیز در شکل زیر نشان داده شده است.

در پایان ذکر این نکته لازم است که به طور کلی درخواست ها از ECU به دو دسته درخواست های عملکردی و فیزیکی قابل تقسیم می باشند. در درخواست های فیزیکی، ECU قادر به دریافت فریم های یکتا و مالتی فریم‌ها می باشد و ارسال پاسخ به درخواست الزامی است مگر آنکه در یک درخواست معین، نیازی به ارسال پاسخ نباشد. در مقابل در درخواست های عملکردی، ECU تنها قادر به دریافت فریم های یکتا بوده و در مواردی همچون عدم پشتیبانی از سرویس یا زیرسرویس مربوطه، عدم قرار داشتن سرویس در محدوده تعریف شده و …. که منجر به ایجاد یک درخواست نادرست می گردد ECU پاسخی ارسال نمی نماید. لازم به ذکر است هر ECU در پروتکل UDS می تواند در چند مدکاری موسوم به Session کار نماید. در هر مدکاری تعدادی سرویس تعریف شده و برخی از این سرویس ها تنها در همان مدکاری قابل اجرا هستند. به صورت پیشفرض با وصل شدن تغذیه ECU، نخست ثبات ها و حافظه ECU مقداردهی اولیه می شود و سپس مد پیشفرض یا استاندارد فعال می گردد. درصورتیکه دستگاه خطایابی به ECU متصل گردد و از آن درخواست خطایابی نماید، ECU به مد دیگری موسوم به مد توسعه یافته یا سازنده (به انگلیسی : Supplier (or extended) Diagnostic Mode) خواهد رفت. به مجرد فعال شدن این مد، تایمری در ECU اقدام به زمان گیری نموده و درصورتیکه هیچگونه سرویس مشخصی در بازه زمانی تعریف شده درخواست نشود، ECU به مد پیشفرض باز خواهد گشت و این روال سیکلی ادامه خواهد یافت.