Первая серия. Нюансы диагностики Scada-систем WinCC в Zabbix
Для управления производством мы в «Северстали» используем SCADA-системы, в частности, SIMATIC WinCC. Такие решения радуют своей универсальностью и мощью, они позволяют управлять процессами, производственными линиями, машинами и установками во всех промышленных секторах компании и отслеживать их работу. Но у WinCC есть и недостатки. Например, если использовать несколько SCADA-систем (а у нас их около тысячи!), то сложно настроить оперативный мониторинг их работоспособности. Это мешает быстро видеть и предупреждать проблемы. Но мы нашли выход — Zabbix.
Как опытный кардиолог, глядя на кардиограмму пациента, может с уверенностью сказать, что тому следует исключить нагрузки и следить за сердцем, так Zabbix способен заметить изменения в графиках метрик WinCC и предупредить о надвигающихся проблемах. Я, Арсений Тиунов, менеджер по визуализации, расскажу, как мы настроили систему мониторинга на производствах «Северстали» и каких результатов добились.
![](https://habrastorage.org/getpro/habr/upload_files/692/b8d/ffa/692b8dffa37dc0fa1dca0bc48655caa7.jpg)
Неоднородность версий мешает увидеть полную картину работы WinCC
Когда у вас на производстве сотни серверов SCADA-систем, их диагностика и поддержание правильной и бесперебойной работы (как серверов, так и самого ПО WinCC) — настоящий вызов для специалиста по автоматизации. Решая эту задачу, мы хотели не только найти удобный способ собрать данные, но и разобраться с тем, какие
метрики мы получим и какие из них нам критично важны. Еще одним ключевым моментом была возможность внедрения найденного решения со стороны коллег на производствах без существенных трудозатрат и в кратчайшие сроки.
Мы уже работали с Zabbix — вели мониторинг состояния самих серверов со SCADA-системами на производствах «Северстали»: Zabbix-агенты собирали информацию о железе, работе ОС, служб и так далее. Данные, безусловно, полезные, но исключительно в разрезе работы самого сервера, а не целевого приложения WinCC. Эта информация не даёт полной картины работы установленного ПО. Нам же был нужен такой мониторинг, который позволит заранее выявить узкие места в производительности SCADA-систем, а также сделать выводы о том, правильно ли настроены исполняемые проекты ПО и правильно ли мы используем ресурсы сервера.
Сложность задачи заключалась в том, что неоднородность ландшафта автоматизированных систем управления технологическим процессом (АСУТП) значительно влияет на попытку разработать универсальное решение. Каждый проект исполняемой программы WinCC уникален по версии ПО, количеству соединений (контроллеров, OPC и т. д.) и сигналов, другим параметрам. Как же определить, какие из узлов диагностики настроены корректно, и как оценить их критерии производительности? Zabbix позволяет это организовать, но его надо тонко настроить. И осуществлять эту настройку надо обязательно на основе анализа метрик по каждому конкретному узлу (группе узлов).
Неоднородность версий WinCC
Различные версии WinCC выходили в разное время и существенно изменились от v7.0 к версии v7.5. SP2 по следующим аспектам:
количество тегов производительности (Performance tags);
количество системных сообщений (System alarms);
количество выведенных в Windows счётчиков производительности (Performance Counters).
Версия WinCC |
Метрики Windows Performance Counters |
Метрики для Zabbix Sender (теги статуса системных сообщений) |
WinCC 7.5 SP2 |
Да (полный набор) |
Да |
WinCC 7.5 SP1 |
Да (частично) |
Да |
WinCC 7.5.0 и ниже |
Нет |
Да |
Исходя из того, что в версиях WinCC ниже 7.5.0 метрики можно получить только скриптом, возможностей для универсального вывода в Zabbix всего набора метрик для каждого узла нет. Мы собираем в Zabbix все метрики, но для анализа WinCC в рамках ландшафта используем их ограниченный набор. Однако в большинстве ситуаций весь набор и не требуется. Тем не менее, у нас остаётся возможность посмотреть все доступные метрики по отдельно взятой Scada-системе на уровне узла Zabbix.
# |
Вид метрики |
Значение метрики |
1 |
TLGRT_AVERAGE_TAGS_PER_SECOND |
Watchdog (постоянно изменяющееся значение) — используется метрика «среднее значение запросов на запись с момента запуска среды исполнения» |
2 |
SCRIPT_COUNT_ACTIONS_IN_QUEUES |
Очередь скриптов |
3 |
RedundantServerState и RM_Master |
Состояние резервирования серверов |
4 |
WinCC_Connections_Pending_tag_read WinCC_Connections_Pending_tag_write TLGRT_TAGS_PER_SECOND |
Важные индикаторы производительности WinCC |
5 |
Приоритет - 0 |
Обычная информация/статус |
6 |
Приоритет - 1 |
Важная информация/статус |
7 |
Приоритет - 2 |
Менее важные, требующие общего разбора |
8 |
Приоритет - 3 |
Предупреждения |
9 |
Приоритет - 4 |
Критично важные (срочная реакция) |
Чуть позже мы расскажем об этих метриках и настройке триггеров по ним.
Возможности Zabbix в контексте WinCC
Zabbix — это специализированное open sourse ПО для мониторинга статусов компьютерной сети, серверов, сетевого оборудования и разных сервисов. Мониторинг серверов WinCC в Zabbix чаще всего представляет собой «плоский» список узлов с группировкой и именованием групп по географическому принципу «Производство — Цех — Агрегат — Узел». Попытка собрать информацию о качестве работы WinCC по конкретному подразделению производства превращается в кошмарный скроллинг по экранам с такими списками. Поэтому, как правило, работа с Zabbix в АСУТП ограничивается реакцией на триггеры (оповещения) о критически важных событиях, настроенных на метрики самих серверов, а не целевого ПО WinCC.
![](https://habrastorage.org/getpro/habr/upload_files/ec6/22e/a6b/ec622ea6b0fb055b82093c1ccc2940d2.png)
Но пора уже рассказать вам о методологиях, которые мы разработали для мониторинга WinCC.
Два направления мониторинга WinCC: предиктивная и ситуативная диагностика
Ещё до начала работ по мониторингу WinCC в Zabbix мы столкнулись с вполне резонным вопросом коллег: «А зачем нам мониторинг ещё и в Zabbix, если мы узнаём о проблеме практически сразу? Нас вызовет оператор производственной линии, и мы узнаем о сбое WinCC». «А для того, — отвечали мы, — чтобы не просто констатировать смерть элемента или всей SCADA, но предугадать и предупредить заранее о возможном сбое».
Мы изучили возможности самодиагностики WinCC, которых оказалось достаточно для решения такой задачи. Нужно лишь вести наблюдение за метриками и выстраивать правила оповещения. Так появилась предиктивная диагностика WinCC.
Предиктивная диагностика WinCC
Помните нашего кардиолога, который заметил изменение работы сердца через кардиограмму? Вот и наш Zabbix видит изменения в графиках метрик WinCC и предупреждает о надвигающихся проблемах. Он собирает параметры двумя способами:
Через чтение внутренних тегов из раздела «Performance» WinCC, начинающихся с символа @.
Через чтение параметров в Windows Performance Counters напрямую, минуя WinCC, без каких-либо настроек со стороны WinCC.
И вот о чём говорит нам полученная информация.
Пиковые значения параметров указывают на нагрузку, вызванную циклически повторяющимися событиями. Это показатель того, что WinCC временно перегружена и, следовательно, может эксплуатироваться только в ограниченной степени. Если после пика нагрузки показатели параметров снова быстро снижаются, ограничений для дальнейшей работы WinCC-системы нет.
![](https://habrastorage.org/getpro/habr/upload_files/5bd/29f/d51/5bd29fd51724a84fb7ad1dfea551224d.png)
Постепенное увеличение параметров указывает на перегрузку или проблему, если их состояние с течением времени не возвращается в норму. Диагностика проблемы в таком случае заключается в мониторинге состояния и изменении во времени этих параметров производительности WinCC.
![](https://habrastorage.org/getpro/habr/upload_files/c92/2b1/a01/c922b1a01e9292c4205b1be07da3b56e.png)
Ситуативная диагностика. Системные сообщения WinCC
Не следует думать, что системные сообщения только «констатируют смерть пациента». Вовремя выявленное важное информационное сообщение или предупреждение (до появления критических сообщений) поможет предотвратить сбойную ситуацию.
В большинстве случаев вы уже используете «Системные сообщения WinCC» и просматриваете их в SCADA-системе. В последних версиях WinCC (на момент написания статьи это WinCC 7.5 SP2 Upd 9) их количество приблизилось к 400. Просмотреть их возникновение на одной-двух SCADA-системах требует времени, а если представить, что у вас несколько сотен серверов?
Поэтому мы решили попробовать передать такой анализ в саму SCADA-систему. Мы написали VBS-скрипт, в котором происходит сортировка возникающих системных сообщений (аварийных событий, предупреждений) на пять групп по приоритетам. Количество полученных уникальных (по номеру сообщения, например, «1000002») сообщений мы стали передавать в Zabbix. Там становится возможным агрегировать эти показатели в вертикально ориентированной архитектуре.
![](https://habrastorage.org/getpro/habr/upload_files/cb1/ca6/78a/cb1ca678a12e237e3ab17a11ff344e2c.png)
Архитектура системы мониторинга в Zabbix
Итак, нам надо было исправить ситуацию, когда узлы сгруппированы лишь по географическому признаку. Вначале мы не понимали, как оценивать участки и производства на наличие проблем. Не умели задействовать инструменты агрегирования данных в Zabbix, а следовательно, не могли получить информацию по конкретному уровню (цех, производство).
Тогда мы построили архитектуру, в которой для каждого пользователя Zabbix были определены узлы, входящие в его зону ответственности. Настроены триггеры. Собранные данные удобно агрегированы в едином дашборде:
![Архитектура мониторинга SCADA-систем Архитектура мониторинга SCADA-систем](https://habrastorage.org/getpro/habr/upload_files/c02/63b/08b/c0263b08b5f7562c3590dc866c3f8cac.png)
С такой архитектурой решения каждому участнику мониторинга работать стало гораздо удобнее.
О примерах настроек WinCC и Zabbix для разных видов диагностики читайте в следующей серии.
Комментарии (7)
mvkozyrev
16.12.2022 04:38По метрикам 1 и 4 возникает вопрос: а что у вас с железом и сетевой нагрузкой? И какой scan time?
Метрика 2: снова, что с железом и не распараллелить ли выполнение скриптов?
ev-gorlov
18.12.2022 10:31распараллелить скрипты - это к разработчику WinCC Siemens, тоже не понимаю почему не могут сделать
ars_tiunov
18.12.2022 10:321) В рамках данной статьи рассматриваются именно метрики самой WinCC, т.к. сбор метрик железа и сетевой нагрузки уже был сделан ранее. Scan time (если мы говорим об интервале обновления) настроен на 2 минуты для метрик WinCC "из коробки" (windows performance counters). А для выполнения VBScript сделали запуск 1 раз в 10 минут. Этих значений вполне хватает для сбора актуальных данных в zabbix. Что касается остальных настроек мониторинга - они во второй части статьи (готовится к выпуску).
2) Время выполнения скрипта VBS по мониторингу - регистрируется в zabbix отдельным значением как дельта времени окончания/начала выполнения. Это значение - меньше 1 секунды для большинства WinCC (в редких случаях 1 секунда). Оценили это значение и не увидели необходимости в распараллеливании скрипта.
OleSv
16.12.2022 09:39«Zabbix — это специализированное отечественное ПО» - откуда такие данные ? https://www.zabbix.com/ru/about
severstal Автор
16.12.2022 09:40Добрый день, огромное спасибо за комментарий - откорректировали неточность этого пункта
neobuh
Это вот вы откуда взяли? На их сайте укзано, что они из недружественной страны. Кроме того они выпустили релиз, что прекращают свою деятельность в РФ и, видимо, вам придется искать новое решение.
Да и про WinCC уже стоит забыть...
mvkozyrev
Сложно забыть, когда "их около тысячи". Будут тянуть до отказа.