آنالیز حالات بالقوه خرابی (FMEA)

آنالیز حالات بالقوه خرابی (FMEA)

بخش بیست و یکم؛ آنالیز حالات بالقوه خرابی (Failure Mode Effect Analysis)

آنالیز حالات بالقوه خرابی FMEA که گاهی اوقات آنالیز حالت خرابی، اثرات و تحلیل بحرانی نیز نامیده می شود (FMECA)، یک ابزار تجزیه و تحلیل متداول برای تجزیه و تحلیل خرابی های مرتبط با اجزای محصول است. قابلیت اطمینان، به عنوان یک ویژگی ذاتی در طراحی، یکی از مهمترین نیازهای عملیاتی هر محصول است، صرف نظر از اینکه چه نوع محصولی (سخت افزار یا نرم افزار) است.

با نگاه کلی به الزامات مربوط به قابلیت اطمینان، می توان مشاهده کرد که این الزامات موضوعات مختلفی را پوشش می دهد، از جمله:

۱-عوامل مرتبط با کارایی و اثربخشی قابلیت اطمینان

۲-چرخه عمر محصول برای اندازه گیری قابلیت اطمینان

۳-شرایط محیطی که انتظار می رود محصول درحال سرویس دهی و نگهداری باشد (مانند دما، رطوبت، ارتعاشات، تشعشع و غیره).

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

 البته برای محصولاتی که از قطعات و اجزاء زیادی تشکیل شده اند می تواند کاری دشوار باشد. برای اینکار هیچ رویکرد استانداردی وجود ندارد و معمولاً شرکت ها از چرخه آزمایش- ارزیابی- اصلاح (Trial-Evaluation-Modify Cycle) استفاده می کنند.

در کنار این روش، اکثر شرکت ها و سازمان های تولیدی در طول فرآیند طراحی محصول از دو ابزار کمکی نیز برای بهتر و ساختارمند شدن فرآیند استفاده می کنند که عبارتند از:

 -تجزیه و تحلیل حالات بالقوه خرابی و آثار آن (Failure mode effect analysis)

– آنالیز درخت خطا (Faulty tree analysis).

FMEA در ابتدا توسط ناسا (NASA) برای بهبود قابلیت اطمینان طراحی سخت افزارها جهت برنامه های فضایی توسعه داده شد. اگرچه سند اصلی FMEA دیگر قابل اجرا نیست، اما روش FMEA به خوبی حفظ و توسعه یافته است. امروزه FMEA به استانداردی قابل قبول برای شناسایی مشکلات قابلیت اطمینان تقریباً در هر نوع سیستمی از طراحی نرم افزار گرفته تا انواع لوازم خانگی، صنعتی و کامپیوتری تبدیل شده است.

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

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

دوم تحلیل بحرانی (Criticality Analysis) است که احتمال وقوع خرابی (نرخ خرابی) را کمی می کند و شدت اثرات ناشی از خرابی ها را رتبه بندی می کند. یعنی مثلا برای رتبه اول، خرابی رخ داده در فلان قسمت از محصول بیشترین تکرار را داشته و اثر مخربی آن نیز بالا است.

برای انجام تجزیه و تحلیل FMEA، برخی از الزامات اساسی وجود دارد که باید برآورده شوند. این الزامات عبارتند از:

۱-داشتن طرح شماتیک از ساختار محصول. بدون درک اولیه از معماری محصول، به ویژه ساختارهای سخت افزاری و نرم افزاری، نمی توان پیامدهای احتمالی را در صورت خرابی یک یا چند جزء شناسایی کرد. این نقطه شروع تحلیل FMEA است.

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

۳- شناخت الزامات محصول. برای طراحی و ساخت محصول یکسری نیازهایی چه از طرف مشتری و یا چه از طرف استانداردهای مربوطه وجود دارد که تحت عنوان الزامات (Requirements) معرفی می شود. اینکه در هر مرحله از طراحی و توسعه محصول این الزامات رعایت شده یا خیر در آنالیز خرابی مهم است.

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

۴- علاوه بر شناخت خود محصول، باید فرآیند های جانبی اما مرتبط با محصول را نیز بشناسیم برای مثال زنجیره تأمین قطعات مورد نیاز محصول کدام است. از کدام شرکت و پیمانکار قطعه خریداری می شود. آیا آنها معتبر و دارای صلاحیت های لازم هستند؟

بر اساس موارد بالا مشخص است که برای تجزیه و تحلیل حالات خرابی کارگروهی لازم است. باید پرسنلی از واحد تحقیق و توسعه، تولید، تأمین و تدارکات، مهندسی و … حضور داشته باشند. بعد از اینکه تیم مورد نظر تشکیل شد گام های ذیل را در نظر داشته باشید:

۱- الزامات سیستم را تعریف کنید به ویژه الزامات مربوط به قابلیت اطمینان. محیط عملکرد، تعداد سطوح و اجزاء مرتبط با هر سطح به دقت مشخص شود. برای اینکار از سطوح بالا شروع کنید و به تدریج به زیر سیستم ها برسید. هدف داشتن یک تصویر واضح از محصول است.

۲-عملکردها را برای هر زیر سیستم از محصول بشناسید و آنرا درک کنید. داده های مورد نیاز طیف وسیعی را شامل می شود از جمله ورودی و خروجی به هر زیر سیستم، مکانیسم عملکرد، زمان و سیکل عملیات، قوانین، مفروضات، استانداردهای عملکردی و غیره است. درک  فناوری  فعلی بکار رفته و محدودیت‌های آن به ما کمک می‌کند تا پیش‌بینی‌های حالت شکست را معنادارتر کنیم.

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

۳- قابلیت اطمینان را برای محصول و هر جز (قطعه یا زیر سیستم) اندازه گیری و ثبت نمایید. این کار برای کمی کردن اثر خرابی مهم است. این مرحله می تواند موازی با گام قبلی انجام شود.

۴- طراحان محصول باید به منابع مختلف اطلاعات، از جمله محصولات مشابه، داده های تامین کننده، داده های تاریخی برای مطالعات حوادث و سوانح مشابه و هر گونه اطلاعات مربوط به شرایط محیط سرویس نگاه کنند.

یک حالت خرابی برای یک قطعه معمولی شامل جنبه های زیر است:

الف- نداشتن عملکرد در زمان مناسب،

ب- عملکرد نوسانی،

ج- توقف نکردن عملکرد زمانی که می خواهیم توقف کند،

د- نداشتن خروجی مورد نظر یا کاهش توان عملیاتی،

۵-علل و آثار خرابی را شناسایی کنید. علت حالت خرابی معمولاً ناشی از یک رویداد داخلی یا خارجی یا تعامل بین آنها است. این احتمال وجود دارد که یک رویداد باعث چندین خرابی شود و یا برعکس نوع خاصی از خرابی دلایل متعددی داشته باشد. علل متداول خرابی عبارتند از کهنه و فرسودگی قطعه، مواد اولیه بی کیفیت، خطای انسانی، نقض استاندارها، شرایط بد محل سرویس (مثلا محیط خیلی مرطوب)، آسیب ناشی از انبارش، جابجایی، حمل و نقل بد و غیر اصولی.

ابزارهای زیادی برای کمک به طراحان در تعیین علل خرابی و روابط بین آنها وجود دارد. به عنوان مثال، نمودار  استخوان ماهی (Fishbone) مدل معروفی که توسط ایشیکاوا معرفی شد، مدل سوئیسی (Swiss model) و تجزیه و تحلیل عوامل انسانی در بروز خطا و سیستم طبقه بندی آن (Human factors analysis and classification system- HFACS) از جمله مهمترین ها هستند.

آنالیز حالت خرابی، تأثیر بالقوه یک خرابی را بر روی دیگر اجزا و یا کل سیستم ارزیابی می کند. خرابی ها بسته به نوع و تأثیر آنها در سطوح مختلف تأثیر می گذارد. به طور کلی، سه سطح برای تأثیر خرابی وجود دارد:

الف- اثر موضعی دارد (Local effect)؛ اثر محلی آن دسته از اثراتی هستند که به طور خاص از خرابی قطعه در پایین ترین سطح محصول ناشی می شوند.

ب- در سطوح بالاتر اثر دارد (Parent-level effect)؛ اینها اثراتی هستند که یک خرابی بر عملکرد یک یا چند سطح بالاتر می گذارد.

ج- کلیت عملکرد محصول تحت تأثیر قرار می گیرد (End-level effect)؛ این اثرات، آنهایی هستند که بر عملکرد کلی سیستم به عنوان یک کل تأثیر می گذارند. یک خرابی کوچک می تواند در کوتاه مدت بدون تأثیر خاصی باشد، یا می تواند عملکرد کلی سیستم را کاهش دهد و یا در نهایت باعث شود سیستم از کار بیفتد.

۶- روش تشخیص خرابی را مشخص کنید (Identify failure detection method)؛ این بخش از FMEA روش هایی را که به وسیله آنها وقوع یک خرابی شناسایی می شود، مشخص می کند. این روش ها عبارتند از:

الف- تشخیص بوسیله کارکنان،

ب- علائم بصیری و یا شنیداری جهت هشدار،

ج- دستگاه های سنجش خودکار.

در هر روش باید شرایط تشخیص صحیح شامل تفکیک عملکرد عادی و سالم (نمونه شاهد) در مقابل موارد خرابی و همچنین زمان و دوره بررسی که می تواند به صورت بازرسی های دوره ای یا مداوم باشد، به دقت تعریف شود.

۷- تعیین شدت خرابی (Assign failure severity)؛ پس از شناسایی تمامی حالت های خرابی و اثرات آنها بر روی عملکرد محصول، باید شدت تاثیر این خرابی ها بر سیستم را با اختصاص یک امتیاز (نمره) رتبه بندی کرد.

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

جدول ۱- سیستم رتبه بندی خرابی در FMEA

عکس سیستم رتبه بندی خرابی در FMEA

۸- تعداد یا فرکانس حالت خرابی و احتمال تشخیص درست آنرا مشخص کنید (Assign failure mode frequency and probability of detection)؛ تجزیه و تحلیل بحرانی، نیمه دوم فعالیت در FMEA است. انجام این مرحله شامل اضافه کردن اطلاعات اضافی در مورد خرابی ها است تا با اجتناب از آنها بتوان به طراحی بهتری دست یافت چراکه طراحان را قادر می سازد تا نگرانی های مربوط به قابلیت اطمینان و نگهداری سیستم را شناسایی کرده و در مرحله طراحی به این نگرانی ها رسیدگی کنند.

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

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

۹- تعیین بحرانی بودن خرابی (Analyze failure criticality)؛ هنگامی که نرخ وقوع و احتمال تشخیص خرابی شناسایی شد، باید با اطلاعات مربوط به خرابی و شکست ادغام شود تا در مورد بحرانی بودن آن ارزیابی صورت بگیرد. ارزیابی می تواند به صورت کیفی و کمی انجام شود.

در ارزیابی کمی برای تعداد مشخصی از قطعه (محصول) و در فاصله زمانی t از رابطه زیر استفاده می شود:

    \[C_{m}(t) = \alpha\beta\lambda t\]

که در این رابطه:

Cm رتبه و امتیاز بحرانی بودن خرابی و شکست مورد نظر

λ نرخ خرابی (فراوانی)

α احتمال حالت خرابی

β احتمال اثر خرابی

t فاصله زمانی 

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

    \[C_{m}(t) =\sum C_{mi} (t)= \sum \alpha_{i}\beta_{i}\lambda_{i}t\]

اگر امکان بررسی تعداد خرابی در یک بازه زمانی مشخص و برای تعداد معینی از قطعات وجود نداشته باشد، آنگاه از رویکرد کیفی استفاده می شود. یک روش معمول استفاده از عدد اولویت ریسک RPN (Risk Priority Number) برای رتبه‌بندی و شناسایی ریسک‌های مرتبط با اجزا و قطعات است. RPN را می توان از رابطه زیر تعیین کرد:

دشواری در تشخیص × وقوع × شدت اثر =RPN

شدت اثر (Severity)؛ هرچه شدت اثر خرابی بالاتر باشد نمره بالاتری نیز دریافت می کند. در فرم هایی که برای ثبت اطلاعات مربوطه استفاده می شود از حرف  “S” استفاده می کنند. این متغیر با اصلاح طراحی محصول یا فرآیند قابل بهبود است.

وقوع (Occurrence)؛ میزان فراوانی خرابی است و هرچه فراوانی بالاتر باشد امتیاز بالاتری دارد. از حرف “O” به عنوان نماد این متغیر استفاده می شود. برای کنترل این متغیر باید علت و زمینه بوجود آمدن خرابی را بهتر و دقیق تر تشخیص داده و بعد کنترل کرد.

تشخیص (Detection)؛ توانایی طرح کنترل فعلی برای تشخیص علت قبل از ایجاد حالت خرابی و یا اگر هم خرابی اتفاق افتاد قبل از اینکه اثر جدی بر عملکرد سیستم داشته باشد بتوانیم آنرا تشخیص دهیم. نماد این متغیر حرف “D” است. معمولاً برای هر محصول یک طرح کنترل در قالب یک فرم تهیه می شود که یکی از کاربردهای آن در همین قسمت است. نمونه ای از فرم طرح کنترل در شکل زیر نشان داده شده است.

عکس فرم برنامه کنترل

شکل ۱- نمونه از فرم برنامه (طرح) کنترل

در کنار تدوین طرح کنترل باید روش های دقیق آماری و بهبود قابلیت تشخیص را در نظر داشته باشیم. هر چه خرابی دیرتر و به سختی تشخیص داده شود امتیاز بالاتری نیز دریافت می کند. به طور کلی قطعه ای با فرکانس خرابی بالا، شدت اثر زیاد و دشواری در تشخیص دارای RPN بالایی است. چنین اجزایی باید در اولویت طراحی قرار گیرند. در اغلب اوقات هم از همین روش کیفی استفاده می شود. معمولا نتیجه تجزیه و تحلیل FMEA در قالب یک جدول است که نمونه از آنرا در شکل (۲) می بینید.

عکس نمونه ای از جدول FMEA

شکل ۲- مثالی از نحوه تدوین آنالیز حالات بالقوه خرابی

توجه داشته باشید که ستون مربوط به بحرانی بودن (criticality) معمولا برابر حاصلضرب شدت در وقوع است یا به عبارت دیگر:

Criticality= S * O

و البته تغییر این مقدار بر حسب نیاز امکان پذیر است. نمونه ای از فرم ثبت اطلاعات برای FMEA را می توانید از اینجا دریافت کنید.

منبع :

Systems Engineering Design Principles and Models, Dahi Liu

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

error: Content is protected !!