Блог

Рецепт загрузили с USB, а на объекте осталась старая версия

Технолог принёс флешку с обновлённым рецептом пастеризации, оператор вставил USB в панель, выбрал файл Yogurt_v15.csv, система показала «загрузка успешна». На экране сверки время выдержки всё ещё 12 минут, а не 14 из письма технолога. В журнале есть строка IMPORT, но активная версия в заголовке рецепта - 13. Файл на флешке точно новый: технолог только что сохранил его в офисе.

Разбор не про выбор неверного рецепта из списка и не про путаницу «квитировать» и «сброс аварии». Здесь цепочка носитель - путь файла - кэш HMI - запись в ПЛК: загрузка формально прошла, а runtime продолжает работать со старой версией в памяти контроллера или с копией из другой папки. Разбираем права записи, подтверждение оператором, версию в заголовке файла и проверки после импорта с USB.

Короткий ответ

После загрузки рецепта с USB старая версия остаётся активной, если файл импортировали не в ту директорию, HMI показал успех по копированию на диск панели без передачи в ПЛК, сработал кэш списка рецептов или не хватило прав на перезапись released-версии. Проверьте путь назначения импорта, номер версии в заголовке файла и в активном рецепте ПЛК, событие LOAD в журнале с парой имя+version, затем принудительную загрузку в контроллер с подтверждением оператора. Без сравнения checksum или revision после импорта «успех» на экране ничего не гарантирует. Отличие от «не тот рецепт»: оператор выбрал правильный файл, но слой записи не обновил активную версию.

USB и путь файла: куда реально попал рецепт

Панель оператора и ПЛК с HMI часто имеют несколько хранилищ: каталог импорта на флешке, папка Import на eMMC панели, рабочая база рецептов runtime, буфер в ПЛК. Сообщение «файл загружен» может означать только копирование с USB в папку инженера, без вызова процедуры LoadRecipe в контроллер.

Типовые ловушки пути: оператор выбрал файл из корня флешки, а актуальная копия лежит в подпапке Recipes/Release/; на флешке два файла с похожими именами Yogurt_v15.csv и Yogurt_v15(1).csv, импортировался старый; импорт пошёл в staging, а экран сверки читает активный рецепт из ПЛК, который не менялся.

Регламент: после вставки USB экран показывает полный путь и version из заголовка файла до нажатия «Импорт». После импорта - второй экран: «в ПЛК загружена версия X» с обязательным подтверждением, не автозакрытием через 2 секунды.

Технолог сохраняет файл с уникальным именем: Yogurt_2026-08-03_v15.csv, а не перезапись Yogurt.csv на флешке, где оператор привык брать «тот же файл».

Кэш HMI и список рецептов на экране

HMI кэширует список рецептов и метаданные для быстрого открытия экрана выбора. Импорт с USB обновил файл на диске, но список на экране остался от вчерашнего сеанса до перезапуска runtime или до явной команды «обновить каталог».

Симптом: в файловом менеджере инженера видна v15, в операторском списке по-прежнему отображается v13 без пометки «обновлён». Оператор не «выбрал не тот рецепт» - он не видел, что каталог устарел.

Процедура после импорта: RefreshRecipeCatalog или перезапуск HMI-службы по регламенту; запись в журнал CATALOG_REFRESH с версией. На объектах без такой команды наладчик перезагружает панель - грубо, но снимает кэш. Web HMI с обрывом сессии - другой класс проблем, но общий принцип: клиент показывает не то, что в источнике истины.

Источник истины для активного рецепта - ПЛК. HMI после reconnect должен читать revision из контроллера, а не из локального кэша вчерашнего дня.

Подтверждение оператором: успех копирования ≠ успех загрузки

Двухэтапная схема снижает риск: этап 1 - импорт файла на панель (копирование); этап 2 - загрузка в ПЛК с экраном сверки ключевых параметров и кнопкой «Подтверждаю версию 15». Если интерфейс объединяет оба шага в одну кнопку «Загрузить с USB», оператор видит одно сообщение об успехе, хотя этап 2 не выполнился из-за ошибки прав или таймаута связи с ПЛК.

Журнал действий оператора должен различать IMPORT_FILE и LOAD_RECIPE_TO_PLC с полями version и checksum. Одна строка «загрузка OK» без version бесполезна при разборе.

Роль оператора без права записи released-рецепта: импорт в staging проходит, перезапись active - нет. На экране «успех», в ПЛК v13. Нужна роль технолога для commit или процедура «импорт → ревью → release» с матрицей ролей.

Версия в заголовке файла и в теле рецепта

Файл называется v15, внутри CSV поле Version=13 забыли обновить. Импорт честно загружает 13. Технолог смотрит на имя файла в проводнике, оператор - на заголовок на экране после загрузки.

Правило редактора: при сохранении на USB автоматически синхронизировать имя файла, поле Version в заголовке и комментарий выпуска. Контрольная сумма тела рецепта (CRC32) в заголовке - при несовпадении импорт отклоняется с явной ошибкой, а не «успехом» со старыми данными.

Экран сверки после LOAD показывает три строки: имя, version, два-три ключевых параметра (время, температура), которые технолог менял в этом выпуске. Оператор сверяет с бумажным листом, а не только с надписью «успешно».

Права записи, read-only и вторая копия базы

Папка рецептов на панели смонтирована read-only после сбоя файловой системы - импорт пишет во временный каталог, который runtime не читает. Права пользователя Windows/Linux на промышленной панели иногда сбрасываются после обновления; служба HMI не может перезаписать recipes.db.

ПЛК принимает LOAD, но retain последнего активного рецепта восстанавливает v13 после перезагрузки, если новая версия не помечена как active в энергонезависимой области. Симптом: «после загрузки с USB было 14 минут, после отключения 24 В снова 12». Нужна процедура commit active version в NVRAM и проверка после power cycle.

Две копии базы: recipes.db и recipes_backup.db; импорт обновил backup, runtime читает primary. Редко, но на объекте после «восстановления» IT перепутали файлы местами.

ПЛК не обновился при успехе на HMI

Связь HMI-ПЛК: импорт локальный, команда LOAD не ушла из-за обрыва Ethernet, ПЛК в STOP, или блокировка записи рецепта пока линия в автомате. HMI показал успех по локальному файлу.

Проверка: в online ПЛК смотреть переменные ActiveRecipeVersion, RecipeLoadDone, флаг ошибки. На HMI - не закрывать экран, пока не пришёл feedback version match из контроллера.

Если рецепт хранится только в ПЛК, а USB импортирует только в HMI-проект без download в контроллер - классическая архитектурная дыра. Регламент импорта должен совпадать с архитектурой: куда попадает файл и кто инициирует LOAD.

Отличие от «оператор запустил не тот рецепт»

Там оператор выбрал имя из списка, но revision не совпала с заданием. Здесь файл и имя верные, импорт с USB прошёл, а активная версия в runtime не сменилась. Журнал покажет IMPORT без следующего LOAD, или LOAD с version 13 при файле v15.

Разбор инцидента начинают с цепочки слоёв, а не с опроса смены «какую кнопку жали».

Симптом, слой и проверка

Симптом Слой (носитель / HMI / ПЛК) Проверка
«Успех», параметры старые HMI: импорт без LOAD в ПЛК Журнал: есть IMPORT, нет LOAD; online version в ПЛК
В файле v15, на экране v13 Файл: несовпадение имени и заголовка Открыть CSV; поле Version; CRC
Новый файл в папке, список старый HMI: кэш каталога Refresh каталога; restart runtime
После reboot снова старая ПЛК: retain / не commit active Power cycle test; NVRAM active flag
Импорт только в Import/, не в базу Путь: staging vs production Путь в журнале; регламент commit
Технолог не может перезаписать Права: read-only / роль Роль release; mount rw; ошибки FS
LOAD в журнале, параметры старые ПЛК: загрузили не тот slot Номер recipe ID; несколько слотов
USB OK, через час снова старое MES или master перезаписал Кто последний пишет active; приоритет
Два файла на флешке Носитель: выбран не тот файл Уникальные имена; дата в имени
Оператор не видел экран сверки HMI: пропущен шаг подтверждения Включить обязательный второй шаг

Вопросы с пуска

Достаточно ли сообщения «импорт завершён»?
Нет. Нужны version в ПЛК и событие LOAD с checksum.

Кто должен нажимать «загрузить в контроллер»?
По регламенту: оператор после сверки или технолог с ролью release. Не оставлять только копирование на диск.

Нужно ли вынимать USB сразу?
После подтверждённого LOAD - да. Пока идёт импорт - нет. Вынимание до commit - риск битого файла.

Помогает ли переименование файла в v15?
Только если Version внутри тоже 15. Имя - не источник истины.

Что писать в журнал?
IMPORT path, LOAD version, user, результат compare с эталоном, отказ с причиной.

Как проверить на FAT?
Сценарий: USB с новой version, импорт, сверка, power cycle, повторная сверка.

Формат файла, кодировка и повреждённый импорт

CSV с разделителем «точка с запятой» из Excel открывают на панели с ожиданием запятой - импорт «успешен», распарсились три поля из сорока, в ПЛК ушли значения по умолчанию из предыдущей версии. Сообщение об успехе относилось к копированию байтов, не к валидации схемы.

Кодировка UTF-8 vs Windows-1251 ломает кириллицу в комментариях, а иногда и числовые поля, если парсер ошибся на спецсимволе. Валидация после импорта должна сравнивать checksum тела, а не только факт записи файла.

Повреждённая флешка или вынимание USB до завершения записи даёт усечённый файл. HMI копирует то, что есть; LOAD отклоняется или загружает частичную структуру. Регламент: дождаться 100 % прогресса, проверить размер файла на панели против оригинала на ПК технолога.

Сценарий проверки на стенде перед вводом в эксплуатацию

Подготовьте флешку с двумя версиями одного рецепта: v13 и v15 с различием в одном параметре, который оператор видит на экране сверки. Прогон: импорт v15, подтверждение, сверка, запись в журнал, отключение 24 В, включение, повторная сверка. Затем импорт v13 поверх без commit - убедиться, что система не даёт silent rollback без записи в журнал.

Отдельно проверьте роль оператора: импорт в staging без права release. Ожидаемое поведение - файл на диске новый, active в ПЛК старый, явное сообщение «требуется технолог», а не «успех».

Аудит после инцидента: цепочка событий

Поднимают лог HMI и ПЛК за интервал импорта: IMPORT_FILE, CATALOG_REFRESH, LOAD_RECIPE, RECIPE_COMMIT, USER_LOGIN. Разрыв между IMPORT и LOAD объясняет большинство случаев «флешка была новая». Разрыв между LOAD и COMMIT - retain и права.

Сравнивают checksum файла на USB, копии на панели и блока параметров в ПЛК. Три несовпадающих значения указывают слой, где остановилась цепочка.

Интеграция с MES и приоритет записи

Если MES ночью отдаёт рецепт в ПЛК, а днём технолог грузит с USB, без правила приоритета последний writer wins непредсказуемо. Запишите: USB release технолога перекрывает MES только после явного commit и записи в журнал действий оператора.

При обрыве MES политика offline должна быть известна: USB разрешён с подписью, но с проверкой version на экране, а не «залили и забыли».

На практике

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

Ссылки по теме

Обсуждение