Смена приняла партию, на экране выбрали рецепт «Молоко 3,2%», подтвердили пуск линии. Через час лаборатория показывает жирность не из той вилки. В журнале видно: загружен рецепт с версией 12, а по производственному заданию должна была быть версия 14 с другим временем пастеризации. Оператор уверяет, что нажимал правильную кнопку. Кнопка была правильная. Версия - нет.
Разбор не про «внимательность персонала», а про то, где в цепочке HMI - ПЛК - MES теряется привязка версии рецепта, кто подтвердил запуск и что должно было заблокировать пуск при несовпадении материала или допуска. Полный стандарт ISA-88 здесь не разбирается; только практические узлы, где ошибка становится возможной на реальном объекте.
Короткий ответ
Неверный рецепт запускается, когда оператор выбирает устаревшее имя без отображения версии, подтверждение не фиксирует пару «рецепт + версия + партия», а ПЛК не сравнивает загруженные параметры с эталоном из задания. Нужны явная версия на экране, двухшаговое подтверждение с записью в audit trail, блокировка пуска при расхождении кода материала и автоматическая проверка checksum рецепта в контроллере перед разрешением.
Имя рецепта и версия - разные сущности
Оператор мыслит названием: «Йогурт клубника». Система хранит структуру параметров с полем Version или Revision, которое меняется при каждой корректировке времени выдержки, температуры или дозировки. На HMI список рецептов часто показывает только имя. Две версии с одним именем визуально неотличимы.
Правило интерфейса: в списке выбора всегда «Имя v14» или «Имя (14) от 2026-03-01». При загрузке в ПЛК передавать не только номер рецепта, но и revision. Контроллер отклоняет загрузку, если revision не входит в список допущенных для текущего SKU.
История на объектах без версионирования: технолог выпускает «йогурт_финал», «йогурт_финал_2», операторы запоминают «второй», новый сотрудник жмет первый. Версия в данных решает это без переименования всего каталога.
Подтверждение, которое что-то значит
Кнопка «Пуск» с одним нажатием не оставляет следа, кроме факта старта. Подтверждение должно включать: кто (роль и пользователь), что (ID рецепта, версия, партия), когда (метка времени с синхронизированными часами), откуда (локальный HMI или задание из MES).
Двухшаговая схема: выбор рецепта, экран сверки параметров с заданием, явное «Подтверждаю запуск версии 14 для партии 2026-047». Второй шаг нельзя пропустить горячей клавишей. Для критичных продуктов добавляют второго подписанта с ролью старшего оператора или технолога.
Запись в журнал действий оператора должна быть необратимой в рамках прав оператора и доступной для аудита. «Стереть строку» без роли администратора ИБ недопустимо. Если журнал только на HMI без передачи в архив, при смене панели следы теряются.
Audit trail: что искать после инцидента
После брака поднимают цепочку: задание MES или сменное задание, выбор на HMI, команда загрузки в ПЛК, факт перехода в автомат. Разрыв в любой точке объясняет, где версия «потерялась».
Типичные дыры: MES отдал версию 14, HMI показал 14, но в ПЛК загрузился последний использованный буфер версии 12 из retain; оператор сменил рецепт после загрузки задания, но до пуска без повторной сверки; наладчик вчера тестировал версию 12 и оставил ее активной в контроллере.
Журнал должен содержать события LOAD_RECIPE, CONFIRM_START, ABORT и смену пользователя. Без LOAD с номером версии разбор превращается в опрос смены.
Контроль допуска материала
Даже верный рецепт с неверным сырьем дает неверный продукт. Штрихкод партии сырья, RFID или ручной ввод кода должен сопоставляться с таблицей допуска: материал A допускает рецепты {R1 v14, R2 v3}, материал B - другой набор.
Блокировка на уровне ПЛК: пока sMaterialCode не совпадает с sRecipeAllowedMaterial для выбранной версии, bAllowStart остается FALSE. HMI может показывать красное сообщение, но решение о пуске должно дублироваться в контроллере. Обход только через роль наладчика с записью причины.
Сканер на линии иногда читает код быстрее, чем оператор успевает подтвердить рецепт. Порядок операций в процедуре: сначала сканирование материала, затем предложение допустимых рецептов, затем подтверждение. Обратный порядок почти гарантирует инцидент при спешке.
Таблица: событие, где версия потерялась, workflow
| Событие / симптом | Где версия потерялась | Что добавить в workflow |
|---|---|---|
| В журнале рецепт 12, в задании 14 | HMI не передал revision в ПЛК при загрузке | Передавать пару ID+version, логировать LOAD с обоими полями |
| Оператор выбрал верное имя | Список без версий, в ПЛК осталась старая | Показ версии в списке, запрет пуска при mismatch с заданием |
| После смены задания старый рецепт | Нет принудительной перезагрузки при новом SKU | Сброс активного рецепта при смене заказа из MES |
| Наладчик тестировал, смена не знает | Retain последнего рецепта в ПЛК | Процедура сдачи смены: сверка активной версии |
| MES не пришел, оператор выбрал вручную | Нет offline-политики версий | Белый список версий для ручного режима с подписью |
| Два одинаковых имени в каталоге | Дубликаты в базе рецептов | Уникальность имени+version, checksum тела рецепта |
| Пуск без скана материала | Допуск не проверяется в ПЛК | Interlock материал-рецепт до CONFIRM_START |
| Версия верная, параметры нет | Загрузили заголовок без тел | Проверка CRC или hash параметров после LOAD |
| Оператор отменил, линия все же стартовала | Пуск не зависел от подтверждения | Старт только по rising edge подтвержденного флага |
Роли, обходы и человеческий фактор
Любой bypass «для ускорения» обнуляет проектирование. Если старший оператор может запустить без скана, это должно быть редким событием с обязательным комментарием и уведомлением технолога. Иначе обход становится нормой к концу месяца.
Обучение смены - не про запоминание номеров, а про чтение экрана сверки: версия, партия, три ключевых параметра, которые оператор понимает физически (температура, время). Цветовая индикация совпадения с заданием зеленым снижает ошибки быстрее, чем дополнительный клик.
Связка HMI и ПЛК без двойных источников
Источник истины для активного рецепта - ПЛК. HMI отображает и инициирует загрузку, но не хранит «текущую версию» только у себя. При reconnect экран читает из контроллера, а не из локального кэша вчерашнего дня.
При редактировании рецепта технологом старые версии не удаляют без архива. Статус «устарела» скрывает их из операторского списка, но оставляет в истории. Иначе через полгода невозможно воспроизвести, что гоняли в марте.
Интеграция с MES и сменным заданием
Когда линия получает заказ из MES, в сообщении должны быть SKU, номер версии рецепта и идентификатор партии. HMI не должен позволять оператору выбрать рецепт вне списка, переданного с заданием, кроме режима аварийного ручного выбора с повышенной ролью. Автоматическая загрузка рецепта при сканировании баркода сменного задания снижает ошибку «выбрал из привычки вчерашний».
При обрыве связи с MES политика должна быть записана: либо работа по последнему валидному заданию с блокировкой смены SKU, либо останов до восстановления. Промежуточное «оператор сам выберет что-нибудь похожее» - источник инцидентов.
Редактор рецептов и права технолога
Технолог меняет параметр и сохраняет рецепт. Без автоматического инкремента версии и записи автора изменение остается невидимым для смены. Редактор должен требовать комментарий к выпуску новой версии и запрещать перезапись released-версии на месте: только новая revision с новым номером.
Тестовая версия (draft) не должна попадать в операторский список до явного release. На объектах, где draft и release в одной таблице без флага, оператор запускает недоделанную версию после того, как наладчик «на минутку проверил».
Checksum и тело рецепта
Номер версии в заголовке без контроля тела рецепта бессмысленен: версия 14 в надписи, а параметры от версии 13 после ручной правки в базе. При загрузке в ПЛК вычисляйте hash или CRC набора параметров и сравнивайте с эталоном для данной revision. Несовпадение - блокировка и сообщение «тело рецепта не соответствует версии».
Эталонные hash хранят в таблице released-версий, которую меняет только технолог. ПЛК или HMI не вычисляют «на глаз», а сверяют с записью из защищенного справочника.
Обучение смены без лекций на два часа
Короткая процедура на посту: перед пуском прочитать три строки на экране сверки - продукт, версия, партия. Если любая строка не зеленая - стоп и старший оператор. Плакат у панели с примером «правильно/неправильно» дешевле одной бракованной партии.
Разбор инцидентов без наказания, но с показом журнала, учит лучше, чем абстрактные правила. «Вот здесь вы подтвердили v12, а в задании было v14» - нагляднее теории ISA-88.
Workflow на экране: минимальный набор экранов
Экран выбора заказа или сменного задания показывает только допустимые SKU. Экран выбора рецепта фильтруется по SKU и показывает версию крупно. Экран сверки выводит три ключевых параметра рядом с эталоном из задания. Экран подтверждения требует удержания кнопки 2 секунды или второго клика «Да, версия 14» - случайный двойной тап по «Пуск» не должен запускать линию.
Отдельный экран «активный рецепт» на главной мнемосхеме дублирует имя, версию и время загрузки. Оператор видит ошибку до того, как нажмет пуск следующей операции.
После инцидента
Оформите разбор по данным, не по виноватым: восстановите timeline из журнала, сравните checksum параметров в ПЛК с эталоном версии 14, проверьте, был ли тест наладчика. Внесите изменения в workflow и повторите сценарий на стенде: попытка пуска с версией 12 при задании 14 должна заканчиваться блокировкой и понятным сообщением.
Частые вопросы
Достаточно ли показывать версию мелким шрифтом?
Нет. Версия - часть идентификатора, она должна быть в том же поле внимания, что и имя.
Кто владелец таблицы допуска материал-рецепт?
Технолог с версионированием при смене SKU. АСУ ТП внедряет проверку, технолог задает содержание.
Нужен ли MES для контроля версий?
Желательно на крупных линиях. На малой линии достаточно HMI+ПЛК при дисциплине журнала и checksum.
Как не замедлить смену?
Сверка занимает секунды, брак партии - смены. Скан и автофильтр рецептов ускоряют, а не тормозят.
Обсуждение