از هشدار تا دستور کار: نگهداری پیشگویانه در سیستم‌های آلن-بردلی و وودوارد
چگونه عیب‌یابی PLC و SCADA را بدون ایجاد اختلال در کنترل، به نگهداری قابل‌اعتماد تبدیل کنیم.
سیگنال از قبل در لایه کنترل وجود دارد
یک PLC اغلب در حالی به کار خود ادامه می‌دهد که وضعیت سلامت آن رو به وخامت است. ابتدا تاریخچه عیب‌یابی را بررسی کنید، نه صفحه شبیه‌سازی را. وقفه‌های ارتباطی به‌تدریج بیشتر می‌شوند. یک ماژول I/O از راه دور، خطاهای مقطعی را گزارش می‌کند. در لایه SCADA، قطع و وصل‌ها پیش از هر توقف تولید تکرار می‌شوند. این‌ها هشدارهای اولیه‌اند، نه نویز. کنترلرهای مدرن از قبل این داده‌ها را ارائه می‌کنند. همیشه به یک شبکه حسگر جدید نیاز ندارید. بخش دشوار، اختصاص دادن مقصدی مفید به هر سیگنال است. این مقصد باید یک سابقه نگهداری مرتبط با یک تجهیز واقعی باشد.
مرحله 1 — وضعیت‌های واقعی سلامت کنترلر را استخراج کنید
منطق پیش‌بینانه باید از سیگنال‌هایی استفاده کند که دستگاه واقعاً پشتیبانی می‌کند. فرض نکنید هر PLC داده‌های سلامت یکسانی ارائه می‌دهد. در سیستم‌های Allen-Bradley ControlLogix (مانند پردازنده Allen-Bradley ControlLogix) یا CompactLogix، شمارنده‌های خطای پورت EtherNet/IP را در کارت‌های ارتباطی مانند ماژول ارتباطی 1756 ControlLogix بررسی کنید. تعداد خطاهای قابل‌بازیابی را برای هر ایستگاه از راه دور دنبال کنید. در یک کنترلر Woodward که از طریق Modbus TCP قابل دسترسی است (در سیستم‌های مانیتورینگ با ماژول‌های I/O وودوارد)، رجیسترهای نیازمند نگهداری و محدودیت عمر را پایش کنید. برخی دستگاه‌ها خطاهای داخلی یا تغذیه غیرعادی را مستقیماً گزارش می‌کنند.
مرحله 1 — همه عیب‌یابی‌هایی را که دستگاه هدف واقعاً ارائه می‌دهد فهرست کنید.
مرحله 2 — شمارنده‌ها را هر هفته روندیابی کنید، زیرا تکرار بهتر از یک رویداد منفرد فرسودگی را آشکار می‌کند.
مرحله 3 — فقط بر اساس شیب صعودی یا مدت‌زمان هشدار دهید، نه یک نوسان لحظه‌ای.
مرحله 4 — هر شمارنده را به یک تجهیز دارای تگ مشخص مرتبط کنید، نه یک رک عمومی.
مرحله 2 — هر هشداری را به تیکت تبدیل نکنید
SCADA توجه اپراتور را جلب می‌کند. واحد نگهداری تصمیم می‌گیرد چه کسی برای تعمیر اقدام کند. اشتباه گرفتن این دو، فرسودگی واقعی را زیر انبوه تیکت‌های بی‌ارزش پنهان می‌کند. هشدار دمای بالا ممکن است فقط رفتار عادی تولید باشد. یک قطع کوتاه نیز ممکن است خودبه‌خود برطرف شود. بنابراین، پیش از ایجاد درخواست کار، وضعیت را ارزیابی کنید. تکرار از یک رویداد منفرد مهم‌تر است. مدت‌زمان نیز اغلب از شدت اوج اهمیت بیشتری دارد. یک انحراف آهسته زیر حد هشدار هم می‌تواند شایسته بررسی باشد. علاوه بر این، تأیید دریافت را از تکمیل کار جدا نگه دارید. اپراتور با تأیید، فقط اعلام می‌کند که خطا دیده شده است. این موضوع ثابت نمی‌کند که تجهیز تعمیر شده است.
مرحله 1 — قانونی اضافه کنید که برای ایجاد درخواست کار، به سه تکرار در هفت روز نیاز داشته باشد.
مرحله 2 — زمینه را پیوست کنید: تجهیز، روند و تعمیرات قبلی.
مرحله 3 — تیکت را فقط پس از انجام و ثبت کار ببندید.
سابقه تعمیر، مدل را دقیق‌تر می‌کند
داده‌های Historian نشان می‌دهند پیش از خطا چه اتفاقی افتاده است. سابقه نگهداری نشان می‌دهد پس از بررسی توسط فرد مسئول چه رخ داده است. فرض کنید یک خطای ارتباطی مرتباً تیکت ایجاد می‌کند. تکنسین‌ها هر بار هیچ نقص سخت‌افزاری پیدا نمی‌کنند. احتمالاً محرک بیش از حد حساس تنظیم شده است. با این حال، اگر همین رویداد همیشه به تعویض یک کانکتور منجر می‌شود، به این الگو اعتماد کنید. این وضعیت شایسته توجه زودتر است. کار تکمیل‌شده، نشانه را از علت جدا می‌کند. یک خطای کاذب I/O ممکن است در واقع به تجهیز میدانی‌ای مربوط باشد که برق خود را از دست داده است. تعویض ماژول، تجهیز اشتباه را تعمیر می‌کند. یادداشت بستن کار، علت واقعی را برای شیفت بعدی حفظ می‌کند.
بدون ایجاد ریسک یکپارچه‌سازی کنید
یک CMMS نباید به کلاینتی با دسترسی ممتاز به سیستم کنترل تبدیل شود. عیب‌یابی را از طریق یک لایه داده به بیرون هدایت کنید. روند را از SCADA یا Historian دریافت کنید. برای اطلاعات استاندارد سلامت و عیب‌یابی، از OPC UA فقط‌خواندنی استفاده کنید. سپس یک سرویس یکپارچه‌سازی، رویدادهای ارزیابی‌شده را از طریق API به پلتفرم نگهداری منتقل کند. این کار ترافیک نگهداری را از منطق حساس به زمان دور نگه می‌دارد. محاسبات پیش‌بینانه نیازی ندارند داخل کنترلر اجرا شوند. علاوه بر این، از شبکه محافظت کنید. یک برنامه نگهداری به‌ندرت باید در حافظه PLC بنویسد. دسترسی آن را به حالت فقط‌خواندنی محدود کنید. پیش از رسیدن هر پیوند خودکار به محیط تولید، فرایند کنترل تغییرات کارخانه را دنبال کنید. در نهایت، ساعت‌ها را تنظیم کنید. رویداد SCADA که با فاصله چند دقیقه از رکورد CMMS ثبت شده باشد، بازسازی خطا را مختل می‌کند.
نتیجه‌گیری & توصیه عملی
نگهداری پیش‌بینانه به صبر و جریان داده پاک پاداش می‌دهد، نه داشبوردهای هوشمندانه. ابتدا فقط وضعیت‌های سلامتی را استخراج کنید که دستگاه‌هایتان واقعاً ارائه می‌دهند. سپس، پیش از ایجاد تیکت، وضعیت را با تکرار و مدت‌زمان ارزیابی کنید. علاوه بر این، اجازه دهید سابقه تعمیر تأییدشده، محرک‌های شما را به‌مرور آموزش دهد. با این حال، هرگز اجازه ندهید CMMS در منطق کنترل بنویسد یا کنترل تغییرات را دور بزند. بنابراین، مسیری فقط‌خواندنی از طریق Historian و OPC UA با زمان همگام‌سازی‌شده ایجاد کنید. در نهایت، زیرساخت کنترل را نیز به‌عنوان تجهیزی قابل نگهداری در نظر بگیرید. این هفته با یک پیوند حیاتی EtherNet/IP شروع کنید. پیش از گسترش در سراسر کارخانه، عملکرد چرخه را از ابتدا تا انتها اثبات کنید.
نویسنده: سان ییفی مهندس اتوماسیون صنعتی است و بیش از 10 سال تجربه در زمینه PLC، DCS و سیستم‌های کنترل دارد.
