Желательно — во время ближайшего планового останова.
Но между покупкой программы и готовностью производства работать под её управлением находится отдельный инженерный проект. В него входят обследование оборудования, проверка обмена данными, перенос логики, настройка архивов, испытания и подготовка персонала. Если начать с закупки, часть этих задач придётся решать уже в рамках выбранного продукта и согласованного бюджета.
Поэтому первый результат подготовки к переходу — не коммерческое предложение поставщика, а понимание того, что именно предприятие заменяет, какие функции обязано сохранить и каким способом проверит новую систему.
Что означает 2030 год — и почему это не дата начала работ
Постановление Правительства РФ № 1912 регулирует переход субъектов критической информационной инфраструктуры на преимущественное применение доверенных программно-аппаратных комплексов на принадлежащих им значимых объектах КИИ. В правилах установлен целевой показатель: по состоянию на 31 декабря 2029 года доля таких комплексов должна составлять 100%. Это не универсальное требование заменить любую иностранную SCADA на каждом российском предприятии.
Есть и другое существенное различие: постановление касается программно-аппаратных комплексов, а не только прикладной программы. Поэтому нельзя автоматически считать, что покупка российской SCADA решает все вопросы соответствия. Сначала необходимо определить применимые требования и границы комплекса, а затем рассматривать его программные и аппаратные составляющие.
Почему выбирать SCADA по презентации слишком рано
Сравнение платформ легко свести к таблице: поддерживаемые протоколы, резервирование, мнемосхемы, отчёты, архивирование. Однако наличие функции в описании ещё не отвечает на вопрос, как она будет работать в конкретной АСУ ТП.
Например, предприятию недостаточно убедиться, что платформа поддерживает обмен с контроллером нужного производителя. Следует проверить конкретную модель, версию прошивки, способ адресации, доступность необходимых переменных и поведение при восстановлении связи. Для архива важен не только факт сохранения значений, но и возможность получить нужную глубину хранения, корректные временные метки и приемлемую скорость выборки.
Поэтому сравнение SCADA российского производства разумно начинать с единого набора требований и испытательных сценариев. Тогда поставщики отвечают на одинаковые вопросы, а заказчик оценивает не убедительность демонстрации, а пригодность решения для своего объекта.
Сначала — технический паспорт действующей системы
Для первичного обследования стоит собрать сведения, которые позволят описать текущую архитектуру и объём переноса:
• перечень серверов, операторских станций, ОС и используемых баз данных;
• модели ПЛК, версии прошивок, протоколы и способы подключения;
• количество внешних сигналов, расчётных параметров и клиентских подключений;
• перечень мнемосхем, скриптов, тревог, отчётов и пользовательских компонентов;
• связи с MES, ERP, лабораторными и другими информационными системами;
• глубину архивов и требования к доступности исторических данных;
• схему резервирования, резервного копирования и восстановления;
• допустимые перерывы в работе и возможные окна переключения.
Отдельно полезно отметить, где находятся актуальные исходники, кто имеет необходимые доступы и какие элементы проекта поддерживаются только силами конкретного специалиста. Такие зависимости лучше обнаружить до согласования сроков внедрения.
Не всё придётся менять. Но это нужно доказать
Один из главных вопросов обследования — можно ли сохранить существующие контроллеры, сети и часть прикладных решений. Ответ нельзя получить только из формулировки «российский аналог»: он зависит от состава оборудования и механизмов взаимодействия.
Например, в презентации платформы SCADA «КАСКАД» описаны поэтапный переход с возможностью эксплуатации гибридных систем и сценарии замены верхнего уровня зарубежных DCS с сохранением ПЛК. Там же приведены сведения об упрощённых механизмах миграции с Wonderware и Simatic WinCC. Это основания для предметной технической проверки, но не обещание автоматического переноса любого проекта без доработок.
Практический шаг для заказчика — выбрать характерный участок и составить таблицу: что сохраняется, что переносится с изменениями, что разрабатывается заново. В неё следует включить не только экраны, но и вычисления, права пользователей, отчёты, архивные запросы и связи с внешними системами.
Когда обсуждать лицензии и бюджет
Запросить ориентировочную стоимость полезно на раннем этапе. Но окончательную спецификацию лучше формировать после определения архитектуры: количества серверов, клиентских подключений, внешних сигналов, интеграционных модулей и требований к резервированию.
Прежде чем купить лицензию SCADA, заказчику стоит согласовать состав поставки и проверить, какие компоненты нужны для пилота, промышленной эксплуатации и последующего расширения. Это помогает избежать ситуации, когда лицензия уже приобретена, а необходимые подключения или функции не вошли в расчёт.
Бюджет проекта при этом не следует ограничивать стоимостью программного обеспечения. Для сопоставления предложений удобно выделить несколько самостоятельных статей:
• Обследование и подготовка технического задания.
• Лицензии и инфраструктура для выбранной архитектуры.
• Перенос экранов, логики, тревог, отчётов и интеграций.
• Работа с историческими данными.
• Стендовые и объектовые испытания.
• Обучение, документация и сопровождение запуска.
Так становится видно, сравнивает ли предприятие одинаковый объём работ. Низкая цена лицензии сама по себе ничего не говорит о стоимости переноса проекта, а подробное предложение на внедрение нельзя напрямую сопоставлять с предложением только на поставку ПО.
Пилот должен проверять неудобные сценарии
Демонстрация готового интерфейса полезна для знакомства с продуктом. Пилот нужен для другого: выяснить, выполняет ли платформа требования предприятия в согласованной конфигурации.
Как выбрать участок для испытаний
Лучше включить в пилот не только простую мнемосхему с несколькими значениями, но и характерные для объекта сложности: нестандартный обмен, расчётные параметры, архивирование, отчёты и интеграцию. При этом испытания команд управления необходимо организовать в безопасном контуре, исключающем непредусмотренное воздействие на действующее оборудование.
В программу проверки стоит включить:
• потерю и восстановление связи с источниками данных;
• корректность отображения недостоверных и устаревших значений;
• обработку большого числа изменений и событий;
• запись архивов и выборку данных за согласованные интервалы;
• отказ компонента и восстановление работы, если это предусмотрено архитектурой;
• разграничение прав и регистрацию действий пользователей;
• восстановление проекта из резервной копии.
Для каждого сценария нужен измеримый критерий: допустимое время восстановления, полнота записей, время открытия отчёта или корректность последовательности событий. Оценка «в целом работает» оставляет слишком много вопросов до промышленного запуска.
Как использовать сведения разработчика
При рассмотрении КАСКАД 4.0, представленного ООО «СибКом Цифра», можно опираться на опубликованную архитектуру: SQLite используется для конфигурационных данных, RocksDB — для оперативных значений, PostgreSQL и Citus — для исторических данных. На странице продукта также указаны работа в нагруженном резерве, API и модуль интеграции со сторонними системами, включая MES и ERP.
Эти сведения помогают сформулировать вопросы для проектирования: как разделить компоненты, организовать хранение, подключить внешнюю систему и проверить отказоустойчивость. Но опубликованный результат нагрузочного тестирования нельзя механически переносить на объект с другим оборудованием, объёмом архивирования и числом клиентов. Сама страница КАСКАД 4.0 содержит описание испытательной конфигурации — её необходимо учитывать при интерпретации показателей.
Параллельная работа — не разрешение одновременно управлять из двух систем
При подготовке поэтапного перехода нужно разделять сбор данных и выдачу управляющих команд. Параллельное получение значений позволяет сравнивать показания и проверять новую визуализацию. Возможность управления технологическим процессом требует отдельного регламента: какая система имеет полномочия, кто разрешает переключение и как исключаются конфликтующие действия.
До начала работ полезно зафиксировать:
• границы пилотного и промышленного контуров;
• порядок предоставления прав на управление;
• ответственных за переключение и контроль результата;
• условия остановки работ и возврата к прежней конфигурации;
• порядок сохранения данных за переходный период.
Что должно быть готово до основной закупки
Чтобы закупка стала обоснованным этапом проекта, а не попыткой заранее угадать его состав, предприятию стоит подготовить следующий комплект:
• Описание действующей системы и перечень критичных функций.
• Границы замены: сохраняемые, переносимые и вновь разрабатываемые компоненты.
• Требования к целевой архитектуре и применимые нормативные ограничения.
• Результаты проверки совместимости и протокол пилотных испытаний.
• Спецификацию лицензий, оборудования и работ.
• План внедрения с контрольными точками, ответственными и условиями возврата.
• Программу обучения и критерии приёмки в промышленную эксплуатацию.
Именно обследование превращает абстрактную задачу «заменить иностранную SCADA» в проект с понятными границами. Начав с него, предприятие получает возможность выбирать платформу под свои требования, а не подстраивать требования под уже купленную лицензию. Время до 2030 года имеет смысл использовать для снятия технических неопределённостей — пока ещё можно спокойно сравнивать варианты, испытывать решения и корректировать план.
