Потому, что ML модель найдет хорошую закономерность в данных (если она есть), но как мы это потом объясним в реальном мире?
В прошлых статьях из цикла я уже писал, как разбирался с PLC-сигналами, приводил данные в порядок, складывал их в ClickHouse и показывал в Grafana. Это была база. Теперь эта база постепенно превращается в более прикладную задачу: понять, почему часть изделий уходит в отбраковку, и можно ли заранее заметить признаки проблемы.
Сразу оговорюсь: точные названия оборудования, производителя, линии, продукта и организации я не раскрываю. Здесь важен не паспорт станка, а подход.
Почему аудит брака сложнее, чем найти нужный бит
Со стороны кажется, что всё должно быть просто: есть изделие, есть брак, есть сигнал в PLC. Берём этот сигнал как целевую переменную, обучаем модель, радуемся.
На практике оказалось немного по другому.
Первый вопрос, в который мы упёрлись: какие виды брака вообще существуют и как они физически выглядят. Одно дело, если изделие явно выброшено системой контроля. Другое — если оператор что-то отключил на панели, линия работает в режиме наладки или часть логики обнаружения временно игнорируется.
И вот тут начинается самое интересное. Если не разобраться в этих нюансах, ML-модель легко превращается в красивую, но бесполезную штуку. Она будет предсказывать не брак, а особенности того, как оборудование было настроено в конкретный день.
Например, можно взять сигнал, который появляется уже после отбраковки. Модель на нём покажет отличную точность. Только пользы от этого немного: она научится узнавать событие, которое уже произошло. А нам хочется понимать, что могло привести к дефекту заранее.
Сначала договориться о терминах
Перед тем как лезть в данные, мы разложили аудит на понятные шаги.
Нужно было зафиксировать:
- какие виды брака бывают;
- где они возникают по ходу процесса;
- кто или что их обнаруживает;
- что считать одной единицей продукции;
- какие механизмы участвуют в формировании конкретного дефекта;
- какие датчики, оси, приводы, температуры, давления и уставки могут быть связаны с этим местом.
Согласен звучит скучно, но без этого никак.
На заводе вообще много вещей, которые в у нас выглядят как обычные колонки в таблице, а в реальности имеют очень разный смысл. Один сигнал может быть причиной. Второй — ранним предвестником. Третий — просто контекстом. Четвёртый — фактом, что дефект уже нашли. Пятый — последствием отбраковки. Шестой - вообще ни разу не изменится за длительный момент сбора данных (т.е. остается просто константой)
Поэтому все сигналы пришлось мысленно делить на группы:
- возможные причины;
- ранние предвестники;
- технологический контекст;
- сигналы обнаружения уже появившегося дефекта;
- сигналы после выброса, которые нельзя использовать для прогноза.
И вот это разделение для промышленного ML иногда важнее, чем выбор между условным CatBoost и нейросеткой.
Смотреть глазами, а не только SQL-запросами
Для аудита нужно было совместить две реальности.
Первая — физическая. Что происходит на оборудовании: где появляется дефект, в какой зоне, при каком сценарии, что было прямо перед этим.
Вторая — цифровая. Какие PLC-сигналы можно потом вытащить из ClickHouse, как они называются, с какой частотой пишутся и как их привязать к реальному событию.
В какой-то момент стало понятно, что просто наблюдать за процессом уже недостаточно. Нам нужны не общие впечатления, а точно размеченные моменты отбраковки.
Самый практичный вариант оказался очень простой: поставить камеру на точку выброса и потом по видео восстановить время и количество выброшенных изделий.
Но тут есть важная мелочь, без которой всё ломается: видео надо синхронизировать с реальным временем. Например, один раз снять в кадре экран телефона с часами и секундами или голосом проговорить точное время. Тогда каждый выброс можно привязать к секундам в ClickHouse.
Говоря совсем проще - сделать ручную разметку и сравнить ее с разметкой из PLC.
Для первого разведочного анализа мы целились в 20–30 надёжно размеченных событий. Это не значит, что 20–30 случаев докажут любую гипотезу. Тут есть нюансы:
- если все случаи одинаковые — это уже сильный материал;
- если это несколько разных видов брака — примеров каждого будет мало;
- часть выбросов может происходить по одной причине, часть по другой;
- внешне похожие события могут внутри оборудования вызываться разными сценариями.
Поэтому цель была не доказать закономерность любой ценой, а собрать честный набор событий и посмотреть, что в нём вообще есть.
Как выглядит датасет для такой задачи
После расшифровки видео датасет должен быть максимально приземлённым. Не абстрактная таблица на миллион строк, а список событий:
event_001 10:02:xx 2 изделия
event_002 10:05:xx 2 изделия
event_003 10:13:xx 1 изделие
...
Дальше под каждое событие можно автоматически вытащить из ClickHouse окно данных. Например, за 60 секунд до выброса и 10 секунд после.
Почему так? Потому что нас интересует не только момент выброса. Нам важнее понять, что происходило до него:
- менялась ли скорость;
- были ли рассогласования;
- росли ли нагрузки;
- прыгали ли температуры или давления;
- менялись ли уставки;
- были ли аварии, блокировки или нестандартные режимы;
- какой был рецепт или тип продукции;
- что делал оператор на панели.
И обязательно нужен контроль: такие же окна времени без брака. Иначе можно найти сигнал, который возникает перед каждым нормальным циклом, и ошибочно назвать его причиной дефекта.
Это типичная ловушка. В данных всегда можно что-то найти. Вопрос в том, имеет ли это отношение к браку.
Зачем нам Grafana и ClickHouse
ClickHouse в этой истории — хранилище, куда удобно складывать быстрые временные данные с PLC. Из него можно вытаскивать окна вокруг событий, сравнивать брак и нормальную работу, проверять гипотезы по сигналам.
Grafana — это уже глаза для людей.
Для инженера удобно быстро открыть графики и увидеть, что происходило вокруг события. Для руководства это ещё важнее: не надо смотреть на сырые регистры, непонятные адреса и таблицы на тысячи строк. Можно показать линию времени, сигналы, выбросы, режимы и объяснить человеческим языком: вот момент дефекта, вот что было до него, вот что повторяется.
Связка Grafana плюс ClickHouse в промышленном мониторинге выглядит очень удачно: ClickHouse быстро отдаёт данные, Grafana красиво и понятно их показывает. И это не просто красивые дашборды ради дашбордов. Это способ обсуждать качество продукции не на уровне ощущений, а на уровне фактов.
В прошлой статье про мониторинг PLC я уже писал, что данные мало просто собрать. Их надо уметь показать так, чтобы по ним можно было принимать решения. В аудите брака это стало ещё заметнее: когда есть размеченные события, график превращается в инструмент расследования.
Документация всё равно догоняет
Отдельная часть работы — понять, какие сигналы вообще что значат.
У нас уже была собрана инженерная карта процесса: от подачи материалов и основных технологических узлов до контроля, удаления брака и дальнейшей передачи продукции. В ней есть реестр I/O, аварии PLC, счётчики выпуска, биты модели продукции и параметры сервоприводов.
Это сильно помогает, но полностью проблему не закрывает. В документации бывают расхождения, пустые описания, непонятные масштабы, неочевидные HMI-параметры. Иногда сигнал есть, но неясно, в каких единицах он приходит. Иногда понятно название, но непонятно, когда именно бит устанавливается.
Поэтому параллельно готовился запрос поставщику: не просто пришлите мануал, а заполните таблицы переменных, укажите адреса, типы данных, единицы измерения, масштабирование и экспорт переменных из среды разработки.
Особенно важны параметры, которые оператор меняет с панели: размеры, скорости, температуры, уставки, режимы. Без них можно видеть только последствия, но не понимать контекст.
Например, если оборудование работало в нестандартном режиме, модель должна это знать. Иначе она может решить, что причина брака в каком-то датчике, хотя на самом деле линия была в наладке или оператор временно изменил важный параметр. Тут интересный лайфхак, режим работы оборудования ≠ брак
Где здесь машинное обучение
ML здесь появляется ближе к концу.
Правильная последовательность выглядит так:
- Понять физический процесс.
- Разобраться с видами брака.
- Найти точку и способ разметки событий.
- Синхронизировать видео, журнал и PLC-данные.
- Вытащить окна из ClickHouse.
- Сравнить брак с нормальной работой.
- Отделить причины от следствий.
- Только потом строить модель.
У модели должна быть понятная целевая переменная, единица наблюдения, историческое окно, горизонт предупреждения и проверка на новых днях, партиях и рецептах.
Если этого нет, модель может быть формально точной, но производству от неё будет мало пользы.
Мне кажется, это один из главных уроков промышленного ML. На заводе нельзя просто взять таблицу, нажать fit и ждать магии. Сначала надо понять, что означают строки и столбцы. Иначе модель будет уверенно отвечать на неправильно поставленный вопрос.
Вывод
Аудит брака на производстве — это история про инженерную подготовку: собрать события, привязать их ко времени, понять сигналы, проверить документацию и только потом искать закономерности.
Мы не пытаемся угадать причину по одному графику и не строим модель на непонятной разметке (как это зачастую любят делать). Мы постепенно превращаем хаотичные заводские данные в систему, с которой уже можно работать.
А когда данные становятся понятными, машинное обучение перестаёт быть модным словом и начинает быть обычным полезным инструментом для оценки качества оборудования.