Импортозамещение SCADA в 2026 году: чек-лист миграции с иностранной системы на российскую платформу

К 2026 году переход на отечественные SCADA-системы перестал быть добровольным выбором для значительной части промышленных предприятий. За последние два года контроль за критической информационной инфраструктурой значительно ужесточился: существует единый перечень типовых отраслевых объектов КИИ, почти из 400 позиций, утверждённый распоряжением Правительства № 360-р от 26 февраля 2026 года. Для объектов первой и второй категорий значимости теперь прямо предписывается, чтобы программное обеспечение размещалось на территории России. Для объектов первой категории, то есть тех, чья неисправность может вызвать катастрофические последствия для безопасности государства, жизни людей или экономики страны, импортозамещение становится обязательным, а не рекомендованным.

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

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

Шаг 1. Инвентаризация текущей системы автоматизации

Перед сравнением платформ необходимо точно описать, что подлежит переносу. На этом этапе фиксируются несколько групп параметров.

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

Именно на этом этапе становится очевидным, какого объёма переход предстоит: заменить систему на нескольких автоматизированных рабочих местах небольшого цеха и мигрировать распределённый диспетчерский комплекс с десятками тысяч тегов на нескольких резервированных серверах — это совершенно разные по трудоёмкости задачи.

Шаг 2. Проверка регуляторных требований к объекту

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

Отдельно стоит проверить статус конкретного программного продукта: включён ли он в Единый реестр отечественного программного обеспечения Минцифры России, есть ли у разработчика лицензия ФСТЭК на разработку средств защиты информации и получено ли заключение о соответствии требованиям для нужной категории значимости объектов КИИ. Эти документы — не формальность для отчётности, а фактическое подтверждение того, что платформа прошла независимую проверку на соответствие актуальным ГОСТам, включая ГОСТ Р 56939-2024 в части безопасной разработки программного обеспечения.

Что обычно упускают на этом шаге

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

Шаг 3. Выбор платформы: критерии сравнения

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

В качестве примера подхода к этим вопросам полезно изучить документацию по платформе Каскад 4.0 от компании ООО «СибКом Цифра» — это одна из российских SCADA-систем, прошедших полный цикл обновления архитектуры с акцентом на задачи импортозамещения. Согласно опубликованным материалам разработчика, платформа построена на микросервисной архитектуре с современным технологическим стеком, использует несколько специализированных баз данных для различных типов данных — SQLite для конфигураций, RocksDB для оперативных значений тегов и PostgreSQL для исторических архивов — и по результатам нагрузочного тестирования демонстрирует до 150 000 изменений в секунду на одно ядро процессора при тестировании на оборудовании с процессором 12th Gen Intel Core i7-12700H. Отдельно зафиксирована обработка миллиона последовательных изменений за 9 секунд на одно ядро при пиковой нагрузке на сеть не более 30–35 Мбит/с.

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

Шаг 4. Проверка совместимости с уже развёрнутой инфраструктурой

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

Не менее важна проверка драйверов и протоколов связи с уже установленным нижним уровнем автоматизации — контроллерами и модулями ввода-вывода. Здесь стоит уточнить не только факт поддержки протокола OPC UA или Modbus TCP, но и такие детали, как количество каналов резервирования при подключении к контроллеру, поддержка автопереключения каналов при смене роли контроллера и возможность чтения исторических данных напрямую с устройства, а не только текущих значений.

Шаг 5. Планирование параллельного запуска и переноса данных

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

• определите порядок переноса — по цехам, по технологическим линиям или по критичности участков;
• заранее решите, как будут перенесены исторические архивы — трендов, алармов, отчётов за прошлые периоды;
• предусмотрите тестовый контур для проверки логики обработки алармов и уставок до переноса в промышленную эксплуатацию;
• согласуйте с эксплуатационным персоналом график обучения работе в новом интерфейсе — это снижает риск ошибок операторов в первые недели после перехода.

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

Шаг 6. Оценка стоимости владения и модели лицензирования

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

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

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

Шаг 7. Обучение персонала и подготовка к эксплуатации

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

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

Итоговый чек-лист миграции

Собирая все шаги воедино, процесс перехода на российскую SCADA-платформу можно свести к следующей последовательности проверок, которую стоит держать в поле зрения на протяжении всего проекта.

• Проведена полная инвентаризация тегов, протоколов, архивов и интеграций текущей системы;
• определена категория значимости объекта КИИ и понятны обязательные меры для этой категории;
• проверен статус выбранной платформы в реест Источник