آگوست 6

Slave، Master، بایت، +، CPU

ع زمان ارسال و دریافت کمتر ازms 1 بوده و CPU قادر به ثبت وقایع نیست)‌ [64].
4-2-1- محاسبه زمانی ارتباط یک MASTER و یک SLAVE به لحاظ تئوری
جهت بررسی زمانی ارتباط معمولا از Bus Cycle Time استفاده می‌شود. منظور از Bus Cycle Time مدت زمانی است که اطلاعات بین Master و تمامی Slave‌ ها جابجا می‌گردد. بسته به نوع پروسه مقدار نرخ ارسال و دریافت باید به گونه ای انتخاب شود که Bus Cycle Time کمترین زمان ممکن را داشته باشد. لازم به ذکر است این نرخ تابع شرایط مختلفی نظیر فاصله بین وسایل می‌باشد [41].
شکل ‏41 : ساختار Bus Cycle
در هربار ارسال و دریافت اطلاعات به هر Slave، در ابتدا Master بسته اطلاعات خود را روی Bus قرار
می دهد که در اصطلاح به آن تلگرام گفته می‌شود. تلگرام شامل یک بخش Overhead و یک بخش دیتا
می باشد. در موقع ارسال دیتا از Master به Slave تلگرام شامل اطلاعات خروجی‌های Slave نیز می‌باشد. در پاسخ هر Slave بعد از خواندن اطلاعات یک تلگرام به Master ارسال می‌نماید که این بسته نیز شامل Overhead و اطلاعات ورودی‌ها می‌باشد. به این ترتیب تمامی اطلاعاتی که می‌بایست بین Master و Slave جابجا شود تبادل شده و Master سراغ Slave بعدی می‌رود [2].
شکل ‏42: ساختار انتقال اطلاعات در پروفیباس
Bus Cycle Time به موارد زیر وابسته می‌باشد:
1. تعداد Slave ها
2. نرخ ارسال ( Transmission rate ) یا Baud Rate
3. حجم اطلاعات (ورودی و خروجی ها) [41]
مقدار دقیق Bus Cycle Time معمولا توسط سازنده تجهیزات محاسبه می‌گردد. زیرا Overhead دیتای انتقالی معمولا شامل زمان‌هایی نظیر زمان انتظار Slave‌ها می‌باشد که از مشخصه‌های فیزیکی دستگاهها بوده و در اختیار سازنده است و قابل تغییر نمی باشد. حال به محاسبه ی زمان از نظر تئوری می‌پردازیم.
تعداد بیت‌های انتقال عبارتند از:
1. Header Byte Length + output data (From Master to Slave)
2. Header Byte Length+ input data (From Slave to Master)
3. TSDR: Slave Reaction Time
4. TSYNC: Sync Time
5. Tid1: Initiator Time
:TSDR مدت زمانی است که یک Slave یک پیغام را دریافت و آنالیز و پاسخ می‌دهد و معمولا هر سازنده یک مقدارMin و Max را برای این منظور ارائه می‌دهد که بین 11Bit تا 255Bit می‌باشد.
TSYNC : حداقل زمانی است که Slave بعد از یک درخواست نیاز دارد تا بتواند درخواست بعدی را بپذیرد (idle state ) . برای Profibus-DP این مقدار 33TBit می‌باشد.
Tid1: مقدار زمان لازم بین دو تلگرام می‌باشد یعنی بعد از دریافت آخرین بیت از آخرین بایت تلگرام این مدت می‌بایست طی شود تا تلگرام جدید شروع شود. این زمان حداقل اندازه TSync بوده که تعدادی بیت جهت بالا بردن صحت ارسال (TSM: Safety Margine) به آن اضافه می‌شود.
حال برای محاسبه زمان ابتدا به محاسبه طول Head می‌پردازیم. همانطور که پیشتر اشاره شد فریم پروفیباس متشکل از Header + Data + Trailer می‌باشد که ساختار توسعه یافته آن به صورت کلی به شکل زیر می‌باشد [41].
LE
LEr
DSAP
SSAP
FCS
ED
1b
var
شکل ‏43: فریم پروفیباس
که جدول زیر نمایانگر تعداد بایت‌های هر المان و وظیفه آن می‌باشد.
جدول 4-1: معرفی هر المان و وظیفه آن در پروفیباس [41]
1 byte
Start Delimiter (used to distinguish telegram format).
Net Data Length (DU) + DA + SA + FC + DSAP + SSAP.
Length repeated.
Destination Address– Where this message goes to.
Source Address – Where this message came from. The address of the sending station.
Function Code (FC=Type/Priority of this message). Used to identify the type of telegram, such as request, acknowledgement, or response telegrams (FC=13 signals diagnostic data). See below.
Destination Service Access Point (COM port of receiver). The destination station uses this to determine which service is to be executed.
Source Service Access Point (COM port of sender).
1 to 32b
(or 1-244b)
Data Units/ Net Data from 1 to 244 bytes.
Frame Checking Sequence (ASIC addition of the bytes within the specified length).
End Delimiter (always 16H).
بسته به نوع دیتا در ساختار فوق تغییراتی اعمال می‌شود که در بحث این پروژه نبوده ولی ساختار مورد استفاده در آزمایشات یعنی ارسال و دریافت اطلاعات را بررسی می‌کنیم که ساختار فوق به صورت زیر تغییر می‌یابد.
DATA
شکل ‏44: فریم تغییر یافته پروفیباس [41]
همانطور که مشاهده می‌شود به غیر از دیتا کلا 9 بایت دیگر به فریم اضافه میگردد. حال با اضافه کردن پارامترهای TSDR ، TSYNC و Tid1 به فرمول زیر می‌رسیم:
TMC = Header + Data+ Trailer + TSDR + TSYN + Tid1
در فرمول فوق داریم:
Header = SD + LE + LER + SD + DA + SA + FC = 7Byte
Trailer = FCS + ED = 2 Byte
مقدار TSDR، TSYNC و T برای PLC‌ های زیمنس مقادیر زیر می‌باشد [65]:
TSDR: 11~60 Bit
TSYN= 33 Bit
T = 37 Bit
هر بایت دیتا با احتساب یک بیت Start ، یک بیت Stop و یک بیت Parity شامل 11Bit خواهد شد [63]. حال برای اینکه نتایج تئوری به دست آمده را با نتایج عملی مقایسه کنیم آزمایشی با PLC‌ های زیمنس ترتیب
می دهیم.
4-2-2- محاسبه زمانی ارتباط یک MASTER و یک SLAVE به لحاظ عملی
در این بخش آزمایشی جهت اندازه گیری زمان انتقال یک بایت دیتا از Slave به Master ترتیب داده تا نتایج را با اطلاعات تثوری بدست آمده از بخش قبل مقایسه نماییم. در این آزمایش یک بایت دیتا از Master به Slave منتقل کرده و سپس همان دیتا به Slave بازگردانده می‌شود. لذا یک بایت ورودی و یک بایت خروجی داریم که در کل 2 بایت دیتا می‌شود در نتیجه:
TMC = 11 × (2×(7 + 2 + 1)) + 49 + 33 + 37= 339 bit
از آنجا که نرخ ارسال 93.75Kbps می‌باشد زمان ارسال هر بیت برابر 0.0107ms می‌باشد لذا زمان هر تلگرام برابر است با:
339×0.0107 = 3.63 ms
این زمان تنها، زمان ارسال اطلاعات جدید می‌باشد. جهت مطالعه برنامه نوشته شده می‌بایست Clock Cycle هر CPU یعنی زمان اجرای برنامه را نیز به زمان بالا به صورت زیر اضافه نمود. بنابراین سیکل کاری سیستم جهت تبادل اطلاعات بین Slave و Master به قرار زیر است:
1. 1ms جهت آماده سازی بایت خروجی در Slave
2. 3.7 ms ارسال اطلاعات از Slave به Master
3. 1ms جهت دریافت در Master وآماده سازی جهت ارسال عدد به Slave
4. 3.7 ms ارسال اطلاعات از Master به Slave
5. 1ms جهت نمایش بایت ورودی در Slave
لذا کل زمان عبارتست از :
1+ 3.7+3.7+1=10.4 ms
البته می‌بایست توجه نمود از آنجا که حداقل زمان قابل محاسبه توسط PLC ، 1 ms می‌باشد این زمان به
10 ms یا 11 ms تغییر خواهد کرد. در نمودار زیر نتایج حاصل از آزمایش این سیستم به صورت عملی و در 1000 بار نمونه گیری مشاهده می‌شود که در ادامه به توضیح علل سایر مقادیر به دست آمده خواهیم پرداخت.
شکل ‏45: نمودار زمان مبادله اطلاعات بین یک Master و یک Slave
شکل ‏46: پراکندگی آماری زمان مبادله اطلاعات بین یک Master و یک Slave
همانطور که مشاهده می‌شود نتایج عملی در مقایسه با نتایج تئوری تا حدود زیادی منطبق بود، و بیشتر نتایج 10 11 ms می‌باشد. نکته قابل توجه این است که پورت پروفیباس و برنامه روی CPU به صورت مستقل کار نموده و چرخه گفته شده در بالا دقیقا پشت سر هم نمی باشد یعنی امکان دارد برای مثال دریافت دیتا در Master دقیقا با انتهای سیکل برنامه همزمان باشد که این امر باعث کاهش زمان انتظار ارسال از Master
می شود. لذا مقادیر معدودزمان های 8 ms و 9 ms به این دلیل و مقادیر 12 ms و 13 ms به دلیل عکس این اتفاق می‌باشد.
از طرف دیگر مقادیر بحث برانگیز این آزمایش 19 ms و 20 ms می‌باشد. حال به بررسی چرایی این مقادیر می‌پردازیم. با مطالعه دقیق تر زمان‌های ارسال یک CPU یعنی فاصله زمانی بین دو ارسال به این نتیجه
می رسیم که هر 256 ارسال و دریافت یک زمان 19 ms یا 20 ms داریم که کاملا متناوب و قانونمند می‌باشد.
شکل ‏47: نمودار زمان بین دو ارسال متوالی اطلاعات یک Master و یک Slave
این فاصله در اصطلاح Gap نامیده می‌شود که در آن CPU علاوه بر کار معمول به بررسی شبکه جهت پیدا کردن نودهای معیوب و یا احیانا یک Master دیگر در شبکه می‌پردازد.
4-2-3- محاسبه زمانی ارتباط یک MASTER و دو SLAVE به لحاظ تئوری
در این حالت تمام تنظیمات مانند حالت قبل می‌باشد با این تفاوت که تعداد Slave‌ها به دو افزایش یافته است. در این حالت Master در هر Bus Cycle می‌بایست هر دو Slave را بخواند پس بالطبع زمان بیشتر خواهد برد. طبق الگوریتم پروفیباس، تلگرام تغییری نکرده و برای هر Slave تمامی مراحل قبل طی می‌شود یعنی برای هر Slave، 3.7 ms طبق تئوری زمان نیاز است تا دیتا تبادل گردد. تفاوت این حالت در این است که در حالت قبل هر 3.7 ms یکبار Slave خوانده می‌شود ولی در این حالت زمان خواندن هر Slave دو برابر
می شود. درواقع فاصله‌های زمانی تغییر می‌کند.
در سیستم بسته شده هرکدام از Slave‌ها یک بایت را به Master فرستاده و Master همان بایت را به Slave مربوطه برمی گرداند. لذا مانند حالت قبل برای هر Slave دو مسیر ارسال و دریافت خواهیم داشت با این تفاوت که در بین هر ارسال و دریافت، Master ، Slave دیگر را نیز باید بخواند یعنی فاصله دوبار خواندن پشت سرهم افزایش می‌یابد. لازم به ذکر است پارامتر TSDR نیز امکان تغییر دارد که جزء مشخصات فیزیکی سیستم‌ها می‌باشد. سیکل کاری سیستم جهت ارسال اطلاعات از Slave1 به Master به قرار زیر است:
1. آماده سازی بایت خروجی در Slave 1 (1 ms )
2. ارسال اطلاعات از Slave 1 به Master (3.7 ms)
3. دریافت در Master (1 ms)
4. ارسال اطلاعات از Slave 2 به Master (3.7 ms)
5. دریافت در Master وآماده سازی جهت ارسال عدد به Slave1 (1 ms)
6. ارسال اطلاعات از Master به Slave 1 (3.7 ms)
7. نمایش بایت ورودی و محاسبه زمان در Slave 1 (1 ms)
لازم به ذکر است از آنجا که CPU در زمان ارسال و دریافت برنامه را نیز اجرا می‌نماید، مرحله ارسال اطاعات توسط Master و آماده سازی آن جهت ارسال به Slave 1 در زمان خواندن اطلاعات Slave 2 صورت میگیرد.
4-2-4- محاسبه زمانی ارتباط یک MASTER و دو SLAVE به لحاظ عملی
در این آزمایش نیز هرکدام از Slave‌ها یک بایت را به Master فرستاده و Master همان بایت را به Slave مربوطه بر می‌گرداند. لذا مانند حالت قبل برای هر Slave دو مسیر ارسال و دریافت خواهیم داشت با این تفاوت که در بین هر ارسال و دریافت، Master ، Slave دیگر را نیز باید بخواند یعنی فاصله دوبار خواندن پشت سرهم افزایش می‌یابد.
در نمودار زیر نتایج حاصل از آزمایش این سیستم به صورت عملی و در 1000 بار نمونه گیری مشاهده
شکل ‏48: نمودار زمان مبادله اطلاعات بین یک Master و دو Slave
شکل ‏49: پراکندگی آماری زمان مبادله اطلاعات بین یک Master و دو Slave
با توجه به آزمایشات انجام شده فاصله زمانی ارسال و دریافت در حدود 16 ms می‌باشد. موارد بالا و پایین شدن زمان نیز مانند حالت قبل به دلیل روی هم افتادن مراحل کاری می‌باشد.
همچنین مشاهده می‌شود Gap موجود در حالت قبل در این حالت نیز به صورت پریودیک اتفاق می‌افتد. با توجه به آزمایشات انجام شده فاصله زمانی ارسال و دریافت در حدود 16 ms می‌باشد.
4-3- محاسبه زمانی ارتباط اترنت
همانطور که در بخش پروفیباس اشاره شد برای بررسی سرعت ارسال و دریافت اطلاعات به روش تئوری و عملی ابتدا دو CPU و سپس سه CPU را به هم متصل می‌نماییم. در حالت اول یکی از CPU‌ ها به صورت متناوب به ارسال یک بایت دیتا به CPU دیگر پرداخته و زمان ارسال را محاسبه می‌کند. برخلاف پروفیباس بلوک‌های ارسال و دریافت اترنت دارای ورودی درخواست و پایه Acknowledge می‌باشد که با فعال شدن بیت درخواست، ارسال شروع و با یک شدن بیت خروجی Acknowledge ارسال با موفقیت به اتمام رسیده است. لذا برای محاسبه زمان نیاز به ارسال یک بیت به CPU دیگر و بازگرداندن آن از CPU دوم به اول نبوده و می‌توان لینک را یکطرفه برقرار نمود و یک بایت را به سمت CPU دوم فرستاد و با بررسی ورودی درخواست و خروجی Acknowledge زمان را محاسبه نمود [51].
در حالتی که سه CPU داریم دو CPU به صورت همزمان نسبت به ارسال دیتا به یک CPU اقدام نموده و در نتیجه بر اثر برخورد‌های حاصل، انتظارمی رود زمان ارسال افزایش می‌یابد. ابتدا به بررسی تئوری و نحوه ارسال می‌پردازیم. پروتکل پروفینت بر پایه اترنت بنا شده است. لذا از همان فرمت استفاده می‌نماید. پروفینت دارای قابلیت‌های بیشتری نسبت به اترنت معمول بر مبنای IEEE می‌باشد که استفاده از ان قابلیت‌ها مستلزم بکارگیری تجهیزات دارای کانکتور پروفینت نظیر PLC‌ ها می‌باشد که در آن پروتکل بر پهنای باند نظارت داشته و ارسال و دریافت را کنترل نموده و قادر به ارتباطات سنکرون می‌باشد ولی در کل این پروتکل طوری طراحی گردیده است که در یک شبکه IEEE نیز مورد استفاده قرار می‌گیرد و قادر به مبادله اطلاعات بین یک وسیله پروفینت و یک وسیله معمول مانند کارت شبکه کامپیوتر می‌باشد که این یکی از مزایای شبکه صنعتی زیمنس نسبت به برندهای دیگر نظیر V-net IP یوکوگاوا می‌باشد. لازم به ذکر است V-net IP تنها با کارت شبکه یوکوگاوا قادر به اطلاعات می‌باشد [15].
برای بررسی ابتدا فریم IEEE را در زیر می‌بینیم:
شکل ‏410: فریم IEEE [5]
چنانچه فریم‌ها پشت سر هم ارسال شود بین هر دو فریم 12 بایت به عنوان Gap نیز وجود خواهد داشت. پروفینت نیز از فریم بالا جهت ارسال و دریافت اطلاعات استفاده نموده و اطلاعات خود را در user data قرار می‌دهد. برای پروفینت داریم [66]:
شکل ‏411: فریم پروفینت [66]
همانطور که مشخص است دو فریم کاملا برهم منطبق می‌باشند. در فریم فوق برای پروفینت، Data Type 8892H می‌باشد [66]. طول دیتا در فریم فوق برابر 72 تا 1528 بایت می‌باشد. چنانچه user data از 46 بایت کمتر باشد به آن Pad (صفر) اضافه می‌شود تا به 46 برسد. از آنجا که در برنامه نوشته شده تنها یک بایت منتقل می‌شود تعداد بایت‌های انتقالی حداقل می‌باشد لذا در هر بار مبادله اطلاعات 72 بایت به همراه 12 بایت Gap ارسال خواهد شد [5]. محاسبه زمان در شبکه‌های مبنی بر اترنت به سادگی شبکه‌های سریال نظیر پروفیباس نمی باشد، زیرا در شبکه پروفیباس تنها عناصر Active و دارای تاخیر، پورت‌های CPU می‌باشند و وسیله خارجی دیگری در مدار نمی باشد ولی در اترنت وجود هاب باعث ایجاد تاخیر در مدار می‌گردد. همچنین از آنجا که مدیریت باس وجود ندارد و فرستنده‌ها بر اساس تاخیرات تصادفی به ارسال اطلاعات می پردازند زمان‌ها دقیق نمی باشند. از سوی دیگر بسته به حجم اطلاعات تعداد وسایل روی باس، درصدی از پهنای باند استفاده می‌شود. یعنی با وجود اینکه پهنای باند شبکه اترنت 100 Mbps می‌باشد ولی به دلایل فنی فوق تمامی این پهنای باند استفاده نمی شود و معمولا از چند صد کیلو بایت فراتر نمی رود. عدد ارائه شده بر روی Hub به عنوان Network Utilization موکد این مطلب می‌باشد که همانطور که در تصویر زیر می‌بینید در ارسال و دریافت‌ها از 1% پهنای باند استفاده می‌شود.
شکل ‏412: Network Utilization
این عدد در زمان ارسال فایل توسط دو کامپیوتر به 100% افزایش می‌یابد.
شکل ‏413: Network Utilization با دو کامپیوتر
مشخصه دیگری که بر روی هاب مورد استفاده وجود داشت چراغ تصادم می‌باشد که با هر تصادم اتفاق افتاده در شبکه روشن می‌شود. درواقع چشمک‌های این چراغ میزان تصادم را نمایش داده و هرچه بیشتر باشند تصادم بیشتری اتفاق افتاده است.
در زمان وجود دو CPU هیچگونه تصادمی نداریم و با افزایش تعداد به سه، هر چند لحظه یکبار تصادم اتفاق می‌افتد. چنانچه دو کامپیوتر به سیستم اضافه شود درصد تصادم به طور چشمگیری افزایش می‌یابد.
شکل ‏414: تصادم در هاب
برای بدست آوردن سرعت انتقال، از اطلاعات قرائت شده CPU خود نرم افزار استفاده می‌نماییم. چنانچه از CPU در حال کار Module Information بگیریم در قسمت Connection Statistic می‌توان تعداد بایت ارسال و دریافت شده در 5 ثانیه گذشته را مشاهده نمود که این مقدار حدود 77000 بایت می‌باشد [67].
شکل ‏415: Connection Statistic [68]
در نتیجه زمان ارسال هربایت برابر 71.4 µs می‌باشد. دلیل پایین بودن این عدد نسبت به پهنای باند اترنت به مشخصه فیزیکی CPU ها نظیر سرعت باس داخلی آنها و نحوه در دسترس قرار گرفتن باس و تاخیرات تصادفی در نظر گرفته شده جهت در اختیار گرفتن باس می باشد که بنابه شرایط فوق هر ارسال و دریافت حدود 12 ms برای 166 بایت و حدود 6 ms برای 84 بایت زمان خواهد بود که به این اعداد 1 ms جهت CPU Cycle اضافه خواهد شد. مجددا یادآوری می‌شود که تمامی اعداد به صورت تقریبی قابل محاسبه می‌باشد. در بررسی عملی سیستم فوق اعداد زیر حاصل شده است که با تقریب خیلی خوبی با نتایج تئوری مطابقت دارد.
شکل ‏416: نمودار زمان مبادله اطلاعات بین دو CPU با اترنت
شکل ‏417: پراکندگی آماری زمان مبادله اطلاعات بین دو CPU با اترنت
با افزایش تعداد CPU‌ها به سه عدد، پهنای باند بین CPU‌ ها تقسیم می‌شود. لذا انتظار



Copyright 2018. All rights reserved.

Posted آگوست 6, 2018 by 92 in category "مقالات

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *