Технолог принёс флешку с обновлённым рецептом пастеризации, оператор вставил 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 - удобный канал для технолога, но без разделения «скопировать файл» и «сделать активной версией в ПЛК» объекты регулярно получают «загрузили, а старая осталась». Один раз проходят сценарий на стенде с флешкой, журналом и отключением питания - дешевле, чем спор с лабораторией о времени пастеризации.
Обсуждение