پنج تکنیک قابلیت اطمینان برای تحلیل تحمل‌پذیری خطا در صنایع

چرا تحمل‌پذیری خطا به چیزی فراتر از سخت‌افزار افزونه نیاز دارد

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

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

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

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

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

قابلیت اطمینان، دسترس‌پذیری، ایمنی و قابلیت نگهداشت‌پذیری یکسان نیستند

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

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

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

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

انتخاب روش بر اساس پرسش مهندسی

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

تحلیل علت ریشه‌ای معمولاً پس از وقوع یک حادثه واقعی آغاز می‌شود و با استفاده از شواهد، نشانه‌های آشکار را از علت‌های فنی و سازمانی زیربنایی جدا می‌کند. مدل‌سازی مارکوف بر حالت‌های سیستم و نرخ جابه‌جایی سیستم بین آن‌ها تمرکز دارد. این روش به‌ویژه زمانی سودمند است که تعمیر، عملکرد آماده‌به‌کار، عملکرد تنزل‌یافته و پوشش تشخیصی تأثیر زیادی بر دسترس‌پذیری داشته باشند.

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

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

تحلیل درخت خطا با پیامد آغاز می‌شود

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

توصیف یک رویداد رأس صرفاً با عبارت «خرابی سیستم» معمولاً بیش از حد مبهم است. این عبارت مشخص نمی‌کند کدام عملکرد از کار افتاده، خرابی چه مدت ادامه داشته یا کدام وضعیت عملیاتی برقرار بوده است. تعریف بهتر می‌تواند این باشد: «از دست رفتن جریان کامل آب سرمایش برای بیش از شصت ثانیه در طول تولید عادی.» این عبارت، مرز روشنی برای تحلیل فراهم می‌کند.

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

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

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

تدوین درخت خطا گام‌به‌گام

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

سپس تیم، علل مستقیم را شناسایی می‌کند. از دست رفتن کامل سرمایش ممکن است به این دلیل رخ دهد که همهٔ پمپ‌ها از دسترس خارج شوند، هدر تأمین مشترک مسدود شود یا شیرهای جداسازی به‌اشتباه بسته شوند. هر علت مستقیم بیشتر تجزیه می‌شود. از دسترس خارج شدن پمپ ممکن است ناشی از خرابی موتور، گیرپاژ یاتاقان، از دست رفتن مکش، خرابی کنترل‌کننده یا قطع منبع برق باشد.

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

FTA کمی، احتمال رویدادها را بر اساس ساختار گیت‌ها با یکدیگر ترکیب می‌کند. محاسبه ممکن است ساده به نظر برسد، اما فرض‌های استقلال به بررسی دقیق نیاز دارند. دو رویدادی که منبع تغذیه، محیط، فعالیت تعمیرونگهداری یا نقص نرم‌افزاری یکسانی دارند، کاملاً مستقل نیستند. نادیده گرفتن این روابط می‌تواند باعث شود یک طراحی افزونه بسیار ایمن‌تر از واقعیت به نظر برسد.

مجموعه‌های برش کمینه خطرناک‌ترین ترکیب‌ها را نشان می‌دهند

مجموعه برش ترکیبی از رویدادهای پایه است که رویداد رأس را ایجاد می‌کند. مجموعه برش کمینه هیچ رویداد غیرضروری ندارد؛ یعنی حذف هر یک از رویدادها مانع وقوع رویداد رأس می‌شود. این ترکیب‌ها به مهندسان کمک می‌کنند کوتاه‌ترین و مهم‌ترین مسیرهای خرابی را شناسایی کنند. این مجموعه‌ها به‌ویژه زمانی ارزشمندند که یک درخت خطای بزرگ شامل صدها رویداد باشد.

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

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

نرم‌افزار FTA می‌تواند مجموعه‌های برش را بر اساس سهم محاسبه‌شده رتبه‌بندی کند. بااین‌حال، مهندسان همچنان باید معنای فیزیکی پشت این اعداد را بررسی کنند. یک احتمال از نظر ریاضی کوچک ممکن است بر فرض‌های ضعیف یا داده‌های عمومی مبتنی باشد که با نصب واقعی مطابقت ندارند. قضاوت مهندسی در سراسر تحلیل همچنان ضروری است.

مثال: افزونگی آب تغذیه بویلر که واقعاً مستقل نیست

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

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

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

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

تحلیل درخت خطا کجا به‌خوبی عمل می‌کند—و کجا نه

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

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

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

بنابراین، FTA زمانی بیشترین اثربخشی را دارد که به‌عنوان بخشی از یک برنامه گسترده‌تر قابلیت اطمینان به کار رود. FMEA می‌تواند حالات خرابی جزئی و دقیق اجزا را ارائه دهد، در حالی که روش‌های مارکوف یا مونت‌کارلو می‌توانند تعمیر، توالی رخدادها و عدم‌قطعیت را بررسی کنند. هیچ درختی نباید بازنمایی کاملی از تمام رفتارهای سیستم در نظر گرفته شود.

تحلیل حالات خرابی و آثار آن از جزء آغاز می‌شود

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

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

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

شکل ۳. FMEA حالت‌های خرابی منفرد، آثار آن‌ها، شدتشان و کنترل‌های موجود برای پیشگیری یا کشف آن‌ها را ارزیابی می‌کند.

یک کاربرگ مؤثر FMEA باید شامل چه مواردی باشد

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

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

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

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

مثال: ورودی‌های افزونه PLC با یک ضعف مشترک

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

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

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

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

FMEA طراحی و FMEA فرایند ریسک‌های متفاوتی را پوشش می‌دهند

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

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

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

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

FMECA ارزیابی رسمی‌تری از بحرانی‌بودن ارائه می‌دهد

تحلیل حالات خرابی، آثار و بحرانی‌بودن (FMECA) با افزودن محاسبات رسمی بحرانی‌بودن، ساختار FMEA را گسترش می‌دهد. این روش ممکن است از نرخ‌های خرابی قطعات، میزان مواجهه با شرایط کاری، مراحل مأموریت، دسته‌بندی‌های شدت و احتمالات شرطی استفاده کند. این روش زمانی مفید است که یک سامانه بزرگ شامل حالات خرابی متعددی باشد و منابع مهندسی باید به سمت مهم‌ترین عوامل مؤثر هدایت شوند.

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

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

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

FMEA کجا به‌خوبی عمل می‌کند—و کجا ممکن است گمراه‌کننده باشد

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

این روش هنگام استفاده برای سیستم‌های بسیار بزرگ می‌تواند تکراری شود. تیم‌ها ممکن است زمان زیادی را صرف مستندسازی حالت‌های خرابی کم‌ارزش کنند و در همین حال تعاملات سیستم را نادیده بگیرند. FMEA سنتی همچنین معمولاً هر بار یک خرابی را بررسی می‌کند. خرابی‌های هم‌زمان متعدد و رویدادهای وابسته به توالی ممکن است به‌وضوح آشکار نشوند.

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

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

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

محاسبات قابلیت اطمینان صنعتی اغلب شامل ورودی‌های نامطمئن هستند. طول عمر قطعه متغیر است، مدت تعمیر تغییر می‌کند، تحویل قطعات یدکی قابل پیش‌بینی نیست و تنش‌های محیطی بر رفتار خرابی اثر می‌گذارند. یک مقدار میانگین واحد همیشه نمی‌تواند این تغییرات را نشان دهد. شبیه‌سازی مونت‌کارلو از طریق نمونه‌گیری تصادفی مکرر به این مشکل می‌پردازد.

مهندس ابتدا یک مدل سیستم می‌سازد و به متغیرهای نامطمئن، توزیع‌های احتمالی اختصاص می‌دهد. سپس شبیه‌سازی ترکیب‌های ممکن بسیاری را تولید می‌کند. در یک اجرا ممکن است فرض شود که یک پمپ پس از ۸٬۰۰۰ ساعت خراب می‌شود و ظرف چهار ساعت تعمیر می‌شود. در اجرای دیگری ممکن است خرابی دیرتر رخ دهد، اما تعمیر به دلیل در دسترس نبودن قطعه یدکی موردنیاز بسیار طولانی‌تر شود.

پس از هزاران یا میلیون‌ها اجرا، نتایج یک توزیع تشکیل می‌دهند. مدل می‌تواند زمان مورد انتظار ازکارافتادگی، کاهش تولید، دسترس‌پذیری سیستم، احتمال موفقیت مأموریت، تقاضای قطعات یدکی یا هزینه نگهداری را برآورد کند. همچنین می‌تواند احتمال نتایج شدید را نشان دهد؛ نتایجی که در یک مقدار میانگین ناپدید می‌شوند.

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

ساخت یک مدل معتبر قابلیت اطمینان مونت‌کارلو

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

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

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

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

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

توزیع نمایی نرخ خرابی ثابتی را فرض می‌کند. این توزیع می‌تواند برای برخی قطعات الکترونیکی در طول عمر عملیاتی مفیدشان مناسب باشد. توزیع ویبول انعطاف‌پذیرتر است و می‌تواند خرابی‌های اوایل عمر، خرابی‌های تصادفی یا رفتار فرسودگی را نشان دهد. توزیع‌های لگ‌نرمال اغلب برای مدت‌زمان تعمیر و فرایندهایی که تحت تأثیر چندین عامل ضرب‌شونده قرار دارند، مفید هستند.

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

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

داده‌های محدود مانع تحلیل نمی‌شوند، اما عدم‌قطعیت باید همچنان آشکار بماند. قضاوت کارشناسی، اطلاعات تأمین‌کنندگان و پایگاه‌های داده صنعتی می‌توانند از برآوردهای اولیه پشتیبانی کنند. مدل باید دامنه‌ای واقع‌بینانه را آزمایش کند، نه اینکه یک فرض نامطمئن را به‌عنوان واقعیتی دقیق ارائه دهد.

مثال: دسترس‌پذیری یک ایستگاه سه‌کمپرسوره

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

تحویل یاتاقان‌های یدکی چند روز طول می‌کشد و خرابی‌های سامانه خنک‌کاری در دماهای بالای محیطی بیشتر می‌شوند. نمایش این تعاملات با یک معادله ساده دسترس‌پذیری دشوار است. یک مدل مونت‌کارلو می‌تواند خرابی کمپرسورها، مدت تعمیر، دوره‌های آب‌وهوایی، دسترس‌پذیری تکنسین‌ها و تأخیرهای لجستیکی را نمونه‌برداری کند.

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

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

شبیه‌سازی مونت‌کارلو کجا عملکرد خوبی دارد—و کجا شکست می‌خورد

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

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

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

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

تحلیل علل ریشه‌ای پس از وقوع رویداد آغاز می‌شود

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

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

بنابراین، تحلیل علل ریشه‌ای نشانه‌ها، علل فیزیکی مستقیم، شرایط مؤثر و ضعف‌های زیربنایی سیستم را از یکدیگر جدا می‌کند. این تمایز مانع از آن می‌شود که سازمان هر تعمیر را راه‌حلی دائمی تلقی کند. همچنین شواهدی فراهم می‌کند که می‌تواند FMEA، FTA، برنامه‌ریزی نگهداری و روش‌های بهره‌برداری آینده را بهبود دهد.

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

شواهد باید پیش از بازگشت کارخانه به شرایط عادی حفظ شوند

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

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

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

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

ساخت خط زمانی رویداد پیش از پرسیدن «چرا»

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

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

پس از درک توالی رویدادها، تیم می‌تواند از ابزارهایی مانند پنج چرا، نمودارهای استخوان ماهی، تحلیل موانع، تحلیل تغییرات یا نمودارهای عوامل علّی استفاده کند. رویدادهای ساده را می‌توان با یک زنجیره علّی کوتاه توضیح داد. حوادث پیچیده معمولاً شامل چندین وضعیت فنی و سازمانیِ به‌هم‌پیوسته هستند.

تحقیق نباید پس از یافتن یک توضیح محتمل متوقف شود. فرضیه‌های جایگزین باید با شواهد آزموده شوند. فرض‌های تأییدنشده باید همچنان به‌عنوان فرض شناسایی شوند، نه اینکه به‌عنوان علل قطعی ارائه شوند.

مثال: خرابی‌های مکرر درایو سرعت‌متغیر

در یک کارخانه، درایو سرعت‌متغیرِ کنترل‌کننده یک نوار نقاله بارها از کار می‌افتد. واحد نگهداری پس از هر رویداد درایو را تعویض می‌کند و تولید به حالت عادی بازمی‌گردد. چند ماه بعد، درایو دیگری از کار می‌افتد. تعویض‌های مکرر نشان می‌دهد که خود درایو ممکن است تمام مشکل نباشد.

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

سوابق نگهداری نشان می‌دهد که پس از تغییر سطح نیروی انسانی، تمیزکاری منظم فیلتر از برنامه نگهداری پیشگیرانه حذف شده است. درایو قطعه‌ای است که از کار افتاده، اما دمای بیش‌ازحد کابینت علت فیزیکی مستقیم است. تهویه محدود و حذف وظیفه نگهداری، عوامل مؤثر و علل سازمانی هستند.

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

اقدامات اصلاحی باید به علل تأییدشده مرتبط باشند

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

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

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

تحقیقات جدی ممکن است به بررسی مستقل نیاز داشته باشند. تیم‌هایی که از نزدیک درگیر رویداد بوده‌اند، ممکن است تحت‌تأثیر فرض‌های قبلی یا فشار سازمانی قرار گیرند. بررسی بیرونی یا بین‌وظیفه‌ای می‌تواند پیش از پذیرفته شدن نتیجه‌گیری‌های نهایی، تحلیل را به چالش بکشد.

خطای انسانی به‌ندرت علت ریشه‌ای کاملی است

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

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

درک این شرایط، مسئولیت‌پذیری فردی را از بین نمی‌برد. بلکه مانع می‌شود همان سیستم فرد دیگری را به سمت همان اشتباه سوق دهد. تحقیقاتی که بر سرزنش متمرکزند ممکن است نیاز فوری به تعیین مسئولیت را برآورده کنند، اما ضعف زیربنایی را برطرف نمی‌کنند.

RCA مؤثر بررسی می‌کند که سیستم چگونه تصمیم‌گیری را شکل داده است. این فرایند می‌پرسد آیا هشدارها قابل‌درک بودند، رویه‌ها عملی بودند، حجم کار معقول بود و ابزارهای موردنیاز در دسترس بودند یا نه. این پرسش‌ها در مقایسه با صرفاً توصیه به افراد برای دقت بیشتر، اقدامات اصلاحی مؤثرتری ایجاد می‌کنند.

تجزیه‌وتحلیل علت ریشه‌ای کجا به‌خوبی کار می‌کند—و کجا کار نمی‌کند

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

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

بررسی‌ها همچنین ممکن است ذهنی شوند. سوگیری تأییدی می‌تواند تیم‌ها را به ترجیح نخستین توضیحی که با شواهد سازگار است سوق دهد. نبود شواهد ممکن است نتیجه‌گیری‌ها را نامطمئن نگه دارد. گزارش‌های قوی، علل تأییدشده، عوامل مؤثر، فرضیه‌ها و پرسش‌های حل‌نشده را به‌روشنی از هم جدا می‌کنند.

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

مدل‌های مارکوف سیستم را در میان وضعیت‌های متغیر دنبال می‌کنند

مدل‌سازی مارکوف، سیستم را از طریق وضعیت‌های عملیاتی تعریف‌شده نمایش می‌دهد. یک سیستم ساده ممکن است فقط شامل وضعیت عملیاتی و وضعیت خراب باشد. یک سیستم تحمل‌پذیر در برابر خطا معمولاً به وضعیت‌های بیشتری مانند کاملاً افزونه، تنزل‌یافته، خراب، در حال تعمیر یا در انتظار قطعه یدکی نیاز دارد. انتقال‌ها این وضعیت‌ها را به هم متصل می‌کنند.

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

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

شکل ۶. مدل‌های مارکوف چگونگی جابه‌جایی سیستم‌ها میان وضعیت‌های سالم، تنزل‌یافته، خراب و تعمیرشده را توصیف می‌کنند.

مدل دومرحالتی اصل پایه را ارائه می‌دهد

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

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

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

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

مثال: یک جفت کنترل‌کننده افزونه دوگانه

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

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

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

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

تجهیزات آماده‌به‌کار به چیزی بیش از یک حالت خرابی فعال نیاز دارند

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

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

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

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

فرض مارکوف هم سادگی ایجاد می‌کند و هم محدودیت

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

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

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

مدل باید جزئیات کافی برای پشتیبانی از تصمیم داشته باشد، بدون اینکه هر تغییر فیزیکی را نمایش دهد. پیچیدگی بیش از حد، مشکلات نگهداری و اعتبارسنجی ایجاد می‌کند. مدل بیش از حد ساده رفتارهای مهم را پنهان می‌کند، در حالی که توضیح مدل بیش از حد جزئیات‌دار ناممکن می‌شود.

مدل‌سازی مارکوف کجا به‌خوبی عمل می‌کند—و کجا نه

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

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

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

مدل‌های مارکوف ابزارهای تحلیلی هستند، نه اثبات فیزیکی. آزمون‌ها، شواهد عملیاتی، FMEA و FTA همچنان ضروری‌اند. مدل به مقایسه راهبردها کمک می‌کند، اما نمی‌تواند جایگزین راستی‌آزمایی معماری واقعی شود.

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

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

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

فرض کنید یک FTA دو خرابی کنترلر را مستقل در نظر بگیرد. بعداً یک RCA نشان می‌دهد که هر دو کنترلر پس از آنکه یک تکنسین تعمیر و نگهداری همان پیکربندی نادرست را بارگذاری کرده، از کار افتاده‌اند. درخت خطا باید یک رویداد مشترکِ تعمیر و نگهداری را اضافه کند. مدل‌های مارکوف و مونت‌کارلو نیز باید وابستگی جدید را دربر بگیرند.

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

خرابی‌های ناشی از علت مشترک می‌توانند کل معماری افزونه را از کار بیندازند

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

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

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

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

پوشش تشخیصی تعیین می‌کند سیستم چه مدت آسیب‌پذیر باقی می‌ماند

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

ادعاهای مربوط به تشخیص باید با دقت بررسی شوند. یک کنترل‌کننده ممکن است خرابی‌های داخلی پردازنده را شناسایی کند، اما نتواند همه خرابی‌های سیم‌کشی میدان را تشخیص دهد. یک ماژول ارتباطی ممکن است قطع کامل لینک را شناسایی کند، اما نتواند نگاشت نادرست داده‌ها را تشخیص دهد. یک منبع تغذیه ممکن است پس از قطع کامل خروجی هشدار دهد، اما هیچ هشداری درباره افت تدریجی عملکرد ارائه نکند.

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

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

زمان تعمیر اغلب به‌اندازه نرخ خرابی اهمیت دارد

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

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

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

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

به‌کارگیری تحلیل قابلیت اطمینان در معماری‌های DCS و PLC

قابلیت اطمینان سامانه کنترل فقط به پردازنده مرکزی وابسته نیست. مهندسان باید کنترل‌کننده‌ها، ماژول‌های ورودی/خروجی، شبکه‌های ارتباطی، منابع تغذیه، سرورها، ایستگاه‌های اپراتوری، هم‌زمان‌سازی زمانی، رابط‌های میدان و تأسیسات پشتیبان را بررسی کنند. هر عنصر مشترک می‌تواند به یک وابستگی مشترک تبدیل شود.

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

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

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

مدل‌های قابل‌اعتماد به داده‌های نگهداری قابل‌اعتماد وابسته‌اند

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

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

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

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

یک گردش‌کار عملی برای بهبود قابلیت اطمینان

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

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

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

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

پرسش‌هایی که ادعاهای ضعیف درباره تحمل‌پذیری خطا را آشکار می‌کنند

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

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

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

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

چشم‌انداز نهایی

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

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

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

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