OPC UA для MES недостаточно без модели заданий

OPC UA хорошо решает подключение, чтение данных, подписки, методы и безопасность канала. Но сам факт наличия OPC UA на станке не означает, что MES понимает производственное задание, умеет поставить его в очередь и получит однозначный отчет о выполнении.

Если системе нужны только режим, аварии, счетчики и текущая нагрузка, добавлять ISA-95 Job Control рано. Если MES должна передать заказ, количество, программу, требования к материалу, разрешить запуск, остановить работу и принять результат, одних произвольных тегов уже мало. Нужна согласованная модель задания, даже если команда проекта решит реализовать ее не строго по стандарту.

OPC UA решает связь, а не смысл задания

OPC UA дает средства обмена, но смысл данных появляется только в информационной модели. Сервер может опубликовать переменную ProductionOrder типа String, и любой клиент прочитает ее без ошибки. Однако из строки неясно, является ли это номером ERP-заказа, сменным заданием, партией, операцией маршрута или именем управляющей программы.

Эту разницу в проектах постоянно стирают. Протокол отвечает на вопросы «как прочитать», «как вызвать метод», «как подписаться» и «кто имеет доступ». Производственная модель отвечает на вопросы «что именно поручено», «какой ресурс требуется», «можно ли изменить поручение» и «какой результат относится к какому заказу».

OPC Foundation описывает эту модель в OPC 10031-4, OPC UA for ISA-95, Part 4: Job Control. Документ определяет Job Order, Job Response, доступ к заданиям в очереди, выполняемым и завершенным заданиям, а также методы управления ими. Это не конкурент OPC UA, а companion specification поверх него.

Для оборудования общего назначения есть еще OPC 40001-3, OPC UA for Machinery, Part 3: Job Management. Он использует типы Job Control и уточняет параметры для машин: плановое количество, число запусков, плановое время, режим выполнения, номера заказов и данные о результате. В OPC UA for Machine Tools версии 1.02 прежняя модель ProductionType уже помечена как устаревшая с указанием на будущую замену Machinery Job Management. Покупать новый станок, опираясь только на старый список production-тегов, значит закладывать последующее переписывание адаптера.

Есть и еще одна граница. ISA-95 Job Control не определяет технологическую логику обработки детали. Подачи, коррекции инструмента, переходы, блокировки патрона и безопасный останов остаются в ЧПУ и PLC. MES управляет поручением, а не движением осей.

Для мониторинга Job Control не нужен

Простой сбор параметров не требует модели заданий, если MES или отдельная система мониторинга не управляет работой станка. Для расчета загрузки и разбора простоев обычно достаточно структурированной телеметрии.

Минимальный контракт мониторинга включает:

• состояние оборудования и режим работы;
• активность автоматического цикла и причину остановки;
• счетчики годных и негодных деталей;
• аварии с кодом, временем появления и подтверждения;
• идентификатор активной программы или текущего задания, если станок его уже знает.

У каждого значения должны быть источник, тип, единица измерения, временная метка и OPC UA StatusCode. Счетчик без правила сброса бесполезен. Состояние Running без определения тоже бесполезно: один поставщик считает станок работающим при вращении шпинделя, другой при активной программе, третий при снятом сигнале аварии.

Для такого сценария подписки OPC UA обычно лучше частого опроса. Клиент получает изменения с серверными временными метками и контролем качества. Частота публикации должна соответствовать задаче: диспетчерскому экрану не нужен поток с периодом контроллера, а анализ коротких остановок теряет смысл при редкой выборке.

Не надо притягивать заказ к каждой температуре и каждой позиции оси. Телеметрия описывает состояние физического объекта. Производственный контекст связывает часть этих данных с конкретной работой. Если смешать два слоя, изменение номера заказа сломает исторические тренды, а замена датчика потребует править модель MES.

Практический критерий прост: если при обрыве связи MES ничего не должна повторно отправлять станку, а после восстановления ей достаточно продолжить чтение, Job Control пока не обязателен. Все меняется, когда потеря сообщения может оставить два задания, неверную программу или незакрытый заказ.

MES начинает управлять с появлением Job Order

Модель Job Order нужна, когда верхняя система поручает единицу работы конкретному рабочему центру. ISA-95 называет Job Order запросом на выполнение работы и располагает его ниже Work Request в структуре производственного расписания. Для металлообработки такой единицей часто становится операция заказа на определенном станке, а не весь заказ клиента.

Хорошее задание отвечает как минимум на следующие вопросы:

• какой у него устойчивый идентификатор и к какому заказу оно относится;
• что нужно изготовить и в каком количестве;
• какой Work Master, маршрут, программа или редакция документа определяет способ работы;
• какое оборудование, материал, оснастка или квалификация требуются;
• когда задание разрешено запускать и каков его приоритет.

Поле с номером УП не заменяет Work Master. Управляющая программа описывает обработку на конкретной системе ЧПУ. Производственное определение может также включать установочную карту, контрольный план, инструкцию по закреплению, версию чертежа и правила регистрации брака. MES вправе ссылаться на утвержденный комплект, а локальная система станка должна проверить, что нужная версия доступна.

Не всякое требование обязано доходить до контроллера. Требование к квалификации оператора может проверять терминал участка. Партию заготовки может подтвердить сканер. Идентификатор приспособления может проверять PLC или оператор. Job Order объединяет эти требования одним контекстом, но не заставляет один сервер исполнять их все.

Приоритет и время начала тоже не равны команде немедленного старта. OPC 40001-3 задает порядок между несколькими разрешенными заданиями через StartTime, затем через Priority; при равенстве выбор остается зависимым от приложения. Это разумная оговорка. Планировщик предлагает порядок, а станок начинает работу только после проверки локальной готовности.

Job Response закрывает производственный контур

Job Response нужен MES не меньше, чем Job Order, потому что команда без подтвержденного результата оставляет заказ в неопределенном состоянии. Стандарт определяет ответ как отчет о работе, выполненной по заданию, и разделяет требования в заказе и фактические данные в ответе.

Это разделение часто портят одним объектом Material. В заказе материал означает требование: марка, размер, партия или допустимый класс. В ответе Material Actual означает то, что реально использовали. Если подменить требование фактом, MES не обнаружит замену партии и не сможет восстановить прослеживаемость.

Та же логика действует для оборудования, физических активов и персонала. Equipment Requirement может требовать станок определенного класса. Equipment Actual фиксирует конкретный рабочий центр. Physical Asset Requirement может описывать тип измерительного прибора, а Physical Asset Actual хранит идентификатор реально примененного прибора. Эти пары нужны не ради красивой иерархии, а для ответа на обычный вопрос отдела качества: «На чем и из чего изготовили именно эту партию?»

Ответ должен содержать промежуточное состояние для долгой операции и окончательный результат после завершения. OPC 40001-3 предусматривает JobResult со значениями Unknown, Successful и Unsuccessful, а также данные о выпуске и производительности. Одного Successful недостаточно: MES нужны фактическое количество, брак, время начала и окончания, а при необходимости идентификаторы полученных деталей или партий.

Состояние и результат нельзя объединять. Running описывает текущую фазу. Successful оценивает завершенную работу. Станок может остановиться штатно после выпуска меньшего количества, а деловая система решит, можно ли считать заказ закрытым. Контроллер сообщает факт, MES применяет производственное правило.

Одна строка заказа неизбежно расползается

Самодельная интеграция обычно начинает ломаться после первого успешного запуска, когда к ней добавляют реальные исключения. На демонстрации MES записывает OrderNo, PartNo, Quantity и бит Start. PLC выполняет программу, увеличивает Produced и выставляет Done.

Затем сеть пропадает после записи Start, но до чтения подтверждения. MES повторяет запись. Если PLC воспринимает фронт бита как новую команду, задание запускается второй раз. Если бит остался установленным, новый запуск не произойдет, но MES не знает, принял ли станок первый. Команда добавляет Ack, затем порядковый номер, затем Busy, затем тайм-аут и ручной сброс.

Следом планировщик меняет количество до запуска. Непонятно, можно ли менять поля при Busy=0, если оператор уже загрузил материал. Появляется Locked. Потом оператор ставит задание на паузу для измерения первой детали. Нужно различить технологическую паузу, аварию и отмену. Появляются Pause, Hold, Fault, Cancel, Abort и несколько таблиц переходов, которые MES и PLC трактуют по-разному.

После этого приходит требование учитывать частично выполненный заказ. Старое поле Done не говорит, изготовлено ли 80 из 100 деталей, отменены ли оставшиеся 20 и можно ли создать продолжение с тем же номером. Команда добавляет номер партии исполнения. Через год в проекте уже есть своя модель заданий, только без общей терминологии, профилей совместимости и документации для следующего поставщика станка.

Популярный совет «начнем с четырех тегов, потом расширим» плох не из-за малого старта. Он плох, когда четыре тега уже используются как внешний контракт и не имеют устойчивого идентификатора команды, определенной машины состояний и правил повторной отправки. Малый пилот допустим, если команда сразу фиксирует границы и не выдает временную схему за готовую архитектуру.

Job Control не устраняет ошибки автоматически. Он заставляет назвать объекты, состояния и методы до ввода в эксплуатацию. Именно эта работа обычно обнаруживает, что MES, PLC-программист и технолог вкладывали разный смысл в слово «задание».

Контракт данных важнее списка тегов

Рабочий контракт должен показывать не только поля, но и направление, обязательность, владельца значения и реакцию на повтор. Ниже приведено сокращенное представление задания для токарной операции. Это не кодирование OPC UA и не точная сериализация ISA95JobOrderDataType, а проверяемый проектный артефакт для согласования MES, шлюза и системы станка.

{
  "jobOrderId": "WO-78431-OP20-R1",
  "workMasterId": "SHAFT-A-OP20-REV4",
  "startTime": "2026-07-27T06:00:00Z",
  "priority": 60,
  "parameters": {
    "orderNumber": "WO-78431",
    "drawingNumber": "SHAFT-A",
    "drawingRevision": "04",
    "plannedQuantity": 120,
    "executionMode": "ProductionMode"
  },
  "materialRequirements": [
    {
      "materialDefinitionId": "STEEL-40X-D52",
      "plannedQuantity": 120,
      "unit": "piece"
    }
  ],
  "equipmentRequirements": [
    {
      "equipmentClassId": "CNC-LATHE-D65"
    }
  ]
}

Идентификатор jobOrderId здесь относится к конкретному исполнению операции. Повторная отправка того же идентификатора не должна создавать второе задание. Если планировщик намеренно выпускает новую редакцию, он создает новый идентификатор или применяет разрешенный стандартом Update до перехода в состояние, где изменение запрещено. Правило выбирают заранее и проверяют на стенде.

Ответ должен ссылаться на тот же идентификатор и отделять факты от плана:

{
  "jobOrderId": "WO-78431-OP20-R1",
  "state": "Ended",
  "jobResult": "Successful",
  "actualStartTime": "2026-07-27T06:14:08Z",
  "actualEndTime": "2026-07-27T13:42:31Z",
  "producedQuantity": 120,
  "scrapQuantity": 2,
  "materialActuals": [
    {
      "materialLotId": "HEAT-91827",
      "consumedQuantity": 122,
      "unit": "piece"
    }
  ],
  "equipmentActuals": [
    {
      "equipmentId": "LATHE-07"
    }
  ]
}

Такой пример сразу поднимает неудобные вопросы. Входит ли брак в producedQuantity? Может ли успешное задание иметь брак? Кто присваивает materialLotId? Как сообщить две партии металла? Когда результат становится окончательным? Пока ответы не записаны, интеграция остается набором предположений.

Машина состояний защищает от двойного исполнения

Определенные переходы состояний снижают риск повторного запуска и спорных команд, но только если клиент и сервер соблюдают их вместе. OPC 10031-4 описывает приемник заданий с методами Store, StoreAndStart, Start, RevokeStart, Pause, Resume, Update, Abort, Stop, Cancel и Clear.

Названия похожи на обычные кнопки, но различия существенны. Pause предполагает возможность продолжить. Stop завершает исполнение управляемым способом по правилам оборудования. Abort применяется, когда нормальное продолжение уже не требуется. Cancel относится к заданию, которое не должно выполняться. Проект должен отобразить эти намерения на реальные возможности ЧПУ и PLC; нельзя обещать MES паузу с продолжением, если цикл станка ее не поддерживает безопасно.

StoreAndStart тоже не означает безусловный физический пуск. В модели задание получает разрешение на исполнение, после чего система учитывает ресурсы, приоритеты и локальные условия. Кнопка «Пуск цикла» может остаться у оператора, если того требует технология или оценка риска.

После тайм-аута клиент не должен вслепую повторять команду. Надежная последовательность такова: MES сохраняет jobOrderId и идентификатор попытки, вызывает метод, а при потере ответа читает список заданий и текущее состояние. Повтор допустим только после проверки того, что сервер не принял исходное поручение. Идемпотентность здесь является свойством согласованного поведения, а не магией транспорта.

В приложении B OPC 10031-4 коды результата методов заданы битовой маской UInt64. Среди стандартных причин есть неизвестный идентификатор задания, неверное состояние, невозможность принять задание и некорректный запрос. Запишите ожидаемую реакцию MES на каждый код. Бесконечный автоматический повтор при Unable to accept Job Order быстро превращает временную проблему в очередь одинаковых сообщений.

Безопасный канал не дает MES права на опасную команду

Механизмы безопасности OPC UA защищают соединение, но проектировщик все равно должен ограничить полномочия клиента и команды, доступные в каждом состоянии станка. Сертификат подтверждает сторону соединения и помогает защитить данные в пути. Он не решает, должна ли учетная запись планировщика иметь право вызвать Abort во время обработки.

Разделите как минимум чтение мониторинга, загрузку задания, разрешение исполнения и аварийное вмешательство. У сервисной учетной записи MES не должно быть административных прав на сервере только потому, что так проще запустить стенд. Отдельно журналируйте идентификатор клиента, метод, jobOrderId, время, исходное состояние и результат вызова.

Сеть предприятия тоже не заменяет локальную безопасность. PLC и ЧПУ обязаны проверять ограждения, зажим, готовность приводов, наличие программы и другие условия независимо от команды MES. Верхняя система может попросить запустить разрешенное задание, но не должна обходить цепи защиты и станочную логику.

Продумайте деградацию при потере связи. Выполняемая операция обычно должна либо безопасно продолжиться локально, либо остановиться по заранее определенному правилу. Нельзя оставлять это решение тайм-ауту клиентской библиотеки. После восстановления MES должна получить фактическое состояние и результаты, а не назначить станку состояние из своей старой копии.

Внедрять полную модель нужно по границе ответственности

Не каждому предприятию нужна вся ISA-95 модель в первом релизе. Нужен минимальный профиль, который закрывает фактическую ответственность MES и допускает развитие без смены смысла идентификаторов.

Удобно разделить внедрение на три уровня. На первом MES только читает унифицированную телеметрию. На втором она сопоставляет активное локальное задание с заказом, но оператор загружает и запускает его на станке. На третьем MES создает Job Order, управляет допустимыми переходами и принимает Job Response. Переходить на следующий уровень стоит только после испытания предыдущего на обрывах связи, перезапусках и ручных действиях.

При выборе реализации запросите не фразу «поддерживается OPC UA», а конкретные NamespaceUri, версии NodeSet, профили и Conformance Units. Для Job Control особенно важно зафиксировать версию: OPC 10031-4 версии 2 содержит несовместимые с версией 1 изменения и использует новое пространство имен. Клиент, написанный под старую модель, не станет совместимым после замены адресов узлов.

Проверьте и OPC 40001-3 Machinery Job Management. Базовый профиль требует JobOrderControl и JobOrderResults, но отдельные плановые параметры и результаты вынесены в разные Conformance Units. Сервер может честно поддерживать базовую модель и не иметь нужного вам PlannedOrderQuantity, результата по материалам или информации о производительности. Это выясняют по профилю и тестом, а не по рекламному описанию.

При подборе и пусконаладке станка с EAST CNC стоит включить интеграционный профиль в техническое задание до поставки: позже согласование семантики почти всегда дороже, потому что MES, шлюз и PLC уже написаны под разные предположения.

Приемка должна ломать счастливый сценарий

Интеграция готова, когда она предсказуемо переживает сбои, а не когда один заказ успешно прошел на стенде. Приемочные испытания должны включать повторные методы, разрыв соединения и противоречащие команды.

Проведите как минимум пять проверок:

1. Отправьте один jobOrderId дважды и убедитесь, что сервер не создал две работы.
2. Разорвите связь после приема задания, но до ответа метода, затем восстановите состояние без повторного запуска.
3. Попробуйте обновить количество до запуска и во время выполнения, сверив разрешенные переходы.
4. Выполните паузу, возобновление, управляемую остановку и отмену в тех состояниях, где оборудование заявляет поддержку.
5. Завершите задание частично, с браком и с заменой партии материала, затем проверьте Job Response в MES.

Для каждого теста заранее задайте ожидаемые состояние, код метода, запись журнала и деловой результат. Формулировка «появилась ошибка» непригодна для приемки. Нужны конкретный StatusCode, ReturnStatus, сохранность jobOrderId и отсутствие нежелательного движения станка.

Если MES только наблюдает, оставьте Job Control за пределами проекта и тщательно определите телеметрию. Если MES распоряжается работой, примите модель задания до написания тегов. Иначе команда все равно построит Job Control, но сделает это случайно, по одной аварийной поправке за раз.