— (191)

وزارت علوم، تحقیقات و فناوری
دانشگاه علوم و فنون مازندران
پایان نامه
مقطع کارشناسی ارشد
رشته: فناوری اطلاعات – گرایش مهندسی فناوری اطلاعات
عنوان/موضوع: ارائه چارچوبی راهبردی برای سیستمهای توزیع شده اجرایی تولید با استفاده از مدل محاسبات ابری
اساتید راهنما: دکتر بابک شیرازی
دکتر ایرج مهدوی
استاد مشاور: دکتر تاجدین
دانشجو: شیوا خلیلی قیداری
بهار 1391
تقدیم به :
پدر و مادرم
که با از خود گذشتگی
تمامی آرزوهایم را رنگ واقعیت بخشیدند.
چکیده:
فرآیند تولید در سازمانهای مختلف، دارای سبکهای متفاوتی است که هدف هرکدام در نهایت تحویل محصول درست در زمان درست به مشتری است. ضمن اینکه با استقرار سیستمهای اجرایی تولید مزایای افزونتری در اختیار مدیران میانی نیز قرار میدهد. در این تحقیق هدف از خلق چارچوب طرح ماژولها، روابط آنها و ملزومات پیادهسازی هرکدام بوده است. چیزی که تا کنون در محیط ابرصورت نگرفته است. در مهمترین بخش که همان شناسایی ماژولهای این سیستم است، ماژول سفارش که در سیستمهای اجرایی اولید سنتی قابل مشاهده بود، مبنای کار قرار گرفته و با رویکرد تحلیلی و با استفاده از متدولوژی SOMA، سایر ماژولها از مله مدیریت منابع، زمانبندی، پسگیری، مدیریت تعاریف و … از آن استخراج شده است. به عبارتی هدف هرچه کوچکتر کردن این ماژول بزرگ در سیستم اجرایی تولید سنتی است. با توجه به محدودیتهای طرح عملی این چارچوب در محیط ابر، یک مطالعه موردی تحت عنوان شرکت جمساز نتیجه نهایی این تحقیق است، مطالعهای که در آن فرآیند اصلی تولید جمساز با راهحل مطرح شده مورد مقایسه قرار گرفته و باتوجه به نظر خبرگان این حوزه و مصاحبه با مدیران تولید و پرسنل مرتبط نتایج نهایی حاصل شد. در مقایسه با سیستمهای مشابه و سنتی و با در نظر گرفتن سبکتر کردن ماژول سفارش، انعطافپذیری هرچه بیشتر و جامعیت و یکپارچگی بیشتر حاصل شد و مدل جدید کسب و کار ابری نیزدیدگاههای جدیدی را برای این سازمانها فراهم آورده است.
فهرست رئوس مطالب
عنوان صفحه
فصل اول- کلیات تحقیق
1
1.1مقدمه 2
بیان مسئله 2
هدف از اجرا4
1.4 توجیه ضرورت انجام طرح 4
1.5سابقه تحقیق 5
1.6 روش پژوهش و تکنیکهای اجرایی 6
1.7استفاده کنندگان از نتایج تحقیق 6
1.8 ساختار فصول 7
فصل دوم- ادبیات موضوع
8
2.1 مقدمه 9
2.2 سیستمهای اجرایی تولید 9
2.1.1 توابع اصلی سیستمهای اجرایی تولید 9
2.2.2 توابع پشتیبان سیستمهای اجرایی تولید 11
2.2.3 استاندارد95 ANSI/ISA 11
2.3 تولید توزیع شده 13
2.3.1چشماندازها ومفاهیم تولید توزیع شده 14
2.3.2فناوری اطلاعات و تولید توزیع شده 16
2.3.3 توسعه محصول همروند 17
2.3.4 انعطافپذیری و قابلیت پیکربندی مجدد با استفاده از سیستمهای توزیع شده خودمختار 19
2.4 سیستمهای اجرایی تولید توزیع شده 21
2.4.1راه حلهای فعلی سیستمهای اجرایی تولید توزیع شده 23
2.4.2الگوهای طراحی جامع برای سیستمهای اجرایی تولید 23
2.4.3تحلیل و مقایسه رویکردهای توزیع شده 26
2.5محاسبات ابری 30
2.5.1نقشها در پردازش ابری 32
2.6اصول معماري سرويس گرا 33
2.6.1 کشف سرویس 35
2.6.2 روش های کشف سرویس 36
2.6.3 معماری های کشف سرویس 38
2.7.جمع بندی 39
فصل سوم- مبانی راهکار پیشنهادی
40
3.1 مقدمه 41
3.2 نگاهی کلی 41
3.2.1 تشریح سیستم های اجرایی تولید و طرح مساله در محیط توزیع شده 43
3.2.2 انتخاب الگوهای راه حل(Solution pattern ) های SOMA 44
3.2.3 الگوی راه حل های پیشنهادی توسط SOMA 44
3.2.4 تعریف موجودیت های کلیدی با استفاده از الگوهای طراحی سیستم ها ی توزیع شده 50
3.3 شناسایی سرویس ها 51
3.4 تطابق رویکرد با مدل محاسباتی ابری 53
3.4.1 مراحل چارچوب از دید محاسبات ابری 53
3.4.2 شناسایی سرویسهای سیستمهای اجرایی تولید 56
3.5 ماژولهای اصلی سیستمهای اجرایی تولید تحت عنوان برنامههای کاربردی سرویس گرا 63
3.6 ارتباطات میان ماژولهای مختلف سیستمهای اجرایی تولید 84
3.7 توابع سیستمهای اجرایی تولید به عنوان سرویس 94
3.8 سبک معماری مناسب برای کنترل سیستم های اجرایی تولید توزیع شده در ابر 96
3.9 زمانبندي جزئي تحت عنوان سرويس 101
3.9.1 ملزومات تامين كننده ابر 102
3.10 مديريت منابع به عنوان سرويس 105
3.10.1 ملزومات تعيين كننده سرويس 106
3.10.2 ملزومات سازمانها 108
3.11 نظارت به عنوان سرويس 109
3.12 جمع بندی 110
فصل چهارم- ارزیابی روش پیشنهادی
111
4.1 مقدمه 112
4.2 مقايسه رويكرد هاي فعلي 112
4.3ارزيابي سيستم هاي اجرايي توليد در محيط ابر و عامل گرا 114
4.4 مطالعه موردی 116
4.4.1 حوزه مطالعه موردی 116
4.4.2 نمونه محصولات مطالعه موردی 117
4.5 سیستم اجرایی تولید جمساز با استفاده از مدل محاسبات ابری 124
4.5.1 مقدمات ابری کردن اجرای تولید 124
4.5.2 پایگاه داده جمساز در محیط ابر 124
4.5.3 زمانبندی و پیگیری به عنوان سرویسهای ابر 125
4.6 ارزیابی فاکتورهای تولید 126
4.6.1 فاکتورهای بهکارگیری فناوری اطلاعات 126
4.6.2 کمبودها و ضعفهای فعلی 127
4.7 سيستم هاي اجرايي توليدمبتني بر ابرفعلي 133
4.8 جمع بندی 135
فصل پنجم- جمع بندی و نتیجه گیری
136
5.1 خلاصه تحقیق 137
5.2 نتایج تحقیق 138
5.3 مقایسه با سایر چارچوبها 138
5.4 محدودیتها و زوایای پوشش داده نشده 139
5.5 چالش هاي مس ابري 139
5.6 آينده سيستم هاي اجرايي توليد در ابر 141
5.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/ISA95
16 شکل2.4تولید هولونی
21 شکل2.5 چالشهای تولید توزیع شده
25 شکل2.6 الگوی سفارش-منبع
35 شکل 2.7مدل معماری وب سرویس
43 شکل3.1 نمایی کلی از رویکرد مورد استفاده
46 شکل3.2 ESB
48 شکل3.3 قالب ESB
50 شکل3.4 سرویس های ESB
54 شکل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.جمعبندی
با توجه به مطالب مطرح شده واضح است که سیستمهای اجرایی تولید توزیعشده میتوانند مزایای فراوانی را برای سازمانها فراهمآورند، اما در مراحل مقدماتی خود نیاز به تحقیقات و بررسیهای زیادی دارند. اولین گام میتوانند ارائه چارچوبی راهبردی باشد که تمامی فعالیتهای موجود در سیستمهای اجرایی تولید را شامل شود. این چارچوب بایستی به نحوی باشد که راهحلی برای چالشهای مطرحشده در ارتباط با سیستمهای اجرایی تولید توزیعشده باشد.
یکی از مهمترین فعالیتها در سیستمهای اجرایی تولید توزیعشده شناسایی سرویسهایی است که بتواند به عنوان دارایی پایه در این سیستم در نظر گرفته شود. همانطور که در بخش سیستمهای اجرایی تولید توزیعشده عنوان شد بیشتر کارهای مرتبط تمرکز بر معماری هولونی و چندعاملی داشتهاست. این تحقیق به دلیل تمرکز برروی کشف سرویس و با توجه به کمبود روشهای سرویسگرا، سیستمهای اجرایی تولید، سعی در رفع چالشهای همروندی، یکپارچگی و قابلیت کار متقابل اجزای سیستم را دارد. دلیلی که از سرویسها در این روش استفاده شده است، قابلیت استفاده مجدد بالای آنها است. با پیدا کردن سرویسهای مورد نیاز این سیستمها، میتوان طراحی و شناسایی سرویس را به نیازمندیهای پوشش داده نشده، محدود و در نتیجه در هزینه و زمان صرفهجویی کرد.

فصل سوم- مبانی راهکار پیشنهادی3.1 مقدمهدر فصل پیش مفاهیم تولید توزیع شده و سرویس گرا توضیح داده شدند و در مورد چالش ها و کمبودهای موجود در این سیستم ها و پتانسیل سرویس گرایی برای ارائه راهکارهای مناسب صحبت شد. یکی از حوزه هایی که مناسب است تا در سیستم های اجرایی تولید برای حصول نتایج بیشتر ، استفاده شود شناسایی سرویس های مورد نیاز است که با استفاده از این رویکرد هنوز راه حل های مناسبی ارائه نشده است .
در این فصل مبانی رویکرد پیشنهادی برای کشف سرویس ها و تحلیل سیستم های اجرایی تولید برای شناسایی سرویس ها توضیح داده می شود. جزئیات مربوط به گام های شناسایی، تعیین مشخصه ها شرح داده می شود. هدف از ارائه این رویکرد همانطور که در فصل اول عنوان شد ارائه چهارچوبی جامع برای سیستم های اجرایی تولید با استفاده از سرویس گرایی است. این چهارچوب بایستی حدالامکان از مزایای سرویس گرا برای کاربرد بهینه در محیط توزیع شده استفاده کرده باشد.
در ادامه فصل، ابتدا نگاهی کلی به رویکرد مورد استفاده و مراحل آن آورده شده است ، سپس با استفاده از الگوهای طراحی معرفی شده در بخش قبل به معرفی طرح کلی سیستم اجرایی توزیع شده سرویس گرا خواهیم پرداخت. در بخش پایانی به صورت جزئی تر رویکرد پیشنهاد شده تشریح می شود.
3.2 نگاهی کلیهدف این تحقیق ارائه چهارچوبی سرویس گرا برای سیستم های اجرایی تولید و مبتنی بر مدل محاسبات ابری است . علت استفاده از سرویس گرایی در ارائه این چهارچوب این است که بتوان با تحلیل ماژولهای مختلف این سیستم ها سرویس های مورد نیاز را استخراج نمود . البته با توجه به ماهیت این سیستم ها و سیستم های امکاناتی ، نمی توان ادعا کرد که تمامی سرویس های چهارچوب شناسایی شده اند ولی سرویس های استخراج شده قابل پاسخگویی برای مهمترین بخش های سیستم هستند. بسیاری از این سرویس ها قابلیت ترکیب با کامپوننت های فعلی سیستم را دارند و بسیاری از آنها بایستی جایگزین راه حل های فعلی شوند.
از این رودر این چارچوب ، سرویس های شناخته شده در حقیقت جزء سرویس های اصلی این سیستم ها هستند و در مراحل دیگر چرخه این سیستم ها ، به عبارتی در فاز توسعه و پیاده سازی نیز نیاز به کشف سرویس وجود دارد که زیر مجموعه این کار قرار نمی گیرد. این سرویس ها منجر به افزایش استفاده مجدد و در نتیجه کاهش هزینه ها حین اجرا خواهد شد.
تحقیقات صورت گرفته نشان می دهد که متودولوژی های متعددی برای تحلیل سرویس گرا ایجاد و به کار گرفته می شود ، رویکردی که ما برای تحلیل این سیستم ها استفاده می کنیم بایستی ویژگی آن را داشته باشد تا سیستم های توزیع شده و بسیار بزرگ را تحت پوشش قرار دهد. در بین متودولوژی های موجود، متودولوژی SOMA (Service Oriented Modelling and Architecture ( کاندید مناسبی برای این کار می باشد.
با توجه به مطالعات انجام شده بر روی دامنه موجود، تمرکز برای کشف و شناسایی سرویس ها و تعیین مشخصه سرویس های مهم این سیستم با استفاده از متودولوژی پیشنهاد شده می باشد.
– ابتدا با بررسی سیستم های اجرایی تولید موجود و شناسایی مشکلات و بسط این مشکلات با در نظر گرفتن محیط توزیع شده جدید ، به شرح مسائل مختلف که برای رفع آنها نیاز به ارائه مدل سرویس گرا داریم می پردازیم.
– با در نظر گرفتن شرح مسائل مختلف برای هر کدام بنا بر متودولوژی در نظر گرفته SOMA و الگوی راه حل پیشنهاد می دهیم.
– با شناسایی سیستم های اجرایی تولید و فعالیت ها و وظایف آنها با استفاده از الگوهای طراحی موجود ، عناصر کلیدی این سیستم ها را شناسایی می کنیم.
– با در نظر گرفتن الگوهای راه حل پیشنهادی و در نظر گرفتن دامنه موجود، الگوهای طراحی سیستم های اجرایی تولید اهداف مهم کسب و کار وسیستم های قدیمی به شناسایی سرویس های پیشنهادی می پردازیم.
– سرویس ها را با روش های موجود بررسی کرده و سرویس های کاندید را شناسایی می کنیم.
طراحی سرویس گرای این چارچوب به نحوی است که سعی شده عناصر موجودیت تا حد امکان قابلیت کار دو به دو را داشته باشند تا یکپارچگی هر چه بیشتر در محیط توزیع شده تولید فراهم شود. این رویکرد طراحی جامع بوده و هدف ارائه مخزن سرویس بهینه حاوی سرویس های پایه ی سیستم های اجرایی تولید در محیط توزیع شده است.
با در نظر گرفتن توضیحات ارائه شده در بالا در زیر نمایی کلی از رویکرد مورد استفاده نشان داده شده است. شکل3.1 مراحل این رویکرد است:

شکل3.1 نمایی کلی از رویکرد مورد استفاده
3.2.1 تشریح سیستم های اجرایی تولید و طرح مساله در محیط توزیع شده
در این مرحله ، فرآیند های کسب و کار بررسی شده و نقاط عطف برای دگرگونی و تغییر شناسایی می شود، نقاطی که با شناسایی آنها مراحل بعدی با وجود آنها آغاز می شود. با بررسی سیستم های اجرایی تولید فعلی و بسط آنها در محیط توزیع شده و بررسی آنها با مجموعه ای از مشکلات پایه و اصلی این سیستم ها آشنا شدیم که بعضاً تامین آنها در محیط توزیع شده منجر به تقلیل اثرات مشکل و گاهی نیز منجر به تشدید آن مشکلات شده است. در ادامه به معرفی مسائل پایه این سیستم ها می پردازیم.
سیستم های اجرایی تولید در حقیقت واسطی بین برنامه ریزی ها در سطح کلان و کارهای ریز شده در سطح ایستگاه های کاری هستند، عده ای هدف رسیدن به این سیستم ها را تامین واسطی که دیدی روشن و شفاف نسبت به امور به آنها بدهد می دانند، مشکل اینجاست که این سیستم ها چگونه می توانند پاسخگوی این نیاز باشند. ( هدف رسیدن به شفافیت در گزارش گیری کلان )
برنامه ریزی های سطح کلان که از لایه ی برنامه ریزی منابع سازمان به این لایه ارسال می شود اغلب در سطح کلان می باشد و جزئیات در آن لحاظ نشده است، چگونه سیستم های اجرایی تولید توزیع شده می توانند زمان بندی دقیق و جزئی شده از اقدامات واقعی داشته باشد. هدف : طرح رسیدن به برنامه ریزی جزئی شده است .
سفارش کاری که از لایه های برنامه ریزی منابع سازمان دریافت می شود چگونه مدیریت می شود تا در زمان مناسب تحویل داده شود ضمن آن که از منابع به حد بهینه استفاده کرده باشد. هدف : ارائه راه حل مدیریت سفارش ها برای رسیدن به بهینگی
دید، نسبت به منابع از نگاه کلان با آنچه در عمل موجود است تفاوت بسیار دارد. آنچه در عمل دیده می شود شامل اطلاعات از منابع ، وضعیت آنها ، رزرو شدن و مکان آنها است. مشکل اینجاست که چگونه اطلاعات به روزی از وضعیت منابع همواره آماده داشته باشیم.
سفارش های کار، نحوه استفاده از منابع و چگونگی زمان بندی و بسیاری از موارد دیگر تولید را لحظه به لحظه پیش می برند ، اینکه بتوان پیگیری دقیقی از کارهای در جریان توسط عوامل داخلی سیستم فراهم آورد ، خود نوعی مشکل برای این سیستم ها می باشد.
در صورت وقوع اتفاق غیر منتظره، این سیستم ها چگونه باید قادر باشند واکنش نشان دهند و وضعیت را به بهترین نحو مدیریت کنند.
در صورت اعمال تغییرات چگونه می توان به نرمی آنها را به سیستم اعمال کرد طوری که بتوان توازنی بین انعطاف پذیری و بهینگی ایجاد کرد.
فرآیند هر تولیدی شامل تعاریف متعددی از مواد اولیه تا نحوه کارایی پرسنل فرآیند تولید و غیره می باشد که دائماً در حین اجرا به سیستم اضافه می شود ، چگونه می توان مدیریت درستی بر این تعاریف برای تسهیل فرآیند اجرا داشت.
3.2.2 انتخاب الگوهای راه حل( Solution pattern ) های SOMA
راه حل های سرویس گرا ذاتاً ترکیبی هستند و معمولاً شامل چندین نوع راه حل می شوند و این به دلیل آن است که در SOMA ، مرحله شناسایی و تشخیص سرویس ها ، بسیار زود انجام می شود و راه حل های متنوعی نظیر توسعه سفارشی ، یکپارچه سازی با سیستم های قدیمی ، توسعه پکیج های برنامه های کاربردی ، طراحی ESB و استفاده از آن و سرویس های کسب و کار مرکب پیشنهاد داده شده است .
SOMA به نوعی طراحی شده است که بتواند به خوبی ماهیت ترکیبی راه حل های سرویس گرا را به کار ببرد و فعالیت های خاص و راهنمایی ها را برای پیاده سازی هر یک از راه حل های عنوان شده را به کار گیرد . در متدولوژی SOMA ، محتوای هر یک از راه حل ها ، متناظر با همان راه حل است که حاوی وظایف ، تولیدات کاری ، نقش ها و راهنمایی هایی شود که از آن تحت عنوان الگوی راه حل استفاده می کنیم.
3.2.3 الگوی راه حل های پیشنهادی توسط SOMA
ESB ، یک الگوی راه حل می باشد ، نه یک محصول ، به نحوی که معماری سرویس گرا می تواند از آن استفاده کند تا چالش ها را در محیط های بزرگ و توزیع شده برطرف سازد، چالش هایی از قبیل اینکه : چگونه می توان سطح بالایی از یکپارچگی و قابلیت کار متقابل بین سیستم هایی که به طور همزمان کار می کنند ایجاد کرد . سیستم هایی که به صورت مجزا مالکیت خود را دارند و به صورت توزیع شده عمل می کنند و به طور همزمان معایب وجود تکنولوژی های مختلف در نقاط توزیع شده مختلف را کاهش داد و از به کارگیری راه حل های سطحی و برهه ای اجتناب کرد، چیزی که منجر به کاهش هزینه ها، افزایش امنیت و افزایش چابکی می شود .
ESB ، در حقیقت تحولی بزرگ در استفاده از واسط های پیغام گرا و وب سرویس ها در سازمان است . در کلامی کوتاه ، ESB یک هاب است که مصرف کنندگان برنامه های کاربردی و سرویس ها را قادر می سازد تا به یکدیگر متصل شوند . اتصالی که به ظاهر متمرکز ولی به صورت فیزیکی به صورت توزیع شده و متمرکز دیده می شود .
محصولات مختلف که در زیر ساختار ESB وجود دارد ، قابلیت های مختلف سیستم های اجرایی تولید و توزیع شده را پشتیبانی می کنند . محصولاتی نظیر:
واسط پیغام ها
پرتال سرورها
مدیریت سیستم ها
شکل3.2 ESB
ESB نه تنها پیشنهاد استفاده از وب سرویس ها را می دهد بلکه امکان این را فراهم می کند که نقش الگویی متداول برای به کارگیری برنامه های کاربردی قدیمی را ایفا کند. این برنامه های کاربردی می توانند در چارچوب SOA با استفاده از به کارگیری سرویس های اضافه تر نظیر اداپترها قابل استفاده باشند .
به طور کلی ESB ، اقدامات زیر را انجام می دهد:
امکان این را فراهم می آورد تا اتصال مناسب بین سرویس ها ایجاد شود.
امکان این را فراهم می آورد تا سرویس ها با یکدیگر بر اساس ملزومات QOS و طی تراکنش های خاص نظیر سنکرون ، آسنکرون ، دائمی و غیردائمی ، اتصال سست و اتصال ضعیف ارتباط برقرار کنند .
به عنوان زیرساختاری متداول برای معماری سرویس گرا ، رخدادها و پیغام های آن باشد به نحوی که پلتفرم های ناهمگون را به صورت شفاف به هم متصل می سازد .
نقش میانجی را بین درخواست ها و پاسخ های سرویس گرا ایجاد می کند.
– با ایجاد سرویس های متغیر ، ردیابی و سرویس های ارزش افزوده
– ایجاد اتصال شفاف بین سرویس ها
ESB پتانسیل برآورده کردن فاکتور بحرانی کسب و کار را دارد :
کاهش هزینه در هزینه های فناوری اطلاعات و افزایش چابکی کسب و کار ، با ایجاد هابی مشترک که سیستم های ناهمگون می توانند به آن متصل شوند و به سرعت با یکدیگر مشارکت داشته باشند ، چرخه توسعه محصول سریعتری داشته باشند و مدیریت فرآیندها را در محیط هایی گسترده پشتیبانی کنند .
ESB ، تکنولوژی مبتنی بر استانداردی را فراهم می آورد که ملزومات برای نگهداری واسط های پیغام گرا که به عنوان مثال مرتبط با هزینه های پرسنل ، نگهداری و … هستند را کاهش می دهد .
قالب مورد استفاده در ESB برای معماری سرویس گرا:
مبنای ESB بر اساس رویکرد توزیع شدگی برای یکپارچه سازی است .این قابلیت آن ، این امکان را فراهم می آورد تا واحدهای کسب و کار مختلف ، برنامه های یکپارچه سازی خودشان را به تدریج توسعه دهند و به صورت محلی کنترل را اعمال کنند . همزمان ، ESB امکان این را فراهم می آورد تا واحد های کسب و کار به صورت انتخابی و به صورت امن به محض نیاز به یکدیگر متصل شوند . ESB یک لایه پیغام رسانی مبتنی بر استاندارد ایجاد می کند که نقش پل ارتباطی است که منطق کسب و کار مختلف را به هم پیوند می دهد .
شکل3.3 قالب ESB
این قالب متشکل از 5 بخش است :
برنامه کاربردی : سرویس ها در معماری سرویس گرا با لایه ای از برنامه کاربردی که زیر آن قرار می گیرد نمایش داده می شود : این برنامه های کاربردی شامل برنامه های کاربردی سمت سرور نظیر IBM Web Sphere ، برنامه های کاربردی قدیمی نظیر CICS ، برنامه های کاربردی NET ، و … برنامه های کاربردی بسته بندی شده شامل SAP ، People soft ،Oracle و … است.
اتصالات
ESB قابلیت اتصال را از طریق کاربران JMS و کانال MQ پروتکل وب سرویس ها و … فراهم می آورد .
باس
جنبه ی باس ESB ، کامپوننت اصلی پیغام رسانی برای سکوی نرم افزاری این قالب است و یکپارچگی را از طریق پارادایم های پیغام دهی نظیر نقطه به نقطه ، درخواست/ پاسخ ، انتشار/ تصدیق فراهم می آورد .
این پیغام ها در مودهای مداوم و غیر مداوم صورت می گیرد . سایر فاکتورهای کلیدی در باس شامل موارد زیر است :
این باس بر روی زیرساختار Web Sphere ایجاد می شود .
ویژگی های آن ، امکان این را فراهم می آورد تا دسترسی سریع و کنترل شکست را با WAS5/6 که از کلاسترهای شبکه استفاده می کنند پشتیبانی کند .
یک پایگاه داده رابطه ای ایجاد شده است تا مکانیزم تداوم و سازگاری پیغام ها را حفظ کند .
هر سرور برنامه کاربردی می تواند به صورت دلخواهانه از یک و یا چند موتور پیغام رسانی میزبانی کند .
میانجی
یک چارچوب میانجی باعث ایجاد انعطاف پذیری و انتزاع برای ESB است که از یک چارچوب مبتنی بر پالیسی برای تعریف میانجی استفاده می کند .
قابلیت های لایه میانجی عبارتست از :
مجازی سازی : نقاط پایانی سرویس ها مجازی شده اند . این کار امکان این را فراهم می آورد تا سرویس ها خودشان مکانشان را بدون تاثیر گذاشتن بر مشتری ها تغییر دهند .
دستکاری پیغام ها : چارچوب میانجی گری ، امکان مسیریابی ، پاک کردن محتوای پیغام ها را فراهم می آورد و این منطق به صورت توزیع شده در شبکه اعمال می شود .
نظارت و مدیریت بر کیفیت سرویس : چارچوب میانجی امکان نظارت خودکار را فراهم می آورد .
انتخاب و مسیریابی پویا : میانجی باعث می شود که توزیع بار به نحو بهتری انجام شود و مسیریابی بر اساس محتوا انجام شود .
انتزاع پالیسی ها : چارچوب میانجی گری امکان این را فراهم می آورد تا مدیریت تعاریف و اعمال رویه ها به راحتی صورت پذیرد .
منطق کسب و کار
ESB منطق کسب و کار را پشتیبانی نمی کند ولی منطق کسب و کار معنوی در برنامه های کاربردی دیگر SOA گنجانده شده اند .
شکل3.4 سرویس های ESB
3.2.4 تعریف موجودیت های کلیدی با استفاده از الگوهای طراحی سیستم ها ی توزیع شده
هسته اصلی سیستم های اجرایی تولید را دو موجودیت منبع و مشتری تشکیل می دهد که در اکثر سیستم های توزیع شده موجودیت منبع با همین نام و تحت عناوین هولون منبع و یا عامل منبع شناخته شده است و موجودیت مشتری تحت عنوان هولون سفارش و یا عامل سفارش شناخته می شود ، تعاملاتی که این دو موجودیت انجام می دهند پایه و اساس الگوی طراحی سیستم های اجرایی تولید را تشکیل می دهد .
استفاده از الگوی طراحی که از تراکم استفاده می کند نیز روشی متداول است که بتوان موجودیت های تولید که در سلسله مراتبی جای دارند را سازماندهی کرد و با استفاده از آن بتوان هر چه بهتر مشکل پیچیدگی را کاهش داد .
به کارگیری میانجی نیز ابزاری قدرتمند است تا با استفاده از آن بتوان سیستم های مختلف را به هم پیوند داد ، این الگوی طراحی صرفاً مختص تولید نبوده و در طراحی های محیط های دیگر نیز متداول است .
3.3 شناسایی سرویس هادر فاز شناسایی سرویس ها علاوه بر سرویس ها ، عناصر کلیدی دیگری نیز شناسایی می شوند نظیر کامپوننت ها و جریان های کاری که ما بیشتر بر شناسایی سرویس ها تمرکز داریم. تجربه نشان داده است که بهترین کار برای شناسایی سرویس ها به کارگیری چندین تکنیک است ، به عبارتی یک تکنیک توان پاسخگویی برای شناسایی سرویس ها را ندارد ، گام اول توسط مدلسازی هدف – سرویس صورت گیرد تا در مرحله اول تطابق بهتری بین اهداف کسب و کار و سرویس های شناخته شده داشته باشیم . سرویس ها در مرحله اول تحت عنوان سرویس مشخص شده شناسایی می شوند ولی در نهایت تنها مجموعه ای از آنها تحت عنوان سرویس کاندید برای پیاده سازی شناسایی می شوند . در ادامه به معرفی سه تکنیک اصلی برای شناسایی سرویس ها می پردازیم :
مدلسازی هدف – سرویس
GSM از سه رویکرد استفاده می کند که چالش ، فرصت ها ، استراتژی ها و اهداف سازمان را مد نظر قرار داده ولی در نهایت اهداف کسب و کار را که محرکه مرتبط با محدوده پروژه مد نظر است را شناسایی می کند و این اهداف به زیر هدفهایی که مرتبط با هدف اصلی است تجزیه می شوند . این تجزیه سلسله مراتبی از اهداف کمک می کند تا زیر اهداف شناسایی شده به بهترین نحو به سرویس ها نگاشت شود . ضمناً این کار بسیار مهم است تا در حین کار فاکتور های کارایی کلیدی (KPI) شناسایی شوند تا تعیین سرویس ها با در نظر گرفتن آنها مشخص شود . KPI ها و معیارهای مشخص شده به کار می روند تا تعیین کنند تا چه حد راه حل سرویس گرایی که مورد استفاده قرار گرفته است موثر است .
GSM محدوده ای که کاربر را درگیر می کند به خوبی مشخص می کند و تعیین می کند که این بخش های کسب و کار نیاز به تغییر برای سرویس گرایی دارد . این مدلسازی بهترین اهداف کسب و کار را که تغییر در آنها تاثیر چشم گیری بر کسب و کار دارند شناسایی می کند . این کار ضمناً امکان محقق شدن اهداف توسط سرویس ها را نیز فراهم می آورد .
تجزیه دامنه
این تکنیک بر تحلیل بالا به پایین دامنه کسب و کار و مدلسازی فرآیندهای کسب و کار تمرکز دارد . در این تکنیک هم از دیدگاه ثابت و هم پویا به کسب وکار نگاه می شود .
دامنه کسب و کار به نواحی عملیاتی دانه درشت تفکیک می شود تا بتوان دید ثابتی نسبت به متغیر داشت . عنصر کلیدی نواحی عملیاتی ، توابع کسب و کار هستند که بایستی برای آن پاسخگو باشند. موجودیت های کسب و کار که پاسخگو برای انجام این توابع هستند نیز در این فاز انجام می شود . فرآیند تحلیل دامنه با شناسایی موجودیت های کسب و کار مشخص می شود . موجودیت هایی که با اتصال سست خودشان ، کل محیط توزیع شده را شکل می دهند . دامنه ها و نواحی عملیاتی آنها ، اتصالات اولیه هستند که تحت نظارت معماری سرویس گرا صورت می گیرد و در نهایت مالک سرویس ها خواهند بود ودید پویا در فرآیند های کسب و کار نمود پیدا می کند . معمولاً فرآیند ها شناسایی شده اند و سلسله مراتب فرآیندها شکل می گیرند تا تجزیه دامنه محقق شود و در نهایت مجموعه ای از فرآیند های کسب و کار که قابلیت پی گیری دارند ،شکل می گیرد تا بتوان دیدی درست از تعامل های فرآیند ها داشت .
هدف مدلسازی فرآیند کسب و کار ، نشان دادن نمایشی از بایدها و داشته هاست .
تحلیل دارایی های فعلی
در این تکنیک، معماری سرویس گرا تحلیل سطح بالایی از سیستم های فعلی ، برنامه های کاربردی ، سرویس ها و سایر دارایی هایی نظیر سیستم ها ، پکیج ها و سیستم های قدیمی را ارائه میدهد که قابلیت آن را دارند تا سرویس ها را در عمل پشتیبانی کنند. تمرکز بر دارایی هایی است که نقش کلیدی در فرآیند های کسب و کار دارد . در ابتدا نگاشتی بین اهداف کسب و کار و برنامه های کاربردی فعلی صورت می گیرد و سرویس های دانه درشت شناسایی می شوند . مشخصه سازی سرویس های دانه ریز تر و مشخصه پیغام ها شکل می گیرد .
انتخاب سرویس های کاندید
این فعالیت متشکل از سه بخش است : فاکتوردهی مجدد به سرویس ها ، تست لیتموس و عقلایی سازی سرویس ها . سرویس ها در سلسله مراتب ، فاکتوردهی مجدد می شوند به نحوی که سرویس های سطح پایین که به نحوی با هم وابستگی منطقی دارند در یک سرویس سطح بالاتر با هم همگروه می شوند . متعاقباً تست لیتموس به یکسوی از سرویس های کاندید اعمال می شود .طرح سرویس ارائه شده در نهایت شامل وابستگی بین سرویس ها ، کامپوننت ها ، جریان های اطلاعاتی و قوانین است .در عقلایی سازی مدل سرویس که مروری کلی توسط ذی نفعان صورت می گیرد تا تایید شود سرویس ها در نهایت رابطه عقلایی باهم دارند.
3.4 تطابق رویکرد با مدل محاسباتی ابریهمانطور که اشاره شد هدف این تحقیق ارائه رویکردی راهبردی برای ارائه سیستمهای اجرایی تولید توزیعشده با استفاده از مدل محاسبات ابری است. با در نظر داشتن این نکته و بانظر به رویکرد، که در بخش پیش مطرح شد، در این بخش درباره نحوه بهکارگیری مدل محاسبات ابری به عنوان بستری قدرتمند جهت ارائه توابع سیستمهای اجرایی تولید به صورت توزیعشده بحث خواهد شد. در این نگاشت تلاش بر این بودهاست که تا حد امکان از قابلیتهای ابر استفاده بهینه شود و تا حد امکان جامع بوده باشد تا سیستمهای اجرایی تولید را در حوزههای مختلف شامل شود.
در ادامه این فصل، در ابتدا ، نحوه به کارگیری مدل محاسبات ابری برای سیستمهای اجرایی تولید از نگاه کلان بررسی شده است، سپس با توجه به مبانی این مدل، سرویسهای مختلفی که در سیستمهای اجرایی تولید تحت عنوان XasS ارائه میشود، شناسایی میشود.
3.4.1 مراحل چارچوب از دید محاسبات ابری
در سالهای اخیر فلسفه ” طراحی در همه جا، تولید در همه جا(DAMA) ” ظهور کرده است. طبق این فلسفه کاربران درخواستهای مختلف تولید خود را از طریق سایتهای مختلف درخواست میکنند. DAMA همچنین میتواند لینک ارتباطی بین بخش برنامهریزی منابع سازمان در سطح کلان، مدیریت ارتباط با مشتری، طراحی و مهندسی منابع فراهم آورد.
با وجود چنین رویکردی و ظهور محاسبات ابری، میتوان پتانسیلهای گسترده آن را در سیستمهای اجرایی تولید توزیعشده به کار برد. به طور کلی در حال حاضر دو رویکرد عمده در به کارگیری محاسبات ابری در امر تولید وجود دارد. رویکرد اول، اتخاذ محاسبات ابری در بخشهای مورد نیاز تولید و رویکرد دوم، ابری کردن کل فرآیند تولید است. در اینجا رویکرد اول مبنای کار قرار گرفته است.
طبق مبانی مدل محاسبات ابری نیازمندیهای مختلف، تحت عنوان سرویس قابل پوشش است. در مدل مرجع این محاسبات، سرویسها میتوانند از بخش محاسباتی ابر، بخش حین اجرای آن و بخش برنامه کاربردی درخواست شود. در این چارچوب، سعی شده است تا توابع اصلی سیستمهای اجرایی تولید را تحت عنوان سرویس دریافت کرد.

شکل3.5 مدل محاسبات ابری و جایگاه سیستم
سیستمهای اجرایی تولید، همانطور که در فصول پیش به آن اشاره شد از بخشها و توابع مختلف تشکیل شدهاند، که هدف اصلی آن وجود مکانیزم کنترلی یکپارچه برای رسیدن به هدف تولید سفارش با رعایت بهینگی در استفاده از منابع میباشد. چون سیستمهای اجرایی تولید در این تحقیق به صورت توزیعشده مورد بررسی قرار گرفته است، لذا بخشهای مختلف آن الزاماً در یک سایت قرار ندارند و بایستی کنترل با رعایت انعطافپذیری و قابلیت کار متقابل عناصر مختلف محقق شود.
از آنجا که محیط ابربه صورت ذاتی چنین اهدافی را تامین میکند، به دنبال آن هستیم تا سرویسهای کاربردی سیستمهای اجرایی تولید را در محیط ابر شناسایی کنیم. به عبارتی خواهان آن هستیم که رویکردی سرویسمحور به برنامههای کاربردی سیستمهای اجرایی تولید در محیط ابر داشته باشیم که حین اجرای تمامی این سرویسها در هنگام درخواست، از منابع و موجودیتهای محاسباتی که در لایههای پایینتر مدل پردازش ابری موجود است، استفاده شود.