Unity Pro на CODESYS: как оценить сложность своего проекта до запроса КП

Запрос на перенос проекта Unity Pro в CODESYS обычно приходит после того, как решение о замене контроллера Schneider Modicon уже принято - деталей о самой миграции у заказчика пока нет. На этом этапе КП можно получить только диапазоном: «от четырёх недель до полугода» ничего не говорит о конкретном шкафу. Причина разброса в устройстве оценки: трудоёмкость переноса определяется составом проекта, эта зависимость сильнее, чем зависимость от объёма кода, и состав виден в самом проекте раньше, чем начнётся обследование.

Ниже - пять мест в дереве проекта Unity Pro, по которым главный инженер может сам, за час работы в среде разработки, прикинуть, в какую часть диапазона попадёт его объект. Это не замена обследованию - переподстройку регуляторов и восстановление недокументированной логики этим способом не оценить. Но по составу проекта разброс сужается с «от и до» до вменяемой оценки, с которой уже можно идти в бюджет.

Сколько кастомных DFB в проекте и что они делают

Коротко: типовые SFB Schneider закрываются библиотеками CODESYS почти без переделки, кастомные DFB заказчика переписываются вручную - и это основная трудоёмкая часть проекта.

В дереве Unity Pro секция DFB Types показывает список пользовательских функциональных блоков. Это ключевая точка оценки: дальше решает характер блоков, само число почти ничего не говорит:

• DFB - обёртка над стандартным SFB (таймер с дополнительной сигнализацией, счётчик с ограничением диапазона) - переносится быстро, аналог в CODESYS собирается из тех же кирпичей.
• DFB с прямым обращением к системным словам и регистрам контроллера (%SW, %MW с завязкой на конкретную модель Modicon) - самая тяжёлая категория. Такие обращения не имеют прямого аналога в архитектуре ОВЕН и переписываются через комбинацию базовых блоков с проверкой логики заново.
• DFB, реализующий отраслевой алгоритм (свой ПИД с нестандартной структурой, каскадное регулирование, собственная логика защит) - трудоёмкость зависит от того, есть ли на него отдельное описание или логику придётся восстанавливать по факту работы объекта.

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

Какие сети заведены на полевой уровень

Коротко: Modbus TCP переносится один-в-один, а X-Way, X-Bus и EtherWay аналога не имеют и требуют либо полной замены сети, либо временных шлюзов.

В конфигураторе Unity Pro - вкладка Communication - виден список сетевых каналов и протоколов. Три сценария:

Что в проекте	Что это значит для миграции
Только Modbus TCP/RTU на полевые устройства	Сеть переносится без изменений, адресация сохраняется
X-Bus между модулями расширения в одной стойке	Пересобирается автоматически при замене I/O на модули ОВЕН, отдельного проектирования не требует
X-Way, EtherWay между контроллерами или к SCADA	Прямого аналога нет, нужен переход на Ethernet TCP/IP с пересмотром топологии, либо шлюз на переходный период

Смешанная сеть - типичная причина, по которой первоначальная оценка «отличается от того, что сказали на встрече». Если в проекте на объекте несколько контроллеров Modicon связаны между собой по X-Way, это отдельная строка в бюджете, которую не видно до тех пор, пока кто-то не откроет вкладку Communication.

Используется ли встроенная графика Unity Pro как HMI

Коротко: если оператор смотрит на анимацию, нарисованную прямо в Unity Pro, это отдельный проект внутри проекта - целая строка в смете, которую легко упустить, ориентируясь только на объём кода.

У части объектов, особенно небольших технологических узлов, визуализация собрана средствами самого Unity Pro (Operator Screens) вместо отдельной SCADA-системы. Такая графика не переезжает в CODESYS автоматически - CODESYS Visualization устроен по другому принципу, привязки к переменным собираются заново, мнемосхемы перерисовываются.

Проверить просто: если в дереве проекта есть раздел Operator Screens с заполненным содержимым - на объекте нет отдельной SCADA, и в смету миграции нужно закладывать полную пересборку экранов. Если Operator Screens пустой или содержит только диагностические заглушки, а визуализация вынесена на отдельный сервер SCADA (Vijeo Citect, стороннее ПО) - этот риск снят, разговор идёт только про контроллер.

Сколько контуров регулирования и какая у них инерционность

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

Количество PID-контуров в проекте считается быстро - блоки PID_FF, PID2, либо кастомные регуляторы из категории DFB выше. Дальше на первый план выходит инерционность процесса, который держит каждый контур:

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

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

Есть ли в проекте документация «как есть» или только код

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

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

Как читать результат: три профиля проекта

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

Компактный проект. До десяти DFB, все первого-второго типа из списка выше. Сеть только на Modbus. Визуализация вынесена в отдельную SCADA. Контуры регулирования быстрые или их немного. Документация сходится с фактом хотя бы по выборочной сверке. Такой проект укладывается в нижнюю часть диапазона методики - четыре-шесть недель, риски предсказуемы, обследование скорее подтверждает объём работ, чем меняет его.

Проект среднего размера. От десяти до двадцати DFB, среди них есть блоки с обращением к системным регистрам. В сети встречается X-Bus между модулями расширения, но X-Way на уровне контроллеров нет. Часть контуров регулирования держит инерционные процессы. Документация местами расходится с фактом. Такой набор признаков обычно означает два-три месяца и отдельный буфер на пересчёт регуляторов - именно то, что закладывается в график как «переподстройка по факту обмеров», а не как формальность.

Тяжёлый проект. Больше двадцати DFB с блоками третьего типа, X-Way между контроллерами или к SCADA, встроенная графика Unity Pro как основной HMI, инерционные контуры с сезонной зависимостью, документация недостоверна больше чем в одном случае из трёх проверенных. Здесь диапазон методики придётся смещать к верхней границе, а обследование стоит закладывать отдельным оплачиваемым этапом - в таком проекте оно не формальность, а значительная часть трудозатрат.

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

Что заложить в ТЗ

• Выгрузку проекта Unity Pro в XEF/ZEF целиком, вместе с библиотеками DFB и не ограничиваясь программными секциями - без библиотек оценить сложность DFB нельзя.
• Явное указание модели контроллера и версии среды разработки (Unity Pro V11/V13 либо EcoStruxure Control Expert V14+) - от этого зависит состав экспортируемых файлов.
• Перечень сетевых протоколов на объекте с указанием, какие устройства на каком протоколе висят - отдельно от общего описания «сеть на Modbus».
• Ответ на вопрос про встроенную графику Unity Pro: используется ли она как HMI или визуализация вынесена в отдельную SCADA.
• Список контуров регулирования с указанием инерционности процесса и с пометкой, есть ли сезонная зависимость настройки.
• Требование указать, насколько документация «как есть» соответствует факту - хотя бы на основании выборочной сверки, описанной выше.
• Согласованное окно простоя для этапа переключения и приёмо-сдаточных испытаний.

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

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

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

Есть ли смысл делать самостоятельный аудит, если миграция и так поручена подрядчику? Да, хотя бы в объёме этой статьи - подсчёт DFB и проверка вкладки Communication занимают меньше часа. Понимание своих цифр до звонка подрядчику меняет разговор: вместо «сколько это будет стоить» разговор идёт «вот у нас пять DFB третьего типа и X-Way на два контроллера, что это значит для срока».

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

Меняется ли оценка, если часть проекта уже переписана сторонним подрядчиком под другую версию Unity Pro? Да, и обычно в сторону увеличения. Проект, прошедший через несколько рук, чаще содержит смешанный стиль DFB и расхождения между документацией и фактической логикой - оба признака из списка выше стоит проверять внимательнее, чем на проекте с одним автором.

Есть ли смысл переписывать DFB заранее, своими силами, до начала проекта миграции? Как правило нет: сигнатура и внутренняя логика DFB всё равно проверяются на этапе аудита подрядчиком, и самостоятельная переработка код в среде Unity Pro не сокращает объём работ в CODESYS - там блок собирается заново под другую архитектуру памяти. Полезнее потратить это время на сверку документации с фактом, описанную выше.

Источники

• Перевод проектов Unity Pro на CODESYS V3.5 - методика - шесть этапов переноса, таблица рисков по типам элементов проекта, чек-лист подготовки к обследованию.
• Кейс: замена системы автоматизации Schneider Electric в здании банка в Туле - перенос логики BMS на ОВЕН и MasterSCADA, пересчёт параметров ПИД-регуляторов по факту обмеров, сохранение функционала без сокращений.
• Schneider Modicon и TAC без поддержки вендора - три сценария - когда миграция оправдана, а когда разумнее держать склад ЗИП.
• Миграция Schneider Electric на ОВЕН - соответствие серий Modicon, особенности перехода на модули ОВЕН.

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