В пятницу после смены наладчик «на пять минут» подключается к контроллеру с ноутбука в обход коммутатора управления. Online change проходит без ошибок. Через два часа линия встаёт: уставки в retain съехали, watchdog поймал задачу после удлинения цикла, оператор видит на панели старую мнемосхему с новыми тегами. В журнале объекта пусто: кто залил, какой билдом, был ли бэкап application - никто не фиксировал. Утренний разбор начинается с вопроса «это прошивка или проект?» и заканчивается откатом «с флешки, которая лежала в шкафу с прошлого года».
Разбираем обновление runtime (прошивки, образа Linux RT, пакетов среды) и загрузку прикладного проекта по сети как две разные операции с общим риском для линии. Фокус - online change против полного download, retain и persistent, окно смены, откат, кто подтверждает, канал «сеть управления» против «ноутбук в сервисный порт». Не даём пошаговый клик по меню конкретной IDE и не повторяем устройство retain как такового - только то, что нужно, чтобы не уронить работающий объект.
Короткий ответ
Прошивку контроллера и прикладной проект обновляют раздельно, в заранее согласованное окно, с бэкапом текущего application, списком retain/PERSISTENT и проверенным откатом. Online change уместен для точечной правки логики без смены карты памяти; полный download - если менялись типы, GVL retain, библиотеки, визуализация или сам runtime. Заливка с ноутбука в обход сети управления допустима только как аварийный канал с той же фиксацией версии, что и штатный путь. После загрузки проверяют цикл, watchdog, уставки, HMI и связь, и только затем снимают ограничение на выпуск продукции. Без подтверждающего лица со стороны эксплуатации «успешный download» не считается выполненным обновлением.
Две разные операции: runtime и прикладной проект
Инженер часто говорит «обновил контроллер», имея в виду три разных действия. Первое - смена прошивки или образа: ядро, runtime среды (CODESYS 3.5 или MasterSCADA 4D на том же железе), драйверы, сетевой стек. Второе - загрузка application: программа, визуализация, карты связи. Третье - правка параметров на живом объекте без смены кода: уставки, рецепты, force. Смешивать их в одном окне «пока линия стоит» - типичный путь к ситуации, когда непонятно, что откатывать.
Прошивка затрагивает поведение всего устройства. После неё старый проект может не стартовать, смениться порядок задач, появиться другой watchdog timeout, измениться драйвер Ethernet. Прикладной проект живёт поверх уже известного runtime. Если оба меняют в одну ночь, при отказе нельзя понять, виноват образ или ST-блок, залитый «заодно».
Правило, которое выдерживает средний завод: сначала доводят runtime на стенде до той версии, что будет на объекте, прогоняют тот же application, и только потом везут образ в цех. Проект после смены прошивки загружают отдельно, с собственной записью в журнале.
CODESYS и MasterSCADA 4D здесь равнозначны как среды на одном контроллере. Online change, полный download, retain и визуализация есть в обеих логиках, названия диалогов разные, дисциплина одна: не обновлять runtime «потому что вышла минорная сборка», если линия в выпуске и откат образа не отработан.
Online change и полный download: когда какой
Online change - подмена куска логики без остановки задачи, пока карта переменных и библиотеки совместимы. Это удобно на пуске, когда правят условие блокировки или масштаб аналога. Это опасно в эксплуатации, если меняют структуру retain, добавляют поле в STRUCT, двигают порядок GVL, подключают новую библиотеку или пересобирают визуализацию. Среда может согласиться на change, а память после следующего power cycle окажется мусором.
Полный download останавливает application, перезаписывает его и стартует заново. Выходы на время оказываются в состоянии, которое задаёт проект и настройки CPU: hold last, safe, ноль. Если это не согласовано с технологией, насос остаётся включённым или клапан падает в закрытие в неподходящий момент. Download с опцией инициализации retain обнуляет уставки, которые смена копила месяцами.
Практическая развилка такая. Правка одного POU без изменения интерфейсов и retain - кандидат на online change, если объект в режиме, где краткий сбой цикла допустим, и есть человек у панели. Любое изменение типов, карт Modbus, задач, библиотек, визуализации, версии compiler - полный download в окно, когда линия в безопасном состоянии. Смена прошивки - всегда полный цикл: стоп выпуска, бэкап, образ, проверка старта, затем проект, затем технологический прогон.
На стенде online change «всегда проходит». На объекте в тот же момент HMI опрашивает теги, OPC-клиент держит подписки, второй контроллер ждёт межблокировку. Удлинение цикла на 20-40 мс во время change может дать ложную аварию связи или срабатывание watchdog, которое на симуляторе не воспроизводится.
Подробности по RETAIN, PERSISTENT и типам download смотрят до окна, а не после того, как уставки обнулились. Здесь достаточно правила: если менялась карта retain - не online change, а download с явным решением, сохранять значения или инициализировать, и с выгрузкой эталона уставок в файл до операции.
Retain и persistent: что переживёт обновление
Переменные без RETAIN после restart и после полного download живут заново. RETAIN переживает питание и большинство перезапусков runtime, если контроллер штатно пишет область. PERSISTENT (в терминологии IEC - связка persistency с retain) рассчитан на переживание смены application при совместимой раскладке памяти. Совместимость ломается, когда в GVL вставили переменную в середину, сменили REAL на LREAL, переименовали поле структуры или сменили порядок бит в упакованном типе.
Перед обновлением снимают снимок: экспорт значений retain, скрин ключевых уставок с HMI, файл рецептов, шаг последовательности, моточасы, если они в retain. После загрузки сверяют не «контроллер в RUN», а конкретные числа. Расхождение «было 82.4, стало 0» - стоп-кран, даже если линия внешне едет.
Отдельный риск - рецепты и файлы вне application: CSV на USB, каталог на eMMC, область, которую HMI считает своей. Download проекта их не обязан трогать, но смена прошивки или прав доступа runtime может. Сценарий «рецепт с флешки вчера, сегодня новый образ» разбирали отдельно; в чек-листе обновления контроллера это пункт «файлы вне проекта не пострадали».
После холодного старта первый цикл может отработать с нулевыми таймерами и сброшенными шагами SEQ. Если блокировки завязаны на «шаг 7 = норма», линия получит ложный запрет или, хуже, ложное разрешение. В окне обновления закладывают время на проход последовательности вручную или на тестовом материале, а не сразу «в работу с первой катушки».
Окно смены, а не «пока оператор отошёл»
Сеть даёт иллюзию, что залить можно в любой момент: VPN, сервисный порт, Wi-Fi наладчика. Линия так не думает. Окно выбирают по технологии: нет продукта в зоне риска, исполнительные механизмы в безопасном положении, соседние участки предупреждены, что межблокировка может моргнуть.
Минимальный состав окна на среднем объекте: согласованное время с начальником смены, присутствие технолога или оператора, который имеет право остановить и запустить, наладчик с правами на контроллер, канал связи, который не режут «оптимизацией» IT в ту же ночь. Если обновление идёт по сети управления, в окне не проводят параллельно перезагрузку коммутатора и смену правил firewall.
Длительность считают не по прогресс-бару IDE. Закладывают: бэкап, сама загрузка, первый старт, сверка retain, проверка цикла и watchdog, прогон ключевых блокировок, тест HMI, тест связи с соседним ПЛК и с диспетчерской, решение «оставляем / откатываем». Для точечного online change это может быть 20-40 минут. Для прошивки плюс проект - часы, и это нужно сказать заказчику заранее, а не в 22:00.
Ночное «быстро залью, утром расскажу» ломает цепочку подтверждения. Утро начинается с чужой версии в контроллере и пустого журнала.
Кто подтверждает: роли, а не «кто с ноутбуком»
Загрузка application - действие с последствиями для выпуска и безопасности. Его подтверждают как минимум двое: тот, кто выполняет (интегратор, штатный АСУ), и тот, кто принимает риск на смене (мастер, технолог, дежурный инженер). Подпись в журнале объекта: дата, время, контроллер, что меняли (прошивка / проект / оба), идентификатор версии, online change или download, retain сохранён или сброшен, результат прогона, откат не потребовался или выполнен.
Права в IDE не равны праву на объект. Учётная запись наладчика, оставшаяся после пуска, позволяет залить что угодно. Это тема ролей на панели и учёток подрядчика; в контексте обновления достаточно правила: сервисная учётка на загрузку включается на окно и отключается после записи в журнал. Заливка «потому что VPN ещё жив» - обход регламента, даже если файл правильный.
На FAT процедуру обновления прогоняют как сценарий приёмки, не как сюрприз первого года эксплуатации. В программу испытаний включают: бэкап, загрузка заведомо чуть изменённого проекта, сверка, откат к тегу SAT. Если интегратор не умеет откатиться на стенде, на линии он тоже не умеет. См. FAT и SAT без сюрпризов на пуске.
Сеть управления и «ноутбук в обход»
Штатный путь: инженерный ПК или сервер в сегменте АСУ, фиксированный IP, журналирование сессии, маршрут через коммутатор управления. Плюс - трафик виден, можно ограничить порт, проще доказать, кто подключался. Минус - зависимость от этой сети: если её «починили» в то же окно, загрузка рвётся на середине.
Обходной путь: ноутбук в сервисный Ethernet контроллера, прямой кабель, иногда USB. Плюс - работает, когда сеть управления лежит. Минус - нет следа на коммутаторе, легко залить не ту версию, легко оставить другой IP и сломать штатный опрос. После обхода обязательно возвращают сетевые настройки контроллера к паспорту объекта и проверяют, что HMI и SCADA снова видят устройство.
Запрещать сервисный порт совсем неразумно: при аварии сети это единственный способ вернуть CPU в RUN с известным проектом. Регламентировать: пломба или учёт ключа шкафа, запись «работа с локального порта», запрет менять проект без бэкапа даже «на пять минут».
По сети не гоняют образ прошивки одновременно с пиковым опросом 200 устройств Modbus TCP «потому что канал гигабитный». Загрузка большого application конкурирует с циклом и стеком. На время окна снижают посторонний трафик: отладку Wireshark на зеркале, массовый опрос архива, перезагрузку OPC-сервера.
Первый старт среды и подключение интерфейсов на новом контроллере и обновление живого - разные режимы. На новом можно ошибиться IP и переподключить. На живом ошибка IP на 10 минут даёт пропажу межблокировок.
Watchdog, цикл и «успешный» RUN
Зелёный RUN после download не равен готовности линии. Смена библиотек и прошивки часто удлиняет задачу: другой драйвер, другая сериализация визуализации, включённый трассировочный лог «на всякий случай». Watchdog, который на старой сборке молчал, начинает перезапускать задачу или весь CPU.
До обновления фиксируют: целевой цикл, фактический max cycle, настройка watchdog, поведение при срабатывании (стоп CPU, сброс задачи, безопасные выходы). После - те же цифры на том же режиме нагрузки: опрос, архив, HMI открыт. Если max cycle вырос и подошёл к порогу, не открывают выпуск, пока не выяснят причину или не отодвинут watchdog осознанно, с записью в паспорт. Слепое увеличение timeout «чтобы не пищал» маскирует зависание логики.
Сценарий, когда ПЛК уходит в STOP после watchdog и не возвращается в RUN, должен быть в инструкции смены: что делает оператор, кого звонит, какие выходы при STOP. Обновление, после которого CPU при редком пике падает в STOP, хуже, чем отказ от этой сборки до разбора на стенде.
Прошивки с новым сетевым стеком иногда дают краткий шторм на порту при старте. Соседние устройства видят обрыв, блокировки падают. В окне предупреждают смежные участки и смотрят журналы не только «своего» контроллера.
Откат: файл, тег, железо
Откат продумывают до загрузки, не после. Для проекта: сохранённый application той версии, что сейчас в CPU (не «похожий с ноутбука ведущего»), плюс снимок retain. Для прошивки: файл образа, процедура из документации производителя, время, за которое CPU будет недоступен, состояние выходов на это время.
IDE может хранить «последний online», который уже не равен тому, что в контроллере, если коллега заливал с другой машины. Поэтому источник отката - архив объекта: каталог версий, Git-тег, подпись в журнале, не рабочий стол наладчика. Связка с версионированием проектов здесь не про религию веток, а про возможность взять тот же бинарник, который прошёл SAT.
Откат прошивки иногда требует физического доступа, а не только Ethernet. Если это так, в окне должен быть человек у шкафа, не только сессия VPN. Откат, который «сделаем в понедельник, если что», при воскресном обновлении равен отсутствию отката.
После отката повторяют тот же чек-лист, что после прямой загрузки: retain, цикл, HMI, связь. Откат - тоже изменение состояния CPU.
Что проверить после загрузки, прежде чем открыть выпуск
Сверка версии application с журналом и с тем, что среда показывает online. Сверка ключевых retain и уставок с выгрузкой. Проход блокировок, которые трогали в этой версии, и пары блокировок «рядом», которые не трогали, но делят задачу. Запись и чтение уставки с HMI. Качество связи: нет шквала Bad Quality, таймауты на прежнем уровне. Журнал аварий контроллера и HMI: нет новых типов сообщений про библиотеки и лицензии runtime.
Если обновляли визуализацию, оператор проходит экраны, которыми пользуется ночью, не только главную мнемосхему. Новая кнопка «не там» даёт ошибку смены быстрее, чем кривой ПИД.
Пакет, который кладут в архив объекта после успешного окна: файл проекта или commit/тег, файл прошивки, экспорт retain, краткий протокол (время, кто, результат), решение об открытии выпуска. Это стыкуется с пакетом документов при вводе в эксплуатацию: обновление - мини-ввод новой версии, а не «поправили на ходу».
Таблица: шаг обновления, артефакт или условие, стоп-кран
| Шаг обновления | Артефакт / условие | Стоп-кран |
|---|---|---|
| Заявка на окно | Согласование смены, безопасное состояние линии, список затрагиваемых шкафов | Нет подписи эксплуатации; продукт в зоне риска; соседний участок не предупреждён |
| Идентификация цели | Имя CPU, IP, серийный номер, текущая версия runtime и application | Не совпал шкаф или IP; online показывает другую версию, чем журнал |
| Бэкап | Выгрузка application, снимок retain/уставок, копия образа при смене прошивки | Бэкап не открывается на второй машине; нет файла той версии, что в CPU |
| Выбор типа загрузки | Online change только при неизменной карте памяти; иначе полный download; прошивка отдельно от проекта | Среда предлагает change при смене STRUCT retain; пытаются залить образ и проект одним махом |
| Канал связи | Штатная сеть управления; локальный порт только как аварийный с записью | Параллельный reboot коммутатора; загрузка через чужой VPN без журнала |
| Загрузка | Стабильный канал, наблюдатель у панели, выходы в ожидаемом безопасном состоянии | Обрыв mid-download; CPU не в ожидаемом STOP/RUN; выходы не в матрице безопасности |
| Первый старт | Цикл и watchdog в допуске, нет новых fault runtime | Max cycle у порога watchdog; STOP после старта; шторм на сети |
| Сверка данных | Retain, рецепты, шаг SEQ, ключевые уставки = эталон | Ноль вместо рабочей уставки; сдвиг единиц; «чужой» рецепт |
| Функциональный прогон | Блокировки, HMI, связь с соседом и верхним уровнем | Ложная авария; нет записи уставки; Bad Quality на критичных тегах |
| Решение | Запись в журнал, открытие выпуска или откат по готовому файлу | «Поживём до утра» без решения; откат без повторной сверки |
Типовые ошибки при обновлении по сети
Считать online change безобидным патчем. Смена типа в retain и «успешный change» расходятся на первом отключении 24 В.
Обновить прошивку и проект в одном заходе без промежуточной проверки. При отказе неясно, что откатывать первым, линия стоит дольше.
Не выгрузить retain, потому что «мы ничего в уставках не меняли». Полный download с инициализацией памяти меняет сам.
Залить с ноутбука, оставить временный IP. Утром SCADA не видит контроллер, смена лечит перезагрузкой всего подряд.
Не предупредить смежные участки. Короткая потеря Run при download выглядит как авария межцеховой блокировки.
Открыть выпуск по зелёному RUN. Watchdog и операторский экран проверяют позже, когда уже идёт продукт.
Хранить откат только на том же ноутбуке, с которого заливали. Ноутбук в ремонте - объекта без версии SAT.
Вопросы при работе
Можно ли обновлять контроллер по VPN, не выезжая на площадку?
Только если регламент это разрешает, канал стабилен, на объекте есть человек у шкафа и панели, откат прошивки не требует физического доступа, и журнал заполняют удалённо с подтверждением смены. Иначе - выезд или перенос окна.
Online change во время выпуска продукции - норма?
Нет как правило. Исключение - заранее описанный класс правок (текст сообщения, не влияющий на выходы) и письменное разрешение эксплуатации. Логика блокировок и регуляторов - только окно.
Что делать, если download оборвался на середине?
Не повторять «ещё раз» вслепую. Смотрят состояние CPU: STOP, boot, частичный application. Дальше - процедура производителя: повторная загрузка с локального порта или откат образа. Линию не запускают, пока версия и retain не сходятся с эталоном.
Нужно ли после смены прошивки заново проходить SAT?
Полный SAT - нет, если контракт не требует. Минимум: регресс критичных сценариев из программы SAT на стенде, затем то же на объекте в окне. Смена мажорной версии runtime ближе к повторной приёмке, чем к «патчу».
Среда CODESYS и MasterSCADA 4D обновляются по-разному?
Файлы и диалоги разные, чек-лист один: бэкап, окно, retain, цикл, откат, журнал. Нельзя считать, что одна среда «безопаснее для online», а другая «только полный download» - смотрят конкретное изменение и документацию runtime на этом железе.
Кто хранит файлы прошивки?
Заказчик в архиве объекта плюс копия у службы, которая имеет право обновлять. Интегратор не должен оставаться единственным владельцем образа после акта.
Ссылки по теме
- Retain в CODESYS 3.5: VAR RETAIN, PERSISTENT и Download;
- ПЛК в STOP после watchdog: не уходит в RUN;
- FAT и SAT: приёмка АСУ ТП без сюрпризов на пуске;
- Версионирование проектов ПЛК: Git на практике;
- Первый старт CODESYS 3.5: документация, подключение, интерфейс;
- Пакет документов при вводе АСУ ТП в эксплуатацию.
Обсуждение