پروتکل ارتباطی (CAN (Controller Area Network و همچنین پروتکل ارتباطی RS485 دو پروتکل شناخته شده در زمینه‌­ی سیستم‌های فیلدباس (Fieldbus) هستند. با این تفاوت که RS485 تنها از لایه فیزکی یا همان لایه اول و پروتکل CAN از لایه دوم در مدل OSI بهره می‌برد، در عین حال مقایسه این دو پروتکل کار سختی است و در این مقاله سعی بر آن است که دو پروتکل با هم مقایسه شده تا به کاربر قابلیت انتخاب بین دو پروتکل داده شود.

مقدمه‌ای در مقایسه پروتکل ارتباطی CAN، RS485 و USART

پروتکل ارتباطی RS485

این پروتکل ارتباطی در سال ۱۹۸۳برای فراهم آوردن قابلیت ارتباطی Multi-Drop برای دستگاه‌هایی با حداقل یک UART ساخته و طراحی شد. تمام سیستم‌های متصل از طریق RS485 می‌توانند با یک دیگر در مد half-duplex ارتباط برقرار کنند. اگرچه مد half-duplex قابلیت ارتباط دو طرفه را ایجاد می‌کند، اما تنها در هر لحظه یک سیستم می‌تواند اقدام به ارسال اطلاعات کند و بقیه مجبور به گوش دادن تا اتمام پروسه ارسال هستند. در واقع RS485 یک پروتکل کامل نیست و تنها قوانین لازم برای انتقال اطلاعات از طریق لایه‌ی فیزیکی را فراهم می‌آورد. در این حالت محتوای پیام به طور کامل بر عهده کاربر می‌باشد که بدین معناست که پیش بینی تمامی ساختارهایی از قبیل ساختار پیام، آدرس دادن دیگر نودها، مکانیسم جلوگیری از تداخل اطلاعات و … همگی باید بدست کاربر توسط یک پروتکل نرم افزاری تعیین شود.

پروتکل ارتباطی CAN

پروتکل ارتباطی CAN در سال ۱۹۸۰ توسط Robert Bosch GmbH ساخته و پیاده سازی شد. در ابتدا این پروتکل تنها برای استفاده در صنایع اتوماسیون ساخته شده بود، اما هم اکنون در بسیاری از زمینه‌ها همانند اتوماسین صنعتی، پزشکی، حمل و نقل و … از این پروتکل استفاد می‌شود. در مقایسه با RS485 پروتکل CAN نه تنها رسانه‌ی انتقال برای ارسال و دریافت اطلاعات را فراهم می آورد بلکه تمامی امکانات به منظور آدرس‌دهی بسته‌ها، جلوگیری از تداخل اطلاعات، تشخیص خطا در ارسال و دریافت اطلاعات، تکرار ارسال اطلاعات آسیب دیده تا زمان حصول اطمینان از ارسال صحیح اطلاعات و … .

همانند RS485 پروتکل CAN از طریق مد half-duplex اقدام به ارسال و دریافت اطلاعات با دیگر اجزا می‌کند. هر پیام در این پروتکل حاوی یک ID است که نمایان گر اولویت پیام با توجه به در نظر گرفتن تداخل اطلاعات است که به این منظور ۸ بایت اختصاص داده شده است. این اطلاعات به صورت سریال یا به عبارت دیگر به صورت پشت سر هم ارسال می‌شوند. تمامی اطلاعات با الگوریتم Non-return-to-zero) NRZ) کدگذاری شده و توسط تمام نودهای درون سیستم دریافت می‌شود. اگر باس اطلاعات خالی باشد هر نود (Node) می‌تواند در لحظه اقدام به ارسال اطلاعات کرده، پیام با اولویت بالاتر بر دیگر پیام‌ها ترجیح داده خواهد شد و برای تمام نودها ارسال خواهد شد. با این منطق دیگر مطمئن خواهیم بود که تنها پیامی برای همه نودها ارسال خواهد شد که دارای بیشترین اولویت است. در واقع پیامهایی با مقدار ID کمتری از لحاظ عددی دارای اولویت بالاتری خواهند بود و در هنگام ارسال پیامهای همزمان از نودهای متفاوت، تنها پیام با اولویت بالاتر ارسال خواهد شد.

مقایسه پروتکل ارتباطی CAN ،RS485 و USART

RS485 با استفاده از ماژول UART عمل می‌کند. بنابراین ارتباط بر مبنای کاراکترهای ۸ بیتی که نوشته یا خوانده می‌شوند انجام می گیرد. بنابراین ساختار پیام باید در یک نرم افزار تعبیه شود. اما در مقابل پروتکل CAN از یک فرمت از پیش تعیین شده‌ی دائمی برای ساختار پیام ارسالی بهره می‌برد که علاوه بر ۰ تا ۸ بایت داده شامل اطلاعات کنترلی برای آدرس دهی و ثبات داده می‌شود (CRC).  در واقع کابر تنها لازم است که مشخصه پیام (Identifier) و حجم داده‌ی ارسالی (Payload) را تعیین کرده و بقیه بیتهای کنترلی توسط بخش CAN controller به داده‌ی ارسالی اضافه خواهند شد. یک کنترلر CAN می‌تواند به صورت یک ماژول داخلی یا یک ماژول خارجی میکروکنترلر استفاده شود.

هر پیام  CAN دارای اولویت مخصوص به خود می‌باشد که از مشخصه پیام (Message Identifier) مشتق می‌شود. پیامهای CAN با اولویت بیشتر توسط بخش کنترلر CAN زودتر بررسی شده و نتیجتا از پیام‌های با اولویت کمتر زودتر ارسال خواهند شد. همچینی بر روی باس CAN پیام با اولویت بیشتر زودتر از دیگر پیامها انتقال می‌یابد.

نتیجتا پروتکل CAN یک راه حل انطباق پذیر با قابلیت Real-Time بودن می‌باشد. با توجه به اولویت هر پیام با در نظر گرفتن ID، حداکثر زمان تاخیر برای هر پیام CAN می‌تواند مستقل از حجم اطلاعات حاضر بر روی باس CAN یا سرعت و بهره دیگر نودها در سیستم تخمین زده شود. این در حالی است که در RS485 قابلت تشخیص تداخل اطلاعات وجود ندارد بنابراین جلوگیری از تداخل داده‌ها باید توسط نرم افزار گارانتی شود. غالبا جلوگیری از تداخل اطلاعات در شبکه‌ی RS485 توسط رابطه‌ی Master/Slave حل شده به این نحو که Master عملیات Polling رابر روی Slave ها یکی پس از دیگری انجام می‌دهد. بنابراین تاخیر برابر تعداد تاخیر تک تک عکس‌العمل‌های تمام نودهای موجود در سیستم خواهد بود که مقدار بسیار بیشتری نسبت به پروتکل CAN خواهد بود.

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

تمامی این ویژگی های CAN از قبیل انتقال تفاضلی، تشخیص خطا، رفع خطا و حذف نودهای مخرب باعث شده است که CAN به یک پروتکل قدرتمند، امن و قابل اعتماد تبدیل شود که در خیلی از حوزه‌های حساس و مرتبط با امنیت همانند وسایل نقلیه، کشتی‌ها، بالابرها، وسایل پزشکی، صنایع هوایی و غیره کاربرد اساسی داشته باشد.

هم اکنون در اغلب میکروکنترلرهای موجود در بازار پروتکل CAN پروتکلی شناخته شده است که همانند RS485 که معمولا با یک UART داخلی کار می‌کند به صورت مجازی مجانی ارائه می‌شوند. در واقع این بدین معناست که در استفاده از این دو پروتکل هیچ مزیت قیمتی وجود نخواهد داشت. قیمت ماژول‌های انتقال دهنده از طریق CAN معمولا از موارد مشابه برای RS485 کمتر است.

با توجه به پیاده سازی کامل پروتکل CAN به صورت سخت افزاری، حجم پردازشی بر روی میکروکنترلر کاهش یافته است (برای هر پیام یک وقفه). این در حالی است که در RS485 همانند UART برای دریافت هر کاراکتر یک وقفه وجود دارد که علاوه بر سخت کردن کار مدیریت نرم افزار بار پردازشی بسیار سنگین تری را بر روی میکروکنترلر تحمیل می‌کند. در واقع به نسبت برای انجام عملیات پردازشی برای RS485 در شرایط مشابه نیاز به CPU قوی تر و نتیجتا قیمت بیشتر خواهد بود.

خلاصه