گزارش سمینار چارچوبی برای انتخاب میان افزار مناسب سیستم های بی درنگ توکار

سمینار کارشناسی ارشد مهندسی کامپیوتر 

گرایش نرم افزار  

چکیده 

میان افزار، که به طور فزاینده ای در سی ستم های از لحاظ نرم افزار ی بزرگ استفاده می شود، نرم افزاری است که میان برنامه های کاربرد ی و سی ستم عامل و شبکه ز یرین قرار می گی رد و مسوول پل زدن روی فاصله میان برنامه کاربردی و زیرساخت نرم افزار/سخت افزار سطح پایین تر است. 

میان افزار مولفه ای در ابتدا برای پشتی نبا ی از سیستم های سازمانی مانند سیستم های رزرواسیون اهو یی، س یستم ها ی مد یریت سرما یه ها ی بانک ی و غی ره ساخته شد. اخی را به کار بردن می ان افزار در سی ستم های  بی درنگ توکار توزیع شده(DRE) آغاز شده است، سی ستم ها یی مانند س ی ستم کنترل فر آیند، دستگاه های موبایل و سیستم های تشخیص روی صفحه2 در اتومبیل ها. بنا به تعریف سیستم های DRE، از لحاظ کارآیی حیاتی اند و نیازمندی های کیفیت خدمت(QoS) سخت و دقیقی برای تاخیر، کارآمدی،

مقیاس پذیری و امنیت دارند. 

در  این جا بر آنیم تا با شناخت دقی ق تر خصوصیات ای ن سی ستم ها نقش می ان افزار را به وضوح در

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

کلمات کل  یدی سیستم ب ی درنگ توکار توزی ع شده، م ین افزار، معماری می ان افزار،Real-time

فصل 1- اگر یش های جدید در دامنه سیستم های بی درنگ توکار توزیع

شده 

1- 1-  مقدمه 

انواع مختلف ی از سی ستم ها ی ب ی درنگ توکار توزیع شده [1] (DRE) وجود دارد اما همگی در ی ک چی ز

مشترک اند : پاسخ درس تی که دیر داده شود تبدیل به پاسخ نادرست می گردد، به عنوان مثال در کاربردهای (غیر نظام ی) کنترل دما ی خنک کننده راکتور هسته ای  ی ا اطم ینان حاصل کردن از کیفی ت و ضخامت فولاد در یک دستگاه فورد کاری داغ. به تازگی شاهد گرایش ها ی جد یدی در سی ستم ها ی DRE به صورت

زیر هستیم [1]: 

فن آو ری اطلاعات در همه اشکال بسیار کالاگرا[2] می شود (یعن ی محصولات سخت افزاری و نرم

افزاری، سریع تر، ارزان تر و بهترمی شوند، همگی با نرخ نسبتا قابل پیش بینی) 

پذیرش فرآیند: الگوی شبکه محور، جایی که برنامه های DRE دارای طیفی از نیازهای کیفیت

خدمت(QoS)، با مجتمع  کردن مولفه های جداگانه و متصل شده با سرویس های محاسباتی و ارتباطی

مختلف ساخته می شوند. 

ماهیت اتصالات مابین برای سیستم های DRE طیف زیر را در بر می گیرد: 

1- از اتصالات خیلی کوچک و سفت به هم بسته[3] مانند س ی ستم ها ی محاسبات مامور ی ت ه ای هو ایی

و تکنولوژی "بردار و قرار بده"[4] برای سوار کردن تراشه ها روی بردهای اصلی، تا 

2- اتصالات بسیار بزرگ و شل به هم بسته[5] مانند س ی ستم ها ی ارتباط راه دور سراسری و سی ستم ها ی

حس گر شبکه شده مورد استفاده در کنترل دمای ساختمان و مصرف انرژی. 

ثتا یر متقابل این  دو گرایش، مفاهیم و سرو یس ها ی جدی د معماری را حول محور می ان افزار استاندارد ابر ی سیستم های DRE برانگیخته است. 

چرا نیازمند میان افزار استاندارد برای توسعه سیستم های بی درنگ توکار توزیع شده هستیم؟ 

به دلیل پای بست های روی وزن، مصرف توان، رد پا ی حافظه وکارایی، تکنیک های توسعه و

متدولوژی ها ی استفاده شده برای نرم افزار های DRE به صورت تاریخی از جری ان اصلی نظا یرشان در

نرم افزارهای  سازمانی و رو م ی زی عقب مانده اند . در نتیجه، سیستم های نرم افزاری DRE توسعه،

نگهداری و  تکامل شان پرهز ینه است. علاوه براین اغلب چنان وی ژه شده اند که نمی توانند به راحتی بر ای

براورده ساز ی  نیازمند یهای جد ی د وظ یفه مندی ی ا ک یفی ت سرویس و نوآوری ها ی تکنولوژی سخت افزار،

نرم افزار یا فرصت های بازار تطبیق داده شوند. 

برنامه نو یسی س یستم ها ی DRE دشوار است بخش ی به  ای ن خاطر که بعضی ویژگیها ی QoS بای د به

همراه وظیفه مندی نرم افزار کاربردی و میان افزار محاسبات توزیع شده پشتی نبا ی شود. 

ویژگیهای QoS کلیدی شامل این مواردند: 

به اشتراک گذاری منابع، همزمانی و هماهنگ سازی عملیات همزمان

پای بست های زمانی ورودی حس گر[6] و خروجی فعال کننده[7]

اختصاص، زمانبندی و انتساب اولویت به محاسبات و منابع ارتباطی به صورت انتها به انتها

مدیریت حافظه

به صورت تاریخی، برنامه های کاربرد ی سی ستم ها ی DRE به صورت دستی برنامه سازی سفارشی می شدند تا این ویژگیهای QoS را پیاده کنند. متاسفانه این فرایند توسعه دستی مستعد خطا و خسته

کننده، به مقدار زیادی در پرداختن به چالش های زیر نا موفق بوده است: 

چند ین سکو[8] و متن های عمل ی اتی  متغی ر: سی ستم های DRE مدرن بای د رو ی بخش همی شه در

حال افز ایشی از وظیفه مندی در نرم افزار سرما یه گذاری کنند. فن آوریها ی سریعا پدی دار شده و انعطاف

پذ یری مورد نیاز بر ای متن های عملیاتی گوناگون، استقرار چند ین نسخه از نرم افزار را رو ی سکوهای مختلف مجبور می کنند، در حالیکه همزمان ویژگیها ی  کل یدی مانند پاسخ بی درنگ و حفظ اولوی ت انتها به

انتها را حفظ می نمایند. 

هزینه ها ی جمعی مالکیت: توسعه وتکامل نرم افزار سفارش ی بر ای سیستم های DRE پیچیده

بسیار  نیروی کار طلب و مستعد خطاست، مانند هواپیماها ی نیمه خودکار(هد ایت شده توسط کامپیوتر) ی ا

سیستم های حمل و نقل خودمختار، و می تواند نماینده بیش از50 درصد کل هزینه های مالکیت این

سیستم ها باشد. 

گرا یش ها ی از رده خارج شده: مدت عمر نامتناسب می ان س ی ستم های DRE دراز عمر (20سال

یا بیشتر) و سکوها و ابزارهای مولفه های حاضر تجاری[9](COTS)(2 تا 5 سال) منجر به از رده خارج

شدگی وس یع نرم افزار م ی شود و هزینه های جمع ی مالکی ت را با  نی از به تو سعه مجدد متناوب نرم افزار و

تازه سازی COTS، چند برابر می کنند [1].

بعضی  این چالش  ها مشابه همان ها یی هستند که جر یان اصل ی سی ستم ها ی توزی ع شده  نی ز با آن ها

روبرو شده و جنبه های دیگر مختص سیستم های DRE می باشند. 

ابر ی دس تیابی به هزینه ها ی توسعه پایین تر و زمان ارای ه به بازار سریع تر، راهبرد های توسعه نرم افزار

های س یستم ها ی DRE به سمت آن چه در خط اصلی توسعه نرم افزار های سی ستم ها ی سازما نی مورد

استفاده قرار م ی گیرد حرکت می کند. بد ین صورت  آینده س ی ستم ها ی DRE بس یار نوی د بخش به نظر می

رسد چرا که انعطاف پذیری و تطابق پذیری می ان افزار های Real-Time CORBA و RTSJ آن ها را

بر ای توسعه در بسیاری از انواع س یستم ها ی DRE مناسب می سازد و همچن ین محدود یت ها ی زمان و

فضای بسیار سختگیرانه که مشخصه سیستم های DRE است اکنون در ORB های ویژه شده قابل

برآورده سازی اند. 

در ادامه ،  این گزارش به ای ن ترتی ب سازمان دهی شده است: ابتدا سابقه تحقی ق و کار های انجام شده

در ای ن زمینه آورده شده است. در فصل دوم به بررسی خصیصه ها ی دقی ق سیستم ها ی DRE و بررسی جداگانه هر یک از جنبه های مهم آن و ارتباط می ان آن ها در  دامنه  ای ن گونه  سی ستم ها می پرداز یم. سپس

در فصل سوم برخی چالش های اصلی س ی ستم های DRE مورد بازبینی قرار می گ ی رد همچنان که تحقی ق

و توسعه صورت گرفته روی  ای ن مسایل و س یاست های دور زدن آن ها تشریح م ی گردند . فصل چهارم به

نوآوری ها و ویژه ساز ی ها یی م ی پردازد که برای کارکرد دقی ق م ی ان افزار های DRE ح  یاتی اند. همچن ین

در  این فصل تکنولوژی مناسب پی اده سازی نرم افزار های DRE و می ان افزار های تجار ی مورد استفاده و

خصیصه های آن ها مقایسه و انتخاب خواهند شد. فصل پنجم نتیجه گیری مباحث مطرح شده را در

بردارد و راه تحقیق آینده را مشخص می سازد و در آخر درفصل ششم منابع مورد استفاده آورده شده

است. 

2- 1-  سابقه تحقیق 

کار های انجام شده مرتبط با موضوع تحقی ق ای ن گزارش را می توان به صورت زی ر گروه بندی و

توصیف کرد: 

میان افزار سفارشی سازی: MicroQoSCORBA [2] ردپای میان افزار را با تولید نمونه سازی

های سفارش ی شده برای  سی ستم های بی درنگ توکار کاهش می دهد. ZEN [3] نمونه ای از ی ک واسطه

درخواست شی[10] (CORBA (ORB با قابلیت سفارشی سازی بالا و پیاده سازی شده با جاوای بی

درنگ می باشد . پروژه های CORBA مانند و ی ژه ساز ی کمینه از هسته تعامل پذیر سراس ری(UIC) [4]

از فرابرنامه نویسی[11] استفاده می کنند تا درجه زیادی از سفارشی سازی میان افزلر را پشتی نبا ی کنند. 

ماش ین ها ی مجاز ی ب ی درنگ : مشخصات بی درنگ برای جاو ا(RTSJ) [5] ویژگ ی ها ی مدیریت

حافظه و زمان بندی  ای را تعریف م ی کند که اجازه نوشتن نرم افزار های  بی درنگ بهJava  را م ی دهند .

پیاده سازی jRate [6] ازRTSJ  توسعه های د یگر ی را برای مدیریت حافظه تدارک می  بیند . Giotto وE-Machine [5] یک مدل زیرساختی تجریدی و ماشین مجازی ای برای سیستم های کنترل توکار با

پای بست های بی درنگ سخت ارایه کرده اند. 

میان افزار مدل گرا[12]: محیط های  پیکر بندی مدل گرا برای م یان افزار مانند مجموعه ابزارCoSMIC  

[7] از گردآوری، استقرار و پیکربندی یکپارچه مولفه ها بالای میان افزار بی درنگ پشتی نبا ی می کنند.

CADENA [7] یک محیط یکپارچه دیگر بر ای ساختن و مدل سازی سیستم های مدل مولفهCCM)CORBA)[13] م ی باشد. DREAM [8] به طراحان س یستم های DRE اجازه م ی دهد تحلیل

قابل زمان بندی بودن س یستم های DRE را بر مبنای مدل انجام دهند. DREAM ی ک مدل محاسباتی را

که دامنه معنایی DRE خوانده می شود  پی شنهاد  می کند که شامل وظایف، زمان سنج ها، کانال های

رویداد و زمان بند ها می شود و از آن برای تع  یین قابل زمان بندی بودن ی ک مجموعه مشخص از وظایف

با زمان مشخص و محاوره های بر پایه رویداد استفاده می گردد. 

فصل 2- عناصر و جنبه های مختلف یک سیستم بی درنگ توکار و نقش متقابل آن ها 

بیشتر چالش های س  یستم های بی درنگ توکار از ا ین حقیقت ناشی م ی شود که بای د با موجود ی ت

های دن یا ی واقعی محاوره کنند که می توانند بسیار پیچی ده باشند و به تعداد بسیار ز یاد. همچن ین ترتی ب

دقیق رو یدادها هم ممکن است بسیار متغی ر باشد بنابراین سی ستم ها ی ب ی درنگ با ی د به محاورات بیرون ی

در یک مقدار زمان از قبل مشخص شده پاسخ دهند. 

در نت یجه طراحان بای د خی لی زود روی نیازمند ی ها ی پاسخ های ب ی در نگ تمرکز کنند علاوه بر ای ن

که منابع محدود س یستم را در نظر بگیرند. در طی مرحله طراحی، معماری، مهندسی نرم افزار و سخت

افزار با یکدیگر کار می کنند تا بتوانند معماری درس تی را که  ای ن نیازمند ی ها را  براورده می سازد انتخاب

کنند. این کار شامل تصمیم گ  یری راجع به ارتباط درونی پردازنده ها، سرعت اتصالات، سرعت پردازنده

ها و غیره می شود. سوالات اصلی که باید پرسیده شوند اینها هستند: 

آیا معماری مناسب است؟ 

اگر ارتباط پیامی شامل گره های ز یادی م ی شود، محتمل است که به دلی ل ازدحام حتی ملای م، سی ستم

قادر براورده ساختن نیازمندی  بی در نگ نباشد. بنابر این ی ک معمار ی ساده تر شانس بی شتری بر ای براورده

سازی نیازمندی بی درنگ دارد. 

آیا سرعت اتصالات کافی است؟ 

به صورت کلی، بار گذاری ی ک اتصال بیش 40% تا 50% ای ده بدی است. به کار گ یری بی شتر ی ک

اتصال باعث می شود تا صف هایی رو ی گره های مختلف ساخته شوند بنابراین موجب مقادیر متغ یری از

تاخیر در ارتباط پیام می گردد.