К 2026 году переход на отечественные SCADA-системы перестал быть добровольной инициативой для значительной части промышленных предприятий. Регулирование критической информационной инфраструктуры за последние два года заметно ужесточилось: действует единый перечень типовых отраслевых объектов КИИ почти из 400 позиций, утверждённый распоряжением Правительства № 360-р от 26 февраля 2026 года, а для объектов первой и второй категорий значимости теперь прямо требуется, чтобы программное обеспечение было размещено на территории России. Для значимых объектов первой категории — то есть тех, чьё нарушение работы способно привести к катастрофическим последствиям для безопасности государства, жизни людей или экономики страны — импортозамещение и вовсе обязательно, а не рекомендовано.
При этом сама по себе замена 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-платформу можно свести к следующей последовательности проверок, которую стоит держать перед глазами на протяжении всего проекта.
- Проведена полная инвентаризация тегов, протоколов, архивов и интеграций текущей системы;
- определена категория значимости объекта КИИ и понятны обязательные меры для этой категории;
- проверен статус выбранной платформы в реестре отечественного ПО и наличие необходимых заключений ФСТЭК;
- подтверждена совместимость платформы с уже развёрнутыми операционными системами, средствами защиты и виртуализацией;
- проверена поддержка нужных протоколов и драйверов для существующего нижнего уровня автоматизации;
- составлен план параллельного запуска с переносом данных без остановки производства;
- оценена модель лицензирования на горизонте нескольких лет развития проекта, а не только на этапе первой закупки;
- запланировано обучение операторов и инженеров с началом ещё на этапе тестового запуска.
Импортозамещение SCADA в 2026 году — это уже устоявшаяся инженерная практика с понятными этапами, а не разовое административное решение. Предприятия, которые подходят к переходу системно — с инвентаризации, через проверку регуляторных требований и совместимости, к поэтапному запуску и обучению персонала — получают не просто формальное соответствие требованиям законодательства, а рабочую систему диспетчерского управления, адаптированную под реальные задачи производства.
Перевод/транскрипция иностранных слов: IT (Ай‑Ти — информационные технологии, Information Technology), SCADA (СКАДА — диспетчерское управление и сбор данных, Supervisory Control and Data Acquisition), OPC UA (ОПС ЮА — протокол промышленной связи, Open Platform Communications Unified Architecture), Modbus TCP (Модбус Ти‑Си‑Пи — протокол промышленной связи, Modbus Transmission Control Protocol), MES (МЭС — система управления производственными процессами, Manufacturing Execution System), ERP (И‑Ар‑Пи — система планирования ресурсов предприятия, Enterprise Resource Planning), SQLite (Эс‑Кью‑Лайт — встроенная реляционная база данных), RocksDB (Рокс‑Ди‑Би — система хранения данных типа «ключ‑значение»), PostgreSQL (Постгре‑Эс‑Кью‑Эл — объектно‑реляционная система управления базами данных), Intel Core i7‑12700H (Интел Кор Ай‑Севен‑Двенадцать‑Тысяч‑Семьсот‑Эйч — процессор компании Intel), SIEM (СИЕМ — система управления информацией и событиями безопасности, Security Information and Event Management).
