Продолжаем цикл статей об ML на производстве.

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

Звучит красиво. Но на практике первый шаг оказался довольно приземлённым: понять что данных нехватает, понять каких данных нехватает и написать нормальный технический запрос производителю оборудования и не попросить «пришлите что-нибудь по датчикам», а чётко объяснить, какие данные и почему они нужны.

Почему нельзя просто взять все данные и обучить модель?

На заводе данные выглядят как хаос: есть регистры, биты, какие-то аналоговые значения, аварии, счётчики, параметры с панели оператора. Формально данные есть. Но непонятно какого качества они для ML?

Если я вижу условный регистр со значением 1200, мне нужно понимать:

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

Без этого модель может научиться не производственному процессу, а каше из неправильно понятых чисел.

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

Что мы хотим предсказывать

Цель у нас достаточно понятная: построить ML-модель, которая сможет анализировать состояние оборудования, режимы работы, аварии, причины остановов и причины брака, чтобы потом помогать предсказывать дефекты продукции.

То есть нам нужны не просто «все данные подряд». Нам нужны данные, которые помогают связать состояние машины с качеством продукции.

Особенно важны:

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

Почему счётчики так важны? Потому что они могут дать почти автоматическую разметку (то самое обучение с учителем). Если оборудование само фиксирует количество годной продукции и брака, вокруг этих регистров уже можно строить первую логику датасета.

Это не значит, что задача сразу решена. Но это огромная разница между «мы руками пытаемся понять, где был дефект» и «у нас есть системный сигнал, от которого можно отталкиваться».

Главная проблема: часть данных есть, но смысла просто не хватает

На текущем этапе у нас уже были некоторые материалы: часть аналоговых значений, часть регистров, часть сигналов, все это мы снимали со станка почти в ручном режиме.

Но все равно этого оказалось недостаточно.

Например, есть D-регистры. Они полезны, но сами по себе не всегда объясняют весь процесс. Чтобы связать их с режимами, состояниями, кнопками, авариями и логикой работы, нужны метки, комментарии и карта адресов (которой, к слову, у нас нет).

Отдельная сложность — данные motion-контроллера. Часть важных параметров может жить не в основном контроллере, а внутри отдельного CPU, связанного с движением. И тут появляется вопрос: можем ли мы читать эти данные через уже существующее подключение к основному PLC по промышленному протоколу, или нужно, чтобы нужные регистры были заранее переданы в область основного контроллера?

Это звучит как мелкая инженерная деталь. Но для ML это критично. Если параметр важен для брака, но мы не можем его стабильно читать, значит в датасете его не будет. А если он появится позже, модель и пайплайн придётся пересматривать. Поэтому помимо ML у нас начинается АСУ ТП и местами даже КИПиА (например анализируем электросхемы оборудования)

Но чтобы наверняка во всем разобратся, лучше спросить данные по оборудованию у производителя.

Как мы сформулировали запрос производителю

Главное это не просить "документацию вообще», потому что вы сталкиваетесь с проблемой авторства/интеллектуальной собственности. Такой запрос почти всегда превращается в отписку.

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

В запрос вошли две основные части.

  1. Заполненная карта I/O и регистров

Например: - фактический адрес в основном PLC; - тип данных; - размер данных; - назначение параметра; - единицу измерения; - масштабирование; - расшифровку значений для кодов и битов; - условие или период обновления.

Это как словарь для данных. Без него нельзя нормально делать ни мониторинг, ни диагностику, ни ML.

  1. Экспорт меток и комментариев из проекта PLC

Отдельно мы запросили экспорт Global Labels и Device Comments из среды разработки PLC.

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

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

Почему точность данных напрямую связана с качеством продукции

В нашей задаче ML нужен как инструмент анализа производственного процесса.

Но инструмент работает только тогда, когда входные данные точные.

Если мы перепутаем адрес регистра или вообще непонимаем что он означает, модель будет смотреть не туда.

Если не узнаем масштабирование, температура или скорость могут оказаться в десять раз больше или меньше реального значения.

Если не поймём, когда обновляется счётчик брака, мы неправильно привяжем дефект ко времени.

Если не получим расшифровку кодов, аварии превратятся в набор чисел без смысла. И найти их на реальном станке потом будет нереально (станок 50 метров в длинну)

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

Формально, конечно, вы как ML инженер сделали свою работу - построили модель, у вас красивый recall. Но кому она нужна? Разве что рассказать об этом на модной конференции?

Практический чек-лист перед ML-моделью брака

Если коротко, я бы проверял такой список:

  1. Определить целевое событие Что именно считаем браком или дефектом? Где это фиксируется?

  2. Найти автоматическую разметку Есть ли счётчики брака, годной продукции и общего количества?

  3. Собрать карту данных Для каждого параметра нужны адрес, тип, размер, единицы, масштабирование и комментарий.

  4. Понять доступность данных Что реально можно читать из PLC? Что недоступно напрямую? Что нужно передавать в читаемую область?

  5. Забрать смысл из HMI Уставки и параметры оператора часто объясняют больше, чем кажется.

  6. Разделять факты и гипотезы Неподтверждённые сигналы нельзя использовать как надёжные признаки.

  7. Не просить лишнего Для анализа обычно не нужен исходный код PLC. Часто достаточно меток, комментариев, адресов и режима чтения.

Вывод

Эта работа пока не выглядит как классический ML опыт: "вот вам ROC-AUC, вот вам Recall, я - молодец"

Но именно то, как я описал - закладывается качество нормальной ML модели.

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

А если этот этап пропустить, модель получится не про производство, а про наши догадки и красивые словечки, ROC-AUC, Recall и т.п. А на реальном производстве это слишком дорогая роскошь.