چکیده- شبیه سازی، تقلید یک چیز واقعی است که در بسیاری زمینهها از جمله مدلسازی سامانههای طبیعی و انسانی، برای کسب بینش پیرامون نحوه کارشان، بهکار میرود[1] (Wikipedia, n.d.).
شبیه ساز کاربردهای بسیاری دارد از جمله کاربردهای آن میتوان به آموزش تجهیزات مختلف اشاره نمود.
به کمک شبیهساز میتوانیم آموزش تجهیزات مختلف را به کاربران بدهیم و شرایط مختلف را برای آمزش اپراتور فراهم نماییم اشتباه در بهکار گیری برخی از تجهیزات مخصوصا تجهیزات نظامی ممکن است منجر به خطرات جانی برای کاربران آنها گردد لذا اهمیت شبیهسازها در بحث آموزش بسیار پررنگ میباشد.
اغلب شبیه سازها در بستر شبکههای کامپیوتری به صورت توزیع شده پیاده سازی می گردند.
پیچیدگی و گستردگی سیستم های شبیهسازی و همچنین وجود پیچیدگی در پیادهسازی معماریهای شبیهسازهای توزیعشده، سرعت ساخت شبیهساز را تا حدی پایین میآورند.
در این مقاله ما به ارائه یک معماری چابک مبتنی بر معماری Publish/subscribe و رویدادگرا بهمنظور طراحی شبیهسازهای آموزشی توزیعشده میپردازیم.
در هر عملیات شبیهسازی چندین کامپیوتر در عملیات شبیهسازی بهعنوان بخشی از شبیهساز نقش ایفا میکنند.
در معماری پیشنهادی نرمافزار اصلی مدیریت زمان اجرای شبیهساز بهصورت توزیعشده بر روی کامپیوترهای مختلف پخش گردیده ولی در فرآیند شبیهسازی یکی از آنها نقش سرور و مابقی نقش واسط ارتباطی بین کامپیوترها را بازی میکند و در صورت به وجود آمدن مشکل برای سرور اصلی از میان سایر نرمافزارها یکی بهعنوان سرور انتخاب میگردد و عملیات شبیهسازی را پیش میبرد.
بازپخش یکی از بخشهای مهم در شبیهساز میباشد که آن را با مکانیزمی که بر اساس زمان شبیهسازی و لاگ موجود در شبیهساز میباشد پیادهسازی مینماییم.
معماری فوق با زبان برنامهنویسی دلفی پیادهسازی گردید و چند شبیهساز به کمک آن پیادهسازی گردیدند و خروجی آنها در زمان اجرا بسیار بهینه از لحاظ زمان تولیدبسیار سریع بودند.
کلمات کلیدی : شبیه ساز آموزشی، معاری سطح بالا، شبیه سازی توزیع شده، شبیه سازی تحت شبکه مقدمه امروزه با گسترده شدن تکنولوژی و تجهیزات فوقالعاده پیشرفته و حساس در صنایع مختلف بهمنظور جلوگیری از ایجاد مشکلات و خطرات جانی کاربران این تجهیزات و همچنین آسیب دیدن این تجهیزات در اثر استفاده نادرست کاربران آنها و ...
آموزش این تجهیزات قبل از استفاده آنها امری بسیار ضروری میباشد.
هدف از به وجود آمدن شبیهسازها کمک به آموزش صحیح اپراتورها میباشد.
استفاده از شبیهسازها به دلیل مزایای آنها از قبیل: تشابه با سیستم اصلی، ایجاد شرایط و سناریوهای مختلف جهت آموزش بهتر اپراتورها و رویارویی با حالات مختلف، هزینه پایین شبیهسازها نسبت به نمونه اصلی و...
باعث همهگیر شده آنها شده است بهطوری در بسیاری از سیستمهای تجاری، صنعتی و ...
شاهد حضور آنها هستیم.
دغدغه اصلی در تولید و ساخت یک شبیهساز بهخصوص شبیهسازهایی که بهصورت توزیعشده با یکدیگر عملیات شبیهسازی را پیش میبرند، کاهش هزینهها، افزایش سرعت تولید شبیهساز، سهولت و عدم پیچیدگی در روند ساخت آن، قابلیت ارتباط با سایر شبیهسازها و ..
هست.
در این مقاله ابتدا به معرفی چند نمونه از معماری موجود و سپس به معرفی یک معماری چابک بهمنظور ساخت شبیهسازها داریم .
مروری بر کارهای پیشین SIMNET [2] معماری مبتنی بر شبکه که برای توصیف شبیهساز توسعه یافته است و سازگار با تمام کامپیوترها میباشد.
چهار گره اصلی در معماری این شبیه ساز موجود می باشد که عبارتند از : یک منبع برای ایجاد تراکنشها ، یک صف انتظار، یک مرکز که سرویسها در آن اجرا میشود و یک کمک که بهمنظور افزایش انعطافپذیری مدلسازی زبان معرفی شده است.
وجود یک گره مرکزی در این معماری که سرویسها در آن اجرا می شوند از جمله مشکلات بارز این معماری می باشد زیرا به هر علت این مرکز دچار مشکل گردد کل فرآیند شبیهسازی مختل میگردد، از دیگر مواردی که شاید بتوان به این معماری ایراد گرفت در نظر نگرفتن مکانیزمی برای بازپخش عملیات شبیهسازی و همچنین مکانیزمی برای ردیابی دادههای خطا و نویز در شبیهساز میباشد.
ALSP ]3[ از جمله معماریهایی که در راستای توسعه شبیهسازهای آموزشی ایجاد گردیده میباشد مأموریت اصلی این معماری ایجاد نمودن یک محیط مجازی برای توصیف محیط جنگ میباشد.
طراحی ALSP در دو حوزه صورت پذیرفته است : معماری نرمافزاری ارتباطات ALSP بر پایه اشیاء کار میکند و ساختار ارثبری در آن ضعیفتر از برنامهنویسی شیءگراست.
مفهوم کلیدی در ALSP کنفدراسیون است که مجموعهای از شبیهسازهای موجود میباشد.
نرمافزار زیرساخت ALSP چگونگی توزیع داده و هماهنگی فرایندها را فراهم میکند.
زیرساخت نرمافزاری ALSP شامل 4 عنصر عمده میباشد: 1- ماژول مشترک ALSP 2- ایمولاتور انتشار ALSP 3- ترمینال کنترل ALSP 4-ابزار مدیریت کنفدراسیون اجرای چندین شبیه ساز به طور همزمان با یکدیگر و همچنین تاثیری پذیر آنها از یکدیگر را تمرین شبیه سازی گویند.
اجازه ورود بدون محدودیت به تمرین شبیهسازی برای شبیهسازهای مختلف از جمله امکانات معماری ALSP میباشد و از طرفی دیگر میتوان این قابلیت را به عنوان یک ضعف برای این معماری در نظر گرفت.
با توجه به اینکه مأموریت اصلی شبیهسازها آموزش میباشد ورود و خروج غیره منتظره شبیهسازها از تمرین شبیهسازی موجب بروز خطا در روند آموزش اپراتورها میگردد که این عیب بسیار بزرگی میباشد.
از دیگر مواردی که شاید بتوان به این معماری ایراد گرفت در نظر نگرفتن مکانیزمی برای بازپخش عملیات شبیهسازی و همچنین مکانیزمی برای ردیابی دادههای خطا و نویز در شبیهساز میباشد.
SIMNET [2] معماری مبتنی بر شبکه که برای توصیف شبیهساز توسعه یافته است و سازگار با تمام کامپیوترها میباشد.
وجود یک گره مرکزی در این معماری که سرویسها در آن اجرا می شوند از جمله مشکلات بارز این معماری می باشد زیرا به هر علت این مرکز دچار مشکل گردد کل فرآیند شبیهسازی مختل میگردد، از دیگر مواردی که شاید بتوان به این معماری ایراد گرفت در نظر نگرفتن مکانیزمی برای بازپخش عملیات شبیهسازی و همچنین مکانیزمی برای ردیابی دادههای خطا و نویز در شبیهساز میباشد.
ALSP ]3[ از جمله معماریهایی که در راستای توسعه شبیهسازهای آموزشی ایجاد گردیده میباشد مأموریت اصلی این معماری ایجاد نمودن یک محیط مجازی برای توصیف محیط جنگ میباشد.
با توجه به اینکه مأموریت اصلی شبیهسازها آموزش میباشد ورود و خروج غیره منتظره شبیهسازها از تمرین شبیهسازی موجب بروز خطا در روند آموزش اپراتورها میگردد که این عیب بسیار بزرگی میباشد.
HLA ]4[ (high-level architecture) یا معماری سطح بالا یک معماری عمومی برای سیستمهای شبیهسازی کامپیوتری توزیعشده میباشد.
HLAاز قوانین شیءگرایی و ساختمان داده برای سادهسازی برنامهنویسی بهره میبرد HLA از اجزای زیر تشکیل شده است: فدریت: هر عضو شرکتکننده در شبیهسازی را یک فدریت میگویند.
فدراسیون: اعلامیهای بین فدریتهاست، که تعریف میکند چگونه و چه چیزی را شبیهسازی خواهند کرد.
RTI (Run Time Infrastructure) زیرساخت زمان اجرا لایهای نرمافزاری است که سرویسهایی مشترک برای فدریتها فراهم میآورد و کل فرآیند شبیهسازی از طریق این نرمافزار مدیریت و اجرا میگردد.
HLA برروی باس اطلاعات و مدل انتشار و ثبتنام کار میکند که مراحل آن عبارتند از: یک فدریت میتواند اطلاعاتی که در فدراسیون ایجاد کرده را انتشار دهد.
فدریت دیگر میتواند برای اطلاعاتی که نیاز دارد ، ثبتنام نماید.
انتشار و ثبتنام براساس مدل شیئی فدراسیون میباشد .
RTI هر اطلاعات مرتبط با ثبتنام فدریتها را رهگیری میکند.
در واقع نیازی نیست که فدریتها مستقیماً باهم متصل شوند.
این نحوه از تعامل قابلیت کار با دیگر اجزا و استفاده مجدد را فراهم میآورد.
HLA نمونه کاملتری از معماری قبلی میباشد شبیهسازهای زیادی را میتواند مدیریت نماید و ارتباط آنها را برقرار و مدیریت نماید ولی بزرگترین مشکل آن زیرساخت زمان اجرا یا همان RTI میباشد از این زیرساخت زمان اجرا یک نسخه در حال اجرا میباشد و ازکارافتادن آن موجب ازکارافتادن کل فرآیند شبیهسازی میگردد مشکل دیگر این معماری پیچیدگی زیاد و تعداد قوانین زیاد آن میباشد که تولید یک شبیهساز با آن را بسیار پیچیده میکند نبود مکانیزمی برای ردیابی خطا و بازپخش از جمله مشکلات وارد به این معماری نیز میباشد.
در شکل 1 ساختار کلی معماری HLA نشان داده شده است.
شکل 1 ساختار کلی معماری HLA شبیه سازهای آموزشی دارای بخشهای متفاوتی میباشد از جمله عبارتند از : تجهیزات مورد شبیه سازی: مهمترین بخش هر شبیه ساز منظور همان تجهیزاتی میباشد که قصد شبیه سازی رفتار آنها را داریم.
سیستم نمایش تصویر: به کمک این سامانه قادر خواهیم بود تصاویر تولید شده توسط موتورهای گرافیکی را بر روی سطوح مختلف استوانهای، کروی و ...پخش نماییم.
سیستم تولید تصویر: این بخش همان ظاهر بصری کار می باشد و یکی از بخشهای پرکاربرد در هر شبیه سار می باشد سیستم مربی: مربی به کمک این سرویس قادر به نظارت بر عملکرد اپراتور را داریم این قسمت قابلیتهای مختلفی از قبیل نظارت بر عملکرد اپراتور، ارزیابی و امتیاز دهی به اپراتور، امکان مشاهده بازپخش رفتار اپراتور را برعهده دارد.
پایگاه داده جغرافیایی: یکی دیگر از امکانات هر شبیهساز پایگاهداده جغرافیایی میباشد که حاوی نقشههای GIS محیط آموزش اپراتور میباشد.
های سیستم حرکتی: هر شبیه ساز بسته به نوع آن نیازمند به یک سکوی متحرک و یک واسط نرم افزاری به منظور ارتباط با سایر بخشهای نرم افزاری دارد وجود سیستمهای حرکتی در شبیهساز به اپراتور حس بهتری از آموزش میدهد.
با قابلیتهای ذکر شده مهمترین قابلیتهای هر شبیهساز میباشند که در معماری پیشنهادی سعی بر پوشش این قابلیتها میباشد قابلیتهایی هم که اضافه بر موارد ذکر شده میباشند توسط معماری پیشنهادی قابل پیادهسازی میباشد.
معماری سیستم پیشنهادی در معماری سیستم پیشنهادی اصل شیءگرایی به طور کامل رعایت گردیده است.
دیاگرام کلی معماری شبیهساز بهصورت زیر میباشد: 3-1 مفاهیم کلی در معماری سیستم پیشنهادی: Module: همان اجزای نهایی و زیرسیستمهای موجود در شبیهساز میباشند.
این قسمت در واقع همان اجزا مختلف در شبیه ساز میباشند که بهعنوان بخشی از شبیهساز نقش بازی میکنند.
Connection Base: هر ماژول دارای یک لایه انتزاعی با نام Connection Base میباشد که ارتباط ماژولها با لایه بالاتر را فراهم مینماید.
و این Connection Base دارای یک صف میباشد که پیامها در آن ذخیره میشوند تا زمانی که ماژول آنها را پردازش نماید.
Connection Layer: یک لایه انتزاعی که ارتباط بین ماژولهای مختلف را برقرار مینماید و دارای یک لیست از ماژولهای متصل به خودش و همچنین آدرس switch متصل به آن میباشد.
Switch: همان زیرساخت زمان اجرا میباشد که ارتباط بین Connection Layerهای مختلف را برقرار مینماید این بخش پیامها و دادههای خروجی ماژولها را دریافت و درشبکه به با حداکثر سرعت با قابلیت اطمینان بالا به مقصد میرساند و برای هر تراکنش یک لاگ در پایگاه داده ایجاد میکند.
در صورتی که مقصد بستهها در حوزه خود Switch باشد از Local High Speed Connection Layer به منظور ارسال بسته ها بهره می برد تا مسیریابی به صورت محلی انجام گرفته و دادها با سرعت بیشتری به مقصد برسند، یک سری سرویسهایی Switch در اختیار ماژولهای متصل به خودش قرار میدهد که این سرویسها عبارتند از: Data Base And Logging System: این سرویس کلیه خدمات مربوط به پایگاهداده را در اختیار شبیه ساز قرار میدهد و امکان ثبت تمام تراکنشها و اطلاعات را در خود میدهد به کمک این سرویس قادر خواهیم بود تمام اطلاعات مربوط به شبیه سازی را در پایگاه داده ذخیره نماییم تا در هنگام باز پخش بتوانیم از آنها استفاده نماییم.
در این قسمت ما میتوانیم هر نوع پایگاه دادهای را به سیستم متصل نماییم.
Debug And Trace System: این سرویس به کاربر توسعه دهنده شبیه ساز این امکان را میدهد تا بتواند بستهها و دادههای خود را در شبیه ساز ردگیری نماید و در صورت وجود هر گونه خطا در آنها این امکان را دارد تا بتواند منبع تولید کننده خطا را ردیابی نماید و خطا را اصلاح نماید این سرویس در حین تولید شبیه ساز کمک بسیاری به توسعه هر چه سریعتر شبیهساز مینماید.
System Structure Control: این سرویس قابلیت کنترل ساختار شبیه ساز را به کاربر می دهد و این امکان را می دهد تا از وضعیت هر ماژول آگاه شود و در صورت وجود هر گونه خطا در آن به صورتی بصری آن را مشاهده نمود در ضمن به کاربر این قابلیت را میدهد تا به راحتی ماژولها را بینConnection Layerهای مختلف جابجا نماید.
Module Management System: این سرویس به کاربر این قابلیت را میدهد تا بتواند ماژول را کنترل نماید و در هر لحضه بتواند تمام اعمال ماژول را کنترل نماید.
3-2 فرآیند اجرا ماژول با دریافت فرمان شروع شبیهسازی کار خود را شروع میکنند به همراه فرمان شروع ساعت اولیه سرور و عرض تیک آن بهتمامی ماژولها ارسال میگردد تا ماژولها بر اساس آن ساعت خود را هماهنگ نمایند و دادههای خود را بعد از گذشت عرض تیک ساعت سرور در صورت نیاز ارسال نمایند با این کار ماژولها با یکدیگر همزمان میگردند البته در بازههای زمانی مختلف ماژولها خود را با ساعت سرور نیز همزمان مینمایند.
ماژولها در صورت نیاز به دریافت ورودی از سایر ماژولها، باید در سرور ثبتنام نمایند تا سرور دادههای مورد نیاز ماژول مربوطه را به طور پیوسته از طریق پیام بهواسطه switch به آنها برساند در هر switch یک جدول