Производитель ушёл из России: как восстановить поддержку АСУ ТП без вендора

Опубликовано: 29 апреля 2026

Коротко: если производитель больше не поддерживает АСУ ТП, не всегда нужно сразу менять всю систему. Часто безопаснее сначала восстановить архитектуру, I/O, протоколы, логику блокировок и реальные отличия от документации, а уже потом проектировать ремонт или миграцию.

Масштаб проблемы: рынок АСУ ТП всё ещё зависит от legacy-решений

После 2022 года российские предприятия столкнулись с резким снижением доступности поддержки, обновлений и поставок от зарубежных поставщиков промышленной автоматизации. По данным CNews, на российском рынке АСУ ТП исторически сильные позиции занимали Siemens, Schneider Electric, Honeywell и Yokogawa, а после 2022 года эти разработчики ушли или существенно сократили работу в России (CNews).

Зависимость от иностранного ПО в промышленности остаётся высокой. В пересказе исследования «Северстали» говорится, что более 98% проектов в металлургии, ТЭК и химии реализуются на иностранном ПО, а около 80% таких проектов связаны с решениями Siemens (Прометалл).

Рынок АСУ ТП при этом растёт, а не сжимается. В 2024 году российский рынок АСУ ТП оценивался в 124,1 млрд рублей, что почти на 50% выше уровня 2023 года (Ведомости).

Что именно ломается, когда вендор недоступен

Уход производителя редко означает мгновенную остановку производства. Чаще проблема развивается постепенно: система продолжает работать, но её поддерживаемость падает.

Техническая поддержка: некому официально подтвердить причины нестандартных отказов, ошибок связи или поведения HMI.
Обновления ПО: уязвимости, несовместимости и ошибки не закрываются привычным каналом.
Запасные части: контроллеры, панели, модули ввода/вывода и коммуникационные платы приходится искать через вторичный рынок.
Среда разработки: проприетарные IDE, старые лицензии и аппаратные ключи становятся отдельным риском.
Знание системы: инженеры, которые вводили объект в эксплуатацию 15-25 лет назад, часто уже недоступны.

Три стратегии: что реально делают предприятия

Работает — не трогай

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

Полная замена на новую платформу

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

Сначала инженерный разбор, потом замена

Третий путь — сначала восстановить картину существующей системы: состав оборудования, I/O, протоколы, алармы, блокировки, HMI-логику, зависимости и критические сценарии. Для legacy-АСУ ТП без полной документации это часто самый управляемый сценарий.

Реверс-инжиниринг АСУ ТП: что важно понимать юридически

У многих предприятий есть опасение, что любой реверс-инжиниринг ПО незаконен. Это слишком грубое упрощение.

В российском праве статья 1280 ГК РФ регулирует права пользователя программы для ЭВМ и базы данных, включая случаи, когда действия с программой могут быть необходимы для обеспечения функционирования и взаимодействия с другими программами (Гарант, ст. 1280 ГК РФ). В европейском праве статья 6 Directive 2009/24/EC допускает декомпиляцию без разрешения правообладателя, если она необходима для получения информации, нужной для совместимости независимо созданной программы с другими программами (Directive 2009/24/EC, Article 6).

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

Как выглядит проект восстановления поддержки legacy-АСУ ТП

Инвентаризация

Первый этап — не «смотреть код», а понять, что именно есть в наличии: контроллеры, модули I/O, HMI, коммуникационные узлы, версии прошивок, инженерные станции, архивы проекта, конфигурационные файлы, резервные копии и документация.

Анализ конфигурации

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

Реконструкция логики

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

Маркировка допущений

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

Типичные ошибки при восстановлении АСУ ТП без вендора

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

Что должно быть на выходе RE-фазы

Хороший результат инженерного разбора — это не «отчёт о проделанной работе», а набор артефактов, который можно передать своей команде или интегратору.

карта оборудования: контроллеры, HMI, станции, шкафы, модули I/O;
карта сигналов: DI/DO/AI/AO, физические каналы, теги и алармы;
описание протоколов и сетевой топологии;
логика interlock'ов, защит и ключевых зависимостей;
errata: расхождения между документацией, конфигурацией и фактическим состоянием;
список рисков и неопределённостей;
ТЗ для следующей фазы: ремонт, миграция, частичная замена или разработка новой системы.

С чего начать: чек-лист для главного инженера

Соберите все доступные архивы проекта, резервные копии, конфиги, дампы, экспорт HMI и документацию.
Зафиксируйте версии ПО, прошивок, инженерных станций и лицензий.
Сфотографируйте шкафы, маркировки модулей, клеммники, панели и коммуникационные устройства.
Опишите сеть: протоколы, адреса, скорости, master/slave-узлы, шлюзы.
Составьте список критических функций, которые нельзя потерять при миграции.
Отдельно отметьте, где есть сомнения: устаревшие схемы, расхождения, неподтверждённые теги, неизвестные модули.

Как к таким задачам подходит RD[AI]

RD[AI] работает с legacy-АСУ ТП как с инженерной задачей восстановления картины системы. Мы не обещаем «переписать всё по кнопке» и не заменяем интегратора, который отвечает за пусконаладку и сдачу объекта.

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

Есть старая АСУ ТП без поддержки вендора?

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

Обсудить задачу

FAQ

Можно ли восстановить систему, если исходного проекта нет?

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

Можно ли сразу заменить старую систему без RE-фазы?

Можно, если есть полная и актуальная документация. Если документация утеряна или устарела, безопаснее сначала восстановить логику и архитектуру.

RD[AI] делает замену системы под ключ?

Нет. RD[AI] закрывает инженерную фазу разбора и подготовки спецификации. Финальную разработку, пусконаладку и сдачу объекта может выполнять ваша команда или профильный интегратор.