1. Цели приёмки SCADA/BMS
2. Полнота графиков vs таблица тегов проекта
3. Аварии: классы приоритета и защита от alarm flood
4. Inhibit / shelve: инженерная практика
5. Рабочий процесс оператора и журнал событий
6. Резервные копии проекта и тест резервирования
7. Чек-лист подписания приёмки SCADA/BMS

Приёмка SCADA (Supervisory Control and Data Acquisition) / BMS — этап, на котором полевая автоматика становится инструментом эксплуатации: графики, аварии, тренды, права пользователей и регламент действий оператора. «Все контроллеры online» недостаточно: нужна сверка с таблицей точек проекта, управляемый поток аварий и подтверждённые процедуры backup/failover. Ниже — методика для инженера ПНР; классы приоритетов и правила shelve/inhibit описываются как инженерная практика (без выдуманных номеров ГОСТ) и должны быть согласованы с ТЗ и регламентом заказчика.

1. Цели приёмки SCADA/BMS

• Подтвердить полноту и корректность человеко-машинного интерфейса (HMI) относительно проекта.
• Проверить, что аварии доходят до оператора с нужным приоритетом и без «шторма» ложных событий.
• Зафиксировать права доступа, аудит действий, синхронизацию времени.
• Передать заказчику восстанавливаемую конфигурацию (backup) и инструкции.
• При наличии резервирования — провести failover-тест по программе испытаний.

2. Полнота графиков vs таблица тегов проекта

Базовый артефакт — таблица точек (tag list) из проекта/ТЗ: имя тега, описание, тип, единица, аварийные пороги, мнемосхема/зона.

1. Экспорт тегов из SCADA ↔ сверка с таблицей (покрытие % и список отсутствующих).
2. Выборочный обход критичных точек: значение на поле = значение на графике = единица измерения.
3. Проверка навигации: обзор здания → этаж/система → агрегат → деталь.
4. Цветовые кодировки (работа / авария / вне доступа) единообразны на всех экранах.
5. Уставки и команды записи доступны только ролям, указанным в матрице доступа.

3. Аварии: классы приоритета и защита от alarm flood

Alarm flood — лавина сообщений, при которой оператор теряет критичное событие. На приёмке проверяют не только «авария появляется», но и управляемость потока.

Типовая инженерная шкала приоритетов (пример для согласования с заказчиком, не норматив):

• P1 / Critical — угроза оборудованию, безопасности, останов критичного процесса; звук + модальное окно / обязательный ack.
• P2 / High — существенное отклонение; быстрая реакция смены.
• P3 / Medium — предупреждение; планируемая реакция.
• P4 / Low / Info — сервисные сообщения; не должны забивать экран P1.

Меры против flood (практика):

• Гистерезис и задержка на срабатывание/сброс (debounce) для «дрожащих» аналоговых порогов.
• Подавление дочерних аварий при мастер-аварии (например, «нет связи с контроллером» вместо сотен Bad по точкам) — если поддерживает платформа и разрешено ТЗ.
• Разумные пороги: не ставить аварию на штатный ночной режим без необходимости.
• Тест: искусственно вызвать пачку событий — оператор должен сохранить возможность ack критичного P1.

4. Inhibit / shelve: инженерная практика

В разных SCADA функции называются inhibit (блокировка генерации/отображения), shelve (временно отложить), disable, out of service. Смысл для ПНР и эксплуатации:

• Разрешать только уполномоченным ролям; действие писать в audit log.
• Указывать причину и срок; по истечении — автовозврат или напоминание.
• На приёмке: продемонстрировать shelve тестовой аварии и возврат; убедиться, что P1 нельзя «тихо» отключить без следа, если регламент это запрещает.
• Запретить практику «отключим все аварии на сдаче, потом включим» без протокола — это скрытие дефектов.

5. Рабочий процесс оператора и журнал событий

Программа приёмки должна включать сценарий смены:

1. Вход под ролью оператора / инженера / администратора — разные права.
2. Обнаружение аварии → ack → комментарий → устранение (поле/команда) → нормализация.
3. Просмотр журнала событий и аварий: фильтр по времени, приоритету, объекту.
4. Экспорт отчёта / тренда за период (как потребует ТЗ).
5. Проверка NTP: метки времени клиентов и серверов согласованы.

Обучение персонала эксплуатации с актом — часто условие подписания заказчиком; заложите в календарь приёмки.

6. Резервные копии проекта и тест резервирования

Backup

• Полная копия проекта SCADA/BMS (версия платформы + конфигурация + графика + скрипты).
• Копии конфигураций OPC/шлюзов, списков тегов, матрицы аварий.
• Носитель / репозиторий заказчика; контрольная сумма или дата/версия в акте передачи.
• Краткая инструкция восстановления (куда класть, под какой УЗ запускать).

Редунданси (если спроектировано)

1. Уточнить по проекту: hot-standby серверов, зеркало БД, резервный канал связи, dual-homing клиентов.
2. Failover-тест: остановить primary (по согласованной методике) → фиксация времени переключения → проверка, что критичные теги и аварии доступны на secondary.
3. Failback (если требуется ТЗ): возврат на primary без потери конфигурации.
4. Не проводить разрушающие тесты без допуска эксплуатации и окна работ.

Если резервирование в проекте не заложено — в акте явно пишут «не применимо», а не «проверено».

7. Чек-лист подписания приёмки SCADA/BMS

Подпись приёмки SCADA/BMS означает, что диспетчеризация пригодна к эксплуатации: точки полны, аварии управляемы, действия аудируются, конфигурация восстановима. Всё остальное — дефектная ведомость с сроками, а не «потом дорисуем графики».