Станок, PLC, HMI, шкафы, датчики, клеевые станции, ножи, барабаны, аварии, отбраковка, операторы, переналадки. И только где-то после всего этого — ML.
У нас была задача подготовить сбор данных с промышленной производственной линии под будущие модели. На первый взгляд задача звучит просто: найти нужные сигналы PLC, подключиться и начать собирать данные для последующего построения ML-модели.
Например, есть несколько дискретных PLC-сигналов. Казалось бы, вот они данные: читай, складывай в базу, потом обучай модель.
Но это ловушка.
Потому что сам по себе адрес PLC почти ничего не значит. Это просто бит. Ноль или единица. Чтобы он стал полезным для ML, нужно понимать:
- где этот сигнал находится на линии;
- к какому узлу он относится;
- что в этот момент производит станок;
- какой установлен рецепт;
- какая стоит оснастка;
- что физически произошло до этого сигнала;
- почему после него мог появиться reject.
Без этого модель будет видеть не станок, а кашу из нулей и единиц.
И вот тут началась самая интересная инженерная часть.
Главная проблема: PLC говорит коротко, а станок живёт длинной цепочкой
PLC-сигналы очень сухие. Они отвечают на вопросы уровня:
- датчик сработал или нет;
- привод готов или в аварии;
- клей готов или нет;
- изделие прошло или потерялось;
- был reject или не был.
Но дефект на линии почти никогда не появляется «в одном бите».
Он обычно рождается раньше:
материал пошёл нестабильно
→ слой лёг чуть криво
→ клей не попал в фазу
→ нож отрезал уже проблемное изделие
→ камера увидела дефект
→ изделие ушло в reject
Если смотреть только на момент reject, мы видим конец истории. А для ML и для ремонта важнее начало.
Поэтому я быстро понял: моя задача не в том, чтобы «читать всё подряд». Моя задача — собрать вокруг каждого сигнала контекст, чтобы потом можно было объяснить человеку у станка, что именно пошло не так.
Не «модель увидела аномалию в одном из PLC-сигналов».
А, например:
Похоже, проблема возникает на одном из предыдущих технологических этапов. Стоит проверить позиционирование, синхронизацию и состояние соответствующего механического узла.
Вот это уже полезный вывод.
Layout оказался не чертежом, а картой для расследования
Первый документ, который я разобрал, был обычным layout линии. Он показывал расположение основных технологических участков, вспомогательного оборудования и зон обслуживания.
Для подключения к PLC пользы почти ноль. Там нет IP-адресов, нет регистров, нет датчиков, нет понятной сетевой схемы.
Но для инженерной работы это всё равно ценный документ.
Почему? Потому что он превращает абстрактный станок в физическую карту.
Когда модель потом свяжет аномалию с определённым технологическим участком, человек должен понимать, куда идти ногами. Не в философском смысле, а буквально: к какой части линии подойти и какой узел проверить.
Второй layout был ещё полезнее. Он показывал уже не просто размещение оборудования, а технологическую последовательность:
подача материалов
→ формирование структуры изделия
→ соединение компонентов
→ технологическая обработка
→ контроль
→ reject или выход готового изделия
И вот после этого адреса из электрической схемы начали оживать.
Например, разные группы сигналов относятся к подаче материалов, формированию изделия, соединению компонентов, обработке, контролю качества и reject. Адреса не изменились, но у них появился смысл.
Это как разница между «неизвестный дискретный сигнал» и «датчик, который контролирует прохождение изделия на определённом этапе процесса».
Для ML это огромная разница.
Рецепт важнее, чем кажется
Следующий документ — чертёж изделия. В нём были предусмотрены несколько форматов продукции.
Я не буду пересказывать размеры и составы, потому что в статье это никому не нужно. Важна не сама таблица размеров, а инженерный вывод:
разные форматы изделия — это разные режимы станка.
При переходе с одного формата на другой меняются материалы, масса наполнителя, ширины слоёв, настройки ножей, фазировка, работа размотчиков, клеевые режимы. Для оператора это нормальная переналадка. Для тупой ML-модели без контекста — внезапная «аномалия».
И это классическая ошибка в промышленных данных.
Если просто сложить в одну кучу данные для разных форматов, модель может начать сравнивать несравнимое. Она увидит, что поведение приводов, клея или reject-логики изменилось, и может решить: «О, дефект». Хотя на самом деле станок просто перешёл на другой рецепт.
Поэтому рядом с каждым измерением обязательно должен быть активный рецепт.
Не где-то в голове у технолога. Не в Excel потом. А прямо в данных:
- какой SKU производится;
- какой формат изделия;
- какая оснастка стоит;
- какая скорость линии;
- был ли переход рецепта;
- была ли переналадка.
Тогда модель сможет отличить реальную проблему от нормального изменения режима.
Для меня это один из главных уроков: ML на заводе начинается не с модели, а с честного ответа на вопрос «что сейчас вообще производит линия?».
Клеевая станция: один alarm может означать разные дефекты
Отдельно я разбирал конфигурацию клеевой системы. Документ показывал, как отдельные клеевые узлы связаны с разными этапами формирования изделия.
Опять же, для подключения документ почти бесполезен: новых PLC-адресов нет, IP-адресов нет, протоколов нет.
Но он даёт другое — понимание, какой клей за что отвечает.
Разные клеевые узлы отвечают за соединение разных компонентов изделия.
И тут alarm перестаёт быть просто alarm’ом.
Например, сигнал о неготовности одного из клеевых узлов — это не просто общий alarm. Он может означать, что определённый компонент изделия не будет закреплён правильно, а дефект обнаружится системой контроля только позже по линии.
То есть цепочка выглядит так:
клеевая станция не готова
→ соединение компонентов нарушилось
→ элемент изделия расположился неправильно
→ камера или контроль увидели дефект
→ изделие ушло в reject
Для человека это понятно. Для модели это тоже нужно сделать понятным.
И тут появляется важная инженерная идея: сигнал должен быть связан не только с устройством, но и с частью изделия.
Не просто:
сработал общий alarm клеевого узла.
А:
alarm относится к клеевому узлу, связанному с определённой частью изделия; если одновременно растёт reject, необходимо проверить соответствующий технологический участок.
Это уже не «сбор данных ради сбора данных». Это подготовка данных для диагностики.
Механика часто объясняет то, чего не видно в PLC
Самый интересный слой оказался в механических чертежах технологических и транспортных узлов.
Там тоже нет новых PLC-регистров. Зато есть ответ на вопрос: как физически рождается изделие.
Сначала формируется основная часть изделия. Затем она переносится между технологическими участками, соединяется с другими компонентами, проходит обработку и контроль качества.
Для ML это почти готовая причинная цепочка:
формирование элемента изделия
→ перенос
→ соединение с другими компонентами
→ технологическая обработка
→ контроль
→ reject
Особенно полезна история с периодическим браком.
Некоторые механизмы работают циклически и имеют несколько повторяющихся рабочих позиций. Если дефект появляется через одинаковое число изделий, это уже не «случайный шум».
Например, если проблема появляется с устойчивой периодичностью, это сильный намёк на дефект одной из рабочих позиций циклического механизма или связанной с ним оснастки.
Это очень красивая инженерная штука.
Модель может заметить периодику в reject. Но без знания механики она не поймёт, что это похоже на проблему одной из повторяющихся рабочих позиций. А инженер с чертежом поймёт.
То же самое относится к транспортным механизмам. Если элемент изделия смещается при переносе, дефект может проявиться не сразу, а только на последующих операциях или контроле. Поэтому сигналы транспортировки, позиционирования и контроля нужно рассматривать не по отдельности, а как одну историю.
Что я в итоге собираю со станка
После разбора документов стало понятно: стратегия «давайте читать всё каждую секунду» не работает.
Станок быстрый. Некоторые события длятся очень недолго. Если опрашивать важные биты слишком редко, можно просто не увидеть короткий импульс. Он был, повлиял на процесс, а в данных его нет.
Поэтому я делю сбор на несколько уровней.
1. Быстрые события
Сюда попадают сигналы, которые могут коротко мигнуть, но сильно повлиять на качество:
- run/stop;
- готовность safety;
- glue ready/alarm;
- servo ready/alarm;
- reject;
- interlock;
- door/guard;
- product transfer;
- cutter states;
- phase-related flags;
- важные операторские кнопки.
Для таких сигналов нужен отдельный высокочастотный контур сбора на коротком приоритетном списке. Не на тысячах сигналов, а только на наиболее важных.
Если сигнал совсем короткий, лучше делать latch или счётчик на стороне PLC, чтобы не потерять событие между опросами.
2. Основной срез линии
Есть большой пласт сигналов, которые не обязательно читать ультрабыстро, но нужно видеть регулярно: статусы, большинство X/Y/M/L, часть приводов, текущие технологические параметры.
Для этого подходит отдельный основной контур с более низкой частотой опроса. Это компромисс: достаточно быстро для наблюдения за процессом, но без неоправданной нагрузки на сеть и хранилище.
3. Аналоговые параметры
Аналоги часто самые ценные для ML, потому что именно они показывают не «сломалось/не сломалось», а постепенное ухудшение:
- натяжение полотен;
- вакуум;
- speed references;
- servo trim;
- drift фаз;
- температура клея;
- косвенные признаки перегруза и износа.
Часть таких параметров имеет смысл читать быстро, часть — реже. Не нужно фанатично тянуть всё с максимальной частотой. Если параметр физически меняется медленно, нет смысла читать его как импульсный датчик.
4. Контекст
Это слой, который чаще всего забывают, а потом удивляются, почему модель бесполезна.
Нужно хранить:
- активный рецепт;
- формат изделия;
- скорость линии;
- смену рулона;
- переходы клеевых машин;
- действия оператора;
- аварии;
- причины reject;
- stop/start;
- maintenance action;
- SKU;
- партию сырья;
- смену;
- downstream quality, если она доступна.
Без этого можно собрать терабайты сигналов и всё равно не понять, что произошло.
Как хранить данные, чтобы потом не страдать
Я не хочу хранить только «текущее значение сигнала». Для ML этого мало.
Для битов важен момент изменения. Не просто «сейчас 1», а:
- когда переключился;
- какой сигнал;
- с какого значения на какое;
- на каком рецепте;
- при какой скорости;
- в каком цикле изделия, если это доступно.
Для аналогов нужен временной ряд: сырое значение и инженерное значение, если известны правила масштабирования.
Для аварий — отдельная лента событий: когда началась, когда закончилась, когда оператор подтвердил.
Для HMI и команд оператора — отдельная лента. Потому что «станок сам начал вести себя иначе» и «оператор нажал кнопку» — это разные истории.
Для качества — отдельные product/cycle records. Идеально, когда можно связать конкретный цикл изделия с тем, что потом увидела камера или downstream-контроль.
Такой дизайн позволяет строить и supervised-модели, и anomaly detection, и нормальную диагностику по журналам.
В чём здесь инженерная элегантность
На поверхности задача выглядит как «подключиться к PLC и выгрузить сигналы».
Но реальное решение оказалось другим:
не просто читать станок, а собрать переводчик между PLC и физическим процессом.
Электрическая схема говорит, что читать.
Layout говорит, где это находится.
Технологическая схема говорит, на каком этапе процесса это работает.
Чертёж изделия говорит, какой сейчас должен быть нормальный режим.
Клеевая конфигурация говорит, какой слой пострадает при alarm.
Механические чертежи говорят, где искать периодический дефект.
А сбор данных связывает всё это во времени.
В итоге получается простая цепочка:
адрес PLC
→ зона станка
→ этап процесса
→ рецепт
→ оснастка
→ возможный дефект
→ место, куда идти смотреть
Вот это уже данные для ML.
Не красивые графики ради графиков. Не тысячи безымянных тегов. А нормальная инженерная база, где каждый сигнал можно объяснить.
Главный вывод
Большая часть документов, которые я разобрал, не дала ни одного нового PLC-регистра. С точки зрения подключения они почти бесполезны.
Но именно они дали главное — смысл.
И теперь для меня подготовка данных под ML на заводе выглядит так:
- Сначала понять физический процесс.
- Потом привязать сигналы к узлам линии.
- Потом добавить рецепт и оснастку.
- Потом правильно собрать быстрые события, аналоги, аварии и действия оператора.
- И только после этого думать о модели.
Потому что ML не должен просто сказать: «у вас аномалия».
Хорошая система должна сказать примерно так:
Проблема похожа на нарушение на одном из предыдущих технологических этапов. Reject появляется позже, но причина, вероятно, возникла раньше по линии. Проверьте позиционирование, синхронизацию и состояние связанных механических узлов.
И вот такой вывод уже можно нести на производство.