بخشی از مقاله
یک نگرش چندعامله گسترده برای افزایش تحمل پذیری خطا
چکیده : ایجاد تحمل پذیری خطا در سیستمهای گسترده، امری دستیافتنی و در عین حال دشوار است. یک سیستم چندعامله به عنوان نمونه مهمی از سیستم های گسترده با بهرهگیری از تکنیکهای رایج تحمل پذیری خطا میتواند قابلیت کنارآمدن با انواع متفاوتی از خطاها را پیدا کند. اما آنچه در این مقاله مورد تاکید است استفاده از ذات چندعامله سیستمها و بهرهگیری از تکنیکهایی است که برخاسته از ویژگیهای خاص سیستمهای چندعامله است.
در این طرح در صورت بروز مشکلی برای یک یا تعدادی از عامل ها، عامل های همتیمی او با اعمال تغییراتی متناسب در وظایف خود سعی در کمک به او مینمایند و وظیفه وی را نیز با همکاری یکدیگر به دوش میگیرند و تا زمانی که مشکل آن عامل برطرف نشده به این روش از کاهش کارایی سیستم جلوگیری میکنند. این همکاری با یک تصمیمگیری گسترده و در طی چند فاز مختلف صورت می گیرد تادر صورت وجود چندین عامل نیازمند کمک، در نهایت عامل هایی با اولویت بالاتر برای کمک انتخاب شوند که بیش از بقیه در کارایی کلی تیم موثرند.
کلمات کلیدی : سیستم چندعامله، تحمل پذیری خطا، درخواست کمک، تصمیمگیری گسترده.١
١. مقدمه
یک سیستم گسترده را می توان به منزله تیمی از عامل های همکار٢ دانست که هر یک وظیفه خاصی به عهده دارند و از تعامل آنها با یکدیگر یک عملکرد واحد حاصل میشود. این شیوه نگرش موجب می شود که بتوان از ایده سیستمهای چندعامله برای توسعه یک سیستم گسترده تحمل پذیر خطا استفاده کرد.
یکی از تکنیکهای رایج برای ایجاد تحمل پذیری خطا در یک سیستم، استفاده از افزونگی٣ است. خاصیت چندعاملی و عملنمودن به صورت مستقل از یکدیگر خود نقطه امیدی است بر این مطلب که در صورت وقوع یک خطا، این مشکل به کل سیستم توسعه نمی یابد و از گسترش آن به نقاط دیگر جلوگیری میشود. علاوه بر افزونگی صرف، در سیستمهای چندعامله، تکنیکهای پیشرفتهتری هم برای ایجاد تحمل پذیری خطا وجود دارد و آن استفاده از خود عامل های موجود در سیستم برای رفع کاستیهای ناشی از خطای عامل همتیمی آنهاست.به بیان دیگر به جای جایگزین نمودن یک عامل خراب با یک عامل دیگر از خارج، از قابلیت های در حال حاضر اضافه دیگر عامل های موجود در طرح استفاده کنیم و نقش عامل خراب را نیز به نحوی بر دوش همکارانش قرار دهیم تا شرایط بحرانی موجود با کمترین تاثیر نامطلوب بر کارایی مرتفع گردد.در اصل علت استفاده از یک محیط چندعامله برای بیان ایدههای این مقاله آن است که در چنین محیطی عناصر متفاوتی برای تقبل نقش یک عامل خراب در سیستم وجود دارد و تنها استفاده مناسب از منابع موجود در سیستم بر عهده روتین تحمل پذیری خطاست.
در این مقاله نیز بهرهگیری از خود عامل های درگیر در حل مساله به منظور رفع خطا در سیستم مورد تاکید است بدون اینکه از عامل واسطه ای٤ به منظور ایجاد هماهنگی در تنظیم وظایف جدید استفاده شود.به بیان بسیار خلاصه، یک عامل در صورت مواجهه با مشکلی که وی را از ادامه همکاری بازدارد، یک پیام درخواست کمک صادر میکند و سایر همتیمیهای خود را از این واقعه مطلع میکند.دیگر عامل ها با دریافت درخواست وی بررسی میکنند که آیاامکان کمک به وی را دارندیا خیر. این بررسی از طریق یک فاز تصمیمگیری صورت می گیرد. در صورت تمایل به کمک و در صورتی که تعدادی عامل، خراب و نیازمند کمک باشند، عامل های کمک رسان بررسی میکنند که به کدام عامل ها و با چه ترتیبی کمک نمایند.
در این مقاله پس از بررسی کارهای مشابه انجام شده در این زمینه که غالبا مرتبط با تشخیص خطا١ هستند و نه رفع خطا٢، روش پیشنهادی این مقاله را تشریح میکنیم و در ادامه به بیان نحوه تحقق بستر آزمون٣ میپردازیم. در ادامه معیار ارزیابی کارایی شرح داده می شود و بعد از توضیحی در مورد سناریوی آزمون و نتایج شبیه سازی، نتیجهگیری و کارهای آینده مطرح میگردد.
٢. مروری بر کارهای مشابه
در مورد ایجاد تحمل پذیری خطا در یک سیستم چندعامله، دو دیدگاه متفاوت وجود دارد : اولین نظریه بر این اصل استوار است که چون سیستمهای چندعامله ساختار ماجولار دارند، ذاتاﹰ تحملپذیر خطا هستند و اگر خطایی در یک ماجول بروز نماید می تواند از کل سیستم ایزوله شده و در سیستم انتشار نیابد. نظریه دوم بیان میکند که سیستمهای چندعامله ذاتاﹰ غیرامن هستند و چون کنترل در آنها توزیع شده بوده و تا حد زیادی غیرقطعی هستند، نمیتوان یک رفتار را به ویژه در شرایط خطا تضمین نمود]٣.[
در بسیاری از تحقیقات انجام شده در حوزههای ٤MAS و ٥DAI عموماﹰ فرض میشود که عامل ها بدون خرابی هستند و تئوری ها و معماریهای ارائهشده از بحث در مورد عامل های دچار اشکال اجتناب می کنند. در ادامه چند نمونه از تحقیقاتی که تحملپذیریخرابی در سیستمهای چندعامله نرمافزاری را به صورت محدود و در شرایط خاص فراهم آورده اند ذکر شده و سپس مرتبط ترین کارها به\ زمینه این پژوهش را با شرح بیشتری بیان میکنیم.
در ]١[ محیطی برای سیستم های توزیعشده همکار پیشنهاد شدهاست. هر یک از این سیستم ها به عنوان یک عامل خودمختار٦ در نظر گرفته می شود و مجموعه عامل ها برای حل مسائل کاربردی واقعی که طبیعتی گسترده دارند با هم همکاری دارند. در این محیط، تحمل پذیری خرابی با جایگزینی عامل های خراب انجام می شود و پس از جایگزینی عامل در برنامه گروه تجدیدنظر صورت میگیرد.
در]٢[ یک سری سرویس های مستقل از دامنه٧ برای رفع خطاهایی مانند حالات استثنایی٨ که ممکن است در محیط رخ بدهد، با اعمال نمودن تغییراتی به پروتکل هماهنگ سازی٩ معروف تیمهای چندعامله یعنی Contract Net معرفی شده است. در]٣[ استفاده از عامل های محافظ١٠ به عنوان روشی برای ایجاد تحمل پذیری خطا در سیستم های چندعامله پیشنهاد شده است. عامل های محافظ، به منظور حفظ یک سری ویژگی ها در سیستم و نیز جلوگیری از ورود سیستم به وضعیتهای ناخواسته در سیستم قرار میگیرند. عامل های محافظ یک ساختار کنترلی برای سیستمهای چندعامله پدید میآورند. علت استفاده از عامل های محافظ آن است که آزادی عامل ها را در جایی که لازم است به منظور حفظ جامعیت سیستم محدود نمائیم ولی این کنترل آزادی باید ساده و قابل تغییر باشد.در]٤[ استفاده از کارتیمی برای ساختن معماری مقاومی که بتواند بر خرابیهای احتمالی واسطها، فائق آید، پیشنهاد شده است.در این روش با استفاده از عملکرد تیمی همواره به صورت تضمینشدهای تعدادی واسط فعال در سیستم چندعامله داریم که عامل های دیگر با آنها در ارتباطند.
کاری نسبتا متفاوت در]٥[، یک مکانیزم ساختاردهی مجدد به وسیله روشهایی که در رشد جنین موجودات زنده استفاده میگردد را بیان می کند.
در این سیستم نشان داده شده است که استفاده از ویژگیهای سطح پایین و با سرعت بالا که در رفع خطای سیستم بدن جنین در طی فرایند تکاملی شکل میگیرند، روشی مناسب برای کاربردهای کنترلی بلادرنگ است. مفهوم Embryonics که از ترکیب واﮊهای جنینشناسی١١ و الکترونیک استخراج شده است، از ایدهرشد جنین در ارگانیزمهای چند مولکولی گرفته شده است.
ایده اصلی این روش در نحوه پیادهسازی ساختاردهی مجدد است که قابلیت هر سلول یا گروهی از سلول ها را توسط همسایههای آنها مشخص می کند و بر اساس این روش، عملکرد هر سلول در صورتی که در موقعیت دیگری در بدن جنین قرار بگیرد، تفاوت خواهد نمود. این مساله به این شکل امکانپذیر میگردد که هر سلول یک کپی کامل از DNA که ارگانیزم را توصیف میکند دارا باشد.
اکنون به تحقیقاتی که بیش از بقیه به جهت گیری این مقاله نزدیک هستند، میپردازیم. در یک سیستم چندعامله، ایده متفاوت برای تحمل پذیری خطا این است که وقتی عاملی، خطایی را در یک سیستم چندعامله مشخص نمود، سیستم به گونه ای تغییر ساختار یابد که یا خطا را برطرف نماید یا به نحوی با آن کنار بیاید.منظور از تغییر ساختار، تغییر عامل های همکار یا تغییر در تعداد عامل های سیستم گسترده میباشد. رفتارتحملپذیرخرابیدر ربات متحرک به معنای آشکارسازی و تشخیص خرابی ها به صورت خودکار و توانایی ادامه فعالیت پس از بروز خرابی می باشد. ]٦[ به آشکارسازی وتشخیص خرابی میپردازد و هدف آن توسعه روشی است که رباتهای متحرک را در آشکارسازی، تشخیص و بر طرف کردن خرابی ها یاری رساند. ALLIANCE یک معماری کنترلی توزیع شده تحملپذیرخرابی برای رباتهای همکار غیرمتجانس١٢ است که با انتخاب اعمال به صورت تطبیقی، کنترل همکاری بین رباتها را انجام میدهد.
انتخاب عمل به صورت تطبیقی با توجه به علایق ربات ها وتحلیل کارآیی سایر رباتها در زمانهای گذشته و حال انجام میشود. در ]٧[ و ]٨[ ویژگیهای عمومی وظایف در مأموریت یک گروه از رباتهای همکار بررسی شده، که نتیجه آن توصیه روش کمک رسانی رباتها به یکدیگر برای افزایش تحمل پذیری خرابی می باشد.در این روش با توسعه معماری ALLIANCE قابلیت کمک رسانی به آن اضافه شده است.
در ]٩[ کمک رسانی در یک سیستم چندعامله به منظور افزایش تحمل پذیری خطا شرح داده شده است که در آن صرف ضریب بحرانی١ بودن وظیفه یک عامل محتاج به کمک را، ملاک تصمیم گیری عامل کمک رسان قرار داده و از پرداختن به پارامترهای دیگر در تصمیم گیری پرهیز نموده است.
]١٠[ چند استراتژی برای ریسک کردن در کمک رسانی را معرفی نموده است.
منظور از ریسک آن است که یک عامل بدون اینکه به زمان رسید وظیفه خود توجه کند، اقدام به کمک رسانی می کند و در صورت رسیدن وظیفه جدیدی برای خود عامل، به علت اولویت بالاتر کارخودش، کار کمک رسانی با وقفه مواجه میشود. در ]١١[ مساله ناشکیبایی٢ عامل در کمک رسانی پرداخته شده است و یک عامل، پیش از تصمیمگیری نهایی برای کمک که بر اساس استراتژیهای پایهای برای زمانبندی صورت میگیرد، میزان میل به کمک رسانی را در خود بررسی می کند . در صورت رسیدن میل به آستانه، عامل اقدام به بررسی فاز بعدی تصمیم گیری برای کمک می کند و بر مبنای نتیجه این مرحله که طی آن، عامل های مناسب کمک رسانی را از میان عامل های محتاج به کمک برگزیده است، ترتیب کمک رسانی نهایی را نیز تعیین میکند. در ]١١[
ضریب بحرانی بودن وظیفه عامل ها در تعیین میزان ناشکیبایی دخالتی نداشته و در اصل میزان اهمیت وظیفه عامل ها درست به اندازه یکدیگر است. درحالیکه در ]١٢[ تعریف میزان ناشکیبایی توسعه یافتهاست و با در نظر گرفتن ضریب بحرانهای متفاوت برای وظیفه عامل ها، فرمول محاسبه کارایی متفاوتی هم ارائه شدهاست. این مقاله به عنوان ادامه ای از کارهای انجام شده، سیاستهای زمانبندی ترکیبی٣ در کمک رسانی را معرفی میکند وبا توجه به آزمایشهای متعدد انجام شده، نشان می دهد که توجه به تمایل عامل به کمک رسانی و استفاده از سیاستهای ترکیبی، کارایی سیستم را به طور قابل توجهی بهبود میبخشد.
٣. روش پیشنهادی
در این بخش فلسفه ارائه و شرح کامل این روش به عنوان یک روش ایجاد تحمل پذیری خطا دریک سیستم چندعامله مطرح میشود.
محیط و فرضیات
به منظور معرفی بهتر ایدهها، یک سیستم چند عامله نوعی مشابه یک سیستم کنترل گسترده٤ برگزیده شده است. در این سیستم تعدادی عامل وجود دارند که هر یک وظیفه خاص خود را دارند و داده های مورد نیاز آنها توسط یک تولید کننده داده، تولید شده و توسط یک باس مشترک در اختیارشان قرار میگیرد. در اصل این دادهها حکم دادههای ورودی از طریق سنسورهای موجود در محیط کنترل گسترده را دارند و هر عامل با پردازشی که روی داده ورودی خود انجام میدهد، یک فرمان کنترلی برای محرک خارج از محیط ارسال میکند. این فرمان در حقیقت، خروجی هر یک از عامل هاست که به صورت مستقل از بقیه تولید شده و روی باس خروجی قرار میگیرد. در این سیستم یک شبیه ساز خطا نیز وجود دارد که به صورت تصادفی موجب بروز خطاهایی با طولهایی متفاوت برای هر یک از عامل ها میشود.
در این سیستم به مساله تشخیص خطا پرداخته نشدهاست و فرض بر این است که هر عامل قادر است از رخداد خطای خود آگاهی یابد و این مساله را با ارسال درخواست کمک به بقیه نیز اطلاع دهد. بنابراین یک باس مشترک به منظور انتقال درخواستهای کمک وجود دارد. این درخواست کمک باید حتیالامکان کوتاه بوده و حاوی مهمترین اطلاعات مورد نیاز برای کمک رسانی به دیگر عامل ها باشد. علاوه بر این فرض شده است که یک عامل قادر است وظیفه همتیمیهای خود را نیز در مواقع لزوم انجام بدهد. فرض دیگری که در سیستم لحاظ شده آن است که ضریب بحران وظیفه هر عامل با عامل های دیگر متفاوت است و بنابراین فرمول کارایی سیستم که در بخش٥ به آن اشاره شده است، با توجه به ضریب بحران وظیفه عامل ها محاسبه میشود.
هر عامل باید از متوسط/ ماکزیمم زمان اجرای وظیفه دیگر عامل ها آگاهی داشته باشد. این اطلاع، عامل را یاری می کند تا در مورد امکان سنجی کمک مورد تقاضا تصمیم بگیرد. علاوه بر این، زمان واقعی انجام کار هر عامل ثابت نیست و این خود بر پویایی مساله میافزاید. به منظور جلوگیری از ارسال کمکهای تکراری به یک عامل که موجب به هدر رفتن امکانات و توان سیستم میشود، عامل های کمکرسان پیش از کمک، وضعیت یک پرچم مشترک اختصاصی را بررسی میکنند. اگر وضعیت این پرچم پایین باشد به این معناست که تا این لحظه به این عامل کمکی نشده است و بنابراین هر کمکی که ارسال شود مطلوب خواهد بود. اما در صورتی که این پرچم بالا باشد، عامل کمکرسان متوجه میشود که در مورد داده فعلی به این عامل کمک شده است و در صورت ارسال کمک، این کمک تکراری خواهد بود. با ارسال داده جدیدی برای یک عامل، پرچم دوباره به حالت پایین میآید تا امکان کمک رسانی را فراهم نماید.
معرفی روش
همانطور که قبلا نیز بیان شد، هدف این تحقیق ارائه روشهایی است که در آنها خود عامل ها به صورت گسترده و با تغییر نقش، اقدام به کمک رسانی به عامل های خراب میکنند تا از کاهش کارایی جلوگیری شده و سیستم با تحمل پذیری خرابی بیشتری قادر به ادامه کار باشد.
در این روش، کمک رسانی هنگامی آغاز میشود که یک عامل با مشکلی مواجه شود. در این شرایط، دیگر عامل ها از طریق باس کمک متوجه میشوند که کدام عامل نیازمند کمک است و داده مورد نیاز برای انجام وظیفه این عامل را از باس مشترک داده برمیدارند. به محض اینکه عامل کمکرسان وضیفه خود را تکمیل نمود، شروع به پردازش تقاضاهای کمک میکند. در ابتدا بررسی میکند که کمک به کدام یک از عامل های خراب مطابق با میل و در جهت منفعت وی میباشد. در این فاز از تصمیمگیری، پارامترهای مختلفی برای اتخاذ یک تصمیم جامع مورد بررسی قرار میگیرد که جزئیات آن کمی جلوتر مطرح شده است. در انتهای این فاز و بر اساس تصمیمات اتخاذ شده، تعداد محدودتری از عامل های کمکرسان، خود را آماده کمک رسانی احساس میکنند. اگر بیش از یک عامل نیازمند کمک باشند، عامل های کمکرسان بر اساس یک استراتژی کمک رسانی توزیع شده که در مرحله طراحی تعیین شده است، ترتیب کمک رسانی را تعیین میکنند. این
