Что на заводе действительно имеет смысл автоматизировать с помощью ИИ

Успех ИИ-проекта на заводе определяется в основном не моделированием. Он определяется тем, насколько точно вы назвали тип своей задачи, выдержат ли её ваши производственные данные и что произойдёт, когда модель ошибётся.

Правила, машинное обучение, оптимизация и языковые модели: что под какую задачу

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

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

Оптимизация — отдельная дисциплина, и её регулярно записывают в ИИ по ошибке. Составление графика при ограниченных мощностях, выстраивание последовательности ради минимума переналадок, назначение аттестованных операторов — это задачи с ограничениями и целевой функцией. Размеченные примеры им не нужны, а вот честные нормы времени и ограничения нужны, и их обычно приходится измерять, а не принимать на веру. Для планирования почти всегда правильный инструмент — решатель, способный выразить вашу реальную оснастку и время сушки, потому что планирование — задача с ограничениями, а не задача прогнозирования.

Языковые модели появились последними, и их область применения конкретна. Им подходит работа, устроенная как документ или диалог: прочитать входящий запрос и составить из него структурированный, сжать длинную историю обслуживания до текста, который техник успеет прочитать перед выходом к станку, ответить, что именно сказано в технологической инструкции о наладке. Они не измерительные приборы: просить их предсказать отказ подшипника по данным вибрации — всё равно что забивать шуруп молотком.

Какие данные на самом деле нужны ИИ-проекту на заводе

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

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

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

Прогнозирование спроса и потребления — там, где отдача ближе всего

У прогнозирования обычно самый короткий путь к деньгам, потому что альтернатива наглядно слаба: на большинстве заводов берут прошлый год и добавляют процент или просят у продаж цифру, которая на самом деле является планом. Модель, использующая историю заказов, сезонность, структуру клиентов, открытую воронку и календарные эффекты, обыгрывает такой подход на позициях с регулярным, повторяющимся спросом. На нерегулярных и проектных позициях — а это часто большая часть номенклатуры и малая доля объёма — обычно не обыгрывает, и наивный прогноз или метод Кростона там трудно превзойти. Честный вариант сначала сегментирует номенклатуру и оставляет такие позиции политике складских запасов и экспертному суждению.

Эффект проявляется дальше по цепочке, а не в самом прогнозе: меняется страховой запас, смещаются сроки закупки позиций с длинным сроком поставки, реже случаются авральные переналадки, ломающие график. Процент точности прогноза на слайде — это не выгода; выгода — дни запаса и число срочных заказов.

Предиктивное обслуживание — только там, где отказ действительно предсказуем

Здесь всё упирается в то, развивается ли отказ постепенно и оставляет ли он след в чём-то измеримом. Износ подшипника, дисбаланс, расцентровка, постепенное засорение фильтра или контура охлаждения, дрейф давления в гидравлике, ползущий вверх ток двигателя на одной и той же операции — это развивается неделями или месяцами, изредка лишь часами, что обычно уже слишком поздно, чтобы ставить датчики, и проявляется в вибрации, токе, температуре или давлении. Модель это видит — но нередко видит и грамотно выбранный порог, поэтому сравнение с простой статистикой здесь принципиально.

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

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

Прогнозирование качества и снижение брака

Качество — это, как правило, там, где лежат самые большие деньги, и там же требования к данным самые жёсткие. Привлекательный вариант предсказывает по условиям во время выполнения заказа, какие детали или партии в зоне риска, чтобы кто-то мог вмешаться до появления брака, а не обнаружить его на финальном контроле.

Это работает, когда процесс оснащён датчиками с разрешением того объекта, который вы хотите предсказывать, и когда у брака есть реальный код причины, привязанный к операции. И это тихо не работает, когда брак списывают в конце заказа на заказ целиком, — тогда модель не может понять, какие условия породили какой отказ.

Один непарадный шаг окупается раньше любой модели: фиксация причин брака на станке, в момент события, из короткого списка причин, понятных оператору. Многие заводы, заказывающие прогнозирование качества, уже по одним этим данным обнаруживают, что небольшое число причин даёт основную часть потерь, и закрывают самую крупную конструкторско-технологическим изменением. Это хороший результат, а не провалившийся проект.

ИИ для планирования производства: почему это задача оптимизации, а не прогнозирования

Если план срывается каждую неделю, причина редко в нехватке интеллекта и обычно — в нехватке ограничений. Меняет дело планировщик, который учитывает общую оснастку, семейства переналадок, квалификации операторов, время выдержки и те окна обслуживания, которые вы намерены соблюдать.

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

Обнаружение аномалий в энергетических и технологических сигналах

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

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

ИИ в продажах и работе с клиентами — там, где работа устроена как документ

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

Конкретно: входящий запрос, разобранный на деталь, количество, требуемую дату и особые требования, с подтянутыми рядом прошлыми предложениями. Переписка, сведённая к записи в CRM с зафиксированным обязательством и следующим действием.

Два правила удерживают это от провала. Модель составляет черновик, а отправляет человек — по крайней мере до тех пор, пока не станет понятен уровень ошибок в этом конкретном процессе. И всё фактическое — цена, срок поставки, остаток, обещанная дата — берётся из системы учёта, а не из модели, которая должна цитировать найденное значение и никогда его не сочинять. Автоматизация CRM, выдумывающая срок поставки, хуже её отсутствия, потому что она связывает компанию обязательством.

Оценка эффекта до того, как что-то покупать

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

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

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

Сколько на самом деле стоит интеграция

Модель обычно самая дешёвая часть; стоимость живёт на стыках. Сначала надо снять сигналы со станков, а реальный завод — это разнородный парк: часть оборудования говорит по OPC UA, часть по Modbus или последовательному протоколу, часть даёт сухой контакт, а к закрытым контроллерам приходится ставить дополнительный датчик на шпиндель, гидроконтур или силовую линию. Затем результат должен попасть туда, где он вызывает действие: на экран, в который оператор и так смотрит, в заявку на ремонт, в ограничение для планировщика, в блокировку по качеству.

После этого приходит сверка нормативно-справочной информации, которую никто не закладывает в объём работ. Артикулы, различающиеся суффиксом между системами, несовпадающие единицы измерения, спецификация, которую ведут в двух местах, идентификаторы станков, изменившиеся при перестановке линии. Ничего сложного в этом нет, и всё это занимает больше времени, чем софт. Предложение, в котором посчитана модель, а стыки оставлены как «интеграция по отдельной оценке», — это не цена.

Кто эксплуатирует модель и что происходит, когда она ошибается

У каждой внедрённой модели должен быть владелец с именем и фамилией, и вопрос закупки — кто в вашей организации им станет. Этот человек должен знать, на чём модель обучена, какие условия выходят за эти рамки, почему она выдала конкретный результат и как вывести её из контура, не останавливая производство. Модель, переставшая отвечать, должна откатываться к тому, что управляло процессом до неё, — к плану выборочного контроля, порогу, проверке оператором, а не к бесконтрольному пропуску продукции и не к остановленной линии. Решите, что именно из этого, до запуска в эксплуатацию.

Объяснимость в цехе — не философский вопрос, а условие принятия системы людьми. Рекомендация, которая говорит, какой сигнал сдвинулся, насколько и относительно какой базы, приводит к действию. Оценка без объяснения игнорируется, а когда игнорирование становится нормой, система превращается в украшение.

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

Управление моделями, дрейф и нагрузка на сопровождение, которую никто не закладывает в бюджет

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

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

И заложите в бюджет постоянные трудозатраты. Модель в эксплуатации — это обслуживаемый актив, ближе к технологическому оборудованию, чем к купленному отчёту. Если ни у кого нет выделенного времени на переобучение, разбор оповещений и проверку того, что данные по-прежнему поступают, она будет деградировать, пока ею не перестанут пользоваться.

Реалистичный первый проект и критерии приёмки

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

До любых покупок сделайте выгрузку данных. Один год, одна линия, условия и результаты в одних и тех же строках, два человека, знающие процесс, подтверждают достоверность строк. Затем сравните с простой альтернативой: порогом, контрольной картой или суждением нынешнего планировщика.

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

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

Где здесь Meta Smart Factory

Meta Smart Factory построена по модульному принципу, и здесь это важно, потому что модуль ИИ и машинного обучения стоит поверх исполнительного уровня, а не рядом с ним. MES даёт события и контекст, подключение IIoT и OPC UA дают сигналы со станков, модуль качества даёт брак с причинами, модуль ТОиР даёт историю отказов, а APS потребляет результат там, где ответом является график, а не прогноз.

Можно начать с одного модуля под одно названное ограничение и добавить следующий, когда первый войдёт в работу. Чего не убирает ни одна платформа, так это самого трудного: договориться, что означают цифры, добиться фиксации причин на станке и решить, кто владеет моделью, когда она ошибается. Разобрать эту последовательность для конкретного завода — более полезный первый разговор, чем демонстрация, потому что демонстрация сработает всегда.