В запросе на внедрение SCADA написано: «Подключить оборудование, сделать мнемосхемы и архив». Один поставщик считает только отображение сигналов, другой включает серверы и настройку сети, третий предполагает управление агрегатами. Предложения выглядят несопоставимыми, потому что участники оценивают разные системы.

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

Сначала определите назначение и границы

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

Разделите три группы обязанностей:

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

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

Соберите паспорт участка

Для условного пилота паспорт может выглядеть так:

Последнюю строку нельзя молча удалить из документа. Для неё назначают владельца проверки, срок и требуемое подтверждение: документацию оборудования и испытание обмена. Предложение поставщика должно показывать, что уже включено, а что зависит от результата этой проверки.

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

Опишите данные, а не только число сигналов

Смета «на 120 тегов» мало говорит о сложности. Среди них могут быть числа, состояния, расчётные показатели и события с разными требованиями. Для каждого тега нужны идентификатор, объект, физический смысл, источник, тип, единица, масштабирование, временная отметка и качество.

Например: PUMP02.PRESSURE_OUT — давление на выходе насоса № 2, в барах. В документе указывается, передаёт ли источник готовое инженерное значение или исходный код, кто выполняет преобразование и как проверяется правильность единиц. Иначе одна команда масштабирует число повторно, а другая показывает его без преобразования.

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

Задайте рабочие сценарии экранов и архива

Количество мнемосхем выводят из задач, а не наоборот. Для каждого экрана опишите, что человек должен обнаружить и куда перейти. В условном пилоте обзор показывает четыре агрегата, качество данных и открытые тревоги; подробный экран помогает рассмотреть выбранный объект.

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

Для пилота можно зафиксировать: давление и состояние насоса просматриваются совместно за выбранный интервал; пропуск связи не соединяется линией, создающей впечатление непрерывного измерения. Оператор должен найти тестовый эпизод и назвать, какие данные действительно доступны. Это критерий полезности архива, а не обещание автоматического определения причины аварии.

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

Разделите тревогу, подтверждение и действие

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

Квитирование отвечает на вопрос, получил ли оператор уведомление. В OPC UA Alarms & Conditions это отдельное действие со своим состоянием подтверждения. Оно не означает, что давление нормализовалось или причина устранена.

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

Включите эксплуатацию в состав требований

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

Требования к восстановлению должны иметь наблюдаемый результат: кто запускает процедуру, какие данные допустимо потерять, за какое время нужно восстановить работу и как это проверяется. Числа согласуются по критичности участка. Резервирование и восстановление из копии решают разные задачи; наличие одного не доказывает другое.

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

Составьте протокол приёмки до демонстрации

Для условного пилота подготовьте пять проверок на стенде:

  1. Источник передаёт согласованное значение; экран показывает правильный объект, число и единицу.
  2. Канал становится недоступен; качество данных заметно меняется, старое значение не выглядит актуальным.
  3. Связь восстанавливается; правило обновления и обработки пропущенного интервала выполняется.
  4. Возникает тестовая тревога; подтверждение и снятие условия различимы.
  5. Инженер открывает архив эпизода; временная шкала, пропуски и связанные сигналы читаются однозначно.

У каждой проверки есть исходные данные, действие, ожидаемый результат и способ фиксации. Испытания не должны нарушать действующий технологический процесс: их среду и порядок согласуют ответственные специалисты.

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

Проверьте, достаточно ли данных для выбора

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

Спектр в каталоге ExtentLab представлен как web-SCADA для наблюдения за оборудованием: телеметрия, архив и тренды, тревоги и квитирование, редактор мнемосхем. Протоколы подключения, резервирование, управление и сертификаты нужно обсуждать отдельно. Для первой встречи достаточно паспорта участка, нескольких заполненных тегов и описания ожидаемых действий оператора.

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

- NIST: Guide to Operational Technology Security.
- OPC Foundation: Acknowledge Method.
- Как проверить SCADA на сценариях предприятия.
- Как сделать мониторинг полезным для производства.

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