Подготовка станка к ML: зачем сигналу контекст
Адрес контроллера сам по себе почти ничего не значит — это бит, ноль или единица. Полезным для модели он становится, когда известно, где он находится на линии, к какому узлу относится, что станок производит в этот момент, какой стоит рецепт и оснастка. Без этого модель видит не станок, а кашу из нулей и единиц.
Ниже — как мы готовим промышленную линию к сбору данных: почему дефект не помещается в один бит, что дают документы, не добавляющие ни одного нового регистра, и как разложить потоки данных, чтобы диагностика умела называть причину, а не только факт.
Почему дефект не помещается в один бит
Сигналы контроллера сухие. Они отвечают на короткие вопросы: датчик сработал или нет, привод готов или в аварии, изделие прошло или потерялось, была отбраковка или нет.
Но дефект на линии почти никогда не рождается в одном бите. Типичная цепочка выглядит так: материал пошёл нестабильно → слой лёг криво → клей не попал в фазу → нож отрезал уже проблемное изделие → контроль увидел дефект → изделие ушло в отбраковку.
Если смотреть только на момент отбраковки, видно конец истории. Для модели и для ремонта важнее начало. Отсюда следует практический вывод: задача не «читать всё подряд», а собрать вокруг каждого сигнала контекст, достаточный, чтобы объяснить человеку у станка, что именно пошло не так.
Разница в формулировке результата:
| Без контекста | С контекстом |
|---|---|
| «Модель увидела аномалию в одном из сигналов» | «Нарушение возникло на предыдущем технологическом этапе; отбраковка появляется позже. Проверить позиционирование, синхронизацию и состояние связанных узлов» |
Первое нельзя отнести в цех. Второе — можно.
Документы, которые не дают ни одного регистра
Большая часть разобранной документации не добавила ни одного нового адреса. С точки зрения подключения к контроллеру они бесполезны. Но именно они дают смысл.
Компоновка линии. В ней нет ни адресов, ни регистров, ни сетевой схемы. Зато она превращает абстрактный станок в физическую карту: когда модель свяжет аномалию с узлом, по компоновке видно, куда идти смотреть.
Электрическая схема говорит, что читать. Компоновка — где это находится. Технологическая схема — на каком этапе процесса работает. Чертёж изделия — каким должен быть нормальный режим. Конфигурация нанесения клея — какой слой пострадает при конкретной аварии. Механические чертежи — где искать периодический дефект.
Собранные вместе, они дают цепочку перевода:
адрес PLC → зона станка → этап процесса → рецепт → оснастка → возможный дефект → куда идти смотреть
Вот это уже данные для машинного обучения, а не тысячи безымянных тегов.
Как разложить потоки данных
Складывать всё в одну таблицу — ошибка, которая проявится на этапе обучения. Разные сущности живут в разном темпе и отвечают на разные вопросы, поэтому потоки разводятся:
- Быстрые дискретные события — состояния датчиков и приводов, с высокой частотой опроса.
- Аналоговые величины — свой темп, своё сглаживание, свои допуски.
- Аварии — отдельная лента: когда началась, когда закончилась, когда оператор подтвердил.
- Действия оператора — отдельно от всего. «Станок начал вести себя иначе» и «оператор нажал кнопку» — принципиально разные истории, и смешивать их нельзя.
- Качество по циклам — записи по изделию или циклу, чтобы связать конкретный цикл с тем, что позже увидел контроль.
Такая раскладка одновременно поддерживает обучение с учителем, поиск аномалий и обычную инженерную диагностику по журналам. Слитая в одну таблицу — не поддерживает ничего из трёх.
Порядок работ
- Сначала понять физический процесс, а не схему подключения.
- Привязать сигналы к узлам линии по компоновке.
- Добавить контекст рецепта и оснастки — без них режим не определяется.
- Развести потоки: быстрые события, аналоги, аварии, действия оператора, качество.
- Обеспечить связывание по времени между потоками.
- Проверить, что по любому сигналу можно ответить, где он физически находится.
- Сформулировать, как результат модели будет звучать для человека у станка.
- И только после этого переходить к выбору модели.
Нижний слой этой работы — сбор и описание самих адресов — разобран в материале о карте сигналов PLC, а порядок инвентаризации источников — в разборе, как привести заводские данные под ML. Что этот слой даёт предприятию управленчески, показано в статье, зачем предприятию MES.
Частые ошибки
Считать подключение к контроллеру основной задачей. Подключение — самая простая часть. Основная работа — построить переводчик между сигналом и физическим процессом.
Собирать всё подряд «на всякий случай». Тысячи безымянных тегов увеличивают объём хранилища и не увеличивают объём знания.
Сливать аварии и действия оператора в один поток. После этого невозможно отличить поведение оборудования от вмешательства человека, а именно эта разница чаще всего и объясняет дефект.
Смотреть только на момент отбраковки. Причина почти всегда раньше по линии, и модель, обученная на конце цепочки, будет уверенно указывать не туда.
Отдавать в цех вывод вида «обнаружена аномалия». Такой результат не приводит ни к одному действию и быстро перестаёт вызывать доверие.
Что делать дальше
Возьмите один сигнал, по которому у вас чаще всего случается отбраковка, и попробуйте письменно пройти цепочку до конца: зона станка, этап процесса, рецепт, оснастка, вероятный дефект, место осмотра. Если цепочка обрывается на первом же звене, проект пока не про детекцию аномалий, а про сбор контекста — и это нормальная стадия, которую честнее пройти осознанно, чем обнаружить после обучения первой модели.