2. β Factor. 1. Redundant

Transcript

1 دوم قسمت نگارش مرتضوی محمد سید مهندس آباد نجف واحد نخبگان و جوان پژوهشگران باشگاه ایران آباد نجف اسالمی آزاد دانشگاه افزونه سامانههای اطمینان قابلیت کليدي: واژههاي فاکتور بتا روش خرابی مشترک علت علت نرخ تخمین روشهای بررسی قابلیت ارزیابی در خرابی مشترک افزونه سامانههای اطمینان دچار خرابی نوع دو اثر در 1 افزونه سامانههای خرابی و مستقل خرابی میشوند: شکست وابسته خرابیهای مهمترین از یکی وابسته. خرابی مشترک علت افزونه سامانههای در اجزاء تا میشود باعث خرابی از نوع این است. خراب همزمان صورت به افزونه سامانهی در دو از بیش خرابی به دیگر عبارت به شوند. بازهی یک در که افزونه سامانهی در جزء مشترک علت میافتد اتفاق کوتاه زمانی افزونه سامانههای در میشود. گفته خرابی خرابی گسترش باعث که دارند وجود عواملی خرابی گسترش این میشوند. اجزاء بین در افزونه سامانهی اجزاء همزمان خرابی باعث مأموریت بازهی در را سامانه کل و شده مشترک علت به توجه میسازد. مشکل دچار و میشود آغاز سامانه طراحی فاز از خرابی مشترک علت رخداد عوامل امکان حد تا باید در و داد کاهش ممکن حداقل به را خرابی را خرابی مشترک علت نرخرخداد نهایت لحاظ اطمینان قابلیت ارزیابی در و محاسبه 2 فاکتور بتا روش حاضر مطالعهی در کرد. نظر در برای پرکاربرد روشهای از یکی که ارزیابی در خرابی مشترک علت گرفتن میباشد افزونه سامانههای اطمینان قابلیت تخمین روشهای سپس و میگردد معرفی میشوند. بیان تفصیل به بتا UPM روش.3.5 اشاره 3 UPM روش به کمی مطالعات در بقیهی به نسبت روش این اما است شده است دقیقتری روش بتا تخمین روشهای علت رخداد ایجاد باعث که عواملی که چرا این در کامل طور به میشوند خرابی مشترک به عوامل از هرکدام و است شده بیان روش برای طرفی از میشود داده شرح مفصل طور این در که مشخصشده محدودهای عامل هر بیشتری دقت با مربوطه کارشناس صورت این میدهد. انجام را عامل هر به وزندهی UPM روش که است شده باعث مطلب توجه مورد کاربردی روش یک عنوان به 9 اردیبهشت پیاپی 191 / 2/ شماره سال 20 / 3. Unified Partial Method 2. β Factor 1. Redundant 27

2 بررسی روشهای تخمین نرخ علت... سال 20 / شماره 2/ پیاپی 191 / اردیبهشت 9 جدول 5. عوامل رخداد علت مشترک خرابی ]12[ جدول. وزنهای هر عامل در روش ]12[ UPM عامل فرعی افزونگی و تنوعپذیری جداسازی فهم و درک سامانه تجزیه و تحلیل تعامالت انسان و ماشین فرهنگ ایمنی کنترل محیطی آزمونهای محیطی عامل اصلی طراحی عملیات محیط طراحان و مهندسان سامانه قرار گیرد. این روش در صنایع هستهای انگلستان استفاده میشود و یک روش جامع برای تخمین مقدار بتا است که منحصر به خاصی نیست. روش UPM مانند دو روش قبل بر اساس نظرات و قضاوت کارشناسان فنی انجام میشود و زمانی مورد استفاده قرار میگیرد که اطالعات دقیقی از علت مشترک خرابی در دسترس نباشد و یا اطالعات به طور دقیق ثبتنشده باشند ]10[. یکی از مطالعات اولیه در رابطه با روش UPM در سال 199 میالدی انجامگرفته است به طوری که عوامل بهکار رفته در این روش را به سه قسمت اصلی تقسیم کرده است: ]11[ عوامل و فعالیتهایی انسانی 4 که باعث خرابی همزمان اجزاء در سامانه افزونه میشود وابستگی عملکردی 5 در سامانههای افزونه که باعث میشود احتمال رخداد علت مشترک خرابی افزایش یابد نرمافزارهایی که باعث میشوند خرابی در کل سامانه انتشار یابد. در سال 2003 میالدی برخی از عوامل رخداد علت مشترک خرابی در روش UPM توسعه داده شد و یک چهارچوب کلی برای اجرای این روش آماده گردید. در این روش 8 عامل اصلی که باعث خرابی همزمان اجزای سامانههای افزونه میشوند تعریفشده است که میتوانند تمام جنبههای خرابی در اثر علت مشترک را پوشش دهند ]12[. این 8 عامل زیرمجموعهی 3 عامل اصلی میباشند + طراحی عملیات محیط که در جدول 5 به صورت خالصه آمده است. عوامل ذکرشده در جدول باال بر اساس تجربه و استانداردهای مختلف جمعآوری شدهاند. هرکدام از این عوامل پنج متفاوت دارند که با حروف و مشخص میشود. هرکدام از این ها برای هر عامل تعریف مربوط به خود را دارند که در جدولهای جداگانه بیانشده است. برای اجرای روش UPM اولین قدم تعریف و تعیین مرز فیزیکی سامانه است ( 7 )G سپس هر عامل توسط کارشناسان مربوطه تعیین میگردد. در مرحلهی بعد وزن هر که برای هر عامل به صورت جداگانه مشخصشده است از جدول تعیین میشود و در نهایت تمام این وزنها با یکدیگر جمع شده و بر عدد تقسیم میشوند تا مقدار نرخ علت مشترک خرابی محاسبه گردد. در صورتی که از روش UPM برای تخمین بتا استفاده گردد مقدار بتا در بازهی بستهی 0/00102 تا 0/302 قرار میگیرد که این بازه همان مقادیر استانداردی است که در استاندارد I 1508 به آن اشارهشده است. توضیح هر عامل و جدول مربوط به وزنهای آن به شرح زیر میباشد: افزونگی و تنوعپذیری : 8 افزونگی شرایط و تعداد اجزاء موازی را نشان میدهد. بهطور مثال یک سامانهی موازی میتواند 011 هر عامل افزونگی و تنوع جداسازی درک سامانه تجزیه و تحلیل تعامالت انسان و ماشین فرهنگ ایمنی کنترل آزمون به صورت 1 از 9 2 باشد یعنی اگر یکی از 2 جزء دچار خرابی شود سامانه خراب است. میتوان تعداد اجزاء افزونه را افزایش داد و یک سامانهی 1 از 10 3 یا 1 از 11 4 ایجاد کرد. در این صورت احتمال رخداد خرابی مشترک کاهش مییابد. منظور از تنوعپذیری میزان شباهت اجزاء با یکدیگر است. اگر اجزاء یک سامانهی افزونه از هر جنبهای با همدیگر شباهت داشته باشند احتمال خرابی همزمان آنها افزایش مییابد. به طور مثال برای یک سامانهی افزونهی 1 از 2 پمپ آب اگر یکی از پمپها با تسمه و دیگری با گیربکس طراحی شود در این حالت احتمال رخداد خرابی همزمان به حداقل ممکن میرسد و 9. 1-out-of out-of out-of-4 7. ommon ause omponent Group 8. Redundancy and iversity 4. Humman Factor 5. Fanctinal ependency. Softward 28

3 نرخ تخمین روشهای بررسی افزایش 12 عملکردی تنوع دیگر عبارت به یا سامانهی یک اجزاء که صورتی در مییابد. خرابی احتمال نیز باشند 13 یکسان غیر افزونه اگر مثال برای مییابد کاهش آنها همزمان دو از افزونه سامانهی یک در آب پمپهای خریداری متفاوت تولیدکنندهی کارخانهی همدیگر به نسبت کمتری تشابههای شوند برای را مختلف های 7 جدول دارند. میدهد نشان تنوعپذیری و افزونگی عامل گردد. انتخاب کارشناس توسط باید که عامل این ارزیابی برای : 14 جداسازی افزونه سامانهی اجزاء قرارگیری مکان باید حالت این در شود. بررسی همدیگر به نسبت و الکترونیکی تجهیزات قرارگیری نحوهی باشد متفاوت میتواند مکانیکی تجهیزات به شود. دستهبندی مختلف گروه 5 در و در افزونه سامانهی اجزاء اگر مثال طور در آنها بگیرند قرار جداگانه محفظههای اجزاء که صورتی در میگیرند. قرار اول گروه جداگانهای محفظههای در افزونه سامانهی آن حائل یا مانع یک آن بر عالوه و باشند این در کند جدا همدیگر از را محفظهها دوم گروه در اجزاء قرارگیری نحوهی صورت سامانهی اجزاء قدر چه هر میشود. تعریف همدیگر از کارکردی شرایط لحاظ از افزونه خرابی رخداد احتمال باشند داشته فاصله اینکه برای میکند. پیدا کاهش آنها همزمان هر جداسازی نحوهی از فیزیکی نمای یک شده ایجاد 4 شکل باشد شده تعریف گروه برای را گروه هر دستهبندی شرایط که است میدهد. نمایش الکترونیکی و مکانیکی اجزاء 4 شکل از مناسب گروه انتخاب از بعد پذیری تنوع و افزونگی عامل برای مختلف سطوح 7. جدول توضیحات سامانه 2 از 1 سامانه مثال )بهطور مشابه و یکسان اجزاء با افزونگی کمترین 4( از 3 سامانه یا 3 از 2 1 سامانه 4 از 1 سامانه مثال )بهطور مشابه و یکسان اجزاء با زیاد افزونگی ( از 2 سامانه یا 5 از 4 از 1 سامانه مثال طور )به مشابه و یکسان اجزاء با زیاد خیلی افزونگی 5( از 2 سامانه یا 5 از 1 سامانه n از 1 سامانه مثال طور )به مشابه و یکسان اجزاء با زیاد فوقالعاده افزونگی باشد( 7>n که شرطی به 2( از 1 سامانه )مانند عملکردی تنوع و یکسان غیر اجزاء با زیاد افزونگی 1 سامانه )مانند عملکردی تنوع و یکسان غیر اجزاء با زیاد خیلی افزونگی یا 4( از )مانند عملکردی تنوع و یکسان غیر اجزاء با زیاد فوقالعاده افزونگی یا 8( از 1 سامانه زیاد عملکردی تنوع و یکسان غیر اجزاء با زیاد خیلی افزونگی زیاد فوقالعاده عملکردی تنوع و یکسان غیر کامال جزء 2 با افزونه سامانهی یک جداسازی عامل برای مختلف سطوح 8. جدول توضیحات از قرارگیری )شرایط باشد شرایط بدترین در افزونه سامانهی اجزاء جداسازی نحوهی باشد(. بدتر 1 گروه گیرد. قرار 1 گروه در همدیگر از افزونه سامانهی اجزاء جداسازی نحوهی گیرد. قرار 2 گروه در همدیگر از افزونه سامانهی اجزاء جداسازی نحوهی گیرد. قرار 3 گروه در همدیگر از افزونه سامانهی اجزاء جداسازی نحوهی گیرد. قرار 5 و 4 گروه در همدیگر از افزونه سامانهی اجزاء جداسازی نحوهی اردیبهشت پیاپی 191 / 2/ شماره سال 20 / 12. Functional diversity 13. Non identical 14. Separation 29

4 نرخ تخمین روشهای بررسی :1 :2 :3 :4 :5 هم به نسبت افزونه سامانه اجزاء قرارگیری حالت تعیین 4. شکل 9 اردیبهشت پیاپی 191 / 2/ شماره سال 20 / میآید. دست به 8 جدول از جداسازی عامل سامانه درک : 15 سامانه درک با رابطه در فناوری بلوغ نشاندهندهی مستقل خرابی بر عالوه که است اجزایی شکست دچار خرابی مشترک علت تحت تشخیص UPM روش در میشوند. است: زیر ویژگی 4 برحسب عامل این سامانهی اجزاء عملیاتی 1 تجربهی دچار خرابی مشترک علت تحت که افزونه 10 عملیاتی تجربهی اگر میشوند. شکست بیشتر یا و باشد سال 10 از کمتر یا و سال باشد. سال 10 از برای 17 جدید و روز به فناوری مشترک علت تحت که افزونه سامانههای از )استفاده میشوند. شکست دچار خرابی نرمافزارهای به نیاز افزونه سامانهی اجزاء دارد(. تخصصی که 18 فناوری و فناوری پیچیدگیهای علت تحت که افزونه سامانهی اجزاء برای میشوند. شکست دچار خرابی مشترک 19 فناوری بودن رضایتبخش که افزونه سامانهی اجزاء برای انتخابشده شکست دچار خرابی مشترک علت تحت میشوند. در میتوانند باال در ذکرشده ویژگی 4 انتخاب برای کارشناسان تصمیمگیری گیرند. قرار استفاده مورد سامانه درک عامل سامانه عملیاتی تجربهی که صورتی در بهکارگیری افزونه سامانهی که )مدتزمانی سال 10 یا سال 10 از کمتر است( شده 15. Understanding 1. xperience 17. Novelty of the technology 18. omplexity of the technology 19. Satisfactory of the technology 30

5 نرخ تخمین روشهای بررسی باشد سال 10 از کمتر یا سال 10 عملیاتی تجربه توضیحات در 4 و 3 2 ویژگی سه هر یا شود استفاده افزونه سامانهی در تخصصی نرمافزار گیرند قرار حداکثر قرار حداقل در ویژگی یک و حداکثر در 4 و 3 2 ویژگیهای از ویژگی دو گیرد قرار حداقل در ویژگی دو و حداکثر در 4 و 3 2 ویژگیهای از ویژگی یک گیرد گیرد قرار حداقل در ویژگی سه هر نیست دسترس در سامانه عملیات با رابطه در کافی اطالعات و تجربه باشد سال 10 از بیشتر عملیاتی تجربه توضیحات شود استفاده افزونه ی سامانه در تخصصی نرمافزار گیرند قرار حداکثر در 4 و 3 2 ویژگی سه هر قرار حداقل در ویژگی یک و حداکثر در 4 و 3 2 ویژگیهای از ویژگی دو گیرد قرار حداقل در ویژگی دو و حداکثر در 4 و 3 2 ویژگیهای از ویژگی یک گیرد گیرد قرار حداقل در ویژگی سه هر 9 اردیبهشت پیاپی 191 / 2/ شماره سال 20 / درک تعیین برای 9 جدول از باشد تجربهی که زمانی و میشود استفاده سامانه از باشد سال 10 از بیشتر سامانه عملیاتی 2 ویژگیهای میگردد. استفاده 10 جدول حداقل 2 در میتوانند هرکدام 4 و 3 از منظور گیرند. قرار )زیاد( حداکثر و )کم( افزونه سامانهی اجزاء برای بهروز فناوری باعث که است نرمافزارهایی از استفاده خرابی مشترک علت رخداد احتمال میشود باعث نرمافزار خرابی چراکه یابد افزایش دچار افزونه سامانهی اجزاء کل تا میگردد اجزاء در فناوری پیچیدگی اگر شوند. خرابی باشد باالترین در افزونه سامانهی جزء یک خرابی اثر در اجزاء اینکه احتمال صورت به تعمیرات و نگهداری در خطا یا و مییابد. افزایش شوند خرابی دچار همزمان ارتباط پیچیدگی افزایش دیگر عبارت به در میدهد افزایش را افزونه سامانهی اجزاء را )زیاد( حداکثر 3 ویژگی حالت این پیچیدگی اگر و میدهد اختصاص خود به باشد پایینتر یا معمول در فناوری ویژگی میکند. اختیار را )کم( حداقل آیا که است سؤال این به پاسخ اصل در 4 سامانهی طراحی برای انتخابشده فناوری که صورتی در خیر یا است مناسب افزونه مشترک علت رخداد احتمال انتخابی فناوری در و حداقل مقدار ندهد افزایش را خرابی رخداد احتمال انتخابی فناوری که صورتی مقدار دهد افزایش را خرابی مشترک علت درک عامل از ویژگی این برای را حداکثر بهتر درک برای میگیریم. نظر در سامانه میشود: بیان زیر مثال مطلب افزونهی سامانهی یک در میشود فرض سامانهی یک از فشارقوی آب پمپهای کمتر( یا سال )10 سامانه درک عامل برای مختلف سطوح 9. جدول سال( 10 از )بیشتر سامانه درک عامل برای مختلف سطوح 10. جدول رد میشود. استفاده آمادهبهکار افزونهی دستی صورت به میتواند سوییچ اولیه حالت حالت این در گیرد انجام اپراتور توسط و کمتر خرابی مشترک علت رخداد احتمال هوشمند سوییچ یک از که است زمانی از خرابی صورت در که چرا گردد استفاده بازمیماند کار از افزونه سامانهی کل سوییچ به احتیاج نیز خود سوییچ سامانهی طرفی از وضعیت این در دارد. تعمیرات و نگهداری سوییچ کردن اضافه با فناوری پیچیدگی است پیداکرده افزایش افزونه سامانهی به رخداد احتمال درعینحال ولی 3( )ویژگی میکند پیدا افزایش نیز خرابی مشترک علت 4(. )ویژگی دارد... ادامه 31 منابع: 1. S. M. Mortazavi, M. Karbasian, and S. Goli, "valuating MTTF of 2-out-of-3 redundant systems with common cause failure and load share based on alpha factor and capacity flow models," International Journal of System ssurance ngineering and Management.201, 2.. O onnora and. Moslehb, " General ause ased Methodology for nalysis of ommon ause and ependent Failures in System Risk and Reliability ssessments," K.. Misra, Handbook of performability engineering: Springer Science & usiness Media, K. N. Fleming, "Reliability model for common mode failures in redundant safety systems," Modeling and simulation, vol., M. Rausand and. Høyland, System reliability theory: models, statistical methods, and applications vol. بگیرید. تماس دبیرخانه با مقاله این منابع دیگر از اطالع برای