کاهش عملکرد SCADA در تغییر شیفت: تشخیص افزایش همزمان بار روی GE HMI و Honeywell Experion

Alarm Management, DCS, GE Proficy iFIX, HMI Performance, Honeywell Experion PKS, Industrial Automation, Root Cause Analysis, SCADA, Shift Change
آوریل 13، 2026

SCADA Performance Collapse at Shift Change: Diagnosing the Concurrent Load Spike on GE HMI and Honeywell Experion

علت مشکل: فریز شدن SCADA فقط در زمان تحویل شیفت

اپراتورها گزارش می‌دهند که سیستم SCADA در هنگام تغییر شیفت پاسخگو نیست. صفحات گرافیکی به کندی بارگذاری می‌شوند. تأیید هشدارها ۵ تا ۱۰ ثانیه طول می‌کشد. مقادیر تگ‌ها در نمایش‌های روند به طور موقت ثابت می‌مانند. PLC به طور عادی به کار خود ادامه می‌دهد. ابزارهای میدانی مقادیر صحیح را نشان می‌دهند. این فریز پس از ۱۵ تا ۲۰ دقیقه خود به خود برطرف می‌شود.

این الگو نشان‌دهنده افزایش بار در سمت سرور است، نه مشکل در ارتباط با تجهیزات میدانی. سیستم GE HMI Proficy iFIX و Honeywell Experion PKS هر دو این مشکل را زمانی تجربه می‌کنند که چندین رویداد همزمان در مرز شیفت رخ می‌دهند. درک هر رویداد به جدا کردن علت اصلی کمک می‌کند.

علت اصلی ۱: راه‌اندازی همزمان ایستگاه‌های کاری و اشتراک مجدد تگ‌ها

در تغییر شیفت، اپراتور خروجی برنامه SCADA را می‌بندد. اپراتور ورودی آن را تازه اجرا می‌کند. در GE HMI Proficy iFIX، هر راه‌اندازی مجدد ایستگاه کاری باعث دانلود کامل اشتراک تگ‌ها از سرور SCADA می‌شود. اگر ۸ ایستگاه کاری در بازه ۲ دقیقه‌ای راه‌اندازی شوند، سرور ۸ درخواست اشتراک همزمان را پردازش می‌کند.

هر اشتراک شامل پرس‌وجوی پایگاه داده، جستجوی تگ و تنظیم مسیر داده‌های زمان واقعی است. سرویس GE Proficy Cim-Manager این درخواست‌ها را مدیریت می‌کند. در بار سنگین، عمق صف از حد بافر فراتر می‌رود. درخواست‌های جدید در صف منتظر می‌مانند. این تأخیر به صورت بارگذاری کند گرافیک در سمت کلاینت ظاهر می‌شود.

راهکار: ایستگاه‌های کاری را طوری تنظیم کنید که به جای راه‌اندازی کامل، برنامه را از حالت تعلیق ادامه دهند. در Proficy iFIX، گزینه Auto-Resume را در خصوصیات فضای کاری iFIX فعال کنید. این کار اشتراک‌های تگ موجود را مجدداً استفاده می‌کند و از بازسازی کامل جلوگیری می‌کند. زمان راه‌اندازی از ۴۵ ثانیه به کمتر از ۱۰ ثانیه کاهش می‌یابد.

علت اصلی ۲: انفجار تأیید هشدارها و طوفان نوشتن در پایگاه داده

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

در Honeywell Experion PKS، رویدادهای هشدار در پایگاه داده هشدار (ADB) نوشته می‌شوند. هر نوشتن نیاز به به‌روزرسانی ایندکس دارد. در بار انفجاری، صف به‌روزرسانی ایندکس سریع‌تر از توان ورودی/خروجی دیسک رشد می‌کند. سرور هشدار Experion با تأخیر بیشتر پاسخ می‌دهد. پنجره‌های هشدار با تأخیر ۳ تا ۵ ثانیه ظاهر می‌شوند. کارت‌های ماژول کنترلر Honeywell و قطعات سیستم C300 ما برای حفظ پایداری در این شرایط بار طراحی شده‌اند.

در GE Proficy iFIX، تأیید هشدارها از طریق SCU (ابزار پیکربندی سیستم) در پایگاه داده تاریخی نوشته می‌شوند. اگر پایگاه داده تاریخی روی همان سرور باشد، رقابت ورودی/خروجی دیسک تشدید می‌شود. Proficy Process Historian ممکن است در این بازه داده‌ها را از دست بدهد.

راهکار: قبل از پایان شیفت، قابلیت قفسه‌بندی هشدارها را برای هشدارهای کم‌اولویت فعال کنید. در Experion PKS، این ویژگی را در تب پیکربندی هشدار تنظیم کنید. تا ۵۰٪ هشدارهای کم‌اولویت تأیید نشده را قفسه‌بندی کنید. این کار انفجار تأیید را با حذف رویدادهای غیر بحرانی کاهش می‌دهد.

علت اصلی ۳: تولید خودکار گزارش شیفت و بار زیاد پرس‌وجو

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

اگر موتور تولید گزارش روی سرور SCADA اجرا شود، با عملیات زمان واقعی برای منابع CPU و دیسک رقابت می‌کند. یک پرس‌وجوی گزارش شیفت معمولی در GE Proficy Process Historian بین ۸ تا ۱۲ ثانیه طول می‌کشد. در این بازه، ظرفیت سرور SCADA برای به‌روزرسانی تگ‌ها و پردازش هشدار کاهش می‌یابد.

در Honeywell Experion PKS، ایستگاه کاری گزارش‌ها از طریق سرور گزارش Experion گزارش‌ها را تولید می‌کند. اگر ایستگاه کاری گزارش‌ها روی همان سرور برنامه Experion باشد، بار پرس‌وجو عملکرد زمان واقعی را کاهش می‌دهد. مانیتور سلامت سرور نشان می‌دهد استفاده CPU در زمان تولید گزارش به ۸۵ تا ۹۵٪ می‌رسد.

راهکار: گزارش‌های شیفت را طوری زمان‌بندی کنید که ۱۰ دقیقه پس از تغییر شیفت اجرا شوند، نه دقیقاً در زمان تحویل. این کار پرس‌وجوی گزارش را از انفجار تأیید هشدار جدا می‌کند. زمان‌بندی را در Experion Report Designer یا زمان‌بند گزارش Proficy Process Historian بررسی کنید.

روش تشخیص گام به گام

وقتی فریز رخ می‌دهد، فوراً داده‌های تشخیصی را جمع‌آوری کنید. تا شیفت بعدی صبر نکنید.

گام ۱: مدیر وظایف ویندوز را روی سرور SCADA باز کنید. استفاده CPU، حافظه و طول صف دیسک را ثبت کنید. مشخص کنید که گلوگاه CPU، RAM یا ورودی/خروجی دیسک است.
گام ۲: رویدادهای ویندوز را برای خطاهای نوشتن پایگاه داده یا تایم‌اوت سرویس بررسی کنید. به دنبال شناسه رویداد ۸۳۳ (تاخیر پایگاه داده) در لاگ‌های Experion یا شناسه رویداد ۴۰۹۶ در لاگ‌های Proficy iFIX باشید.
گام ۳: تعداد اشتراک‌های تگ SCADA را مرور کنید. در Experion PKS، از Station Manager برای نمایش آمار اشتراک‌های فعال استفاده کنید. در GE Proficy iFIX، از صفحه تشخیص سیستم برای بررسی عمق صف Cim-Manager استفاده کنید.
گام ۴: الگوی انفجار تأیید هشدار را در لاگ هشدار بررسی کنید. تعداد تأییدهای هشدار را در بازه ۵ دقیقه‌ای اطراف تغییر شیفت بشمارید. اگر تعداد بیش از ۵۰ در دقیقه باشد، طوفان نوشتن پایگاه داده علت اصلی است.
گام ۵: برنامه زمان‌بندی تولید گزارش را بررسی کنید. به دنبال گزارش‌هایی باشید که برای شروع در زمان تغییر شیفت تنظیم شده‌اند. زمان شروع را ۱۰ تا ۱۵ دقیقه به تعویق بیندازید تا همپوشانی کاهش یابد.

نتیجه‌گیری و توصیه‌های عملی

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

در GE HMI Proficy iFIX، Auto-Resume را فعال کنید تا بازسازی کامل اشتراک‌ها حذف شود. در Honeywell Experion PKS، قفسه‌بندی هشدارها را فعال کرده و گزارش‌ها را ۱۰ دقیقه پس از تغییر شیفت زمان‌بندی مجدد کنید. هر دو پلتفرم از انتقال پایگاه داده تاریخی به سرور اختصاصی بهره‌مند می‌شوند. این کار پردازش تگ‌های زمان واقعی را از بار پرس‌وجوی گزارش جدا می‌کند. ماژول‌های ورودی/خروجی Honeywell قابل اعتماد تضمین می‌کنند که صحت داده‌های میدانی حتی در زمان افزایش بار سرور حفظ شود.

یافته‌های تشخیصی را در سیستم مدیریت نگهداری و تعمیرات (CMMS) کارخانه مستند کنید. یک روش عملکرد تغییر شیفت ایجاد کنید که سه رویداد بار را در بازه ۳۰ دقیقه‌ای توزیع کند. نتایج را به مدت دو هفته پایش کنید. اگر استفاده CPU در زمان تغییر شیفت هنوز بیش از ۸۰٪ بود، ارتقای سرور SCADA یا افزودن سرور دوم برای توزیع بار را در نظر بگیرید.