Импортозамещение ПЛК: Ловушка «теги совпали - проект перенесен»

На миграции ПЛК есть опасная фраза: «Теги совпали, значит проект перенесен». Обычно она появляется в момент, когда новый контроллер уже опрашивается из SCADA, на экране видны знакомые имена переменных, часть кнопок реагирует, тренды рисуются, а команда хочет быстрее закрыть задачу. Снаружи система действительно выглядит почти как старая. Но для АСУ ТП внешний вид - слабое доказательство.

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

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

Проект ПЛК нельзя считать перенесенным только потому, что SCADA или HMI видит знакомые имена тегов. Нужно проверить инженерный смысл сигналов, типы данных, масштабирование, порядок обновления, аварийные сценарии, операторские действия, сеть и восстановление после сбоев. Миграция должна проходить как отдельный проект с FAT: на стенде проверяют не только чтение переменных, а поведение объекта в нормальных, аварийных и переходных режимах.

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

Если при миграции создать в новом проекте тег с тем же именем, SCADA будет довольна. Лампочка снова станет зеленой. Но если новое условие готовности вычисляется проще, объект может начать пускаться раньше, чем должен. Для оператора это выглядит как «экран тот же». Для механики и технолога - уже другой объект.

Такая разница редко ловится статической таблицей “старый тег - новый тег”. Таблица полезна, но она проверяет наличие адреса, а не смысл. В реальной миграции рядом с именем нужно держать описание: откуда сигнал берется, что означает, когда меняется, кто имеет право его записывать и что происходит при отказе.

Один из самых неприятных классов ошибок при переносе - несовпадение типов данных и масштабов. На экране значение может выглядеть правдоподобно, но быть уже не тем. Давление было целым числом с коэффициентом пересчета, стало REAL; счетчик был беззнаковым, стал знаковым; время раньше задавалось в миллисекундах, а новая библиотека ожидает секунды. Пока система работает в спокойном диапазоне, ошибку можно не заметить.

На объекте это проявляется странно. Счетчик вдруг переполняется не там, где ожидали. Уставка принимается, но фактический диапазон другой. Аналоговый вход 4-20 мА вроде пересчитывается, но аварийный порог срабатывает раньше. Битовая маска аварий читается, но один бит “уехал” на соседнюю позицию. Все это не похоже на большой отказ. Скорее на серию мелких, раздражающих дефектов, которые всплывают после пуска и портят доверие к новой системе.

Поэтому при миграции нужно сравнивать не только имя тега, но и инженерную семантику. Для критичных сигналов фиксируют тип, единицы измерения, диапазон, масштаб, направление обмена, допустимые границы, реакцию на обрыв и bad quality. И лучше делать это не в стиле “переменная A соответствует переменной B”, а в стиле “давление после фильтра, бар, 0-10, авария ниже 1.5, при обрыве датчика - недостоверность и запрет автостарта”. Тогда команда проверяет технологический смысл, а не совпадение букв.

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

Если объект простой, разница может не сыграть роли. Но в дозировании, счетчиках импульсов, быстрых блокировках, позиционировании или плотной логике interlock временная модель уже влияет на поведение. Фронт, который раньше ловился стабильно, теперь иногда пропускается. Таймер, который раньше был “запасом”, становится заметной задержкой. Фильтр, который спасал от дребезга, начинает запаздывать. Код при этом может быть “логически тот же”.

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

Аварийная логика особенно плохо переносится “по тегам”. В старом проекте авария могла иметь задержку срабатывания, фиксацию до подтверждения, запрет автоматического возврата, отдельный класс в журнале и особую индикацию на панели. Если перенести только бит Alarm, внешне все будет почти нормально: красное сообщение появляется. Но половина смысла уже потеряна.

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

При миграции аварии нужно проверять как истории: что должно случиться, что увидит оператор, что сделает ПЛК, можно ли сбросить ошибку без устранения причины, попадет ли событие в журнал и как объект вернется в работу. Это не всегда весело гонять на стенде, зато именно такие проверки отделяют перенос проекта от “лампочки загорелись”.

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

Кнопка “Пуск” раньше могла писать короткий импульс, а после переноса держит бит постоянно. Уставка раньше требовала подтверждения, а теперь уходит сразу. Ручной режим раньше полностью жил в ПЛК, а теперь часть состояния дублируется на HMI. Цвет “готов” выглядит тем же, но раньше он учитывал блокировки, а теперь показывает только отсутствие аварии.

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

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

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

Особенно опасно, когда старая система годами жила на неформальных настройках. Где-то SCADA терпела длинный таймаут, где-то драйвер молча держал последнее значение, где-то после перезапуска нужно было вручную обновить соединение. При переносе все это становится “невидимым наследством”. Если его не проверить, новая система формально работает, но при первом сетевом сбое дает другую картину: устаревшее значение без bad quality, потерянное событие, неправильное время в архиве или команда, оставшаяся в старом состоянии.

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

Если ПЛК переносится на новый стек, FAT нужен не для красивого протокола. Он нужен, чтобы спокойно сломать систему на стенде до того, как она встретится с производством. На объекте каждая ошибка сразу превращается в простой, давление смены и быстрые решения. На стенде можно искать первопричину без фонового шума.

Минимальный FAT для миграции ПЛК удобно собрать вокруг нескольких блоков:

Хороший FAT отвечает на простой вопрос: что именно проверено до выезда и какие риски остались. Если в протоколе есть только “теги читаются”, это не приемка миграции, а демонстрация связи. При замене ПЛК нужно видеть, как система ведет себя в нормальной работе, в аварии, при потере связи, после перезапуска и при ошибочном действии оператора.

Подход к приемке АСУ ТП подробнее разобран в статье «FAT и SAT: приемка АСУ ТП без сюрпризов на пуске». Для миграции ПЛК этот материал особенно полезен: стенд нужен не ради галочки, а ради сохранения управляемости объекта.

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

Если после этого остается понятный протокол FAT, план SAT на объекте, актуальные резервные копии и обновленная документация, миграция становится управляемой. Если же есть только таблица тегов и уверенность “ну оно же читается”, проект пока не перенесен. Он подключен. Разница между этими словами на пуске очень быстро становится материальной.

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

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

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

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

Откат оставили “на случай чего”. Если откат не проверен заранее, в окне работ он превращается в импровизацию. Для действующего производства это слишком дорогой формат творчества.

При переходе на новые ПЛК и панели СТАБУР миграцию лучше рассматривать не как замену одной коробки на другую, а как проверяемый инженерный проект. Среда разработки, модули I/O, HMI, сеть и документация должны сходиться в одном пакете испытаний. Тогда новый контроллер становится не “похожим на старый по тегам”, а реально готовым к эксплуатации.

•Импортозамещение АСУ ТП: честные итоги двух лет и где все еще болит;

•FAT и SAT: приемка АСУ ТП без сюрпризов на пуске;

•Паспорт объекта АСУ ТП после пуска: что передать заказчику;

•Почему оператор обходит HMI: человеческий фактор;

•Git для проекта ПЛК: минимальный регламент для малой команды.