دانلود مقاله ارائه یک معماری چابک به‌منظور توسعه شبیه‌سازهای سازی توزیع‌شده

چکیده- شبیه‌ سازی، تقلید یک چیز واقعی است که در بسیاری زمینه‌ها از جمله مدل‌سازی سامانه‌های طبیعی و انسانی، برای کسب بینش پیرامون نحوه کارشان، به‌کار می‌رود[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 یک جدول وجود دارد که اطلاعات مربوط به فرستنده‌ها و گیرنده و داده‌های دریافتی و ارسالی در آن مشخص می‌گردد این جدول در اختیار تمام switch ها قرار دارد.

البته برای ارسال و دریافت داده در ماژول مکانیزمی وجود دارد که مستقیم میتوان گیرنده هر داده را مشخص نمود بدون اینکه در Switch ثبت نام نمود و در آنجا در حین ارسال مقصد را به همراه دادههای ارسالی مشخص مینماییم.

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

ماژول هنگامی که داده‌های خود را تولید کرد آنها را از طریق Connection Base خود به لایه بالاتر از خودشConnection Layer می‌رساند، درصورتی‌که بسته حاوی گیرنده بود و آن گیرنده در لیست ماژول‌های متصل به آن بود بسته را مستقیماً به‌دست آن ماژول می‌رساند (این ارتباط با سرعت بالایی انجام می‌گردد با این کار ارتباطات محلی با سرعت بیشتری انجام می‌گردد و ترافیک شبکه تا حدی کمتر می‌شود) و لاگ آن را برای switch می‌فرستد و switch آن را لاگ می‌نماید و درصورتی‌که بسته حاوی مقصد نبود و یا ماژول در لیست ماژول‌های متصل به Connection Layer نبود آن را تحویل switch می‌دهد و switch به جدول مسیریابی خود نگاه می‌کند و درصورتی‌که ماژولی برای داده‌های آن ثبت‌نام نموده بود داده‌ها را به سمت مقصد ارسال و سپس آنها را لاگ می‌نماید.

در ابتدای فرآیند شبیه سازی هر Switch که به‌عنوان سرور انتخاب گردید ساعت شبیه‌سازی بر اساس تیک‌های آن برنامه‌ریزی می‌شود و داده زمان ذخیره شدن در لاگ با این ساعت ذخیره می‌شوند.

در انتخاب سرور 2 راهکار پیش رو داریم راه‌کار اول انتخاب توسط کاربر و راهکار دوم انتخاب بر اساس سنگین‌ترین یعنی اینکه سیستم switch هایی را برای سرور بودن در نظر می‌گیرد که تعداد ماژول‌های بیشتری به آنها متصل باشد و درصورتی‌که دارای تعداد ماژول‌های برابری بودند switch که بیشترین switch به آن متصل بودند انتخاب می‌گردند و در غیر این صورت به‌صورت تصادفی انتخاب می‌گردد.

ماژول‌ها با دریافت ورودی‌ها فرآیند شبیه‌سازی را پیش می برند و داده‌هایی را به‌عنوان خروجی کارشان در هر لحظه ایجاد می‌نمایند و این داده‌ها را به همراه آدرس مقصد(این آدرس هم قابل تعریف در ماژول‌های یک شبیه‌ساز می‌باشد و هم قابلیت تعریف به‌صورت یک جدول کلی در هر Connection Layer یا switch نمود می‌توان از هر دو حالت بهره برد) را از طریق Connection Base مربوط به خودشان در اختیار Connection Layer مربوطه قرار داده و Connection Layer مربوطه درصورتی‌که ماژول مقصد یا ماژول‌هایی که برای دریافت داده‌های این ماژول قبلاً ثبت‌نام نموده‌اند به خودش متصل باشد داده‌ها را در اختیار آنها قرار می‌دهد و لاگ مربوطه را به سرور ارسال می‌کند در غیر این صورت داده‌ها را به Switch ارسال می‌نماید و Switch به همین ترتیب عمل می‌نماید تا در نهایت داده‌ها به مقصد برسند .

ماژول‌ها برای دریافت داده‌های مورد نیاز هم می‌توانند ثبت‌نام نمایند و هم این امکان وجود دارد تا در مواقع مورد نیاز در قالب Event داده‌های مورد نیاز به ماژول‌های مربوطه ارسال گردد.

نکته قابل‌توجه این است که در هر کامپیوتر یک نسخه از زیرساخت زمان اجرا در حال اجرا می‌باشد ولی نقش Connection Layer برای Switch مرکزی بازی می‌کند و به ‌محض این که Switch مرکزی از سرویس‌دهی خارج گردید یکی از همین نسخه‌ها که زمان مهر کوچک‌تری دارد به‌عنوان Switch مرکزی انتخاب می‌شود و مشخصات خود را به تمام اجزا شبیه‌ساز می‌فرستد.

در معماری پیشنهادی برای بازپخش بدین‌صورت عمل می‌شود که داده‌ها از لاگ بر اساس زمان مهر سرور مرتب شده استخراج می‌شوند و تمام داده توسط سرور برای ماژول‌های مختلف ارسال می‌شود با این کار ماژول‌ها به‌محض دریافت ورودی‌ها خودشان خروجی مورد نظر را تولید و فرآیند شبیه‌سازی ب همان ساعت جلو می برند و اپراتور می‌تواند عملکرد خود را مشاهده نماید.

به‌منظور ردیابی خطاها و نویز این امکان در سرور مهیاست تا بتواند داده‌های هر ماژول و یا هر بخشی را با توجه به نیاز خود فیلتر نماید تا بتواند از صحت عملکرد آنها اطمینان حاصل نماید.

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

امکانات ضروری در ساخت شبیه ساز آموزشی به طور پیش فرض در معماری مذکور اضافه گردیده است.

در روش پیشنهادی زیرساخت زمان اجرا ایجاد یک گلوگاه کلیدی نمی‌کند.

بدلیل مکانیزمهای ارسال و دریافتی که برای معماری مذکور در نظر گرفتهایم ارتباطات محلی با سرعت بسیار بالایی انجام گرفته ترافیک شبکه تا حدی کم می شود در این حالت فقط لاگ به سمت سرور جهت ذخیره‌سازی ارسال می‌گردد .

نحوه بازپخش اطلاعات و همچنین دیباگر داخلی که قابلیت فیلتر نمودن داده‌ها به‌منظور آشکار نمودن نویز و خطا در داده‌ها و ...

از دیگر امکانات معماری پیشنهادی می‌باشد.

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

فشرده‌سازی اطلاعات ارسالی، پیش‌بینی یک روش مناسب تر به‌منظور یافتن بهترین سرور در زمان خرابی سرور، برخورد مناسب با خروج غیره منتظره ماژول‌ها و یا حتی راه‌اندازی مجدد آنها از جمله کارهایی می‌باشد که در آینده باید به دنبال راه‌حلی مناسب برای آنها بود.

مراجع [1].Wikipedia.

(n.d.).

Simulation.

Retrieved from wikipedia.org:http://en.wikipedia.org/wiki/Simulation [2]Taha, H.

A.

(1988, December).

Introduction to SIMNET v2.

0.

In Proceedings of the 20th conference on Winter simulation (pp.

93-101).

ACM.

[3]Weatherly, R.

M., Wilson, A.

L., Canova, B.

S., Page, E.

H., Zabek, A.

A., & Fischer, M.

C.

(1996, January).

Advanced distributed simulation through the aggregate level simulation protocol.

In System Sciences, 1996., Proceedings of the Twenty-Ninth Hawaii International Conference on, (Vol.

1, pp.

407-415).

IEEE.

[4] of the IEEE Computer Society.

IEEE standard for modeling and simulation (M&S) high level architecture (HLA)-IEEE std 1516-2000, 1516.1-2000, 1516.2-2000.

New York: Institute of Electrical and Electronics Engineers