Part Production Cell

Учебный MES и KPI-слой

Как состояние PLC становится понятным результатом заказа

Это учебный кейс о том, как рядом с PLC появляется слой MES. Контроллер остаётся источником фактов: он знает состояние ячейки, ошибки и счётчики. MES добавляет к этим фактам время и контекст заказа, а Dashboard собирает результат.

Я прошёл один сценарий от действий оператора до событий и расчёта. Поэтому здесь можно не только увидеть OEE, но и понять, откуда взялась каждая длительность и какая причина повлияла на Availability.

Экраны показывают разные части сценария: переходы состояния, проверку условий OEE и финальное Pareto. За счёт общей истории каждый показатель можно разложить до события и правила расчёта.

PLC → MES

события, OEE и traceability

Part Production Cell — MES & OEE Summary

Задача

Не просто показать состояние, а сохранить историю заказа

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

Part Production Cell — MES & OEE Overview

PLC — источник фактов

PLC хранит состояние ячейки, fault code, разрешение на работу и производственные счётчики. HMI показывает эти факты, а не подменяет их своим состоянием.

MESCollector — контекст и время

Gateway Timer читает факты PLC и записывает стартовые значения заказа, статус и события. Он не управляет PLC и не считает KPI.

SQL и Dashboard — показать результат

Named Queries собирают историю заказа. Dashboard показывает результат расчёта, но не создаёт производственные данные и не меняет логику ячейки.

Контекст заказа

Один заказ проходит через явные состояния

На старте заказ получает target, исходные значения счётчиков, время запуска и статус. Пока он активен, MESCollector связывает факты PLC с order_id. После ORDER COMPLETE граница отчёта фиксируется, поэтому открытый Dashboard не меняет длительности.

FEED

В #2009 ячейка принимает материал. MES связывает это обычное состояние с активным order_id.

Срабатывает E-stop

Ячейка переходит в FAULT, когда нарушен E-STOP OK. MES сохраняет fault code 60 вместе с активным order_id.

Ошибка и восстановление

E-STOP сохранён как причина FAULT. После reset MES добавляет FAULT_CLEARED и STATE_PAUSED, поэтому восстановление остаётся в истории заказа.

Журнал MES

События дают последовательность, которой нет в одном PLC-теге

production_events хранит время, order_id, состояние, контекст ошибки и тип события. Вместо очередного снимка экрана журнал сохраняет сам переход: готовая или бракованная деталь, нехватка материала, ошибка, сброс ошибки и смена состояния.

Классифицировать каждую деталь

PIECE_GOOD и PIECE_REJECT сохраняют результат каждой детали. Good, Reject и Total считаются от стартовых значений заказа, а не от общего счётчика машины.

Сохранить смены состояния

STATE_* строят последовательность: feed, clamp, process, inspect, release, pause и fault. На ней держится расчёт длительностей.

Связать ошибку с заказом

FAULT_STARTED и FAULT_CLEARED сохраняют fault code вместе с активным order_id. Поэтому в Dashboard видна не только текущая ошибка, но и её место в истории заказа.

Из журнала в KPI

Длительность строится по границам событий, а не по опросу таймера

SQL собирает длительность между соседними событиями. Одновременные события деталей и состояния остаются отметками, а не создают лишний интервал. В результате отчёт показывает понятный баланс: общее время, пауза, fault, ожидание материала и работа.

Одна причина на один интервал

Сначала интервал проверяется на fault, затем на операторскую паузу и только потом на нехватку материала. Поэтому одно и то же время не учитывается дважды.

Пауза остаётся видимой

Операторская PAUSED — запланированная рабочая пауза. Она остаётся в breakdown, но не входит в planned production time и не снижает Availability.

Время распределено полностью

Для #2010 unclassified_ms = 0. Всё наблюдаемое время разложено по понятным категориям, а не пропало между опросами.

OEE и улучшение

Показатель полезен, только если видны его условия и причина потерь

Performance считается только при заданном идеальном цикле, а OEE — когда валидны все три составляющие. Если данных не хватает, Dashboard честно показывает N/A. Pareto отдельно оставляет только причины, которые действительно снизили Availability.

Идеальный цикл — вход для OEE

Для завершённого #2010 в расчёт передаётся ideal_cycle_time_ms = 5 000. Он нужен только для Performance: на экране Performance 96,7%, Quality 100%. На движение PLC параметр не влияет.

Не показывать ложный процент

При ideal_cycle_time_ms = 0 Performance не показывается процентом, а OEE становится N/A. Availability и Quality остаются видимыми. После возврата 5 000 мс расчёт восстанавливается.

Итоговые KPI и Pareto потерь

Итоговые KPI: Availability 54,3%, Performance 80,5%, Quality 76,9% и OEE 33,6%. Pareto показывает, почему снизилась Availability: больше всего времени забрал E-stop, затем — нехватка материала.

Что показывает кейс: