Сначала данные, потом «предсказание»

Ирландская Total Plastic Solution (TPS) — небольшое производство деталей методом литья пластмасс под давлением. В кейсе сети European Digital Innovation Hubs компания описана как предприятие с 10–49 сотрудниками и 28 термопластавтоматами. У TPS уже была собственная ERP, но производственные показатели попадали в неё с задержкой не менее одной смены — около восьми часов. По этим данным было трудно вовремя заметить износ узла, оценить цену переналадки или точно посчитать энергию на деталь.

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

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

Что изменилось на производстве

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

Система также связала энергопотребление с выпуском изделий и режимами оборудования. TPS использовала эти сведения для планирования производства, запуска нагревателей в нужное время и оценки затрат на деталь. В отдельном примере на другом предприятии данные позволили найти избыточное усилие смыкания формы, связанное с браком. По сообщению сети EDIH, разработка TPS с мая 2024 года была установлена ещё на трёх заводах. Это сведения проекта, а не независимый аудит эффекта на каждой площадке.

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

Где здесь локальный ИИ, а где обычная автоматика

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

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

Интеграция с ERP должна вести к задаче на осмотр с привязкой к машине, смене, графику параметра и ответственному, а не к загадочному сообщению «вероятность поломки 87%». Полезно сохранять, подтвердил ли мастер неисправность, какие действия предпринял и сколько было простоя. Эти обратные метки дают материал для пересмотра порогов и модели.

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

Данные и ограничения, которые нельзя пропустить

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

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

Кибербезопасность особенно важна на границе производственной сети. На первом этапе делайте поток из OT в аналитический контур преимущественно односторонним и не предоставляйте ИИ запись в контроллер. Доступ к сигналам и журналам ремонта распределяйте по ролям. Автоматическое управление нагревателями в TPS описано отдельно; повторять его без инженерной оценки защиты и штатных межблокировок нельзя.

Как считать экономику без придуманного эффекта

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

Модельный пример, не результат TPS: если один подтверждённый сигнал предотвращает четыре часа остановки стоимостью 20 000 ₽ в час, потенциально сохранено 80 000 ₽. Но если система даёт 20 ложных тревог в месяц по часу проверки каждая, эти затраты, стоимость датчиков, внедрения и обслуживания необходимо вычесть. Пока неизвестно, действительно ли остановка случилась бы, оценку нельзя записывать как полученную прибыль.

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

Следующий шаг для руководителя

Назначьте совместный разбор производственника, электрика и ИТ-ответственного. Выберите одну линию, один вид затратного простоя и три измеряемых сигнала. Зафиксируйте, кто подтверждает тревогу, кто открывает наряд в ERP и кто имеет право менять режим станка. Через месяц оцените качество данных и цену проверки сигналов; лишь затем решайте, нужна ли модель аномалий.

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