جمع بندی:
در این فصل به چگونگی ارتباط بین PLC‌ های زیمنس از طریق شبکه اترنت و شبکه پروفیباس پرداختیم و پیکربندی این دو شبکه را به لحاظ سخت افزاری توضیح دادیم. همچنین بلوک‌هایی مورد نیاز در برنامه نویسی را معرفی کرده و با بهره گرفتن از آن شبکه اترنت و پروفیباس را شبیه سازی و پیاده سازی نمودیم که در ضمایم این پایان نامه موجود می‌باشد. حال می‌خواهیم در بخش بعدی به بررسی تئوری رفتار زمانی این دو شبکه در انتقال دیتا بپردازیم و در نهایت با نتایج بدست آمده از آزمایش‌های عملی مقایسه و بررسی نماییم.
فصل چهارم
تحلیل تتوری و عملی شبکه‌های صنعتی
(اترنت و پروفیباس)
تحلیل تئوری و عملی شبکه‌های صنعتی
(اترنت و پروفیباس)
مقدمه
برای روشن شدن دلیل نیاز به تحلیل و بررسی زمانی یک پروتکل ارتباطی نظیر اترنت ابتدا به ارائه یک مثال

(( اینجا فقط تکه ای از متن درج شده است. برای خرید متن کامل فایل پایان نامه با فرمت ورد می توانید به سایت feko.ir مراجعه نمایید و کلمه کلیدی مورد نظرتان را جستجو نمایید. ))

( اینجا فقط تکه ای از متن فایل پایان نامه درج شده است. برای خرید متن کامل پایان نامه با فرمت ورد می توانید به سایت feko.ir مراجعه نمایید و کلمه کلیدی مورد نظرتان را جستجو نمایید. )

می‌پردازیم. فرض کنید سه ایستگاه برای انتقال اطلاعات در سایت وجود دارد و یکی از آنها در حال ارسال دیتا به مقصد است و دو ایستگاه دیگر منتطر خالی شدن بستر هستند. به محض اینکه بستر آزاد شد یکی از ایستگاه‌ها به طور تصادفی قادر به فرستادن دیتای خود به مقصد خواهد شد . بنابراین این نوع شبکه، تضمینی به ارسال دیتا از یک ایستگاه در یک زمان خاص به مقصد را نخواهد داشت و مفهوم ارسال اطلاعات به صورت زمان حقیقی از بین خواهد رفت. نقص اترنت باعث شد متخصصان از پروتکل‌های دیگری همچون WorldFIP, Profibus, P Net و غیره در سطح فیلد و کنترل استفاده کنند تا از به موقع رسیدن اطلاعات به سطح مانیتورینگ مطمئن باشند. آنان جهت ارتقاء سرعت این نوع پروتکل‌ها تلاش زیادی کردند اما تا کنون موفق به دست یابی به سرعت اترنت نشده اند و همچنان انتقال دیتا با این پروتکل‌ها با تاخیر چشمگیری همراه است [۹].
لازم به ذکر است زمان-حقیقی بودن یک سیستم به معنای انتقال و دسترسی آنی به اطلاعات نمی‌باشد، بلکه منظور تضمین دسترسی به داده در یک زمان معین یا کمتر از آن می‌باشد. چرا که عملاً در هیچ شبکه ای به دلیل وجود تاخیرات ذاتی سیستم نمیتوان به انتقال آنی اطلاعات رسید، حتی اگر از نور، به عنوان سریع ترین مدیای موجود، استفاده نمود. در واقع هدف اصلی در این پروژه شناخت و مدل سازی زمان تاخیر سیستم و یا به عبارت بهتر قانونمند کردن تاخیر در شبکه اترنت و پروفیباس و محاسبه حداکثر زمان آن و ارائه راهکار جهت کم کردن این زمان می‌باشد. این تاخیر عمدتاً منشاء نرم افزاری داشته و به پروتکل مورد استفاده بستگی دارد. نکته دیگری که در این زمینه می‌توان به آن اشاره نمود این است که طراحی یک سیستم کنترل بر روی یک شبکه با تاخیر بالا ولی با مدل شناخته شده برای تأخیر، مناسب تر از طراحی آن بر روی یک شبکه سریع ولی فاقد تضمین دسترسی به اطلاعات می‌باشد. به عنوان مثال در برخی موارد شبکه زمان حقیقی مانند مدباس^[۶۲] (به عنوان یکی از کندترین پروتکل های صنعتی موجود) در یک بستر RS-485 با نرخ انتقال ۲۴۰۰ b/s بر شبکه اترنت با نرخ انتقال Mb/s ۱۰۰ ترجیح داده می شود؛ چرا که در آن تضمین ارسال، انتقال و دریافت داده در زمان معین موجود می‌باشد، چیزی که در یک شبکه اترنت با تمام ویژگی‌ها و سرعت بالا وجود ندارد [۹].
برای درک بهتر علل موثر در تاخیرات به وجود آمده در شبکه و بهینه نمودن آن، در این بخش با بهره گرفتن از CPU‌ های زیمنس، چندین مدل شبکه ی اترنت و پروفیباس ارائه و به لحاظ تئوری بررسی می‌گردد. سپس هر یک از این مدل‌ها با CPU ها به صورت عملی آزمایش و با نتایج تئوری مقایسه می‌گردد.
محاسبه زمانی ارتباط پروفیباس
همانطور که در بخش‌های قبل ذکر گردید ارتباط پروفیباس بر مبنای ارتباط سریال Half Duplex می‌باشد که از بستر ارتباطی RS-485 جهت ارسال و دریافت اطلاعات استفاده می‌کند. همانطور که می‌دانیم RS-485 از یک زوج سیم جهت ارسال و دریافت بهره می‌برد. لذا در هر لحظه یک وسیله متصل به یک باس RS-485 امکان ارسال داشته و مابقی وسایل فقط شنونده هستند. لذا جهت مدیریت باس معمولا در این سیستم‌ها از یک Master استفاده می‌شود. در سیستم مورد بررسی ما نیز این امر لحاظ گردیده است. دو توپولوژی یک Master و یک Slave و یک Master و دو Slave مورد بررسی قرار گرفته است [۶۳].
شایان ذکر است از آنجا که ارتباط سریال مبتنی بر پروفیباس می‌تواند نرخ‌های ارسال متفاوت داشته باشد در تمامی آزمایش‌ها باس بر روی نرخ Kbps 93.75 تنظیم گردیده است. این فرض می‌تواند بین Kbps 9.6 تا Mbps 12 متغیر باشد که با توجه به سیکل زمانی CPU‌های استفاده شده (۱ ms) در نرخ‌های بالاتر از Kbps 93.75 به دلیل سرعت بالا امکان ثبت وقایع وجود ندارد(درواقع زمان ارسال و دریافت کمتر ازms 1 بوده و CPU قادر به ثبت وقایع نیست)‌ [۶۴].
محاسبه زمانی ارتباط یک Master و یک Slave به لحاظ تئوری
جهت بررسی زمانی ارتباط معمولا از Bus Cycle Time استفاده می‌شود. منظور از Bus Cycle Time مدت زمانی است که اطلاعات بین Master و تمامی Slave‌ ها جابجا می‌گردد. بسته به نوع پروسه مقدار نرخ ارسال و دریافت باید به گونه ای انتخاب شود که Bus Cycle Time کمترین زمان ممکن را داشته باشد. لازم به ذکر است این نرخ تابع شرایط مختلفی نظیر فاصله بین وسایل می‌باشد [۴۱].
شکل ‏۴‑۱ : ساختار Bus Cycle
در هربار ارسال و دریافت اطلاعات به هر Slave، در ابتدا Master بسته اطلاعات خود را روی Bus قرار
می دهد که در اصطلاح به آن تلگرام گفته می‌شود. تلگرام شامل یک بخش Overhead و یک بخش دیتا
می باشد. در موقع ارسال دیتا از Master به Slave تلگرام شامل اطلاعات خروجی‌های Slave نیز می‌باشد. در پاسخ هر Slave بعد از خواندن اطلاعات یک تلگرام به Master ارسال می کند که این بسته نیز شامل Overhead و اطلاعات ورودی‌ها می‌باشد. به این ترتیب تمامی اطلاعاتی که می‌بایست بین Master و Slave جابجا شود تبادل شده و Master سراغ Slave بعدی می‌رود [۲].
شکل ‏۴‑۲: ساختار انتقال اطلاعات در پروفیباس
Bus Cycle Time به موارد زیر وابسته می‌باشد:
تعداد Slave ها
نرخ ارسال ( Transmission rate ) یا Baud Rate
حجم اطلاعات (ورودی و خروجی ها) [۴۱]
مقدار دقیق Bus Cycle Time معمولا توسط سازنده تجهیزات محاسبه می‌گردد. زیرا Overhead دیتای انتقالی معمولا شامل زمان‌هایی نظیر زمان انتظار Slave‌ها می‌باشد که از مشخصه‌ های فیزیکی دستگاه ها بوده و در اختیار سازنده است و قابل تغییر نمی باشد. حال به محاسبه ی زمان از نظر تئوری می‌پردازیم.
تعداد بیت‌های انتقال عبارتند از:
Header Byte Length + output data (From Master to Slave)
Header Byte Length+ input data (From Slave to Master)
T_SDR: Slave Reaction Time
T_SYNC: Sync Time
Ti_d1: Initiator Time
:T_SDR مدت زمانی است که یک Slave یک پیغام را دریافت و آنالیز و پاسخ می‌دهد و معمولا هر سازنده یک مقدارMin و Max را برای این منظور ارائه می‌دهد که بین ۱۱Bit تا ۲۵۵Bit می‌باشد.
T_{SYNC :} حداقل زمانی است که Slave بعد از یک درخواست نیاز دارد تا بتواند درخواست بعدی را بپذیرد (idle state ) . برای Profibus-DP این مقدار ۳۳TBit می‌باشد.
T_id1: مقدار زمان لازم بین دو تلگرام می‌باشد یعنی بعد از دریافت آخرین بیت از آخرین بایت تلگرام این مدت می‌بایست طی شود تا تلگرام جدید شروع شود. این زمان حداقل اندازه T_Sync بوده که تعدادی بیت جهت بالا بردن صحت ارسال (T_SM: Safety Margine) به آن اضافه می‌شود.
حال برای محاسبه زمان ابتدا به محاسبه طول Head می‌پردازیم. همانطور که پیشتر اشاره شد فریم پروفیباس متشکل از Header + Data + Trailer می‌باشد که ساختار توسعه یافته آن به صورت کلی به شکل زیر می‌باشد [۴۱].

SD

LE

LEr

SD

DA

SA

FC