Что показывает кейс WRS Energie

WRS Energie + Druckluft — немецкая микрокомпания, которая занимается эффективностью систем сжатого воздуха. В опубликованном European Digital Innovation Hubs кейсе она описана как предприятие с 1–9 сотрудниками. Компания сочетает измерительное оборудование, инженерный аудит и облачную платформу AnalyzAir: данные о расходе, давлении, влажности и работе компрессоров превращаются в показатели, предупреждения и рекомендации.

В карточке EDIH указано, что решением пользуются более 100 клиентов, а повышение эффективности систем может достигать 30%. Эти цифры следует читать корректно: это заявленные поставщиком результаты, воспроизведённые в официальном кейсе поддержки стартапа, а не независимый аудит конкретного завода. Сам проект EDIH был связан прежде всего с партнёрами, финансированием и масштабированием бизнеса WRS, а не с контролируемым сравнением алгоритмов.

Масштаб проблемы при этом подтверждается независимо. Руководство Министерства энергетики США по системам сжатого воздуха отмечает, что утечки иногда расходуют 20–30% производительности компрессора; на плохо обслуживаемом предприятии типична потеря около 20%, а системная программа обнаружения и ремонта может снизить её до уровня менее 10%.

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

Почему одного детектора утечки недостаточно

Разовая ультразвуковая проверка хорошо находит конкретное шипящее соединение, но не отвечает на три управленческих вопроса:

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

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

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

Архитектура для локального контура

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

Далее поток можно построить так:

  • промышленный шлюз читает Modbus, OPC UA или штатные сигналы контроллера;
  • брокер MQTT передаёт данные в локальную временную базу;
  • сервис качества отбрасывает невозможные значения, помечает разрывы и сохраняет статус датчика;
  • расчётный слой строит удельные показатели: кВт·ч на кубометр, базовый расход вне производства, перепад давления и длительность работы под нагрузкой;
  • модель оценивает ожидаемый режим для смены, продукта и температуры;
  • отклонение проходит детерминированные правила по длительности и размеру эффекта;
  • подтверждённый сигнал создаёт черновик заявки в CMMS или журнале ремонта;
  • ответственный сотрудник принимает заявку, указывает причину и подтверждает результат после работ.

Локальный контур уместен, когда телеметрия относится к закрытой производственной сети, связь нестабильна или предприятие хочет самостоятельно хранить историю оборудования. Для одного завода достаточно обычного сервера или промышленного ПК; обработка временных рядов редко требует GPU. Облачная схема удобнее при множестве площадок и общей команде аналитиков, но тогда надо отдельно решить вопросы исходящего трафика, хранения истории, доступа поставщика и работы при потере связи.

LLM можно добавить на самом конце: она составит понятный отчёт по смене или объяснит, какие измерения привели к приоритету. Давать ей право самостоятельно менять уставки компрессора или закрывать ремонтную заявку не стоит. Такие действия должны проходить через правила, роли и подтверждение человека.

Какие данные нужны модели

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

Полезный набор включает:

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

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

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

Экономика: считать подтверждённую экономию

Заявленные WRS «до 30%» нельзя переносить в бюджет другого предприятия. Сначала нужна собственная базовая линия. Для грубой модели можно использовать:

`эффект = мощность × часы × тариф × доля потерь × доля устранённых потерь × коэффициент реакции компрессора`.

Например, возьмём условный компрессор 90 кВт, 6000 часов работы в год и тариф 8 рублей за кВт·ч. Допустим, 20% выработки теряется, половину этих потерь удаётся устранить, а особенности регулирования превращают только 60% снижения расхода в реальную экономию электроэнергии. Модельный эффект составит около 259 тыс. рублей в год: `90 × 6000 × 8 × 0,20 × 0,50 × 0,60`.

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

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

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

Ограничения и риски

Рост расхода может быть вызван не утечкой, а новым пневмоинструментом, продувкой, изменением продукта или неисправным датчиком. Без контекста производства модель будет создавать ложные заявки.

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

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

Наконец, телеметрия раскрывает режимы работы предприятия. Для локальной установки нужны отдельные сервисные учётные записи, сегментация OT-сети, журнал доступа и резервное копирование временных рядов. Модель не должна получать права на запись в контроллеры только потому, что умеет читать данные.

Практический пилот на четыре недели

1. Выберите один компрессорный контур и назначьте владельца экономического результата.
2. Зафиксируйте давление, расход, мощность и режим производства без вмешательства.
3. Проведите ночной или выходной тест и ручной ультразвуковой обход.
4. Создайте реестр утечек с местом, оценкой потерь, ответственным и сроком.
5. Устраните несколько приоритетных дефектов и повторите измерение при сопоставимой нагрузке.
6. Только после этого обучите простую модель базового расхода и запустите её в теневом режиме.
7. Принимайте решение о масштабировании по подтверждённым кВт·ч и рублям, а не по красивому графику аномалий.

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