Schneider Modicon и TAC без поддержки вендора - три сценария для главного инженера

Система на контроллерах Schneider Electric, смонтированная до 2022 года, чаще всего продолжает работать. Контроллеры Modicon держат технологический процесс, TAC Xenta управляет вентиляцией и холодоснабжением, TAC Vista рисует мнемосхемы на АРМ диспетчера - визуально ничего не изменилось. Изменилось то, чего не видно из диспетчерской: линейка снята с производства, штатных каналов поставки нет, лицензии и обновления не выпускаются. Отказ одного модуля ввода-вывода перестал быть рутинной заявкой на замену.

Главный инженер здесь принимает решение не о том, «сломается или нет» - сломается, вопрос только когда, - а о том, в каком состоянии объект встретит этот момент. Ниже - три сценария, которыми на практике закрывают этот риск, критерии выбора между ними и разбор того, что в третьем сценарии - плановой миграции - занимает основную часть срока. Фактура опирается на проект замены системы автоматизации и диспетчеризации в здании крупного банка в Туле, где программно-аппаратный комплекс на TAC Xenta и TAC Vista заменён на ОВЕН и MasterSCADA без вывода объекта из эксплуатации.

Что именно стало недоступно, а что продолжает работать

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

Разложим по узлам, потому что «Schneider ушёл» - слишком крупная формулировка, чтобы на её основе принимать решение:

• Контроллеры и модули ввода-вывода продолжают исполнять загруженную программу неограниченно долго. Проблема возникает в момент отказа: оригинальную замену по штатным каналам не купить; параллельный импорт даёт непредсказуемый срок и не даёт гарантии на изделие.
• SCADA верхнего уровня работает на выданных ранее лицензиях. Новых лицензий и обновлений нет, а значит, нет и расширения: добавить рабочее место диспетчера, увеличить число тегов сверх лицензионного лимита или перевести сервер на новую ОС - недоступно.
• Среда разработки остаётся на инженерных рабочих станциях, если её не переустанавливать. Здесь риск бытовой: выход из строя ноутбука с установленной средой и активацией превращает изменение алгоритма в отдельную проблему.
• Полевой уровень - датчики, приводы, преобразователи, кабельные трассы - к уходу вендора отношения не имеет. Это отдельный слой, который в большинстве случаев переживает замену контроллеров без изменений.
• Проприетарные сети. Это тот узел, который чаще всего недооценивают. LonWorks и другие фирменные шины требуют не только совместимого контроллера, но и совместимого сетевого оборудования: сеть придётся перекладывать на Ethernet и Modbus, потому что завести новые контроллеры в старую шину не выйдет.

Разделение важно, потому что сценарии ниже закрывают разные части этого списка. Склад ЗИП снимает риск по контроллерам и модулям, но не снимает риск по лицензиям и сети. Миграция закрывает всё сразу, но стоит проекта.

Сценарий 1 - эксплуатировать как есть, держа склад ЗИП

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

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

Когда это разумное решение:

• Горизонт эксплуатации объекта короткий. Здание идёт под реконструкцию или переезд через год-два - вкладываться в новую систему автоматизации бессмысленно, надо дотянуть.
• Система простая и однородная. Пять одинаковых контроллеров одной модели и три типа модулей ввода-вывода закрываются небольшим складом. Разнородная система из десятка серий требует склада, сопоставимого по стоимости с миграцией.
• Бюджет текущего года не позволяет проект, но позволяет закупку оборудования. Формально это разные статьи, и на практике этим часто пользуются, чтобы не оставить объект без плана вообще.

Что этот сценарий не закрывает:

• Лицензии верхнего уровня. Склад контроллеров не поможет, если отказал сервер SCADA или потребовалось добавить рабочее место.
• Отказ узла, которого нет в резерве. Полностью укомплектовать склад под все возможные отказы дороже, чем заменить систему.
• Изменение алгоритма. Любая переделка технологии упирается в среду разработки, которая тоже не поддерживается.
• Требования регуляторов. Объекты, попадающие под требования по критической информационной инфраструктуре, обязаны переходить на доверенные решения к установленным срокам - склад ЗИП этот вопрос не закрывает вовсе (см. требования 187-ФЗ к АСУ ТП).

Практический смысл сценария - выиграть год-полтора на подготовку проекта. Заменить проект он не способен.

Сценарий 2 - точечная замена по мере отказов

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

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

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

• Каждый узел стыкуется отдельно. Российский контроллер в старой сети требует шлюза или преобразователя интерфейсов. На один узел это разумная мера, на пятый - зоопарк точек преобразования, где отладка одной неисправности занимает больше времени, чем сама замена.
• Логика расползается по уровням. Часть алгоритмов остаётся в старых контроллерах, часть переезжает в новые, часть закрывается скриптами на верхнем уровне. Через два года никто не может ответить, где именно считается уставка.
• Замены делаются в аварийном режиме. Отказ случается не по графику. Значит, замена идёт под давлением сроков, без обследования, без нормальной документации и часто с временными решениями, которые остаются навсегда.
• Верхний уровень остаётся прежним. Новые контроллеры отдают данные в старую SCADA, а она по-прежнему без поддержки. Основной риск - лицензионный и сетевой - не снимается ни на шаг.

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

Сценарий 3 - плановая миграция целиком

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

Ключевое отличие от второго сценария - не в объёме замены, а в том, что архитектура проектируется целиком до начала работ, а сроки работ выбираются заранее под режим объекта.

Как это устроено на практике - на примере здания банка в Туле, где заменялся комплекс TAC:

Узел	Было	Стало
Контроллеры BMS	Schneider Electric (TAC)	ОВЕН
Модули ввода-вывода	Schneider Electric (TAC)	ОВЕН
SCADA верхнего уровня	TAC Vista	MasterSCADA
Сетевая инфраструктура	LonWorks + Ethernet	Ethernet, Modbus
Система мониторинга заказчика	Simple SCADA	Simple SCADA, перенастроена на новую АСУ

Соответствие здесь функциональное, а не «корпус в корпус»: часть функций перераспределяется между модулями под архитектуру новой системы. Под управление в этом проекте попали семь подсистем - приточно-вытяжная вентиляция, холодоснабжение, климатконтроль помещений, контроль протечек, телеметрия электрики по Modbus, мониторинг ИБП по SNMP и приём обобщённого сигнала «ПОЖАР» от противопожарной защиты.

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

Как выбрать сценарий: пять вопросов к объекту

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

Вопросы, ответы на которые сужают выбор до одного варианта:

Вопрос к объекту	Ответ ведёт к сценарию
Сколько лет здание проработает в текущей конфигурации?	Меньше двух - склад ЗИП; больше пяти - миграция
Сколько разных серий контроллеров в системе?	Одна-две - склад закрывает риск; четыре и больше - склад дороже проекта
Есть ли требования по КИИ и импортозамещению ПО?	При наличии требований - только миграция, срок диктует регулятор
Нужно ли развивать систему - новые подсистемы, рабочие места, теги?	При планах на развитие - миграция, старые лицензии его не поддержат
Сеть проприетарная или на Ethernet?	Проприетарная - точечная замена почти невозможна технически

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

Что в миграции занимает время на самом деле

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

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

• Обследование и снятие логики «как есть». Проекты выгружаются из контроллеров, инвентаризируются шкафы, кабельные трассы и точки ввода-вывода, составляется карта сигналов и алгоритмов по каждой подсистеме. На объектах, переживших несколько подрядчиков, фактическая логика расходится с исполнительной документацией - и верить приходится выгрузке из контроллеров.
• Перепроектирование. Разрабатывается рабочая документация на замещающую систему с сохранением логики работы, адресации сигналов, структуры тегов и набора мнемосхем. Чем точнее сохранена структура, тем меньше переучивается операторская смена.
• Пересчёт параметров регулирования. Параметры ПИД-регуляторов из BMS-линейки Schneider не переносятся в ОВЕН напрямую - коэффициенты пересчитываются и подстраиваются по факту, с обмерами на работающей системе. Это работа на объекте, и её длительность задаётся инерционностью контуров: квалификацией наладчика её не ускорить.
• Поэтапное переключение по графику эксплуатации. Шкафы и компоненты меняются по одному, по графику, согласованному со службой эксплуатации. На время переключения узла соответствующие контуры временно переводятся в ручной режим, а длительные отключения климатического оборудования выносятся за пределы рабочих часов.
• Пусконаладка и передача. Загрузка проектов, проверка алгоритмов, калибровка датчиков, настройка SCADA, мнемосхем и журналов, приёмо-сдаточные испытания, эксплуатационная документация и обучение работе с новым АРМ.

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

Что заложить в ТЗ, если выбрана миграция

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

Минимальный состав требований:

• Перечень подсистем, попадающих под замену, и явное указание тех, что остаются как есть.
• Требование сохранить функционал без сокращений: алгоритмы регулирования, телеметрию, диагностику, журналирование, мнемосхемы. Формулировка «аналогичный функционал» без перечня приводит к спору на приёмке.
• Смежные системы заказчика, которые должны продолжить работать: указать платформу и то, что её переделка в объём не входит; совместимость обеспечивается структурой тегов новой АСУ.
• Режим работы объекта: допустимые окна отключений по каждой подсистеме, возможность временного перевода контуров в ручной режим, ограничения по рабочим часам.
• Требование к обследованию как к отдельному этапу с результатом в виде карты сигналов и алгоритмов - до разработки рабочей документации. Совмещать обследование с монтажом недопустимо.
• Состав пусконаладки: проверка алгоритмов, калибровка датчиков, настройка журналов событий, режимные испытания, отдельно - проверка цепей противопожарной защиты, если обобщённый сигнал заведён в АСУ.
• Комплект передаваемой документации и обучение персонала работе с новым АРМ.
• Отношение к полевому уровню: сохраняется, дополняется, заменяется частично - и по какому критерию принимается решение по каждому датчику.

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

Частые вопросы

Можно ли отложить решение ещё на год, если пока ничего не отказало? Допустимо, и это осознанный первый сценарий - при условии, что год потрачен на подготовку: инвентаризацию состава системы, оценку однородности, проверку наличия среды разработки и резервных копий проектов. Год, потраченный на ожидание, отличается от года, потраченного на подготовку, тем, что во втором случае к моменту первого отказа есть готовое ТЗ.

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

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

Что происходит с датчиками и приводами при миграции? Как правило, ничего - полевой уровень к уходу вендора отношения не имеет и остаётся на месте. Замена отдельных датчиков возникает точечно, когда фактическое состояние прибора не позволяет ему работать дальше, либо когда тип сигнала не согласуется с выбранными модулями ввода-вывода. Это решается по результатам обследования.

Насколько ОВЕН перекрывает функционал линейки TAC? На уровне задач автоматизации инженерных систем здания - перекрывает, что и подтверждается объёмом сохранённого функционала в проекте по Туле: семь подсистем без сокращений. Прямого соответствия «модель в модель» при этом нет, и не надо его искать: часть функций перераспределяется между модулями под новую архитектуру.

А если система не на TAC, а на Modicon в промышленном контуре? Логика трёх сценариев та же, но вес критериев меняется: в технологическом контуре выше цена простоя, а окна для переключений короче. Соответствие серий Modicon и особенности миграции по каждой модели разобраны на отдельной странице - миграция Schneider Electric на ОВЕН.

Источники

• Кейс: замена системы автоматизации Schneider Electric в здании банка в Туле - миграция комплекса TAC Xenta и TAC Vista на ОВЕН и MasterSCADA, семь подсистем, сохранение работы Simple SCADA заказчика, объект не выводился из эксплуатации.
• Миграция Schneider Electric на ОВЕН - таблицы соответствия по сериям Modicon и TAC, этапы миграции, особенности по каждой модели.
• Импортозамещение АСУ ТП по 187-ФЗ - сроки перехода на доверенные решения для объектов критической информационной инфраструктуры.
• Миграция АСУ ТП: Schneider и Siemens на российские контроллеры - обзорный материал по замещению импортных систем автоматизации.

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