Для всех сигналов установили опрос раз в секунду: «Так надёжнее». Через месяц архив вырос, сервер стал работать тяжелее, а короткое событие всё равно не попало в историю. Увеличение частоты не помогло, потому что одни источники обновлялись медленнее, другие требовали фиксации события на месте возникновения.

Частоту выбирают от задачи наблюдения и характеристик всей цепи данных. Важны длительность изменения, допустимая задержка, возможности источника и способ хранения. Универсального интервала для SCADA нет. Ниже приведена методика выбора и условный расчёт нагрузки; все численные настройки требуют проверки на конкретном объекте.

Сформулируйте, что нужно увидеть

Начните с решения пользователя. Он наблюдает устойчивый режим, разбирает короткие переходы, считает расход за смену или должен быстро заметить отклонение? Эти задачи предъявляют разные требования к детализации.

Для каждого класса сигналов заполните четыре строки:

Например, инженеру нужен температурный тренд для анализа прогрева за десятки минут. Другому специалисту требуется последовательность дискретных событий продолжительностью сотни миллисекунд. Одинаковый опрос этих сигналов не даёт одинаково полезной информации.

Если речь идёт о быстром управлении или защите, задачу нельзя решать настройкой частоты экранного мониторинга. Такие функции выполняются предусмотренными проектом компонентами с собственными требованиями. Обзор SCADA помогает наблюдать, но не подменяет их.

Разделите пять разных интервалов

Под словом «опрос» часто смешивают несколько процессов:

В OPC UA об интервале выборки прямо учитывается возможность пересмотра запрошенного интервала сервером; нижележащая система может обновлять данные медленнее. Запрос раз в 100 миллисекунд не создаёт десять новых измерений в секунду, если источник выдаёт одно.

Описание подписок OPC UA отдельно определяет цикл публикации уведомлений. Эти параметры полезно различать и в других архитектурах. Ссылки объясняют принципы стандарта, а не подтверждают поддержку конкретного протокола в выбранном продукте.

Составьте карточки групп сигналов

Вместо единой настройки подготовьте небольшую матрицу в виде карточек. Числа ниже — только кандидаты для испытаний при описанных допущениях.

Группа А — температура корпуса. Задача: видеть тренд прогрева. По предварительной записи значимые изменения развиваются за десятки секунд; нужна проверка на реальных режимах. Кандидат интервала сбора — пять секунд. Проверка: сравнить полученную историю с более подробной эталонной записью и оценить, не теряются ли нужные изменения.

Группа Б — краткий дискретный импульс. Задача: не потерять факт события длительностью около 200 миллисекунд. Опрос раз в секунду может полностью его пропустить. Следующий шаг — проверить фиксацию события, счётчик или буфер на источнике и способ передачи с временем возникновения. Само уменьшение интервала не считается доказательством полноты.

Группа В — накопленный расход за смену. Задача: определить разницу показаний счётчика. Кандидат — чтение раз в минуту при условии, что исходное устройство корректно накапливает значение. Отдельно проверяются сброс, переполнение и длительный перерыв связи. Пропуск промежуточного чтения и потеря итогового счётчика имеют разные последствия.

Карточка всегда содержит основание, а не только число. Если длительность процесса неизвестна, сначала нужна измерительная запись или информация производителя.

Посчитайте нагрузку до массового подключения

Возьмём условный набор из 120 сигналов. При сборе каждого раз в секунду получается 120 значений в секунду. За сутки без перерывов: 120 × 86 400 = 10 368 000 значений.

Разделим набор: 20 сигналов собираем раз в секунду, 100 — раз в пять секунд. Средний поток: 20 / 1 + 100 / 5 = 40 значений в секунду. За сутки — 3 456 000. Это втрое меньше исходного количества.

Расчёт описывает число значений, а не сетевых запросов. Один запрос может получать несколько сигналов, а ответы содержат служебные поля. Для оценки канала нужны фактические размеры сообщений, группировка и повторные передачи. Для диска — формат хранения, индексы, сжатие и дополнительные записи.

Если система передаёт только изменения, фактический поток зависит от поведения процесса и фильтров. Среднее за спокойную смену не описывает пиковый поток при запуске оборудования или восстановлении связи. Испытайте именно такие режимы.

Проверьте задержку от события до экрана

Интервал опроса — только часть задержки. В условной последовательной цепи можно оценить ожидания: до обновления источника 0,5 секунды, до выборки одна секунда, до публикации одна, доставка 0,2, обновление экрана одна. Суммарная оценка — до 3,7 секунды при этих допущениях.

Это расчётная иллюстрация без очередей и повторов, а не гарантия максимальной задержки. Некоторые этапы работают иначе или одновременно, а перегрузка добавляет ожидание. Реальную задержку измеряют от контролируемого события до наблюдаемого результата.

Зафиксируйте, какие часы используются и насколько они согласованы. Если источник и экран имеют разные временные базы, разность отметок может отражать ошибку часов. Полезно проверять не только типичный результат, но и максимальные наблюдённые задержки в согласованных нагрузочных условиях.

Не путайте фильтрацию с получением данных

Фильтр небольших изменений уменьшает поток сообщений, но меняет то, что попадёт в историю. Плавный рост из маленьких шагов, дребезг и короткий пик могут обрабатываться по-разному. Правило нужно проверить на характерной последовательности значений.

Опишите, что сравнивается с порогом, когда сохраняется новая точка и как ведёт себя качество. Требования к полноте событий и к красивому графику не одинаковы. Усреднение может быть полезно для отчёта, но скрывать изменение, важное для разбора остановки.

Также согласуйте очередь: хранится ли несколько изменений между отправками, что происходит при переполнении, виден ли факт потери. Частая выборка без достаточного сохранения и передачи не гарантирует, что оператор или архив увидят все выбранные точки.

Проведите пилот на разных режимах

Выберите несколько сигналов каждого класса и воспроизведите допустимые тестовые сценарии. Испытания проводят в согласованной среде без нарушения рабочего процесса.

  1. Постоянное значение: подтвердить доступность без ложных сообщений о потере связи.
  2. Плавное изменение: сравнить историю с эталонной записью.
  3. Короткое событие: проверить факт фиксации и временную отметку.
  4. Одновременные изменения: измерить пиковую нагрузку и задержку.
  5. Перерыв связи: проверить качество данных и обозначение пропуска.
  6. Восстановление: выяснить, есть ли накопленная история и как она передаётся.
  7. Рост числа сигналов: проверить, сохраняются ли требуемые характеристики.

Для каждого испытания заранее определите критерий: допустимую потерю детализации, задержку, полноту события или поведение при отсутствии данных. Критерии задаются рабочей задачей. Фраза «на глаз всё обновляется» для приёмки недостаточна.

Сохраните принятое решение

Мини-шаблон итоговой записи: идентификатор группы; рабочая задача; скорость обновления источника; выбранный интервал; правило передачи; архивная детализация; контроль доступности; результаты испытаний; ограничения; владелец и дата пересмотра.

Пересматривайте настройки, когда меняется задача, источник или объём данных. Ускорение интерфейса не должно незаметно менять нагрузку на контроллеры. Изменение частоты сбора и фильтров фиксируется как изменение конфигурации.

В Спектре заявлены телеметрия, архив и исторические тренды, тревоги и квитирование, редактор мнемосхем. Для обсуждения мониторинга подготовьте несколько таких карточек. Доступные способы подключения и фактические характеристики обработки следует подтвердить на ваших источниках и сценариях.

Источники и материалы по теме

- OPC Foundation: интервал выборки и ограничения источника.
- OPC Foundation: публикация уведомлений подписки.
- Техническое задание на SCADA.
- Карта тегов и смысл сигналов.

Все материалы →