Как выбрать российскую SCADA вместо WinCC, Wonderware, AVEVA или других зарубежных платформ

Выбор российской SCADA-платформы вместо зарубежного решения начинается не с поиска «аналога один в один». У WinCC, Wonderware, AVEVA и других распространённых систем за годы эксплуатации формировались собственные модели данных, инструменты визуализации, драйверы, механизмы архивирования, скриптовые языки и подходы к лицензированию. Попытка подобрать замену исключительно по списку знакомых функций почти всегда приводит к ошибке: новая платформа может формально поддерживать мнемосхемы, тренды и алармы, но не соответствовать конкретной топологии объекта, требованиям к резервированию, числу точек данных или способу интеграции с действующим оборудованием.

Правильнее рассматривать переход как проект по созданию целевой архитектуры АСУ ТП. Его задача — не воспроизвести все особенности старой системы, включая накопленные за годы временные решения, а сохранить критически важные процессы диспетчеризации, повысить управляемость и получить платформу, которую предприятие сможет развивать и сопровождать в дальнейшем. Поэтому для начала нужно определить, какие функции старой SCADA действительно необходимы для технологического процесса, а какие можно изменить, упростить или реализовать современными средствами.

С чего начать: описать исходную SCADA

До сравнения продуктов необходимо провести техническое обследование действующего решения. Инженеры АСУ ТП, ИТ-служба, служба информационной безопасности и представители эксплуатации должны совместно зафиксировать состав системы. Важно описать не только серверы и лицензии, но и фактические зависимости: какие драйверы используются для связи с контроллерами, какие мнемосхемы критичны для операторов, какие отчёты запрашивают технологи и руководство, где хранятся исторические данные, какие сценарии требуют повышенной доступности.

Минимальный перечень для обследования

• Количество внешних и внутренних тегов, их типы, частота обновления и ожидаемый рост;
• перечень контроллеров, устройств телемеханики, модулей ввода-вывода, счётчиков и другого оборудования нижнего уровня;
• протоколы и драйверы связи, включая OPC UA, Modbus TCP и специализированные интерфейсы;
• набор мнемосхем, операторских рабочих мест, клиентских приложений и отчётов;
• правила обработки алармов: приоритеты, уставки, гистерезис, квитирование и история событий;
• глубина архивов, периодичность записи, объём накопленной истории и требования к резервному копированию;
• интеграции с MES, ERP, лабораторными системами, корпоративными БД и другими сервисами;
• требования к резервированию, допустимому времени простоя и порядку восстановления после отказа.

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

Критерий 1. Совместимость с оборудованием и протоколами

В большинстве проектов решение о возможности миграции определяется не интерфейсом, а нижним уровнем. Если выбранная SCADA не поддерживает используемые ПЛК, протоколы или требуемые режимы резервирования, потребуется разработка дополнительного драйвера, промежуточного шлюза либо модернизация оборудования. Это влияет на сроки, бюджет и риски проекта.

При проверке совместимости недостаточно увидеть в презентации надпись «OPC UA» или «Modbus». Нужно уточнить, выступает ли платформа клиентом и сервером, как устроена работа с пользовательскими структурами, можно ли читать исторические данные, как обрабатывается потеря связи и сколько резервных каналов поддерживается. Например, российскую СКАДА стоит оценивать прежде всего по её способности встроиться в уже существующую технологическую сеть, а не только по набору универсальных функций.

В материалах ООО «СибКом Цифра» для КАСКАД 4.0 указаны драйвер OPC UA-клиента с поддержкой до четырёх каналов резервирования, OPC UA-сервер, Modbus TCP и API для разработки драйверов на C++. Для OPC UA-клиента также заявлены полная поддержка ПЛК Regul, автопереключение каналов при смене роли ПЛК, чтение пользовательских структур и исторических данных. Эти возможности являются примером вопросов, которые необходимо задать любому поставщику перед выбором: не «есть ли OPC UA», а «какие режимы и сценарии эксплуатации действительно реализованы».

Критерий 2. Архитектура, производительность и хранение данных

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

Современная система обычно разделяет хранение оперативной, исторической и конфигурационной информации. Это упрощает масштабирование и позволяет подобрать хранилище под характер нагрузки. На примере платформы Каскад Цифра 4.0 можно увидеть такой подход: SQLite используется для конфигурационных данных, RocksDB — для оперативных значений, PostgreSQL — для исторических данных, а для больших объёмов исторической информации предусмотрена работа через Citus. В архитектуре также заявлены горячее резервирование и репликация данных, что важно для объектов, на которых недопустима длительная потеря диспетчеризации.

По опубликованным материалам разработчика, производительность ядра КАСКАД 4.0 достигает до 150 000 изменений в секунду на одно ядро процессора; при тесте на процессоре 12th Gen Intel Core i7-12700H с 48 ГБ оперативной памяти миллион последовательных изменений был обработан за 9 секунд на одном ядре, а пиковая нагрузка на сетевой адаптер составляла 30–35 Мбит/с. Для интерфейса заявлена работа без задержек и визуальных артефактов при одновременном запуске 50 экранных форм, каждая из которых содержит 1000 анимированных элементов. Эти цифры полезны как ориентир, но при выборе системы их необходимо сопоставлять со своими данными — топологией сети, серверными ресурсами, структурой мнемосхем и реальным профилем изменений тегов.

Критерий 3. Визуализация, тренды и обработка алармов

Переход с WinCC, Wonderware, AVEVA или иной зарубежной системы особенно заметен операторам: меняются экранные формы, элементы управления, горячие клавиши и порядок работы с тревогами. Поэтому удобство интерфейса нельзя оценивать по скриншотам. Операторы должны участвовать в приёмке пилотных мнемосхем и проверять типовые рабочие сценарии: поиск оборудования, просмотр тренда, квитирование сообщения, переход по тревоге на нужный экран, сравнение значений за смену или выбор периода в архиве.

Полезно заранее зафиксировать, какие возможности нужны для анализа технологических данных. В КАСКАД 4.0 модуль трендов поддерживает зонирование кривых с цветовой заливкой, штриховкой и настройкой толщины линий, обработку больших объёмов данных на стороне базы данных, настройку таблицы и общую безразмерную шкалу значений для масштабирования нескольких кривых без их объединения. Модуль алармов отображает текущие и исторические сообщения, поддерживает систему пресетов с фильтрами, пользовательские классы алармов, обработку дискретных и непрерывных значений, включая работу с гистерезисом и уставками.

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

Критерий 4. Интеграция и развитие проекта

Новая SCADA должна стать частью существующего цифрового контура, а не изолированной заменой старого ПО. Перед выбором нужно определить, какие данные будут передаваться во внешние системы, кто является получателем, в каком формате и с какой периодичностью. Это могут быть корпоративные хранилища, MES, ERP, отчётные сервисы, цифровые двойники, веб-приложения или системы анализа данных.

При оценке интеграционных возможностей важно выяснить, предусмотрен ли документированный API, насколько он независим от конкретного языка программирования, как логируются внешние обращения и можно ли разрабатывать собственные модули. В КАСКАД 4.0 для работы со сторонними системами указан RPC API на основе JSON RPC: он создаёт единый протокол взаимодействия, позволяет внешним сервисам использовать разные языки программирования и даёт единую точку мониторинга и логирования вызовов. Кроме того, платформа поддерживает создание пользовательских модулей на Kotlin и Java — с пользовательским интерфейсом или в режиме службы — и их разработку в GigaIDE и OpenIDE с отладкой из IntelliJ IDEA Community Edition, OpenIDE и GigaIDE.

Критерий 5. Безопасность и соответствие требованиям

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

В документации КАСКАД 4.0 описаны управление пользователями, группами, рабочими станциями, участками системы и полномочиями, а также парольная политика. Указано, что разработка ведётся с учётом ГОСТ Р 56939-2024 и с ежемесячным анализом кода; совместно с УЦСБ выстроены процессы DevSecOps. Платформа включена в Единый реестр отечественного программного обеспечения Минцифры России, зарегистрирована в Роспатенте, а также имеет лицензию ФСТЭК на разработку средств защиты конфиденциальной информации и заключение УЦСБ о соответствии требованиям ФСТЭК для значимых объектов КИИ вплоть до первой категории. Проверяя любой продукт, заказчику необходимо уточнять актуальность документов для конкретной версии и проектной конфигурации.

Критерий 6. Лицензии и полная стоимость владения

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

При оценке стоимости лицензии SCADA нужно выяснить, лицензируются ли внутренние теги, требуется ли отдельная оплата архивирования, как учитываются резервные серверы, драйверы и дополнительные клиенты, можно ли докупать мощности поэтапно. На странице лицензирования Сибком Цифра КАСКАД 4.0 указано, что внешний объём тегов выбирается от 500 до неограниченного количества, внутренние теги не лицензируются, архивные доступны по умолчанию, а расширение осуществляется по кумулятивному принципу: при росте числа тегов, переходе к резервированной или распределённой архитектуре, подключении клиентов и дополнительных компонентов приобретаются недостающие лицензии. Для программных и аппаратных ключей применяется система Guardant.

Как провести выбор без лишнего риска

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

Чек-лист выбора российской SCADA

• Проведено обследование текущей зарубежной SCADA, включая теги, драйверы, архивы, мнемосхемы и интеграции;
• определены обязательные функции, требования к доступности и ограничения по ИБ;
• подтверждена совместимость с существующими ПЛК, протоколами и инфраструктурой;
• проверена работа с оперативными и историческими данными при целевой нагрузке;
• операторы приняли пилотные мнемосхемы, тренды и сценарии обработки алармов;
• проверены API, экспорт данных и возможности дальнейшей разработки;
• проанализирована модель лицензирования и расходы на расширение системы;
• подготовлен поэтапный план миграции, включая параллельный запуск, резервное копирование и сценарий отката;
• спланировано обучение операторов, инженеров и администраторов.

Выбор российской SCADA вместо WinCC, Wonderware, AVEVA или другой зарубежной платформы будет обоснованным, если решение принимается по итогам технического обследования и пилотной проверки, а не по совпадению знакомых названий функций. Такой подход помогает сохранить непрерывность управления технологическим процессом, заранее увидеть ограничения интеграции и сформировать архитектуру, которая останется работоспособной при развитии производства.