Колапс на производителността на SCADA при смяна на смяна: Диагностика на едновременния пик на натоварване върху GE HMI и Honeywell Experion

Симптомът: SCADA замръзва само по време на смяна

Операторите съобщават, че SCADA системата става неотзивчива по време на смяна на смяната. Графичните страници се зареждат бавно. Потвържденията на аларми отнемат 5–10 секунди. Стойностите на таговете замръзват за момент на дисплеите с тенденции. PLC продължава да работи нормално. Полевите уреди показват правилни стойности. Замръзването се разрешава само след 15–20 минути.

Този модел сочи към пиково натоварване на сървъра, а не към проблем с комуникацията на полето. Системите GE HMI Proficy iFIX и Honeywell Experion PKS изпитват този проблем, когато няколко събития се сблъскат на границата на смяната. Разбирането на всяко събитие помага да се изолира доминиращата причина.

Основна причина 1: Паралелен рестарт на работна станция и повторно абониране за тагове

При смяна на смяната, операторът, който излиза, затваря SCADA приложението. Влизащият оператор го стартира наново. В GE HMI Proficy iFIX всеки рестарт на работна станция задейства пълно изтегляне на абонаментите за тагове от SCADA сървъра. Ако 8 работни станции рестартират в рамките на 2 минути, сървърът обработва 8 паралелни заявки за абонамент.

Всеки абонамент включва заявка към базата данни, търсене на тагове и настройка на маршрутизацията на реалновременни данни. Услугата GE Proficy Cim-Manager обработва тези заявки. При голямо натоварване дълбочината на опашката надвишава буферния лимит. Новите заявки за абонамент чакат в опашката. Забавянето се проявява като бавно зареждане на графики на клиентската страна.

Мерки за смекчаване: Конфигурирайте работните станции да използват възобновяване на приложението вместо пълен рестарт. В Proficy iFIX задайте опцията Auto-Resume в свойствата на работното пространство iFIX. Това използва съществуващите абонаменти за тагове, вместо да ги изгражда наново. Времето за стартиране намалява от 45 секунди до под 10 секунди.

Основна причина 2: Взрив на потвърждения на аларми и буря от записи в базата данни

По време на предаване, операторът, който излиза, потвърждава натрупаните аларми. Типична смяна генерира 200–400 алармени събития. Ако 80% остават непотвърдени, влизащият оператор ги потвърждава на партида. Всяко потвърждение генерира транзакция в базата данни, записваща името на оператора, времевия печат, ID на алармата и коментар.

В Honeywell Experion PKS алармените събития се записват в Алармената база данни (ADB). Всяко записване изисква актуализация на индекса. При взривно натоварване опашката за актуализация на индекса расте по-бързо, отколкото дисковият I/O може да обработи. Experion Alarm Server отговаря с увеличена латентност. Алармените изскачащи прозорци се появяват със забавяне от 3–5 секунди. Нашите Honeywell контролерни модулни карти и C300 системни компоненти са проектирани да поддържат стабилност при тези натоварвания.

В GE Proficy iFIX потвържденията на аларми се записват в историческата база данни чрез SCU (System Configuration Utility). Ако историкът е на същия сървър, конкуренцията за дисков I/O се влошава. Proficy Process Historian може да загуби данни през този период.

Мерки за смекчаване: Активирайте отлагане на нископриоритетни аларми преди края на смяната. В Experion PKS конфигурирайте функцията за отлагане на аларми в раздела за конфигурация на аларми. Отлагайте до 50% от непотвърдените нископриоритетни аларми. Това намалява взрива на потвърждения, като елиминира некритичните събития.

Основна причина 3: Автоматично генериране на отчети за смяна и претоварване на заявки

И двете SCADA платформи GE и Honeywell поддържат автоматично генериране на отчети в планирани часове. Често срещаните отчети за смяна включват общи производствени стойности, обобщения на престои, статистика за аларми и енергийна консумация. Тези отчети правят заявки към историческата база данни за хиляди точки данни.

Ако двигателят за генериране на отчети работи на SCADA сървъра, той се конкурира за CPU и дискови ресурси с реалновременните операции. Типична заявка за отчет за смяна в GE Proficy Process Historian отнема 8–12 секунди за изпълнение. През този период SCADA сървърът има намалена способност за обновяване на тагове и обработка на аларми.

В Honeywell Experion PKS, работната станция за отчети генерира отчети чрез Experion Reports Server. Ако работната станция за отчети споделя същия сървър с Experion Application Server, натоварването от заявките влошава реалновременната производителност. Мониторът за здравето на сървъра показва скок на използването на CPU до 85–95% по време на генериране на отчети.

Мерки за смекчаване: Насрочете отчетите за смяна да се изпълняват 10 минути след смяната, а не точно по време на предаването. Това отделя заявките за отчети от взрива на потвърждения на аларми. Проверете графика в Experion Report Designer или в планировчика на отчети на Proficy Process Historian.

Стъпка по стъпка диагностична процедура

Когато настъпи замръзване, съберете диагностични данни незабавно. Не чакайте следващата смяна.

• Стъпка 1: Отворете Windows Task Manager на SCADA сървъра. Запишете използването на CPU, паметта и дължината на опашката за диска. Определете дали тесният участък е CPU, RAM или дисков I/O.
• Стъпка 2: Проверете Windows Event Viewer за грешки при запис в базата данни или изтичане на време на услуги. Потърсете Event ID 833 (превишена латентност на базата данни) в логовете на Experion или Event ID 4096 в логовете на Proficy iFIX.
• Стъпка 3: Прегледайте броя на абонаментите за тагове в SCADA. В Experion PKS използвайте Station Manager за показване на статистики за активни абонаменти. В GE Proficy iFIX използвайте екрана System Diagnostics, за да проверите дълбочината на опашката на Cim-Manager.
• Стъпка 4: Прегледайте алармения лог за модел на взрив. Пребройте броя на потвържденията на аларми в рамките на 5-минутен прозорец около смяната. Ако броят надвишава 50 на минута, бурята от записи в базата данни е доминиращата причина.
• Стъпка 5: Проверете графика за генериране на отчети. Потърсете отчети, конфигурирани да започват по време на смяната. Изместете началния час с 10–15 минути, за да намалите припокриването.

Заключение и препоръки за действие

Колапсът на производителността на SCADA при смяна се дължи на три паралелни събития. Първо, работните станции рестартират и се абонират наново за всички тагове едновременно. Второ, операторите потвърждават на партида натрупаните аларми, генерирайки буря от записи в базата данни. Трето, автоматичните отчети за смяна правят заявки към историческата база данни в пиково натоварено време.

В GE HMI Proficy iFIX активирайте Auto-Resume, за да елиминирате пълното изграждане на абонаменти. В Honeywell Experion PKS активирайте отлагане на аларми и пренасрочете отчетите 10 минути след смяната. И двете платформи печелят от преместване на историческата база данни на отделен сървър. Това отделя реалновременната обработка на тагове от натоварването на заявките за отчети. Надеждните Honeywell I/O модули гарантират целостта на полевите данни дори при пикови натоварвания на сървъра.

Документирайте диагностичните резултати в CMMS на завода. Създайте процедура за производителност при смяна, която разпределя трите натоварващи събития в рамките на 30 минути. Наблюдавайте резултатите в продължение на две седмици. Ако използването на CPU все още надвишава 80% по време на смяна, обмислете ъпгрейд на SCADA сървъра или добавяне на втори сървър за разпределение на натоварването.