پنج روش قابلیت اطمینان برای تحلیل تحمل خطای صنعتی

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

تحلیل حالات خرابی و آثار آن با مؤلفه آغاز می‌شود

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

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

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

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

یک کاربرگ مؤثر تحلیل حالات خرابی و آثار آن باید چه مواردی را دربرگیرد

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

نگاه نهایی

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

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

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

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