На запуске производства эта дискуссия возникает почти неизбежно. Технолог говорит: «рецепт должен быть в системе, чтобы видеть версии и партии». Интегратор отвечает: «проще записать набор уставок в ПЛК, он и так управляет установкой». IT-служба просит единый справочник, журнал изменений и права доступа. А эксплуатация хочет одного: чтобы при обрыве связи линия не встала из-за красивой архитектуры.
Все стороны по-своему правы. Проблема начинается, когда слово «рецепт» используют для разных вещей: для утвержденной рецептуры продукта, для задания на конкретную партию, для набора чисел в регистрах контроллера и для алгоритма, который физически открывает клапаны, держит температуру и останавливает процесс при аварии.
Короткий ответ такой: MES должна владеть производственным контекстом, версией рецепта и фактом выполнения партии, а ПЛК - безопасно исполнять принятые параметры на оборудовании. ПЛК не обязан каждый цикл спрашивать разрешение у MES, но и превращать контроллер в единственную базу рецептур опасно: теряются версии, согласования, отчеты и понятная ответственность.
ISA-95 простым языком: не этажи ради схемы, а границы решений
ISA-95 часто показывают как пирамиду из нескольких уровней. В реальном проекте от нее полезно оставить не рисунок, а один вопрос: кто принимает решение и кто отвечает за достоверность данных.
На верхнем уровне ERP планирует: сколько продукции требуется выпустить, к какому сроку, из какого заказа возникла потребность. ERP не должна выбирать момент открытия конкретного клапана.
MES находится ближе к цеху. Она знает, какая партия сейчас выпускается, какая утвержденная версия рецепта ей назначена, какое сырье списано, какая операция выполнена и какой отчет должен появиться после окончания. Здесь живет производственная идентичность продукта: партия, маршрут, статус, прослеживаемость, результаты и отклонения.
SCADA и HMI дают оператору рабочее окно процесса: состояния, тревоги, тренды, ручные действия в разрешенных пределах. Их роль важна, но экран оператора сам по себе не должен становиться владельцем рецептуры только потому, что через него вводят значения.
ПЛК управляет машиной в реальном времени. Он принимает допустимый набор параметров, проверяет готовность и ограничения, ведет последовательность оборудования, читает датчики, командует приводами и в любой момент обязан поставить безопасность выше производственного задания.
Полевой уровень - датчики, клапаны, двигатели, преобразователи - дает измерение и выполняет воздействие. Он не знает, что сегодня выпускается партия крема или раствора версии 17; это уже контекст верхних систем.
Общий принцип ISA-95 в прикладном виде звучит так: чем ближе решение к физическому риску и реальному времени, тем ближе оно к ПЛК; чем ближе данные к партии, версии, качеству и отчетности, тем ближе они к MES.
Ранее мы подробно разбирали, как связать уровни цеха и MES в материале «ISA-95 без теории: как связать уровни цеха, MES и ERP без хаоса в интеграциях». Здесь вопрос уже конкретнее: где провести границу именно для рецепта и данных производства.
Один рецепт - две разные сущности
Представим, что линия выпускает продукт по рецепту R-204, редакция 12. Для MES это не просто набор уставок. Это утвержденная версия, связанная с номенклатурой, заказом, партией, допусками, статусом разрешения к производству и, возможно, процедурой согласования.
Для ПЛК рецепт в момент работы выглядит иначе. Контроллеру нужны конкретные исполняемые данные: температура выдержки, время перемешивания, скорость привода, разрешенный выбор оборудования, предельные рабочие диапазоны. Эти значения должны попасть в него в проверяемой форме и быть зафиксированы на время выполнения операции.
Отсюда полезное разделение:
•Мастер-рецепт - утвержденная производственная версия. Ее создает, хранит, версионирует и выдает в работу MES либо другая назначенная система управления рецептами.
•Исполняемый экземпляр - принятая ПЛК копия параметров для конкретной партии или операции. Она нужна, чтобы оборудование работало устойчиво, даже если соединение с верхним уровнем кратковременно пропало.
•Алгоритм и защитные границы - программа ПЛК: последовательность исполнительных действий, блокировки, аварийные пороги, проверки исправности и разрешения. Это не «рецепт от MES», а часть АСУ ТП и безопасности машины.
Если MES выдает температуру 82 градусов, а инженерный предел нагревателя установлен до 75, ПЛК не должен послушно принять команду и ждать, пока отчет в MES станет красным. Он должен отклонить задание и вернуть причину отказа. Верхняя система задает допустимое производственное намерение, контроллер подтверждает, что оно выполнимо и безопасно на конкретном оборудовании.
Это не статья о том, как раскладывать batch на фазы и операции. Такой подход подробнее разобран в материале «ISA-88 batch на практике: рецептура, этапы и единица оборудования без академического тумана». Здесь важнее не структура процедуры, а владельцы информации на границе MES и АСУ ТП.
Кто владелец данных: таблица, которую стоит согласовать до разработки
Спор «чей это тег» нельзя закрыть фразой «его пишет MES» или «он лежит в ПЛК». Физически значение может храниться в нескольких местах. Владелец - это система или функция, которая определяет его смысл, правила изменения и источник истины при расхождении.
У этой таблицы есть важная оговорка: владелец качества не всегда MES. На предприятии с отдельной LIMS или QMS именно она может утверждать лабораторный результат и выпуск продукции. Тогда MES не «придумывает качество», а связывает решение качества с партией и передает дальнейший статус производству.
Что должно оставаться в ПЛК
Идея «вынесем все рецепты в MES» иногда доходит до опасного абсурда: контроллеру оставляют лишь команды включить или выключить механизм, а вся логика разрешений пытается жить наверху. Так делать не нужно.
В ПЛК должны оставаться:
1.Алгоритмы управления механизмами и последовательностями, которые требуют детерминированного исполнения.
2.Межблокировки, аварийные остановы, защиты оборудования и проверка готовности.
3.Инженерные минимумы и максимумы, которые нельзя превысить ни рецептом, ни ручным вводом, ни ошибочным обменом.
4.Принятый исполняемый набор параметров текущей партии с номером рецепта и ревизии.
5.Локальное поведение при потере связи: можно ли завершить уже начатую операцию, требуется ли безопасная остановка, как восстанавливается синхронизация.
6.Фиксация фактически выполненных действий и отклонений, которые возникают на физическом уровне.
Например, MES вправе назначить партию с температурой процесса 68 градусов и временем выдержки 20 минут. Но только ПЛК знает, открыт ли контур охлаждения, исправен ли датчик, достигнута ли температура в реальности и можно ли продолжать цикл после срабатывания защиты.
Чего не стоит превращать в «истину ПЛК»
Небольшая установка без MES часто годами хранит несколько рецептов непосредственно в контроллере или панели оператора. Это может быть нормально в масштабе одной машины, если предприятие сознательно назначило такой источник истины и обеспечивает резервное копирование, права доступа и журнал изменений.
Но при появлении учета партий, качества и нескольких линий эта модель быстро становится слабой. Если окончательная версия рецепта существует только в ПЛК, возникают вопросы:
•кто и когда изменил уставку;
•по какой версии изготовлена конкретная партия;
•одинаковы ли рецепты на двух линиях;
•кто утвердил изменение;
•как доказать, что отчет относится именно к выполненному набору параметров;
•что восстанавливать после замены контроллера или загрузки старой резервной копии.
В такой архитектуре ПЛК выполняет не свою работу: вместе с управлением машиной он невольно становится системой версий, аудита и производственной отчетности. Обычно это дешевле на первом пуске и дороже после первого серьезного разбора отклонения.
Конфликт интегратора и IT: оба спорят о реальном риске
Интегратор обычно защищает управляемость оборудования. Он видел нестабильные сети, зависающие серверы и ночные пуски, когда связь с MES еще не готова, а механика уже должна работать. Поэтому ему близка мысль: «важные параметры держим локально, иначе линия станет заложником верхней системы».
IT-служба и владелец MES защищают не менее реальную сторону: единые справочники, доступы, историю изменений, кибербезопасность, отчеты и прослеживаемость. Они опасаются, что локальные таблицы в десятках контроллеров превратятся в неконтролируемые копии, о которых вспоминают после брака или аудита.
Правильное решение обычно не выбирает одного победителя. Оно разделяет ответственность:
•MES хранит мастер-версию, назначает ее партии и ведет журнал производственного контекста.
•ПЛК принимает в работу локальный экземпляр рецепта только после проверки номера версии, полноты данных, диапазонов и готовности оборудования.
•После принятия ПЛК работает с зафиксированным набором параметров; MES не меняет его посреди операции незаметной записью отдельного тега.
•Если параметр нужно изменить в ходе партии, это оформляется как разрешенное действие с причиной, автором и возвратом факта в отчет.
•При временной потере связи поведение линии заранее описано: продолжить текущий безопасный шаг, остановиться после шага или запретить старт новой партии.
Так у интегратора остается управляемая машина, а у IT и производства - версия, отчетность и доказуемая история.
Как передавать рецепт: не россыпью тегов, а транзакцией
Худшая реализация интеграции выглядит так: MES записывает двадцать уставок по отдельности, ПЛК в этот момент уже читает часть новых и часть старых значений, оператор нажимает «Пуск», а затем никто не понимает, по какому рецепту реально пошел цикл.
Рабочий обмен строится как небольшая транзакция:
1.MES формирует задание: BatchId, RecipeId, RecipeRevision, параметры и контрольную информацию.
2.ПЛК получает полный набор в буфер, не применяя его сразу к активному циклу.
3.ПЛК проверяет состав, версию, диапазоны, доступность оборудования и отсутствие конфликта с текущей операцией.
4.ПЛК возвращает статус: принято, отклонено либо требуется действие оператора, обязательно с причиной при отказе.
5.После подтверждения рецепт становится исполняемым экземпляром и блокируется от незаметной замены во время выполнения.
6.В ходе процесса ПЛК передает фактические значения, состояния и события, привязанные к BatchId и ревизии.
7.После завершения MES собирает производственный отчет и связывает его с качеством, сырьем и итоговым статусом партии.
В интерфейсе полезно явно различать «запрошенную ревизию», «принятую ревизию» и «выполняемую ревизию». Если на экране есть только поле RecipeNumber, при расследовании легко обнаружить, что все считали его одним и тем же, хотя системы имели в виду разные состояния.
Транспорт для такого обмена может различаться в зависимости от платформы, но данные должны иметь понятную модель и статусы. Почему семантика объектов и прав доступа важнее простой передачи значений, мы показывали в статье «OPC UA для инженера АСУ ТП: практический запуск без интеграторского хаоса».
Партия, отчет и качество: почему их нельзя достроить постфактум
Иногда рецепт передают в ПЛК, а вопрос партии откладывают: «сначала запустим оборудование, потом подключим MES и отчеты». Для пробной механики это понятно. Для промышленной эксплуатации возникает риск: процесс уже физически работает, но никто не может однозначно связать выпущенный продукт с параметрами, вмешательствами и результатом проверки.
Минимальный контекст партии должен появляться до старта производственного исполнения:
•идентификатор партии;
•продукт и утвержденная ревизия рецепта;
•линия или единица оборудования;
•время принятия задания контроллером;
•пользователь или система, выдавшая запуск;
•статусы выполнения и отклонений.
Отчет не должен строиться только из фразы MES «я отправила задание». В него нужен подтвержденный физический факт от АСУ ТП: задание принято, цикл действительно стартовал, параметры применены, операция завершена или остановлена по конкретной причине.
С качеством граница еще заметнее. ПЛК может измерить температуру и сообщить, что выдержка прошла без аварии. Но он не должен сам решить, что партия годна, если для выпуска нужен анализ пробы или решение службы качества. Равно как лабораторная система не должна напрямую открывать клапан: она выдает статус или разрешение, а безопасное действие исполняет АСУ ТП.
Четыре ситуации, которые нужно договорить до FAT и SAT
Красивый обмен в штатном режиме не гарантирует устойчивую систему. Настоящие споры начинаются на отклонениях.
MES недоступна в момент старта. Можно ли запустить новую партию по последнему загруженному рецепту? Если да, кто разрешает это действие и как позже связывается локальный запуск с записью в MES? Если нет, система должна ясно сообщить причину запрета, а не оставлять оператора угадывать.
Связь пропала во время исполнения. ПЛК чаще всего должен безопасно закончить уже принятую операцию или перейти в заранее заданное состояние. Продолжать получение меняющихся команд от системы, которой уже нет на связи, невозможно; значит, сценарий должен быть локальным и протестированным.
Рецепт обновили, пока старая партия еще идет. Новая ревизия применяется к следующему разрешенному запуску, а не подменяет параметры активной партии. Исключение возможно только для формализованной корректировки с журналом причины и подтверждением.
Качество заблокировало партию. MES или QMS должна передать статус удержания, а АСУ ТП - обеспечить запрет на дальнейшую разрешенную операцию, если это предусмотрено технологией. При этом аварийная безопасность и возможность безопасно освободить оборудование остаются в логике ПЛК.
Эти сценарии полезно проверять не в переписке после пуска, а в программе испытаний. С точки зрения передачи объекта заказчику такой контракт не менее важен, чем исходники: в паспорте объекта АСУ ТП после пуска должны остаться актуальная архитектура обмена, версии, доступы и результаты проверки нештатных случаев.
Чек-лист границы MES - ПЛК перед внедрением
Перед тем как программист начнет создавать теги, команде стоит письменно ответить на вопросы:
1.Какая система является источником истины для мастер-рецепта и его ревизии?
2.Кто назначает рецепт конкретной партии и формирует BatchId?
3.Какие параметры ПЛК принимает от MES, а какие инженерные пределы никогда не изменяются верхним уровнем?
4.Каким образом ПЛК подтверждает, что получил и принял полный набор параметров?
5.Можно ли изменить рецепт после старта операции и как фиксируется такое изменение?
6.Что делает оборудование при потере связи до старта и во время выполнения партии?
7.Кто является владельцем результата качества и каким статусом он ограничивает дальнейшее производство?
8.Какие фактические события и измерения возвращаются из ПЛК для отчета MES?
9.Где хранится журнал ручных вмешательств, отклонений, отказов принятия рецепта и причин остановки?
10.Как эта логика будет проверена на FAT, SAT и при восстановлении после сбоя?
Если ответы сводятся к «потом настроим обмен», проект еще не готов к промышленной интеграции. Названия тегов можно дописать быстро; потерянную границу ответственности приходится восстанавливать уже на работающем производстве.
Итог
Рецепт не заканчивается в тот момент, когда набор уставок записали в контроллер. Его производственная жизнь начинается в MES: версия утверждается, назначается партии, связывается с отчетом и качеством. В ПЛК рецепт становится исполняемым экземпляром - тем набором параметров, который контроллер проверил, принял и безопасно отработал на оборудовании.
Хорошая интеграция не заставляет MES управлять клапанами и не вынуждает ПЛК отвечать за историю производства. Она делает границу явной: MES знает, что и по какой версии выпускается, а АСУ ТП гарантирует, как это физически выполняется и где оно должно быть остановлено.
Обсуждение