صفحه محصول - فصل دوم پایان نامه رایانش ابری کارشناسی ارشد

فصل دوم پایان نامه رایانش ابری کارشناسی ارشد (docx) 1 صفحه

دسته بندی : تحقیق

نوع فایل : Word (.docx) ( قابل ویرایش و آماده پرینت )

تعداد صفحات: 1 صفحه

قسمتی از متن Word (.docx) :

وزارت علوم، تحقیقات و فناوری دانشگاه علوم و فنون مازندران پایان نامه مقطع کارشناسی ارشد رشته: فناوری اطلاعات – گرایش مهندسی فناوری اطلاعات عنوان/موضوع: ارائه چارچوبی راهبردی برای سیستمهای توزیع شده اجرایی تولید با استفاده از مدل محاسبات ابری اساتید راهنما: دکتر بابک شیرازی دکتر ایرج مهدوی استاد مشاور: دکتر تاجدین دانشجو: شیوا خلیلی قیداری بهار 1391 تقدیم به : پدر و مادرم که با از خود گذشتگی تمامی آرزوهایم را رنگ واقعیت بخشیدند. چکیده: فرآیند تولید در سازمانهای مختلف، دارای سبکهای متفاوتی است که هدف هرکدام در نهایت تحویل محصول درست در زمان درست به مشتری است. ضمن اینکه با استقرار سیستمهای اجرایی تولید مزایای افزونتری در اختیار مدیران میانی نیز قرار میدهد. در این تحقیق هدف از خلق چارچوب طرح ماژولها، روابط آنها و ملزومات پیادهسازی هرکدام بوده است. چیزی که تا کنون در محیط ابرصورت نگرفته است. در مهمترین بخش که همان شناسایی ماژولهای این سیستم است، ماژول سفارش که در سیستمهای اجرایی اولید سنتی قابل مشاهده بود، مبنای کار قرار گرفته و با رویکرد تحلیلی و با استفاده از متدولوژی SOMA، سایر ماژولها از مله مدیریت منابع، زمانبندی، پسگیری، مدیریت تعاریف و ... از آن استخراج شده است. به عبارتی هدف هرچه کوچکتر کردن این ماژول بزرگ در سیستم اجرایی تولید سنتی است. با توجه به محدودیتهای طرح عملی این چارچوب در محیط ابر، یک مطالعه موردی تحت عنوان شرکت جمساز نتیجه نهایی این تحقیق است، مطالعهای که در آن فرآیند اصلی تولید جمساز با راهحل مطرح شده مورد مقایسه قرار گرفته و باتوجه به نظر خبرگان این حوزه و مصاحبه با مدیران تولید و پرسنل مرتبط نتایج نهایی حاصل شد. در مقایسه با سیستمهای مشابه و سنتی و با در نظر گرفتن سبکتر کردن ماژول سفارش، انعطافپذیری هرچه بیشتر و جامعیت و یکپارچگی بیشتر حاصل شد و مدل جدید کسب و کار ابری نیزدیدگاههای جدیدی را برای این سازمانها فراهم آورده است. فهرست رئوس مطالب عنوانصفحهفصل اول- کلیات تحقیق11.1مقدمه2بیان مسئله2هدف از اجرا41.4 توجیه ضرورت انجام طرح41.5سابقه تحقیق51.6 روش پژوهش و تکنیکهای اجرایی61.7استفاده کنندگان از نتایج تحقیق61.8 ساختار فصول7فصل دوم- ادبیات موضوع82.1 مقدمه92.2 سیستمهای اجرایی تولید92.1.1 توابع اصلی سیستمهای اجرایی تولید92.2.2 توابع پشتیبان سیستمهای اجرایی تولید112.2.3 استاندارد95 ANSI/ISA112.3 تولید توزیع شده132.3.1چشماندازها ومفاهیم تولید توزیع شده142.3.2فناوری اطلاعات و تولید توزیع شده162.3.3 توسعه محصول همروند172.3.4 انعطافپذیری و قابلیت پیکربندی مجدد با استفاده از سیستمهای توزیع شده خودمختار192.4 سیستمهای اجرایی تولید توزیع شده212.4.1راه حلهای فعلی سیستمهای اجرایی تولید توزیع شده232.4.2الگوهای طراحی جامع برای سیستمهای اجرایی تولید232.4.3تحلیل و مقایسه رویکردهای توزیع شده262.5محاسبات ابری302.5.1نقشها در پردازش ابری322.6اصول معماري سرويس گرا332.6.1 کشف سرویس352.6.2 روش های کشف سرویس362.6.3 معماری های کشف سرویس382.7.جمع بندی39فصل سوم- مبانی راهکار پیشنهادی403.1 مقدمه413.2 نگاهی کلی413.2.1 تشریح سیستم های اجرایی تولید و طرح مساله در محیط توزیع شده433.2.2 انتخاب الگوهای راه حل(Solution pattern ) های SOMA443.2.3 الگوی راه حل های پیشنهادی توسط SOMA443.2.4 تعریف موجودیت های کلیدی با استفاده از الگوهای طراحی سیستم ها ی توزیع شده503.3 شناسایی سرویس ها513.4 تطابق رویکرد با مدل محاسباتی ابری533.4.1 مراحل چارچوب از دید محاسبات ابری533.4.2 شناسایی سرویسهای سیستمهای اجرایی تولید563.5 ماژولهای اصلی سیستمهای اجرایی تولید تحت عنوان برنامههای کاربردی سرویس گرا633.6 ارتباطات میان ماژولهای مختلف سیستمهای اجرایی تولید843.7 توابع سیستمهای اجرایی تولید به عنوان سرویس943.8 سبک معماری مناسب برای کنترل سیستم های اجرایی تولید توزیع شده در ابر963.9 زمانبندي جزئي تحت عنوان سرويس1013.9.1 ملزومات تامين كننده ابر1023.10 مديريت منابع به عنوان سرويس1053.10.1 ملزومات تعيين كننده سرويس1063.10.2 ملزومات سازمانها1083.11 نظارت به عنوان سرويس1093.12 جمع بندی110فصل چهارم- ارزیابی روش پیشنهادی1114.1 مقدمه1124.2 مقايسه رويكرد هاي فعلي1124.3ارزيابي سيستم هاي اجرايي توليد در محيط ابر و عامل گرا1144.4 مطالعه موردی1164.4.1 حوزه مطالعه موردی1164.4.2 نمونه محصولات مطالعه موردی1174.5 سیستم اجرایی تولید جمساز با استفاده از مدل محاسبات ابری1244.5.1 مقدمات ابری کردن اجرای تولید1244.5.2 پایگاه داده جمساز در محیط ابر1244.5.3 زمانبندی و پیگیری به عنوان سرویسهای ابر1254.6 ارزیابی فاکتورهای تولید1264.6.1 فاکتورهای بهکارگیری فناوری اطلاعات1264.6.2 کمبودها و ضعفهای فعلی1274.7 سيستم هاي اجرايي توليدمبتني بر ابرفعلي1334.8 جمع بندی135فصل پنجم- جمع بندی و نتیجه گیری1365.1 خلاصه تحقیق1375.2 نتایج تحقیق1385.3 مقایسه با سایر چارچوبها1385.4 محدودیتها و زوایای پوشش داده نشده1395.5 چالش هاي مس ابري1395.6 آينده سيستم هاي اجرايي توليد در ابر1415.7 اقدامات آتی142مراجع و منابع143چکیده انگلیسی147 فهرست جداول عنوانصفحهجدول 3.1 سرویس- هدف57جدول3.2 تجزیه دامنه61جدول 3.3 به كارگيري ابر زمانبندي105جدول 4.1 مقایسه چارچوب های فعلی113جدول 4.2 ارزیابی پایگاه داده جمساز در محیط ابر125جدول 4.3 زمانبندی و پی گیری به عنوان سرویس126جدول 4.4 دید مشتریان و چارچوب پیشنهادی128جدول 4.5 دید مدیران و چارچوب پیشنهادی129جدول 4.6 دید بهره وری و چارچوب پیشنهادی130جدول 4.7 تحلیل استراتژیک چارچوب فعلی131جدول 5.1 مقایسه با سایر چارچوب ها139جدول 5.2 سیستم های اجرایی تولید ابری هیبریدی142 فهرست تصاویر و نمودار صفحهعنوان11شکل2.1 توابع اصلی سیستمهای اجرایی تولید12شکل2.2 مدل لایه ای سیستم های اجرایی تولید13شکل2.3 مدل عام سیستمهای اجرایی تولید در استاندارد ANSI/ISA9516شکل2.4تولید هولونی21شکل2.5 چالشهای تولید توزیع شده25شکل2.6 الگوی سفارش-منبع35شکل 2.7مدل معماری وب سرویس43شکل3.1 نمایی کلی از رویکرد مورد استفاده46شکل3.2 ESB48شکل3.3 قالب ESB50شکل3.4 سرویس های ESB54شکل3.5 مدل محاسبات ابری و جایگاه سیستم55شکل 3.6 سیستم های اجرایی تولید توزیع شده56شکل3.7 ماژول های سیستم های اجرایی تولید 60شکل3.8 زیر سیستم های اصلی سیستم های ابر64شکل 3.9 جستجوی سرویس65شکل 3.10 اطلاع رسانی از تغییر سرویس65شکل 3.11 ثبت سرویس66شکل 3.12 شبه کد ثبت سرویس67شکل 3.13 مقداردهی اولیه به منابع68شکل 3.14 تغییرات در منابع68شکل 3.15 شبه کد تغییر در منابع70شکل 3.16 نمودار فعالیت زمانبند71شکل 3.17 شبه کد زمانبند73شکل 3.18 مدیریت چرخه حیات سفارش74شکل 3.19 شبه کد توزیع کننده76شکل 3.20 بازرس77شکل 3.21 شبه کد بازرس79شکل 3.22 پی گیری کننده80شکل 3.23 پی گیری کننده82شکل 3.24 دریافت گزارش از تحلیلگر83شکل 3.25 شبه کد مدیریت داده های سفارش84شکل 3.26 مدیریت سفارش85شکل 3.27 نقش میانجی86شکل 3.28 مدل اطلاعاتی واسط ها87شکل 3.29 مذاکره میان مدیر منابع و مدیر سفارش88شکل 3.30 مذاکره میان مدیریت منابع مختلف89شکل 3.31 بخشی از مذاکرات کنترل فرآیند اجرای سفارش90شکل 3.32 مذاکرات بین مدیر منابع و بازرس91شکل 3.33 مذاکره میان سرویس های سطح بالاتر و مدیر سفارش91شکل 3.34 ارائه گزارش92شکل 3.35 مذاکره بین بازرس و مدیر93شکل 3.36 مذاکراتی برای کنترل میان چندین مدیر منبع95شکل 3.37 همه چیز تحت عنوان سرویس97شکل 3.38 مدیریت چرخه حیات سفارش98شکل 3.39 ملزومات کاربران، سازمان ها و تامین کنندگان99شکل 3.40 ارکسترازیسون ماژول مدیریت سفارش101شکل3.41 چیروگرافی102شکل3.42توزیع سرویس ها در محیط ابر104شكل 3.43 مجازي سازي زمانبندي106شکل 3.44 مدیریت منابع تولید110شکل 3.45نظارت برتخصیص منابع116شکل 4.1 مقایسه رویکرد عامل گرا و محیط ابر118شکل4.2 مدل فرآیند سیستم های اجرایی تولید فعلی119شکل 4.3 سیستم اجرایی تولید ابری پیشنهادی120شکل 4.4 پروفایل تولید121شکل 4.5 مدیریت دستورالعمل تولید122شکل 4.6 ایجاد داشبورد دسترسی123شکل 4.7 توزیع134شکل4.8 شاخص OEE و سیستم اجرایی تولید ابری مقدمه در این بخش به شرح کلیات تحقیق پرداخته میشود تا ایجاد ذهنیتی درست از موضوع تحقیق و چارچوب مورد نظر، اهمیت آن و روش تحقیق ایجاد شود. از این رو در ادامه، ابتدا به بیان مسئله تحقیق میپردازیم و اهداف پیش رو را مشخص خواهیم کرد. سپس به توجیه ضرورت انجام طرح و سابقه تحقیق خواهیم پرداخت. معرفی روش پژوهش و تکنیکهای اجرایی بخش بعدی این فصل خواهد بود و نهایتاَ به شرح مراحلی که در فصول آتی طی خواهیم کرد میپردازیم. 1.2 بیان مسئله سیستم های اجرایی تولید ، سیستم های مبتنی بر فناوری اطلاعات هستند که عملیات تولید را در کارخانه ها مدیریت می کنند. در طول سالها استانداردها ومدلهای بسیاری برای چنین سیستمهایی پیشنهاد شده است که محدوده آن را مشخص می کنند. فعالیتهای کلیدی این سیستمها عبارتند از: مدیریت تعریف محصول. این کار شامل ذخیره سازی، کنترل ورژن، تبادل با سایرسیستمها که حاوی داده های اصلی هستند، نظیرقوانین تولید، ، لیست منابع و همه داده هایی که حول محور اینکه یک محصول چگونه تولید می شود. مدیریت تعریف محصول به عبارتی بخشی از مدیریت چرخه حیات محصول است. مدیریت منابع. مدیریت منابع شامل ثبت، تبادل، و تحلیل اطلاعات منابع است . هدف این کار آماده سازی و اجرای سفارشات تولید با منابع درست است. زمانبندی فرآیند تولید. این فعالیت شامل زمانبندی تولید به عنوان مجموعه ای از سفارشات کاری است که بتوان نیازمندیهای محصول را پوشش داد. که اینها معمولاً ازبرنامه ریزی منابع سازمان و یا سیستمهای پیشرفته برنامه ریزی و زمانبندی نشات می گیرند تا بتوان استفاده بهینه از منابع محلی داشت. توزیع سفارشات محصول. براساس نوع فرآیند تولید این کار ممکن است شامل توزیع بسته های کاری بیشتر، ارسال آنها به مراکز کاری و انجام تنظیمات برای شرایط از پیش تعیین شده باشد. اجرای سفارشات محصول. اگرچه اجرای واقعی توسط سیستم های کنترل فرآیند انجام می شود سیستم مدیریت اجرایی تولید بازرسی هایی بر منابع و سایر سیستم ها برای پیگیری فرآیند تولید دارد. جمع آوری داده های محصول. این کارشامل ذخیره سازی و تبادل داده ها، وضعیت تجهیزات، اطلاعات منابع، گزارش گیری از محصولات به صورت داده های تاریخی و یا پایگاه داده های رابطه ای است. تحلیل کارایی محصول. تهیه داده های مفید از داده های خام جمع آوری شده درباره وضعیت فعلی محصول، مرورکارهای در حال اجرا و ارزیابی کارایی محصول در برهه زمانی گذشته. دنبال کردن و پی گیری محصول. ثبت و احیای داده های مرتبط برای نمایش تاریخچه کاملی از لیست منابع، سفارشات و تجهیزات. در سالهای اخیر در کنار مفهوم سیستمهای اجرایی تولید، مفهوم سازمانهای شبکهای مطرح شده است، اجزای این سازمانها موقتاً کنار هم جمع شده تا بتوانند مهارتها و منابع را با یکدیگر به اشتراک بگذارند. درسیستم های تولیدی چنین سازمانهایی با رویکرد توزیعشده روبرو هستیم، چیزی که به معنی تولید محصول درست، در مکان درست،هزینه درست، زمان درست، شرایط درست می باشد. زنجیره تامین از تامین مواد خام تا تولید و توزیع و حمل و نقل و انبارداری و فروش محصولات به صورت پراکنده و در نقاط جغرافیایی مختلف صورت می گیرد. ازآنجا که مسئولیت به سازمانهای مختلف سپرده میشود در نتیجه کنترل مداوم و هماهنگی برای چنین چرخه حیاتی بسیار پیچیده میشود.کارهای صورت گرفته اغلب به صورت کنترل متمرکز بوده و کمتر کنترل به صورت غیرمتمرکز و توزیع شده صورت گرفته است. هدف اصلی در چنین تولیدی کاهش هزینه ها ، کاهش زمان مدیریت، هرچه ساده تر شدن و یکپارچگی فرآیندها و زیرسیستمها، تکنولوژیهای جدید و به روز رسانیها است. ضمناً کاهش اتلاف در تولید، سرعت در قابلیت پیکربندی مجدد در قبال رخدادهای منتظره و غیرمنتظره از دیگراهداف تولید توزیع شده محسوب میشود. حال برای تحقق واقعی و بهینه چنین سیستمهای تولید توزیع شده ایی، نیازمند به کارگیری فناوری اطلاعات و پردازش توزیع شده هستیم چیزی که امروزه تحت عنوان پردازش ابری با ان آشنا هستیم. پردازش ابری به سرعت در حال تغییرصنایع و سازمانها برای تحقق اهدافشان می باشد. صنایع تولیدی توسط فناوری اطلاعات و تکنولوژی های هوشمند در حال توانمند شدن هستند. قدرت اصلی پردازش ابری در فراهم آوردن سرویس محاسبات در لحظه با قابلیت اعتماد بالا، مقیاس پذیری و قابل دسترس بودن در محیطهای توزیع شده است. درپردازش ابری همه چیزتحت عنوان سرویس در نظرگرفته میشود به عبارتی (Xaas) مانند نرمافزاربه عنوان سرویس، پلتفرم به عنوان سرویس، زیرساختاربه عنوان سرویس که این سرویسها ساختارلایه ای را برای پردازش ابری فراهم میآورند. با توجه به فلسفه طراحی در همه جا تولید در همه جا، نیازمند تبادل اطلاعات در بین سایتهای مختلف تولید هستیم لذا پردازش ابری نقش کلیدی در تحقق این فلسفه دارد . به طور کلی دو نوع اتخاذ پردازش ابری در محیطهای تولیدی وجود دارد. یکی اتخاذ مستقیم تکنولوژیهای پردازش ابری و دیگری تولید ابری که همان ورژن تولیدی پردازش ابری است. در اکثر روشهای پیشنهادی در اتخاذ پردازش ابری مدیریت به صورت متمرکزصورت گرفته است. لذا هدف غیرمتمرکز و توزیع شدگی مدیریت این سیستمهای تولیدی است. در این پایان نامه هدف ارائه چارچوبی کلان برای مدیریت سیستمهای تولیدی است در این چارچوب به ارائه مدل لایهای با توجه به لایههای مدل پردازش ابری پرداختهایم. در این مدل سعی میشود ماژولهای اصلی سیستمهای تولیدی اجرایی استخراج شده و با تطابق این ماژولها با معماری سرویسگرا چارچوبی یکپارچه ارائه شود. این چارچوب به نحوی است که فرآیندها و رویههای انجام کار را با الهام از مدل پردازش ابری گردآوری میکند و در محیطهای توزیعشده ابری راهحلی برای مدیریت سیستمهای تولیدی اجرایی در حین عدم تمرکز ارائه می دهد. هدف از اجرا پردازش ابری محیطی کاملاًمتفاوت به صورت مجازی و مقیاس پذیرتر برای سازمانها به وجود آورده است،مزایای این محیط ازطریق سرویس و از راه اینترنت در اختیار کاربران قرارمیگیرد. مصرف کنندگان ازابربه عنوان پلتفرم استفاده می کنند، پشتیبانی کنندگان ابر پردازش ابری را به عنوان یکی ازتوانمندسازهای صنایع تولیدی درنظرمی گیرند لذا هدف تعمیم این ایده به محیطهای تولیدی میباشد تا با خلاقیت ایجاد شده توسط ابر بتوان استراتژی های کسب و کاررا جهت دهی کرد. هدف در تولید ابری هرچه توانمندترکردن تولید، ایجاد کارخانههای کارا که همکاری موثر با یکدیگر دارند می باشد و اشتراک منابع با به کارگیری محیط ابرتسهیل و تسریع شود. یکپارچه تر کردن محیطهای تولید توزیع شده هدف دیگر تولید ابری است که با مقیاس پذیرشدن منابع و مدلهای جدید کسب و کار پیشنهاد شده با ابر، محقق میشود. . 1.4 توجیه ضرورت انجام طرح با توجه به تلاش سازمانها برای کوچکتر شدن و به کارگیری ساختارهای شبکه ای، همواره این سوال مطرح میشود که چگونه سیستمهای اطلاعاتی تولیدی این شرکتها در محیطهای توزیعشده مدیریت میشوند تا کارایی در چنین شرکتهایی به حداکثر برسد، لذا بر آن شدیم تا با ارائه چارچوبی کلان برای سیستمهای تولیدی توزیعشده با استفاده از مدل محاسبات ابری به مدلسازی این مفهوم بپردازیم. مدلی که ماهیت آن ظهورنوآوری در مدیریت بوده و مدیریت محیطهای توزیع شده تولیدی را تسهیل میکند. سابقه تحقیق بروچر و سایرین در مطالعه خود به این نتیجه رسیدند که در یک محیط تولیدی با اطلاعات بسیارزیاد ، برنامههای کاربردی می توانند سرویس گرا باشند. آن ها یک پلتفرم مبتنی بر ماژول و قابل پیکربندی برای تولید ارائه کردند. هدف تقابل با مشکل یکنواختی برنامه های کاربردی موجود در زنجیره تامین کد-کم-سی ان سی است. رویکرد پیشنهادی تحت عنوان تولید مبتنی بر کامپیوترآزاد یا اوپن سی بی ام( open CBM )مطرح شد تا بتوان با آن تولید مشارکتی را تقویت کرد. ایده پیشنهادی مشابه یاس( Aaas) است در حالیکه در اینجا برنامه های کاربردی تحت عنوان برنامه های کاربردی یکپارچه در نظر گرفته نمی شوند ولی به صورت مجموعه ای از سرویس ها که ارتباط سستی با یکدیگر دارند و ماژولاریتی و قابلیت استفاده مجدد از یک سیستم را تضمین می کنند، لحاظ میگردند. برای افزایش سرویس گرایی و کاهش پیوستگی وان در ولد یک چارچوب نصب و اجرا (pug and play) برای ایجاد نرم افزار شبیه سازی ماژولار عنوان کرد. در این چارچوب کاربر در لایه برنامه کاربردی در سیستم تولید ابری این امکان را دارد تا هدف شبیه سازی را انتخاب کند و اجرای شبیه سازی را تحت عنوان مولفه (کامپوننت) انتساب دهد. این مولفه ها در عمل موجودیت های نرم افزاری هستند ( و اینکه تحت عنوان ساس-Saas -در تولید ابری و محاسبات ابری شناخته می شوند) وماژولهای خودشمولی می شوند که قابل جابه جایی و پلاگ شدن بعد از شبیه سازی را داشته و خروجی از طریق کامپوننت ها پس پردازش می شوند. در چنین معماری، ماژول های نرم افزاری شناسایی و بارگیری شده و در حین اجرای چارچوب مورد استفاده قرار می گیرند. با کاهش پیوستگی مشکل عدم سازگاری بروزمی کند.ناش چارچوبی برای حل مشکل عدم سازگاری سیستم های سی آ ( CA )مطرح کرد. این چارچوب بسیارشبیه یک سیستم یاس( Iaas ) است. پلتفرم اینترفیس های منحصر به فرد برای سیستم های متفاوت کد-کم-سی ان سی(cad-cam-cnc) فراهم می کند. یک انبار داده بسیار پیچیده تجهیز شده است تا اطلاعات تولید را به عنوان پایه ای برای نشان دادن دانش تولید که با استفاده از شمای XML افزوده شده است، تجهیز کند. سیستم متشکل از انبار داد ه های تولیدی، دانش تولیدی، باس تبادل اطلاعات و اینترفیس های مختلف است که به عنوان ساختار اصلی عامل (agent) به کاررفته است تا باس تبادل داده ها و اینترفیس ها را پشتیبانی کند. در این سیستم کامپوننت های مختلفی اززنجیره کد-کم-سی ان سی(cad-cam-cnc) می تواند اطلاعات را تبادل کند در همین راستااخیراً مختار و هوشمند پلتفرمی را ارائه داده اند که تئوری طراحی بدیهی را برای پی بردن به قابلیت کار کردن بین زنجیره سی آ (CA) نشان می دهد. متدولوژی طراحی بدیهی با این هدف مطرح شده است که یک نقشه راه سیستماتیک از ترکیب بهینه تبادل داده ها از طریق راه حل های مستقیم و غیر مستقیم در محیط CA پیشنهاد می کند. این رویکرد به اینکه چگونه یک منبع، طراحی ،تولید و کپسوله می شود و اینکه چگونه لایه سرویس جهانی ایجاد می شود فراهم می آورد، پرداخته است . وانگ و زو یک پلتفرم توزیع شده تولیدی دیمپ (DIMP) را پیشنهاد کردند. این پلتفرم یک محیط یکپارچه بین برنامه های کاربردی کد-کم-سی ان سی( cad-cam-cnc ) فراهم می سازد. این یک ساختار مبتنی بر ماژول است که برای یکپارچه کردن پلتفرم از همان معماری سرویس گرا استفاده کرده است. در این پلتفرم درخواست-های کاربران جمع آوری شده و به صورت الگويي از سرویس های نرم افزاری سازمان دهی شده است. در دیدگاه سرویس گرا، ابزارهای نرم افزاری متجانس به صورت ترکیب کننده های سرویس مجازی یکپارچه می شوند و برای کاربر فراهم می شوند، در این روش، نرم افزارها در فرآیندهای عملیاتی جایگذاری می شوند. با توجه به شکاف موجود در ادبيات هدف اين تحقيق ارائه چارچوبی کلان برای مدیریت سیستم های تولیدی است. این چارچوب به ارائه مدل لایه ای با توجه به لایه های مدل پردازش ابری می پردازد. و به نحوی سازماندهی خواهد شد که فرآیندها و رویه های انجام کار را با الهام از مدل پردازش ابری گردآوری کند و در محیط های توزیع شده ابری راه حلی برای مدیریت سیستم های تولیدی اجرایی در حین عدم تمرکز ارائه دهد. 1.6روش پژوهش و تکنیکهای اجرایی یک روش پژوهش راهبردی صورت خواهد گرفت . طی مطالعات کتابخانه ای و مطالعه مقالات به مضمون ارائه شده میپردازیم. گردآوری اطلاعات با مطالعه اسناد و مدارک در دسترس (کتب ، مقالات ، گزارشات) جمع آوری و دسته بندی داده ها با مطالعه مدل ها و چارچوب های موجود در زمینه سيستمهای توزيع شده اجرايي توليد تحلیل داده های جمع آوری شده و ارزیابی تطبیقی مدل های همتراز با کمک مدل محاسبات ابری ارائه چارچوبی راهبردی برای سیستمهای توزیع شده اجرایی تولید با استفاده از مدل محاسبات ابری 1.7استفاده کنندگان از نتایج تحقیق نتایج حاصل از این تحقیق در حقیقت چارچوبی است که حاوی ماژولهای مختلف بخش تولید است، هرسازمان تولیدی برحسب شرایط ممکن است در یکی از این بخشها قوی و یا ضعیف باشد. این ماژولهای توزیعشده در ابر و مدل اقتصادی آن میتواند راهحلی مناسب برای هر یک از این شرکتها باشد. 1.8 ساختار فصول در ابتدا به بررسی ادبیات موضوع در چند حوزه مفاهیم اولیه سیستمهای اجرایی تولید، تولید توزیعشده، سرویسگرایی و مدل محاسبات ابری پرداخته شد. در خلال این بخش توابع اصلی سیستمهای اجرایی تولید بر اساس استانداردهای مختلف مطرح شد. استانداردهای اصلی استاندارد MESA بوده و استاندارد بعدی که جامعتر بوده،ANSI/ISA 95 میباشد که MESA نیزمبنای آن بوده است. متعاقباً بحث تولید توزیعشده مطرح شد و چشماندازها و مفاهیم تولید توزیعشده نیز مرور میشود. مفاهیمی نظیر تولید هولونی و عاملگرا، سپس نقش فناوری اطلاعات در تولید توزیعشده و انواع سبکهای بهکارگیری مطرح می شود. در ادامه مدل محاسبات ابری و ویژگیها و پتانسیلهای آن، نقاط قوت و ضعف آن، فرصتها و تهدیدهای آن و ویژگیهایی نظیر مجازیسازی و خاصیت الاستیکی ابر و ... بحث می شود. سپس بحث سرویسگرایی و شناسایی سرویسها که مبنای مدل محاسبات ابری در این تحقیق است به صورت مفصل مورد بررسی قرار میگیرد. در فصول آتی رویکرد مورد استفاده در ادامه تحقیق مطرح میشود، در حین بهکارگیری رویکرد نیازمند به کارگیری متدولوژی مناسب برای شناسایی سرویسهای مورد نظر در سیستم مورد بررسی هستیم، نهایتاً در متدولوژی SOMA ، راه حل ESB برای ماژول اصلی این سیستم یعنی مدیریت سفارش انتخاب میشود. درطی مراحل شناسایی سرویسها، در این متدولوژی مدلسازی سرویس-هدف و تجزیه دامنه صورت میگیرد. ماژولهای اصلی سیستم اجرایی تولید توزیع شده، مدیریت سفارشها، مدیریت منابع، زمانبندی، پیگیری، بازرسی، مدیریت تعاریف است، برای بهکارگیری تمامی این ماژولها نیازمند آن هستیم تا با نمودارهای فعالیت، نحوه تعامل آنها را با یکدیگر نشان دهیم. نهایتاً چارچوب پیشنهادی در قالب یک مطالعه موردی به بحث و بررسی گذاشته شده واز دیدگاههای مناسب ارزیابی شده است. در ادامه با توجه به شرکتهایی که پیشرو در طراحی سیستمهای اجرایی تولید هستند، نتایج پیادهسازی عملی نشان داده شده است. فصل دوم- ادبیات موضوع 2.1 مقدمه هدف از این فصل آشنایی با مفاهیم اصلی که در این تحقیق مورد استفاده قرار گرفته، میباشد. در ابتدا مفهوم سیستمهای اجرایی تولید و تولید توزیعشده معرفی و مورد بحث قرار میگیرد. سپس سیستمهای اجرایی تولید توزیعشده عنوان میشود ودرنهایت رویکرد محاسبات ابری و ویژگیهای آن به عنوان ابزاری جهت توانمند ساختن سیستمهای اجرایی تولید توزیعشده شرح داده میشود. 2.2 سیستمهای اجرایی تولید منشاء مفهوم سیستم اجرایی تولید را میتوان در سیستم جمعآوری دادهها، در اوایل دهه 80 یافت، زمانیکه سازمانهای مختلف هریک برای خود قوانین ونظمهای متفاوت، نظیر طراحی تولید، مدیریت پرسنل تولید داشتند. به تدریج با ظهورCIM معیاری برای تفکیک این وظایف عنوان شد ودر اواسط دهه 90، سیستمهای جمعآوری دادههای تولید، خودرا به نحوی ارتقا دادند تا به سمت سیستمهای یکپارچه پیش روند. با به کارگیری روزافزون فناوریاطلاعات برای بهبود عمل تولید، در اواخر دهه 90 نیاز به تعریف مدونی برای سیستمهای اجرایی تولید احساس شد. لذا MESAدر سال 2000 نمونههایی ازتعریف اجرا برای تولید عنوان کرد. از دید این انجمن اجرا به معنای ایجاد محصول، ایجاد و اندازهگیری قطعات، انتقال لیست اقلام موجود به و یا از ایستگاههای کاری، تغییر اولویت سفارشات، انتساب مجدد پرسنل و اقلام موجود و همچنین زمانبندی مجدد است. تمامی واژههایی که توسط MESA تحت عنوان اجرا مطرح شدهاست بیانگر نوعی پویاییست که مستلزم کنترل، زمانبندی و پیگیری پویا برسیستم اطلاعاتی تولید است. 2.1.1 توابع اصلی سیستمهای اجرایی تولید MESA 7 تابع اصلی را برای سیستمهای اجرایی تولید تعریف کردهاست که بیشتر کارکردهای اصلی این سیستم را تحت پوشش قرار میدهد. این توابع عبارتند از: واسط سیستمهای برنامهریزی: سیستمهای اجرایی تولید بایستی به طور مستقیم با سیستمهای برنامهریزی همراه شود تا در یک ارتباط دوطرفه سفارشهای کاری وسایر ورودیها رادریافت کرده و برای لایههای پایین ترجمه کند و گزارشها و اطلاعات کنترلی رابه لایههای بالای سازمان منتقل کند[1]. سفارش کاری: سیستماجرایی تولید، سفارشهای کاری را دریافت کرده، تغییرات را بر روی سفارشها مدیریت میکند و لیستی متوالی و اولویتدهی شده را ایجاد، تغییر، برنامهریزی و نگهداری میکند. در این لیست تغییرات و زمانبندی ذخایر مواد اولیه خاص و تجزیه وترکیب سفارشات مشهود است[1]. ایستگاههای کاری: این بخش از سیستمهای اجرایی تولید، مسئول پاسخگویی در قبال پیادهسازی برنامه و سفارشها و پیکربندی منطقی ایستگاههای کاری است[1]. پیگیری ومدیریت لیست کالاها: این بخش ازسیستمهای اجرایی تولید، نقشه به روزی از تمامی لیستکالاها و محل ذخیرهها وکارهای در حال جریان نگهداری میکند[1]. جابهجایی مواد اولیه: هدف از این بخش کنترل جابهجایی مواد اولیه به ایستگاههای کاری است[1]. جمعآوری دادهها: این بخش از سیستمهای اجرایی تولید در حقیقت چشمها وگوشهای مدیریت اطلاعات در تولید هستند واطلاعات را جمعآوری میکنند و در نتیجه سیستم میتواند به روز باقی بماند[1]. مدیریت استثناها: یک بخش ضروری سیستمهای اجرایی تولید این است که چگونه یک سازمان تولیدی در قبال رویدادها و استثناها واکنش نشان میدهد واینکه بتواند تغییرات را کنترل کرده و عملیات جایگزین را انجام دهد[1]. شکل2.1 توابع اصلی سیستمهای اجرایی تولید ] SEQ شکل2.1_توابع_اصلی_سیستم¬های_اجرایی_تولید \* ARABIC 1[ 2.2.2 توابع پشتیبان سیستمهای اجرایی تولید علاوه بر7 تابع اصلی سیستمهای اجرایی تولید، 9 تابع پشتیبان نیز عنوان شده است که درسطح پایینتری ازاهمیت قرار میگیرند. این توابع عبارتنداز: کنترل فرآیندآماری مدیریت نگهداری کنترل حضور وغیاب مدیریت دادههای تولید پردازش وارزیابی کارایی مدیریت تامین کننده پیگیری رد و اثرمحصولات مدیریت اطلاعات کارگاه تعیین کیفیت[1] باوجود این توابع اصلی وپشتیبان، باز ضرورت وجود استانداردی جزئیتر برای سیستمهای اجرایی تولید احساس میشد که در ادامه به شرح آن خواهیم پرداخت. 2.2.3 استاندارد ANSI/ISA95 این استاندارد دیدلایهای وسلسلهمراتبی به سیستمهای اجرایی تولیددارد وعلاوه بر MESA، مدل PRM را نیز به عنوان مبنایی برای بسط خود در نظر گرفته است. این استاندارد متشکل از 5 بخش است که بخش اول برمدلها و واژهشناسیها تمرکزدارد، بخش دوم شامل صفات مدل اشیا است و بخش سوم برمدل مدیریت عملیات تولید که خود شامل سیستمهای اجرایی تولید میشود. بخش چهارم برارتباط لایه سیستم اجرایی تولید با لایه های بالاتر سازمانی تمرکز دارد و بخش پنجم به ارتباط سیستم اجرایی تولید بالایههای پایینی تولید تمرکز دارد[2]. لذا بخش سوم این استاندارد مورد بحث واقع شدهاست. شکل2.2 مدل لایهای سیستمهای اجرایی تولید قبل از شرح سیستمهای اجرایی تولید مروری برمدیریت عملیات تولید خواهیم داشت که خود 4بخشPOM و IOMو QOMو MOM تقسیم بندی میشود که توابع اصلی مسا (MESA)که در بخش قبل شرح دادهشد با حداقل یکی از این بخشها مرتبط است. ISA 95 یک مدل فعالیت عام برای سیستمهای اجرایی تولید تعریف میکند که شامل مدیریت، تعریف محصول، مدیریت منابع، زمانبندیجزئی شده، توزیع کار، مدیریت استثنا، پیگیری، جمعآوری دادهها و تحلیل است[3]. شکل2.3 مدل عام سیستمهای اجرایی تولید در استاندارد ANSI/ISA95 ISA95 تمامی عناصر مدل عام که در بالا عنوان شد را به تک تک عناصراصلی POM و IOM و QOMو MOM نگاشت میدهد. نتیجه نهایی این نگاشت یک سری وظایف مشخص شده و یک مدل فعالیت برای هر کدام از این نگاشتهاست. 2.3 تولید توزیعشده حضور همزمان در بازارهای منطقهای مختلف، هم برای تامینکننده وهم برای تولیدکننده امری اجتنابناپذیر است. این پیکربندی به دلیل رقابت شدید، با خلاقیت بالا و به منظور حصول نتایج با کارایی مطلوب، مطرح شدهاست. محیط رقابتی جهانی، نیاز ممتد برای شناسایی و بهکارگیری چشماندازهای جدید تولید، متدهای سازگارشده وتکنولوژیهای به روز را تحمیل میکند. مهمترین چشمانداز در چنین محیطی بهرهگیری از ساختارهای توزیعشده است. قدرت رقابتی ساختارهای توزیعشده در این قابلیت آنها نهفته است که میتوانند عناصر تشکیلدهنده را به صورت شبکهای همروند، مشتریمدار و با ساختار و فرآیند جدید شکلدهند. کار در محیطهای توزیعشده سازگاریپذیراست ضمن اینکه سیستمها وتجهیزاتی یکپارچه وجود دارند که به خوبی مجدداً پیکربندی میشوند و تکنولوژیهایی که میتوانند اطلاعات را به دانش تبدیل کنند، تا بتوان تصمیمگیری بهتری داشت. تمامی این مزایا روند حرکت به سمت تولید توزیعشده را پرشتابتر کردهاست[4]. 2.3.1چشماندازها ومفاهیم تولید توزیعشده درطول مسیری که به سمت تولید توزیعشده طی شدهاست، اصول ومفاهیم پیشرفتهای از تولید ومدیریت ارائه شدندکه به مرور زمان با پیشرفت فناوری رشد مطلوبی داشتهاند. مهمترین این اصول، تولید باریک در سال 1988، تولید چابک در سال 1994، کارخانههای فرکتال در سال 1995، تولید هولونی در سال 1998 بوده است. در حال حاضر نیز سیستمهای چند عاملی به عنوان پلتفرمی پیشتاز در تولید توزیعشده مطرح شدهاست[4]. تولید باریک تولید باریک ویا سازمانهای باریک که به طورخلاصه باریک نامیده میشوند یک فعالیت تولیدی است که تمامی هزینههای منابع را برای هدفی به کار گیرد که برای مشتری ارزشآفرین باشد و هر فعالیت غیر ارزشزا را حذف میکند. از دیدگاه مشتری، یعنی کسی که محصول یا سرویسی را مصرف میکند، ارزش به فعالیت یا فرآیندی اطلاق میشود که وی حاضر است برای آن هزینه پرداخت کند. تولید باریک، مخصوصاً، بر این ایده تمرکز داردتا ارزش را با کار کمتر فراهم آورد. این ایده نخستین بار توسط سیستم تولید تویوتا مورد استفاده قرار گرفت. از این رو گاهی تحت عنوان تویوتیسم معرفی میشود. برای بسیاری از افراد، این دیدگاه مجموعهای از ابزار است که به تعریف و حذف ضایعات تمرکز داردو تمرکز اصلی بر بهبود جریان و هموار کردن کاراست. در نتیجه حذف ممتد ضایعات از سیستم مدنظر است نه ضایعات برای هر تولید جداگانه. ایده تولید باریک، همچنین به صورت مجموعهای از مفاهیم که اتصال سستی دارند و با هدف کاهش هزینهها با هم همکاری کردهاند، نیز تعریف میشود. این اصول شامل پردازش کشش، کیفیت عالی برای نخستین بار، کاهش ضایعات، بهبود مستمر، انعطاف پذیری، حفظ ارتباط طولانیمدت با تامین کننده، خودمختاری، تراز کردن بار و کنترل بصری جریان کار است[5]. تولید چابک تولید چابک، واژهای است که برای سازمانی به کار میرود که از فرآیندها، ابزارها و آموزش، به نحوی استفاده میکند تا بتواند به سرعت به نیازهای مشتری و تغییرات پاسخدهد. حال آنکه هزینهها و کیفیت را حفظ کردهاست. فاکتور توانمند ساز برای تولید چابک استفاده از یک پایگاه داده مشترک برای قطعات و تولید است. تولید چابک، به عنوان گام بعدی تولید باریک در تکامل تولید در نظر گرفته میشود. تفاوت بارز این دو رویکرد مشابه تفاوت یک انسان لاغر با یک انسان ورزشکار است[6]. کارخانههای فرکتال مهمترین ویژگی کارخانههای فرکتال، خودتشابهی و الگو داخل الگو بودن آنها است. ایده کارخانههای فرکتال بر این ویژگیآنها تاکید داد و کارخانههای تولیدی را پیشنهاد میدهد که متشکل از اجزا کوچک است- یک موجودیت فرکتال . اولین ویژگی آنها خودسازماندهی شدن آنها است . آنها از متدهای حل مشکل خودشان و راهحلهای بهینه خودشان برای بهبود فرآیندهایشان استفاده میکنند. دومین ویژگی آنها پویایی آنهاست به نحوی که میتواننداطلاعات را از محیط دریافت کرده و خود را سازگار کنند و ویژگی خودتشابهی کارخانههای فرکتال به معنی آن است که اهداف تک تک آنها در اهداف واحدشان نیز نمود پیدا میکند[7]. تولید هولونی واژه هولون ریشه در واژه یونانی هولوس به معنی تمام دارد. هولونها در تولید دارای دو ویژگی مهم هستند، خودمختار بودن و ماهیت مشارکتی آنها. هولونها در نواحی که خود در آن حضور دارند با هم ارتباط دارند ضمن اینکه خصوصیت مشارکتی بودن آنها بین نواحی نیز نمود پیدا میکند. در ادامه معماریهای مبتنی بر این تولید آمده است[8]. شکل2.4تولید هولونی ]8[ سیستمهای چندعاملی سیستمهای چندعاملی متشکل از عاملها و محیطشان است. معمولاً، سیستمهای چندعاملی بر عاملهای نرمافزاری تمرکز دارد، هرچند این عاملها میتوانند سختافزاری نیز باشند. محیط عامل میتواند دارای ویژگیهایی نظیر در دسترسبودن، پویایی، قطعیت، اپیزودیک بودن و ... را داشتهباشد. مهمترین ویژگی سیستمهای چندعاملی، خودمختاری، دید محلی، و غیر متمرکز بودن آنها است. در ادامه نیز چندین معماری مبتنی بر سیستمهای چندعاملی مطرح شدهاست[9]. 2.3.2فناوری اطلاعات و تولید توزیعشده نقش ابزارهای فناوری اطلاعات در شکلدهی به مفاهیم تولید توزیعشده، نقشی غیرقابل چشمپوشی است. این ابزارها باایجاد محیطهای کاری مرکب از مجازی و واقعی و مشارکتی و خلق مفاهیمی نظیر P&P ، بستر تولیدرا با مزایا و نوآوریهای بسیار روبرو ساختهاست. تولید توزیعشده در بسترفناوری اطلاعات، همواره با سبکهای به کارگیری متفاوتی همراه بودهاست. که عبارتند از : سبک موازی: این سبک سبب میشود تا زمان اجرای کوتاهتری را با اجرای چندین مرحله به صورت موازی و یا با همپوشانی به دست آوریم. این کارمستلزم بهروزرسانیهای بلادرنگ و مبتنی بر رخداد است. سبک حتمی: این سبک ترکیب مناسبی از تمامی شبکهها و زنجیره تامین را از بخشهای کوچکتر فراهم میآوردکه تقریباً به صورت مجزا مدیریت میشوند. سبک رفتاری: شبکههای ترکیبشدهای را به صورت پویا فراهم میآورد که ازلحاظ دادههای مبتنی بررویداد و منطق وتمامی تعاملات به یکدیگر وابستهاند. سبک تکراری: این سبک براین حقیقت تاکید دارد که ماهیت این ساختارها دائماً در حال تکامل است و نتایج تکرار در تغییرات بایستی در طول مراحل ساختاری منتشر شود. سبک کپسولهسازی: این سبک این امکان را فراهم میآورد تا بتوان شبکهها و فرآیندهایی را ایجاد کرد که عناصررابا هم ترکیب میکند تا موجودیتهای اتمی به وجود آورد تا دادههای تولید را بر حسب نیاز بایکدیگر تبادل کنند[4]. مفهوم شبکهای بودن در تولید جایگزین مدیریت سلسلهمراتبی شدهاست که بدون شک مزایای رقابتی بسیای را به همراه خواهد آورد و به طبع آن دیگر رویکردهای کنترل فعلی کارآمد نخواهد بود که این موضوع یکی از مهمترین چالشهای سیستمهای تولید توزیعشده است.ضن آنکه زمانبندی تولید به صورت پویا، قابلیت کار متقابل عناصر و تامین یکپارچگی بهینه سایر مشکلات پیش روی این رویکرد هستند[4]. 2.3.3 توسعه محصول همروند طبق اصطلاح قدیمی که همواره حق با مشتری است، این اصطلاح، در دنیای امروز و در شرایطی که مشتریها به جای خرید آنچه تولید کننده میسازد، خودشان هستند که تصمیم میگیرند تولید کننده چه چیزی برای آنها تولید کند نیز صادق است. درک ویژگیهای چنین تولیدی سبب میشود تا مدیریت تولید جدید و موثری داشته باشیم. فاکتورهای موفقیت در تولید در چنین شرایطی به دو گروه تقسیم میشود: ویژگیهای فرآیند: فاکتورهایی که ماهیت فرآیندهای تولید جدید را ضبط میکنند. معمولاً فاکتورهایی هستند که قابل کنترلند( انجام دادن درست پروژه) ویژگیهای انتخابی: فاکتورهایی که پروژههای جدید محصولات و شرایط آنها را شرح میدهد و خارج از کنترل رهبر پروژه و تیم است( انتخاب پروژه درست)[10] با وجود چنین فاکتورهایی تولید در سازمانهای گسترده مبتنی بر 5 رویکرد است: استراتژی تولید: هدف استراتژی تولید سازمانهای توسعه یافته این است که همه محصولات را به نحوی به هدف اصلی خود برساند و به دنبال جستجو برای محصول جدید باشد و اصولاً بر چهار تابع طراحی جامع- تکنولوژی محور، بازار محور، مبتنی بر پندار و کاربر محور- استوار است[11]. برنامهریزی تولید پیشرفته: توسعه محصول شتابزده برای سازمانهای توسعه یافته بسیار مهم بوده، چرا که نیازمند این هستند که همواره پیشرو باشند، پیشرو بودن بدین معنی است که محصول جدید و یا نسل جدیدی از تولید داشته باشد. مهمترین ویژگی پیشرو بودن این است که تحمل زیادی در برابر ریسک داشته باشد و چرخه حیات کوتاهی داشته باشد. هفت ویژگی چنین کسبوکارهایی عبارتست از: فرآیند تعریف محصول بازارگرا، تیمهای پروژه چندعملکردی، برنامهریزی پیشتوسعه یافته، فازهای توسعه که با هم همپوشانی دارند، تمرکز برویژگیهای کلیدی، توسعه محصول افزایشی بر اساس استفاده مجدد و حافظه سازمانی در دسترس. توسعه محصول در سازمانهای توسعهیافته، بایستی همواره با تولید خانوادهای از محصولات باشد و هستهای تحت عنوان پلتفرم شکل میگیرد که شامل معماری مشترک تمامی خانواده است[12]. مدیریت هزینههای تولید: مهمترین گام در مدیریت هزینههای فرآیند این است که دریابیم چگونه سه فاکتور تکنولوژی، تولید و سیستم را همراستا قرار داده تا بتوان کاهش چشمگیری در هزینهها ایجاد کرد[13]. تحلیل بازار: این رویکرد شامل فعالیتهای موقعیتیابی محصول است. هماهنگ کردن فعالیتها: این کار باعث یکپارچه شدن قابلیتهای خاص در محیط توزیعشده است. فناوری اطلاعات، توسعه محصول را از جهات مختلف پشتیبانی کرده است و ابزارهای مختلفی برای وظایف مختلف پیشنهاد کردهاست. ابزارهایی که اجرای وظایف محصول جدید را پشتیبانی میکنند. ابزارهایی که طراحی و کنترل فرآیند را پشتیبانی میکنند. ابزارهایی که همکاری بین بازیگران را پشتیبانی میکنند. ابزارهایی که مدیریت اطلاعات را پشتیبانی میکنند. تکامل مشارکتی سوالی که در ابتدا مطرح میشود این است که چه تفاوتی در مفهوم شبکههای صنعتی و تولید توزیعشده وجود دارد. در شبکههای صنعتی، مهمترین مشکل موضوع همکاری است ولی تولید توزیعشده که منشا آن فناوری اطلاعات است چگونه است؟ موضوع همکاری، همانطور که در شبکههای صنعتی مطرح بود در تولید توزیعشده نیز بهعنوان یک موضوع مهم مطرح میشود ونیاز به بسط بر اساس مفاهیم فعلی دارد تا بتوان به یک تئوری پایه رسید. مبنای این تئوری پایه بایستی عبور از سیستم سلسله مراتبی و کنترل مستقیم منابع به سمت مفهوم شبکههایی با موجودیتهای اتصال سست باشد. در تولید توزیع شده مفهومی تحت عنوان تکامل مشارکتی مطرح میشود. این موضوع پیش از این در مفاهیم زیستشناسی مطرح شده و مدلهای آن برای تولید توزیعشده نیز کاربردی است و به معنای همکاری دوطرفه بین دو جفت است که به یکدیگر وابسته هستند، برای رسیدن به هدفی جامعتر. میتوان این مفهوم را برای عاملهای خودمختار در تولید که دوبهدو به هم وابستهاند نیز بسط داد[4]. 2.3.4 انعطافپذیری و قابلیت پیکربندی مجدد با استفاده از سیستمهای توزیعشده خودمختار تغییر سریع مرزهای سیستمهای تولید صنعتی، این نیاز را به بار آورده است تا طبق شرایط مختلف، رفتار انعطافپذیری صورت گیرد. برای امکان پذیر ساختن این انعطافپذیری پیشرفته، سیستمهای کنترل تولید، بایستی در این شرایط خود را تغییر دهند. برای انعطافپذیری مطلوب، تکنولوژیها و معماریهای جدید در تمامی سطوح کنترل مورد نیاز است. تکنولوژیهای مختلفی برای رسیدن به این هدف مطرح شدند ولی اکثر آنها به خوبی با یکدیگر سازگار نیستند. برای رفع این چالش از معماریهای جامع شیگرا، سرویسگرا و عاملگرا استفاده میشود. معماری شیگرا چشم انداز بسیار قوی است که نه تنها بر طراحی نرمافزار تمرکز دارد بلکه میتواند بسیار سریع در حوزههای دیگر نظیر سیستم کنترلی و پیادهسازی آن به کار رود. چنانچه میتوان آثار این چشمانداز را در دو معماری بعدی نیز مشاهده کرد. مهمترین ویژگی معماری شیگرا تعریف اشیا و مشخصههای دادههای اشیا و واسطهای پرکاربرد و تعریف وابستگیهای مختلف در بین اشیا است. لذا معماری شیگرا دارای ساختاری است که میتواند اهداف تولید توزیعشده را برای انعطافپذیری تحت پوشش قرار دهد[15]. معماریدیگر معماری عاملگرا است که مهمترین عنصر آن عامل است. با وجود تعاریف مختلف برای واژه عامل، عاملها موجودیتهایی هستند که به صورت مستقل از هم عمل میکنند و شامل مدل محیطی خاص خود و اهداف داخلی هستند و توانایی این را دارند که به صورت هدفمند با شرایط محیطی ارائه شده عمل کند. در سیستمهای کنترل تولید، معمولاً سیستمهای چندعاملی برای این به کار میروند تا فرآیند تصمیمگیری کنترلی را در بین موجودیتهای خودمختار اما شریک با هم توزیع کند. مهمترین مزیت معماری عاملگرا در کنترل ، امکان ایجاد کپسولهسازی مناسب از بخشهای فرآیندتصمیمگیری کنترل است[17]. معماری بعدی، معماری سرویسگرا است که ایده آن از سال 1996 مطرح شد، معماری سرویسگرا تحت عنوان چشماندازی رفتاریساختاری تعریف میشود که کاراییهای سیستم را با استفاده از کاراییهای محل و موجودیت توزیعشده بالا میبرد. مهمترین ویژگی معماری سرویسگرا، به صورت سرویساست که برای هر موجودیت و قوانینی که آنها به کار میبرند تعریفشده است. سرویسهای موردنظر بایستی توسط شبکهای از موجودیتها در دسترس باشد و از واسطهای استاندارد استفاده کنند . بنا بر این لازم نیست دانشجزئیشده در مورد رفتار داخلی سرویسها به کاربران آموخته شود. استفاده از معماری سرویسگرا برای کنترل یک سیستم در سالهای اخیر بسیار پرکاربرد شدهاست. مثالهایی برای این برنامهکاربردی، سیستمهای مبتنی بر وبسرویس برای پیکربندی وسایل و یا تعامل مبتنی بر وبسرویسهای سازمانها است[16]. همانطور که قبلاً اشاره شد، سیستمهای کنترلی تولیدکه در حال حاضر استفاده میشود، به اندازه کافی ساختار کارآمد و رفتار مناسب و قابلیت استفاده بهینه و یکپارچگی را در رویههایشان ندارند لذا تعدادی از اهدافی که بایستی تامین شود، با نیمنگاهی به فناوری در ادامه عنوان شده است[14]. تولید بصری: هدفش تامین واسط کنترلی مناسب با بهرهگیری از فناوری و خلق تصویری بزرگ از رویدادها و دادههای مختلف تولید است. تولید مشارکتی: به کارگیری فناوری در لایههای پایین تولید تمرکز دارد. تولید واقعی: بر تعریف سیستمهای اجرایی تولید در محیط واقعی و ارائه راهحل جامع اشاره دارد. تولید باز: تمرکز تولید توزیعشده بر رویکرد منبع باز میباشد. تولید مبتنی بر رویداد: توسعه یک سرویس واسط برای رویدادها که امکان ثبت رویدادها، توسط تولیدکنندگان رویدادها و مصرفکنندگان رویدادها است را فراهم میآورد. در اینجا معماری سرویسگرا میتواند راهحل مناسبی باشد. شکل2.5 چالشهای تولید توزیع شده] 4[ 2.4 سیستمهای اجرایی تولید توزیع شده با روبروشدن با نیازهای روز افزون برای انعطافپذیری و سازگاری سیستمهای تولید، غیرمتمرکزسازی کنترلهای اجرایی تولید اهمیت بسیاری پیدا کردهاست. از این رو در سالهای اخیر تحقیقات بسیار و فعالیتهای توسعهای بسیاری برای حل این مشکل انجامشده است. یکی از بهترین نتایج این فعالیتها مجموعهای از الگوهای طراحی است که شامل شرح موجودیتهای اصلی و شمای تعاملی بین آنها است. در ادامه برخی از این الگوها شرح داده شده است و نمونههای آن در سه رویکرد PROSA، متامورف و PABADIS نشان داده شده است. سیستمهای کنترلی متعارف امروزی با چالشهای زیر برای روبرو شدن با سیستمهای تولید مدرن روبهرو هستند. سفارشات غیرقابل پیشبینی: مشتریان و سفارشات تولید دائماً تغییر میکنند، معمولاً زمانیکه تولید آغاز شدهاست. کارگاهپویا: پیکربندی منابع در سطح کارگاه در طول تولید تغییر میکند، چیزی که طراحی اجرای سفارشات را دشوار میسازد. پیچیدگی کارگاه و سفارشات: سیستمهای تولید مدرن با پیچیدگی روزافزون و نیازمندیهای انعطافپذیر سفارشات تولید و همچنین تغییر در پیکربندی کارگاه روبرو هستند. به علت ماهیت سلسلهمراتبی سیستمهای متمرکز که به شدت ایستا بوده و به سختی خود را با این تغییرات سازگار میکنند و ضمن آنکه فرآیند تصمیمگیری در لایه بالایی هرم اتوماسیون معمولاً برلایه برنامهریزی منابع سازمان متمرکز شدهاست و در نتیجه طرح تولید به سختی در قبال تغییرات و استثناها واکنش نشان میدهد، معماری سرویسگرا پیشنهاد می شود. در محیطی که انعطافپذیری بالایی لازم بوده نظیر تولید قطعات بسیار سفارشی شده، بهینهسازی مطلق تولید به سختی میتواند مورد غفلت قرار گیرد، اما نکته مهم این است که در محیط،دائماً در حال تغییربوده و نبود انعطافپذیری سبب میشود که نتوان مکانیزمهای بهینهسازی بسیاری را لحاظ کرد. سیستمهای کنترل توزیعشده، حل چنین مسائلی را با ارائه دو مکانیزم مورد بررسی قرار دادهاست. انتقال فرآیند تصمیمگیری از لایه برنامهریزی منابع سازمان به لایهسیستمهای اجرایی تولید، جایی که افق برنامهریزی کوتاهتری دارد و در نتیجه بهتر میتواند در قبال تغییرات واکنش نشان داد. توزیع کنترل در طول مجموعهای از موجودیتها ی مستقل که مسئولیت خاصی را برای انجام سفارش انجام میدهند. برای اینکه بتوان انعطافپذیری بیشتری را برای کنترل و برنامهریزی تولید فراهم کرد، چشماندازهایی از سیستم کنترل تولید تعریف شدند و به چندین معماری و مفهوم توسعه یافتند. چشمگیرترین آنها مفهوم تولید هولونی و معماریهای چشمگیر نظیر پروسا و متامورف Iو II. ایده کلی سیستمهای کنترلی توزیعشده این است که فرآیند تصمیمگیری، همانند کاراییهای سیستم در بین موجودیتهایی که مستقل عمل میکنند و تحت عنوان هولون خوانده میشوند، توزیع میشود[4]. 2.4.1راه حلهای فعلی سیستمهای اجرایی تولید توزیعشده تمامی بازهراهحلها در سیستمهای اتوماسیون توزیعشده توسعهیافته از جزئاً متمرکز تا تماماً توزیعشده متغیر است. بعضی از آنها شامل معماری کامل هستند که نه فقط سیستمهای اجرایی تولید را شامل میشوند بلکه کنترل را در تمامی سطوح شامل میشود. سایرین صرفاً مکانیزم پشتیبانیکننده دارند که فقط امکان این را فراهم میآورند تا سیستمهای متداول با ملزومات صنایع مدرن سازگار شوند. بیشتر معماریهای سیستمهای اجرایی تولید توزیعشده از تکنولوژی چندعاملی استفاده میکنند و واژه عامل علیرغم تفاوت اصلی منشا سیستمهای چندعاملی است. معروفترین معماری موجود، پروسا است که یک معماری مرجع هولونیک است که براساس سه نوع هولون پایه شکل گرفته است: محصول، سفارش و منبع. علاوه بر آن برای تمامی معماریهای موجود توزیعشده، الزام برای دیدن کارگاه وایجاد واسطی این اجبار را به همراه آورده است تا چهارمین نوع کامپوننت نیز شکل گیرد. معماری دیگر که بر اساس مفهوم هولونی شکل میگیرد متامورف I و متامورف II است. این معماری از موجودیت مدیاتور استفاده میکند که مکانیزم ارتباطی را برای سیستمها و کامپوننتهای مختلف فراهم میآورد و کارایی بسیاری را برای سیستمهای اجرایی تولید فراهم میکند. ضمن آنکه متامورف اولیه بیشتر یک ابزار یکپارچه کننده برای سیستمهای درگیر بوده تا یک راهحل جامع. نهایتاً اینکه متامورف، با معماری چندعاملی درگیر شد، معماری که تلاش میکند کاراییهای سازمانهای تولیدی را در محیط توزیعشده بالا برد. به عنوان مثال، زیرساختارهای سازمانهای تولیدی مبتنی بر عامل، یک معماری هیبریدی مبتنی بر عامل است که مدیاتور را با رویکرد عاملهای خودمختار ترکیب میکند. معماریهایی نظیر کارخانههای فرکتال پیشرفته اززنجیره تامین اطلاعاتی استفاده میکنند که از کارایی واسط منابع مبتنی بر عامل استفاده میکند که هدایت سفارش تولید غیر متمرکز را بر اساس استراتژی بهینهسازی محلی انجام میدهد. بر عکس آن اتوماسیون کارخانه بر اساس پابادیس، معماری عاملی را فراهم میآوردکه سطحی از اتوماسیون را فراهم میآورد که کل هرم اتوماسیون را تحت پوشش قرار میدهد ولی هدف اصلی اش سیستم اجرایی تولید توزیعشده جامع است. 2.4.2الگوهای طراحی جامع برای سیستمهای اجرایی تولید سازماندهی یک سیستماجرایی تولید و ارتباط آن با برنامهریزی منابعسازمان و لایه پایین تولید الگوهای جامعی دارد که توسط بسیاری از راهکارهای سیستمهای اجرایی تولید توزیعشده دنبال شدهاست. الگوهای طراحی به طور بسیار گسترده در فناوری اطلاعات مورد استفاده قرار گرفته است و با ظهور شیگرایی ایده الگوی طراحی ، به عنوان اصل طراحی مستقل از برنامهکاربردی برای مهندسی نرمافزار اتخاذ شد. در سالهای اخیر استفاده از الگوهای طراحی در چندین نظم که شامل طراحی برنامههای کاربردی کنترلی یکپارچه است، متداول شده است. همراه با طراحی کنترل، برنامههای کاربردی الگوهای طراحی را به عنوان مبنا توسعه قرار دادند. در زمینه سیستمهای کنترلی توزیعشده، عاملها بسیار مورد پذیرش قرار گرفتهاند واین دلیل آن است که الگوهای طراحی، در این زمینه بسیار مورد شرح وتفصیل قرار گرفتهاست، ولی در سایر رویکردها نظیر سرویسگرایی نیز قابل اجرا است. در سیستمهای اجرایی تولید دو موجودیت عامل به همراه سه دسته از دانش وجود دارد که مرتبط با فرآیند اجرای سفارشهای تولید است. این دو موجودیت که سفارش و منبع هستند. معمولاً توسط دستهبندیهای دانش تولید، دانش سفارش و دانش منبع انجام میشوند. عاملهای منابع مرتبط با واحد تولید، انواع مختلفی دارند، هر عامل یک منبع را با قابلیتهای تولید خاص به نمایش میگذارد و برای اجتماع عاملها دانشی حاوی اطلاعات منابع فراهم میآورد. این عامل برای تمامی تصمیمات کنترلی مرتبط با منابع، شامل زمانبندی منابع بر طبق الگوریتمهای زمانبندی مشارکتی ،کنترل منابع در لایه پایین تولید و همچنین فعالیتهای پشتیبانی نظیر نگهداری و فعالیتهای چرخه حیات را پاسخگو است. با روبهرو شدن با این موجودیتها و توزیع دانش، کل سیستم بدین ترتیب عمل میکند که تمامی عاملها جامعهای از عاملها را شکل میدهند که شامل عاملهای منابع و عاملهای سفارش هستند. این جامعه عاملها همچنین شامل یک تابع ثبت نام خاص برای منابع است. هنگام آغاز بهکارکردن یک عامل منبع، این عامل، قابلیتهای تولیدش را ثبت میکند. قابلیتهایی که تحت عنوان توابع تولیدی قابل استفاده نمایش دادهشده است. این توابع تولید، قابلیت جستجو داشته، مقداردهی اولیه میشوند، پارامتردهی میشوند و در حین تعامل دو عامل منبع و سفارش متوقف و شروع به کار میکنند[18]. از طرف دیگر، هر عامل سفارش، یک سفارش محصول را تحت پوشش قرار میدهد که متشکل از مجموعهای از گامهای تولید است که برای فرآیند تولید ضروری میباشد. ضمناً عامل سفارش بایستی برای قابلیتهای تولید موردنظر که توسط عامل منبع برای انجام سفارش پیشنهاد داده میشود، مذاکره کند. بدیهی است که برای انعطاف پذیری سیستم مفید خواهد بود اگر دو عامل سفارش و منبع، هرکدام زمانبندی خودشان را نگهداری کنند و هر کدام به صورت مستقل تصمیمات زمانبندی خودشان را انجام دهند ولی به صورت مشارکتی[19]. شکل2.6 الگوی سفارش-منبع] 19[ هنگام آغاز به کارعامل منبع، این عامل خودش را به جامعه عاملها میشناساند ، بدین ترتیب که جامعه عاملها از توابع تولید که متعلق به عامل منبع است با خبر می شوند و یا آنکه از تست کنترل آن عامل منبع عبور می کنند. هر عامل سفارش، سفارش تولید خودش را گام به گام بر اساس شماره تعامل بین عامل منبع و عامل سفارش پردازش میکند. عامل سفارش، گام تولید بعدی را که بایستی اجرا شود را انتخاب میکند. عامل سفارش، برای دانش جامعه عاملها، مجموعه از عاملهای منابع را که شامل توابع تولید که میتواند برای گام تولید بعدی عامل سفارش مورد استفاده قرار گیرد را مشخص میکند. عامل سفارش با عامل منبع مشخص شده مذاکره میکند و طی آن تابع تولیدی بعدی که قرار است مورد استفاده قرار گیرد و زمانبندی مورد استفاده مشخص میشود. بنابراین،عامل سفارش از تمامی عاملهای منبع مورد نیاز برای زمانبندی سوال میکند ودرباره تابع تولید بعدی که قرار است مورد استفاده قرار گیرد، تصمیم میگیرد و این تابع را تخصیص میدهد. عامل منبع مرتبطی که تابع تولید آن انتخاب شده است، منابع را در زمانبندی خودش تخصیص میدهد. در لحظه توافق، عامل سفارش به عامل منبع دسترسی یافته تا تابع تولید مدنظر را آغاز و پارامتردهی کند. اگر پردازش پایان یافته باشد، آنگاه توابع پردازشی، نتایج پردازش را برای عامل سفارش با استفاده ازعامل منبع مرتبط گزارش میدهد[4]. 2.4.3تحلیل و مقایسه رویکردهای توزیعشده از آنجا که راهحلهای مختلف سیستمهای اجرایی تولید معمولاً برای حوزههای مختلف پیادهسازی نظیر زمانبندی، پشتیبانی از مشتری، بهرهوری منابع و یکپارچگی سیستمتمرکز دارند. لذا نمیتوان آنها را با هم مقایسه کرد. در ادامه تمرکز بر سیستمهایی است که تمامی فرآیندهای تولید را تحت پوشش قرار میدهند. از این رو مفاهیم مبتنی بر هولون نظیر پروسا و متامورف و مفاهیم مبتنی بر عاملها نظیر پابادیس که بازه وسیعتری را تحت پوشش قرار میدهند، بررسی شده و یکپارچگی عمودی تمامی لایهها را مدنظر قرار میدهیم. هولون منابع و عاملهای محلی اگر به طور کلی صحبت کنیم دو عنصر اصلی در کارخانههای توزیعشده وجود دارد: منابع و مشتریها، که مشتریها با الگوی طراحی سفارش نشان داده شده است. منابع در سیستمهای تولید هولونی توسط هولون منابع نشان داده شده است، چیزی که نمایشگر منابع سطح ماشین نیز هست. هولونهای منابع متشکل از قطعات فیزیکی است که با عنوان منابع تولید در سیستم تولید هولونی شناخته میشوند و بخش پردازش اطلاعات که منابع را کنترل میکند. بخش دوم متدهایی را نگهداری میکندکه منابع تولید را تخصیص میدهد و دانش و رویههای سازماندهی و منابع فیزیکی تولید را کنترل میکند تا تولید را به پیش ببرد. در پابادیس، هولونهای منابع واحد تولید مشارکتی نامیده میشود، چیزی که در عمل واحد تولید کارگاه نیز هست. بخش پردازش اطلاعات هولونهای منابع به بهترین نحو با مفهوم عاملهای منابع تناسب دارد و یا عاملهای محلی در پابادیس- که در آن واحد تولید مشارکتی، بخشی از توابع کنترلی را نیز شامل میشود. مهمترین تفاوتی که وجود دارد این است که در پابادیس، عامل محلی، کمابیش یک واسط بین جامعه عاملها و واحد تولید مشارکتی است و عاملهای محلی یک واسط عام دارد که امکان یکپارچگی با هر سختافزار خاصی را دارد. در سیستم تولید هولونی، هولونهای منابع چیزی فراتر از این واسطها هستند. چیزی که تمامی کاراییهای واحد تولید مشارکتی(توابع، واحد کنترل و سطح ارتباطی عاملها) در آن به خوبی پیادهسازی شده است. پابادیس بخش منطقی و استاندارد سطح کنترل را تشخیص میدهد، آنچه که قابل استفاده برای هر واحد کنترلی مشارکتی، بخش مختص هر ماشین و بخشهایی که بایستی توسط مشتریان سیستم پیادهسازی شود، نیز است. چنین امکانی سیستم را انعطافپذیرتر میکند و سطح کنترلی را کپسوله میسازد و امکان افزودن کارایی جدید را راحتتر میسازد، زمانی که مشتری(سازما ن صنعتی دیگر) بایستی یک منبع مستقل از کارخانه به سیستم تولید اضافه کند وآنوقت دیگر لازم نیست نگران قابلیت کار متقابل با کامپوننتهای جدید باشد و مشتری فقط بایستی واسط را دنبال کند. عاملهای هولون فقط منابع را پشتیبانی نمیکنند، علاوه بر آن تمامی امکانات تولید را نیز مدیریت میکنند. این بدان معنی است که قادرند با یکدیگر ارتباط برقرار کنند تا بتوانند استفاده بهینه از ماشینها داشته باشند ولی پابادیس اجازه نمیدهد عاملهای منابع با یکدیگر ارتباط برقرار کنند این بدین جهت است که سیستم محصولگرا شود نه ماشینگرا. چیزی که بزرگترین تفاوت بین پابادیس و سیستم تولید هولونی است. محصول و کارایی آن هدف اصلی در پابادیس است ولی سیستم تولید هولونی بیشتر بر استفاده بهینه از ماشین تمرکز دارد. چنانچه هولونهای سفارش صرفاً به صورت مجموعهای از پارامترهای تولید که بایستی تولید شود خلاصهشده است[20]. هولونهای سفارش و عاملهای تولید در مقایسه هولونها و عاملهای محلی تفاوت بین عاملهای تولید در پابادیس و هولون سفارش در سیستم تولید هولونی واضحتر است. عامل تولید یک نمونه موجودیت است که تمامی مراحل تولید یک قطعه کاری را مدیریت میکند. این عامل تصمیمات، فعالیتها و دانش خودش را بر اساس یک سفارش کاری قرار میدهد. چیزی که مشخصه کاملی از فعالیتهای تولید را با در نظر گرفتن وظایفی که بایستی انجام شود، تا یک سفارش تولید کامل شود، ارائه میدهد. همزمان با سفارش کاری، ماشین خاصی را اختصاص نمیدهد و به جای آن کاری را که بایستی انجام دهد را مشخص میکند. این اصل، به عامل تولید این آزادی را میدهد تا تصمیمگیری کند، چه ماشینی بایستی استفاده شود و امکان عوض کردن ماشین در حین اجرا را میدهد. یک هولون سفارش بسیار سادهتر است. کمابیش یک درخواست مشتری است، چیزی که نیازمندیهای محصول در آن مشخص شده است. چنین ویژگی برای تولید انبوه مزیت محسوب میشود، چرا که هولون سفارش به یک قطعه کاری خاص متصل نیست. یک هولون سفارش کار زمانبندی و تخصیص منابع را انجام نمیدهد، چرا که دانش این کار را در مورد مشخصه محصولات و لایه های پایین کارخانه ندارد[20]. هولون محصول و عامل تولید ضرورت هولون سفارش بر روی مستقل از تکنولوژی بودن محصول است. این بدین معنی است که هولون سفارش که قطعه کاری را به نمایش میگذارد، دانش تکنیکی در مورد مشخصه کارخانه ندارد و هیچ اطلاعاتی در مورد اینکه یک محصول چگونه تولید میشود ندارد. هولونهای سفارش با هولون محصول تماس میگیرند تا بفهمد یک محصول چگونه تولید میشود و بر اساس پاسخ، اجرای تولید را انجام میدهد. استانداردسازی توابع که توسط مفهوم واحد تولید مشارکتی پشتیبانی میشود ، شرحی عام از کاراییهایی که وابستگی خاصی به تکنولوژی ندارد، میدهد. در پابادیس هیچ موجودیت مشابه هولون محصول وجود ندارد. عاملهای تولید، نمایندگی هولون محصول و هم هولون سفارش را دارند. مزیت هولون محصول این است که مشخصه محصول جدید میتواند در هرزمانی به سیستم اضافه شود. ولی در عوض هولونها نمیتوانند رفتار خود را در قبال تغییرات برنامهریزی نشده سازگار کنند[20]. هولون پرسنل و عاملهای مدیریت کارخانه هولون پرسنل، معادل عامل مدیریت کارخانه در پابادیس است. هدف اصلی هولونهای پرسنل این است که به کامپوننتهای دیگر مروری از سیستم بدهند. در نتیجه اغلب برای نظارت یا پشتیبانی کارایی مورد استفاده قرار میگیرد. یکی از توابع اصلی سیستمهای اجرایی تولید که توسط این مفهوم به نمایش گذاشته شده است، زمانبندی است. به عنوان مثال پروسا، از واحد متمرکزسازی به نام هولون زمانبندی استفاده میکند. در پابادیس، زمانبندی ساده شده است و در عاملهای تولید توزیع شده است. این رویکرد سیستم را منعطفتر میکند ضمن اینکه باید اشاره کرد هیچگاه راهحل بهینه را ارائه نمیدهد. پابادیس تعداد نمونههای جدید را با بهکارگیری معماری پایه فعلی کاهش میدهد. این کارباعث میشود، عاملهای تولید پیچیدهترشود.اماباعث میشود کل معماری سادهتر شود. بر خلاف آن، پروسا امکان تعریف نمونههای جدید را فراهم میکند، اما هولونهای پایه را ساده نگه میدارد. چیزی که برای هر دو معماری مشترک است، این است که هر دو از واحدهای متمرکز اجتناب میکنند[20]. تراکم تراکم نکتهای کلیدی در سیستم اجرایی تولید هولونی است. تراکم باعث میشود تا عاملها را در سلسلهمراتب جای داد. این یک راهحل است که بتوان از پس پیچیدگی هولونهای مستقل بر آمد. این راهحل، از ارتباطات پیچیده و بار شدید شبکه در سیستم جلوگیری میکند ولی باعث میشود به سمت سیستمهای متمرکز عقبگرد داشته باشیم و مقیاسپذیری را کاهش میدهد. تراکم لایهجدیدی را در هرم کنترل معرفی میکند و منطق هولونها را پیچیدهتر میسازد. در پیادهسازی عملی حتی ارتباطات نیز مشکلزا میشود، چرا که هولونها بایستی با یکدیگر در لایههای مختلف ارتباط داشتهباشند. چیزی که منجر به پیچیدگی کل فرآیند شده لذا، بایستی توازنی بین مکانیزم ارتباطی تکی سادهتر و سربار اضافهتر ایجاد شود. پابادیس از تراکم عاملهااستفاده نمیکندو سعی میکند از پیچیدگی ارتباطات با ارائه نمونههای بیشتر بدون وابستگی اجتناب کند. موضوعی که اهمیت ارتباطات را کمتر میکند. این منجر به کاهش بهینگی شده و در عوض به نحوی کارآمد انعطافپذیری و مقیاسپذیری را در سیستم افزایش میدهد[20] میانجی این کار دشواری است که بتوان معماری پروسا و متامورف را با هم مقایسه کرد. میانجیها در متامورف ابزارهای قدرتمندی هستند که سیستمهای مختلف را به هم پیوند میدهد. ولی به سختی به عنوان معماری یک سیستم تولیدی در نظر گرفته میشود. تا حدی میانجیها مشابه هولون پرسنل در سیستمهای تولیدی هولونی و یا عاملهای مدیریت کارخانه در پابادیس است. آنها منجر به کارایی متمرکزی برای سیستم میشوند- با ایجاد هماهنگی با سایر عاملها. میانجیها میتوانند با موفقیت در مفاهیم دیگر مورد استفاده قرار گیرند، نظیر پابادیس و پروسا- برای اتصالات عاملهای مختلف و همچنین فراهم آوردن راهحلهایی برای مشکلاتی که مستلزم مروری خلاصه بر کل سیستم است. ولی به طور خاص، میانجیها نمیتوانند به عنوان معماری تولیدگرا مطرح شوند. چرا که مختص توابع سیستمهای اجرایی تولید نیستند(نظیر زمانبندی) و یا اینکه اکتورهای مختلف را در کارخانه به نمایش نمیگذارند. تلاش برای ایجاد یک معماری در متامورف II بیشتر یک رویکرد متمرکز بوده که میانجیهای خاصی را برای هر تابع اتوماسیون سیستم کارخانه داشته و منجر به سلسلهمراتب قوی بین آنها میشود. ممکن است مهمترین دستاورد مفهوم میانجی توانایی آن برای گردهم آوردن مجازی گروههای مختلف بر اساس نیازهای مشابه است. این قابلیت انعطافپذیری بالایی را به همراه میآورد[20]. 2.5محاسبات ابری ظهور پدیده ای که امروزه تحت عنوان پردازش ابری شناخته می شود،به طور اساسی راهی را که سرویسهای فناوری اطلاعات ایجاد، توسعه ، به کارگرفته ،مقیاس داده شده و به روز شده و نگهداری میشوند را تغییر داده است. از طرف دیگرهمچنان که پردازش ابری گسترده تر می شوندپیچیدگی مدیریت کل زیرساختار و معماری آن با توجه به ماهیت توزیع شده بودن آن افزایش می یابد. پردازش ابری نشانگر همگرایی دو روند عمده در فناوری اطلاعات است. الف. کارایی فناوری اطلاعات، چیزی که قدرت کامپیوترهای مدرن را به بهترین نحو و به صورت بهینه با استفاده از سخت افزارها و نرم افزارهای مقیاس پذیر به کار گرفته است ب. چابکی کسب و کار، جایی که فناوری اطلاعات می تواند به عنوان ابزاری برای توسعه سریع و پردازش موازی استفاده شود و استفاده از تحلیلگرهای کامپیوتری و ابزارهای تعامل جابه جایی پذیرکه به کاربران به صورت بلادرنگ پاسخ میدهد نیز براین چابکی افزوده است. مفهوم بهرهوری در فناوری اطلاعات شامل ایده های موجود در پردازش سبز نیز هست، به عبارتی نه تنها باعث صرفه جویی در مصرف منابع می شود بلکه علاوه برآن کامپیوترها می توانند به صورت پراکنده در مناطق جغرافیایی قرار گیرند که هزینه انرژی پایینتر آید. واژه چابکی به معنای پردازش ارزان نیست بلکه این امکان را فراهم می آورد تاکسب و کارها قادر باشند از ابزارهای محاسباتی که می توانند به سرعت به خدمت گرفته شوند استفاده کنند تا سرمایه های اولیه را صرف نکنند. پردازش ابری یک مدل سرویسی فناوری اطلاعات است ،چیزی که هم سخت افزار و هم نرم افزار را در لحظه نیاز به مشتریان از طریق اینترنت به صورت سلف سرویس و مستقل از مکان ارائه می دهد. منابعی که لازم است تا به سطح قابل قبولی از کیفیت سرویس برسیم بایستی به بهترین نحو تقسیم شده باشد، دائماً مقیاس پذیر باشد، به سرعت قابل نظارت باشد، مجازی شده باشد و با کمترین تعامل با پشتیبانی کننده قابل تامین باشد. بایستی اشاره کنیم که تعریف ما بدین معنی نیست که همواره سرویس توسط شخص سومی ارائه می شود ولی تاکید ما بیشتر بر ابعاد زیر می باشد1. استفاده بهینه از منابع 2. منابع فیزیکی مجازی شده3. انتزاع معماری4.مقیاس پذیری پویای منابع5. خاصیت الاستیکی و خودنظارتی خودکار شده منابع6. حضور در همه جا-یعنی مستقل از وسیله و مکان. پردازش ابری می تواند توسط سرور های داخلی یک سازمان نظارت شودو یا اینکه می شود از یک پشتیبانی کننده ابر تامین شود- کسی که ریسک هزینه های اولیه را پذیرفته است. بسیاری از ایده های اولیه در پردازش ابری جدید نیستند و بسیاری از آنها به سال 1965 بازمی گردند. ولی بسیاری از آنها حاصل تلاقی شرایط فعلی است که اطلاعات مستقل از وسیله و مکان را دریافت می کند و از ویژگی های تکنولوژی محاسبات امروزی بهره میگیرد. پردازش ابری مزایای فعلی را شامل می شود[21]. 1.به طور چشمگیری هزینه ورود را برای بسیاری از سازمانهای کوچک کاهش می دهد. سازمانهایی که تلاش دارند تا وارد کسب و کارهایی شوند که که احتیاج شدید به محاسبات دارد، چیزی که در گذشته فقط برای سازمان های بزرگ امکان پذیر بود. 2.دسترسی سریع به سخت افزار را بدون هیچ هزینه اولیه ای فراهم می سازد، چیزی که باعث می شود تا بسیار سریعتر وارد کسب و کار شوند. 3.پردازش ابری موانع را بر سر خلاقیت برمی دارد ، چرا که توسط برنامه های مختلف، در نقاط مختلف و در همه جا قابل دسترس است. 4.پردازش ابری کار سازمانها را برای گسترش سرویسهای خودشان آسان می کند. 5.پردازش ابری دو دسته از برنامه های کاربردی را ممکن می سازد. الف. برنامه های تعاملی موبایل ب. پردازش دسته ای موازی. درحالیکه شاهد ظهور پردازش ابری هستیم و این اتفاق سالها و یا شاید یک دهه به طول انجامد ولی سه تکنولوژی پایه تشکیل دهنده آن هستند: مجازی سازی، چند مستاجری و وب سرویسها . مجازی سازی تکنولوژی است که ویژگیهای سخت افزاری پلتفرمهای کامپیوتری را از کاربران پنهان می سازد و در عوض یک پلتفرم شبیه سازی شده و انتزاعی را فراهم می آورد. این پلتفرم شبیه سازی شده نظیر یک سیستم مستقل و تمام منظوره رفتار می کند ولی بر خلاف پلتفرم سخت افزاری قابل پیکربندی در لحظه است و قابلیت نگه داری و تعویض آسانی دارد. این پلتفرم به بهینه ترین نحو مورد استفاده قرار می گیرد و هزینههای عملیاتی و هزینههای اصلی را کاهش می دهد. در حالیکه ایده مجازی سازی به سال 1960 باز می گردد ولی در سالهای اخیر است که منابع شبکه ای و محاسباتی به درجه ای رسیده اند که بتوان این سیستم شبیه سازی شده را با کارایی بالا پیاده سازی نمود. ایده بعدی بحث چند مشتری بودن است، چیزی که یک نمونه از یک برنامه کاربردی به چندین مشتری خدمت می رساند. این باعث می شود تا بهره وری بیشتری از منابع سیستم داشته باشیم(در حافظه و سربار پردازشی). یک وب سرویس همانطور که در W3C آمده است یک سیستم نرم افزاری است که به نحوی طراحی شده است تا تعامل ماشین به ماشین و سازگار را در یک شبکه فراهم آورد. این تعریف شامل سیستم های متفاوتی می شود ولی کاربرد متعارف آن در ساختار مشتری- سرور می باشد که از طریق پروتکل متعارف HTTP با هم ارتباط دارند. وب سرویس ها کمک می کنند تا اینترفیس بین برنامه های کاربردی استاندارد شود و کلاینتها بسیار راحتتر به برنامه های کاربردی در شبکه ها دسترسی داشته باشند[21]. نقشه راه برای کارشناسان سیستم های اطلاعاتی و محققین پردازش ابری نظیر هر مدل دورنمای تکنولوژیکال پردازش ابری به سرعت در حال رشد است و شاید امکان پذیر نباشد که بتوان آینده آن را حدس زد ولی بحث اقتصادی قضیه جریان را به پیش می برد. نقاط قوت: قابلیت مقیاس پذیری سرویسها در زمان بسیار کوتاه، یکی از کامپوننتهای اصلی پردازش ابری مدیریت هزینه ها است که نقطه قوت دیگر آن محسوب می شود. نقاط ضعف: سازمانها کنترل فیزیکی خود را بر روی داده هایشان از دست می دهند و دیگر اینکه شرکتهای بزرگ برای برنامه های حساس و حیاتی خود با احتیاط از بستر ابر استفاده می کنند. فرصتها: یکی از فرصتهای چشمگیر پردازش ابری این است که به کشورها کمک می کند بدون هیچ هزینه اولیه ای از امکانات فناوری اطلاعات استفاده کنند. به جز کشورها کمپانی های کوچک هم فرصت مهمی برای پردازش ابری هستند تا بدون هزینه اولیه به اهداف خود که قبلاً قابل دسترسی نبود برسند. Mashup فرصت دیگری برای پردازش ابری است. Mashup صفحه وب و یا برنامه کاربردی است که داده ها و یا کارایی ها را از یک ویا چند منبع خارجی با هم ترکیب می کند و سرویس جدیدی را می سازد. تهدیدها: یکی از تهدیدهای پردازش ابری سنگر گرفتن در قبال آن به علت احساس عدم امنیت نسبت به آن است و دیگری خطر دزدیده شدن اطلاعات از پشتیبانی کنندگان ابر است. نگرانی دیگر بحث عدم وجود استانداردها است[21]. 2.5.1نقشها در پردازش ابری: 1.مشتریان: در محیط ابر مشتریان آنچه در عمل مشتریان محسوب می شوند، کسانی هستند که فقط هزینه استفاده از سیستم را پرداخت می کنند. 2. پشتیبانی کنندگان: پشتیبانی کنندگان وظیفه نگهداری و به روز رسانی سیستمها را بر عهده دارند ضمناً وظیفه به روزرسانی نرم افزارهایی که در ابر مورد استفاده قرار می گیرند را نیز دارند. 3.توانمندساز: از واژه توانمندساز برای سازمانهایی استفاده می شود که محصولات و سرویسهایی را می فروشند که تحویل تجهیز و اتخاذ پردازش ابری را آسان می کنند. 4.تنظیم کنندگان: تمامی ذینفعان نقاط مختلفی از زنجیره تامین ابر را به نمایش می گذارند. بر خلاف نقش تنظیم کنندگان نقشی است که از تمامی ذینفعان عبور می کند و بین نقشی است[21]. 2.6اصول معماري سرويس گرا معماري سرويس گرا روشي براي طراحي سيستم هاي نرم افزاري با استفاده از سرويس هااست. از اين رو اصولي در اين پارادايم تعريف شده اند كه مبناي توسعه، نگهداري و استفاده از معماري سرويس گرا مي باشند. اين قواعد زمينه هاي زير را در بر مي گيرند[22]. استفاده مجدد، دانه بندي، پيمانه اي بودن، قابليت تركيب،مولفه سازي و قابليت هاي همكاري پيروي از استانداردها( استاندارد هاي عمومي و خاص صنايع) شناسايي و طبقه بندي ، تهيه و تحويل، و نظارت و رديابي سرويس ها. علاوه بر موارد فوق، قواعد معماری دقیقی برای طراحی و تعریف سرویس ها پیشنهاد شده است که بر رفتار طبیعی سیستم و سبک طراحی آن تاثیر می گذارند.[23]اصول زیر برای طراحی معماری سرویس گرای کارآمد پیشنهاد شده است : قرارداد سرویس استاندارد : سرویس های درون یک مخزن سرویس از استانداردهای طراحی قرارداد یکسانی پیروی می کنند. این قرارداد یک توافقنامه ارتباطی است که بر اساس یک یا چند سند توصیف سرویس تعیین می شود. اتصال سست سرویس ها : قراردادهای سرویس اتصال ضعیفی میان نیازمندی های مصرف کننده ها اعمال می کنند و خود از محیط پیرامونشان جدا هستند . تجرید سرویس : قرارداد های سرویس فقط اطلاعات حیاتی را شامل می شوند و اطلاعات در مورد سرویس به آنچه در قراردادهای سرویس منتشر می شود محدود است . قابلیت استفاده مجدد سرویس : سرویس ها فقط منطق کاری را نمایش می دهند و می توانند به عنوان منابع سازمانی قابل استفاده مجدد تلقی شوند . بسته بندی سرویس : دست یابی به کارکرد سرویس از طریق یک واسط خوش تعریف امکان پذیر است . در واقع کاربرد سرویس از دید کاربر به صورت جعبه سیاه است . خودمختاری سرویس : سرویس ها بر محیط زمان اجرای خود سطح کنترل بالایی دارند . قابلیت شناسایی سرویس ها : فراداده های گویایی به سرویس ها الحاق می شود که به شناسایی و تفسیر آنها کمک می کند. قابلیت ترکیب سرویس : سرویس ها عناصر موثری برای ترکیب هستند، بدون توجه به اندازه و پیچیدگی ترکیب مورد نیاز. معماری سرویس گرا و راه حل های مبتنی بر وب سرویس از دو نقش کلیدی پشتیبانی می کنند : یک درخواست کننده سرویس (مشتری) و یک تولید کننده سرویس که از طریق درخواست های سرویس با یکدیگر تعامل دارند. در نتیجه نقش ، نوع شرکت کننده در معماری سرویس گرا را مشخص می کند[24]. میان درخواست کننده و تولید کننده یک رابطه اتصال ضعیف وجود دارد ،که به طور خاص در اینترنت ، از اهمیت بالایی برخوردار است زیرا دو طرف ممکن است در سازمان های متفاوتی باشند . سرویس های معماری سرویس گرا برای درخواست کننده قابل رویت هستند اما ، مولفه های درونی آنها چنین نیستند. درخواست کننده سرویس تا زمانی که کارکردی مورد نیاز او برآورده می شود نیاز ندارد از جزئیات پیاده سازی سرویس مطلع باشد. در مقابل، تولید کننده سرویس به نحوه طراحی مولفه ها ، مدیریت و دسترسی آنها اهمیت می دهد . تولیدکننده های سرویس ، سرویس ها را در در قالب استاندارد تعریف و توصیف کرده سپس آنها را در مخازن سرویس، همراه با اطلاعاتی در مورد جزئیات فنی و نحوه دسترسی به سرویس منتشر می کنند . توصیف سرویس ها معمولاً در قالب فایل های زبان توصیف سرویس های وب (WSDL) صورت می گیرد. هر فایل WSDL شامل اطلاعاتی در مورد نوع متغیر های ، عملیات ، واسط ، نقاط و زمان اتصال سرویس می شود. درخواست کننده سرویس از روی اطلاعات موجود در مخازن ، سرویس مورد نیاز خود را پیدا می کند. سپس با استفاده از اطلاعاتی که تولید کننده فراهم کرده است اتصال خود با تولید کننده را برقرار کرده و از سرویس استفاده می کنند . نمای این معماری در شکل 2-4 نمایش داده شده است . شکل 2.7مدل معماری وب سرویس] 26[ در ادامه با توجه به موضوع این تحقیق به معرفی روش های کشف سرویس پرداخته می شود . 2.6.1 کشف سرویس یکی از مزایای معماری سرویس گرا فراهم کردن بستری برای استفاده از سرویس های تولید شده در خارج از سازمان است که سبب صرفه جویی در هزینه و سرعت بخشیدن به فرآیند توسعه سیستم می شود[25].از این رو به ساز وکارها و روش هایی نیاز است تا یک سازمان را در شناسایی سرویس های مورد نیاز خود کمک کنند. موضوع کشف سرویس در همین راستا مطرح می شود و رابطه نزدیکی با روش های انتشار سرویس و بازیابی اطلاعات دارد . کشف سرویس عمل تطبیق نیازهای یک مشتری با اطلاعات ارائه شده در توصیف سرویس توسط ارائه دهندگان سرویس است. درخواست کننده سرویس می تواند توصیف سرویس را در زمان طراحی یا زمان اجرا از مخازن توصیف سرویس ، مانند UDDI، بدست آورد[26]. کشف سرویس در اکثر مواقع در ادامه شناسایی سرویس انجام می شود . در شناسایی سرویس با تحلیل نیازمندی های سیستم ، تشخیص داده می شود که به چه سرویس هایی نیاز است . در مرحله بعد یا این سرویس ها تولید می شوند و یا با استفاده از روش های کشف سرویس، سرویس های متناظر با سرویس های شناسایی شده کشف می شوند . گسترش معماری سرویس گرا و افزایش تعداد تولید کننده های سرویس های وب سبب شده است نیاز به روش هایی جدید برای توصیف و کشف سرویس ها احساس شود ، به خصوص در مورد همکاری های بین سازمانی. از چالش های مطرح در زمینه کشف سرویس می توان به تفاوت در نحوه توصیف سرویس ها توسط سازندگان سرویس ، مخازن نگهداری سرویس ها و زبان های توصیف سرویس متفاوت اشاره کرد[28] . روش های متفاوتی برای کشف سرویس معرفی شده اند که هر کدام سعی در رفع این چالشها دارند اما در میزان اهمیتی که به هر یک از مسائل نام برده می دهند، متفاوت می باشند. در ادامه این روش ها به صورت مختصر معرفی می شوند. 2.6.2 روش های کشف سرویس هدف کشف سرویس تسهیل دسترسی درخواست کنندگان به توصیف سرویس ها است . برای این منظور روش های متفاوتی ارائه شده اند که تلاش می کنند دسترسی آسان با دقتی بالا به سرویس ها را برای درخواست کنندگان فراهم کنند. این روش ها عمل تطبیق بین سرویس درخواستی و سرویس های موجود را بر روی توصیفات سرویس ها که در قالب فایل های WSDL آمده است انجام می دهند . روش های کشف سرویس را می توان به دو دسته کلی روش های کارکردی و روش های غیر کارکردی تقسیم کرد. در ادامه در مورد هر دسته از این روش ها توضیح مختصری داده می شود[28] . روش های کشف سرویس مبتنی بر توصیف کارکردی در این دسته ، روش ها توصیفات عملکردی سرویس ها را با نیاز های عملکردی درخواستی تطبیق می دهند . توصیفات عملکردی یک سرویس را مشخص می کند . این روش ها به سه دسته تطابق لغوی ، تطابق معنایی و تطابق رفتاری تقسیم می شوند[28] . روش های تطابق لغوی بر اساس کلمات کلیدی ، واسط های سرویس و طبقه بندی ها عمل تطبیق را انجام می دهند . در این روش ها یک پرس و جو شامل موارد نامبرده شده در بالا ایجاد می شود و سپس با استفاده از روش های تطابق متن نزدیک ترین سرویس شناسایی می شود . یکی از مشکلات این روش ها این است که کلمات ، واژگان و دسته بندی هایی که دو طرف تولیدکننده و درخواست کننده به کار می برند ممکن است متفاوت باشد و سبب شود که تمام سرویس ها مرتبط شناسایی نشوند. همچنین در روش هایی که تطابق بر اساس واسط های سرویس انجام می شود لازم است که تولید کننده سرویس اسامی معنا داری برای متغیرهای ورودی و خروجی تعیین کنند که این امر همیشه انجام نمی شود. روش های تطابق رفتاری عمل تطابق را بر اساس فرآیند رفتاری و عملکردی سرویس انجام می دهند و نه توصیف سرویس . در این روش ها از ماشین حالت برای مدل سازی رفتار سرویس استفاده می شود و انتشار و جستجو سرویس نیز با استفاده از ماشین های حالت صورت می گیرد . از مشکلات این روش ها می توان به دشواری مدل سازی سرویس های بزرگ و پیچیده اشاره کرد. همچنین تولید کننده و درخواست کننده سرویس باید از دانش خوبی در مورد ماشین های حالت و حوزه عمومی رفتار سرویس داشته باشند[28]. در روش های تطابق معنایی ، روابط و مفاهیم معنایی توصیف سرویس ها نیز در فرآیند تطبیق لحاظ می شود . این روش ها بسته به نحوه کشف روایط معنایی به چهار دسته روش های بازیابی اطلاعات ، روش های مبتنی بر هستان شناسی و روش های مبتنی بر محتوا ، تقسیم می شوند . روش های مبتنی بر بازیابی اطلاعات از موتورهای جستجو و خزنده های وب برای پیدا کردن فایل های WSDL در اینترنت استفاده می کنند . سپس روش های بازیابی اطلاعات را برای فرآیند تطبیق به کار می برند . تشابه معنایی بین توصیف و درخواست سرویس با استفاده از پایگاه های داده ای لغوی ، مانندWordNet، انجام می شود. ایراد این روش در این است که نتایج فرآیند جستجو ممکن است دقت 100 درصد نداشته باشند[28] . در روش هایی که از هستان شناسی در فرآیند تطبیق بهره می برند هستان شناسی حوزه نقش عمده ای ایفا می کند . در فرآیند تطبیق روابط معنایی میان توصیف و درخواست سرویس با توجه به هستان شناسی معین می شود و سپس عمل تطبیق صورت می گیرد. یکی از مشکلات این روش هزینه بسیار بالای ایجاد و نگهداری یک هستان شناسی است . علاوه بر این تعریف هستان شناسی برای تمامی حوزه ها عملاً میسر نیست . از دیدگاه درخواست کننده نیز درک مفاهیم و روابط درون هستان شناسی ممکن است دشوار باشد . فرآیند تطبیق در روش های مبتنی بر محتوا با توجه به شرایط محتوا معین شده در زبان پرس و جو محتوا و اطلاعات عملیات محتوا که در پرس و جو درخواست کننده مشخص شده اند انجام می گیرد . البته نیاز به تعریف یک زبان قراردادی برای نمایش عملیات و شرایط محتوا از معایب این روش است . همچنین برای بیان شرایط و عملیات محتوا در این زبان ، درخواست کننده باید دانش خوبی از حوزه سرویس داشته باشد . روش های کشف سرویس مبتنی بر توصیف غیر کارکردی این دسته از روش های کشف سرویس بر اهمیت ویژگی های غیرعملکردی از دیدگاه درخواست کننده تاکید دارد. عامل اصلی در این روش ها سطح کیفیت خدمات (QoS) ارائه شده توسط تولید کنندگان است . برای این منظور مدل توسعه داده شده UDDI نیز پیشنهاد شده است تا از QoS ها ، ویژگیهای قابلیت استفاده از پرکاربردترین ویژگی ها در زمینه پیدا کردن سرویس های مورد نیاز درخواست کنندگان را شناسایی کند . بر این مبنا روشی ارائه شده است که انتظارات و ترجیحات درخواست کنندگان را در شناسایی سرویس مناسب دخالت می دهد . در اغلب این روش ها از محاسبات فازی برای رسیدن به توازن میان ویژگی های مختلف، در حالتی که سرویسی که تطابق کامل با نیازهای درخواست کننده داشته باشد پیدا نشود ، استفاده می شود[29]. 2.6.3 معماری های کشف سرویس معماری های متفاوتی برای کشف سرویس ارائه شده اند که بیشتر به محل مخازن سرویس و نحوه دسترسی به آنها می پردازند . معماری های پیشنهاد شده را می توان به دو دسته کلی معماری های متمرکز و معماری های توزیع شده تقسیم کرد. در معماری های متمرکز ، سرویس ها در یک مخزن مرکزی مانند UDDI یا پورتال وب نگهداری می شوند . معماری هایی که از UDDI به عنوان مخزن استفاده می کنند خود به دو دسته معماری های مرکب و معماری های مبتنی بر واسطه تقسیم می شوند . از مزایای معماری متمرکز این است که دسترسی سریع به تمام توصیفات سرویس ها را فراهم می کند . اما در مقابل این روش با چالش هایی نیز مواجه است از جمله اینکه خود مخزن مرکزی به یک گلوگاه تبدیل می شود زیرا دسترسی به سرویس ها فقط از طریق آن انجام می شود . مسئله دیگر در ارتباط با این معماری این است که ثبت سرویس ها بر عهده خود تولیدکننده ها است و در صورتی که این کار انجام نشود مخازن سرویس قدیمی شده و سرویس های تازه را شامل نمی شوند . روش هایی که معماری توزیع شده را پیشنهاد می کنند از قابلیت انعطاف پذیری و توسعه پذیری بهره می برند . در چنین معماری هایی سرویس ها در وب سایت تولید کننده نگهداری می شوند و از ساز و کارهای متفاوتی برای پیدا کردن سرویس ها استفاده می شود. روش هایی که از معماری توزیع شده استفاده می کنند را می توان بر اساس نحوه دست یابی به سرویس ها به سه دسته معماری های مبتنی بر اینترنت ، معماری های مبتنی بر عامل ها و معماری های همتا به همتا تقسیم کرد[30] . 2.7.جمعبندی با توجه به مطالب مطرح شده واضح است که سیستمهای اجرایی تولید توزیعشده میتوانند مزایای فراوانی را برای سازمانها فراهمآورند، اما در مراحل مقدماتی خود نیاز به تحقیقات و بررسیهای زیادی دارند. اولین گام میتوانند ارائه چارچوبی راهبردی باشد که تمامی فعالیتهای موجود در سیستمهای اجرایی تولید را شامل شود. این چارچوب بایستی به نحوی باشد که راهحلی برای چالشهای مطرحشده در ارتباط با سیستمهای اجرایی تولید توزیعشده باشد. یکی از مهمترین فعالیتها در سیستمهای اجرایی تولید توزیعشده شناسایی سرویسهایی است که بتواند به عنوان دارایی پایه در این سیستم در نظر گرفته شود. همانطور که در بخش سیستمهای اجرایی تولید توزیعشده عنوان شد بیشتر کارهای مرتبط تمرکز بر معماری هولونی و چندعاملی داشتهاست. این تحقیق به دلیل تمرکز برروی کشف سرویس و با توجه به کمبود روشهای سرویسگرا، سیستمهای اجرایی تولید، سعی در رفع چالشهای همروندی، یکپارچگی و قابلیت کار متقابل اجزای سیستم را دارد. دلیلی که از سرویسها در این روش استفاده شده است، قابلیت استفاده مجدد بالای آنها است. با پیدا کردن سرویسهای مورد نیاز این سیستمها، میتوان طراحی و شناسایی سرویس را به نیازمندیهای پوشش داده نشده، محدود و در نتیجه در هزینه و زمان صرفهجویی کرد. مراجع و منابع Michael McClellan, “Manufacturing Execution systems”, MES Solutions, Baltimore, Maryland, 2001 http://en.wikipedia.org/wiki/ANSI/ISA-95 “ANSI/ISA–95.00.03–2005”, Enterprise-Control SystemIntegration Part 3: ActivityModels of ManufacturingOperations Management, 2005 Michle Kuhnle,”Distributed manufacturing,Paradaigm,Concepts, Solutions and Examples”,chapter1,2009 http://en.wikipedia.org/wiki/Lean_manufacturing Y.Y. Yusuf, M. Sarhadi, A. Gunasekaran, “Agile manufacturing:The drivers, concepts and attributes”, Production Economics, A. Tharumarajah A. J. Wells L. Nemes,” Comparison of Emerging Manufacturing Concepts”,CSIRO Manufacturing Science & Technology, Preston, Victoria, Australia Pascal Blancb, Isabel Demongodinb, Pierre Castagna,” A holonic approach for manufacturing execution system design:An industrial application”, Engineering Applications of Artificial Intelligence, 2008 http://en.wikipedia.org/wiki/Multi-agent_system Cooper, RG. 2001. Winning at New Products: Accelerating the Process from Idea to Launch 3rd edn. New York: Perseues Books Montoya-Weiss, M.M. and T.M. ODriscoll.2000.From experience: applying performance support technology in the fuzzy front end. Jounal of Product Innovation Management,17:143-161 Zirger, B. and J.Hartley. 1996.The effect of acceleration techniques on product developmenttime.IEEE Transactions on Engineering Managemnet, 43(2):143-152 Shank, J. and V. Govindarajan.1988. The perils of cost allocation based on production volumes. Accounting Horizons, 4:71-79 Rode, J. and D. Wunsch. 2007. A Research Agenda for Adaptive Manufacturing. (12th IEEE Int.Conf. on Emerging Technologies and Factory Automation Proceedings), September, patras Vyatkin,V., Z.Salcic, P. Roop, and j.Fitzgerald. 2007. Information Infrastructure of Intelligent Machines based on IEC61499 Architecture. IEEE Industrial Electronics Mgazine,1(4). Bieberstein, N., R.G. Laird,D.K.Jones, and T.Mitra.2008.Ececuting SOA- a practical Guide for the service-oriented Architect. Upper Saddle River: Pearson Wannagat, A., B. Vogel-Heuser, H.Mubarak, and P. Gohner. 2007. Evaluation of Agent oriented Methodologies for the Development of Flexible Embedded Real-time systems in Automation ATP-International Shen, W., Q. Hao, H. Yoon and D.H Yoon and D.H. Norrie. 2006. Application of agent systems in intelligent manufacturing: an update review. Internationa Journal of Advanced Engineering Informatics. Radjou, N. 2003. Software agents in business: still an experiment. Agent Link Magazine, issue 13, June. Michle Kuhnle,”Distributed manufacturing,Paradaigm,Concepts, Solutions and Examples”,chapter6,2009 Sean Marston a, Zhi Li a, Subhajyoti Bandyopadhyay a,, Juheng Zhang a, Anand Ghalsasi, “Cloud computing — The business perspective”, Decision Support Systems, (2011) 176–189 Service-oriented architecture. Available from:http://en.wikipedia.org/wiki/Service-oriented architecture Marks, A. and M. Bell, Service-Oriented Architecture: A Planning and Implementation Guide for Business and Technology, 2006, New Jersey: John Wiley & Sons Krafzig, D., K. Banke, and D. Slama, Enterprise SOA: Service Oriented Architecture Best Practices, 2005, Englewood Cliffs Prentice-Hall. Erl, T., Service-oriented Architecture: Conepets, technology, and Design, 2005. New Jersey: Prentice Hall PTR XML. Available from: Http://eb.wikipedia.org/wiki/XML Becker, J., O. Muller, and M.Woditsch, An Ontology-based Natural Lnaguage service discovery engine- Design and Experimental Evaluation, in 18th European Conference on Information Systems,2010 D,Mello, D.A. and V.S. Ananthanarayana. A Review of Dynamic Web Service Description and Discovery Techniques. In First international Conference on Integrated Intelligent Computing.2010 Ye, G., et al., A qoSaware Model for Web Services Discovery, in First International Workshop on Education Technology and computer science ,2009 Sellami, M., et al., A Recommender System for Web services Discovery in aDistributed Registry Environment, in Fourth International Conference on Internet and Web Aoolications and Services,2009 A. Lüder, J. Peschke, A. Bratukhin, A. Treytl, A. Kalogeras and J. Gialelis, “The PABADIS’PROMISE - Architecture”, Proceeding of ANIPLA, 2006 Siew Poh Lee, Lai Peng Chan, Eng Wah Lee, “Web Services Implementation Methodology for SOA Application”, 2006 Enterprise service bus, “http://en.wikipedia.org/wiki/Enterprise_service_bus” Service-oriented modelling and architecture, http://www.ibm.com/developerworks/library/ws-soa-design1 Amjad Umar, Adalberto Zordan, “Reengineering for service oriented architectures: A strategic decision model for integration versus migration”, The journal of system and software,2009 Ivona Brandic, Dejan Music, Schahram Dustdar, “Ser vice Mediation and Negotiation Bootstrapping as First Achievements Towards Self-adaptable Grid and Cloud Ser vices”, ACM, Barcelona, Spain, 2009 Valérie Issarny , Nikolaos Georgantas, Sara Hachem, Apostolos Zarras, Panos Vassiliadist, Marco Autili, Marco Aurélio Gerosa, Amira Ben Hamida, “Service-oriented middleware for the Future Internet: state of the art and research directions”, journal of internet service applications, 2011 Bhaskar Prasad Rimal, Admela Jukan, Dimitrios Katsaros, Yves Goeleven, “Architectural Requirements for Cloud Computing Systems: An Enterprise Cloud Approach”, journal of grid computing, 2011 Xun Xu, “From cloud computing to cloud manufacturing”, Robotics an d Computer-In tegrat ed Manuf acturing, 2012 Goncalo Ca ndido, Jose Barata, Armando Walter Colombo, Francois Jammes, “SOA in reconfi gurable supply cha ins: A research roadmap”, Engin eering Applications of Art ificial Intelligence, 2009 Iván Corredor, José F. Martínez, Miguel S. Familiar, “Bringing pervasive embedded networks to the service cloud: A lightweight middleware approach”, Journ al of Systems Archite cture, 2011 LuisRodero-Merino, LuisM.Vaquero, VictorGil, Ferm nGalÆn, JavierFontÆn, RubenS.Montero, “Frominfrastructuredeliverytoservicemanagementinclouds”, Future Generation computer systems, 2010 Brecher C, Lohse W, Vitr M. Module-based platform for seamless interoperable CAD-CAM-CNC planning. In: XU XW, NEE AYC, editors. Advanced design and manufacturing based on STEP. London: Springer; 2009. Van de Velde PJMC. Runtime configurable systems for computational fluid dynamics simulations. PhD thesis. Auckland: Department of Mechanical Engineering, University of Auckland; 2009. Nassehi A, Newman ST, Xu XW, Rosso JR. RSU. Toward interoperable CNC manufacturing. Computer Integrated Manufacturing 2008;21:222–30 Mokhtar A, Houshmand M. Introducing a roadmap to implement the universal manufacturing platform using axiomatic design theory. International Journal of Manufacturing Research 2010;5:252–69. Wang X, Xu X. DIMP: an interoperable solution for software integration and product data exchange. Enterprise information systems. TEIS-2010-0110, in press. doi: 10.1080/17517575.2011.587544. http://www.manufacturing-executive.com/thread/1753,” MES in the Cloud: Is it Time?” http://msdn.microsoft.com/en-us/library/dd129909.aspx, “Distributed Applications in Manufacturing Environments” http://www.instrumentation.co.za/news.aspx?pklnewsid=37607, “Manufacturing execution systems in the cloud” http://www.bakertilly.com/Manufacturers-Switching-to-Cloud-Computing, “Success in the Cloud: Manufacturers are switching to Cloud computing systems to achieve improved business performance” http://www.bizjournals.com/prnewswire/press_releases/2011/12/08/PH18957, “BellHawk Cloud-Based MES System Adds Automated Barcode Label Printing” Abstract: The process of manufacturing in different organizations has different styles, that the target of each one is to deliver the proper product to customer in an appropriate manner.By the way, deployment of manufacturing execution systems gives more advantages to the managers in middle layer. In this research, we had purpose of creating framework with modules, connections an necessary requirements, something that had never taken place in cloud environment. In MES module recognition which is the most important part of research, the order module that was seen in traditional MES, is the basis of work, and with analytic approach using SOMA methodology, other modules such as resource management, scheduling, tracking and tracing , definition management and so on is extracted from it. In other words, the purpose is smallising this huge module. Considering the limitiation of practical scheme of this frame in cloud environment, acase study wich is named Jamsaz organization was the most important of this research, the study which production process of Jamsaz has been compered with and due attention t experts of this scope and interview with the execution manager and related staff, th final result has been obtained. Comparing to traditional MES to take into consideration the new order module lightened and more flexibility and integrity obtained and the new model of business made new point of view available for this organizations.