ИИ-агент на производстве: смены, простои и качество в OwenCloud

Производственная компания с тремя площадками вела телеметрию в OwenCloud: контроллеры и датчики на линиях, архив параметров, уведомления дежурному, графики на телефоне. Учёт заказов и наряды жили в 1С:ERP (ERP, Enterprise Resource Planning — планирование ресурсов предприятия), лаборатория вела журнал качества, мастера — бумажные обходы. Системы работали, данные шли, но разбор смены по-прежнему начинался с выгрузки в Excel: мастер складывал ряды из облака, наряды из учётной системы и записи лаборатории в одну таблицу и вручную искал, где линия встала и почему партия ушла в отклонение.

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

Смежный разбор того же уровня — ИИ-агент поверх контроллеров SIMATIC S7: причина простоя, брак по партиям и загрузка цехов.

Коротко

OwenCloud собирает телеметрию с приборов и хранит её 90 дней, но не объясняет простои и отклонения качества. ИИ-агент читает архив через API или выгрузку, сопоставляет его со сменами, нарядами и партиями, находит остановки и отклонения и отдаёт мастеру протокол смены с фактами. Уставки и команды оборудованию остаются за человеком.

Содержание

• Почему в облаке есть данные, а разбора смены нет
• Что съедает время между сигналом и решением
• Что делает ИИ-агент поверх OwenCloud
• Какие риски это снимает
• Сколько часов это возвращает
• Что остаётся за человеком
• Как это выглядит на практике
• Как внедрить поэтапно
• Что в итоге
• Источники

Почему в облаке есть данные, а разбора смены нет

OwenCloud — облачный сервис диспетчеризации: он опрашивает приборы, хранит значения параметров, показывает дашборды, графики, таблицы и мнемосхемы, отправляет уведомления в SMS, на почту, в Telegram и push, позволяет выгружать архив в XLSX и отдаёт открытый API для интеграций. По данным сервиса, к нему подключено больше 50 тысяч приборов, им пользуются более 14 тысяч клиентов, а за три месяца в системе фиксируется свыше 12 миллионов событий. Сервис включён в реестр российского программного обеспечения под номером 29562, данные хранятся в дата-центрах уровня Tier III на территории России.

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

У облака есть и технические границы, которые заранее определяют, что агенту доступно, а что нет. Минимальный период опроса в тарифах OwenCloud — от 10 до 60 секунд в зависимости от плана, глубина хранения архива — 90 дней. Это значит, что облако хорошо видит сменные и часовые процессы: выработку, расход, температуру, давление, загрузку линии. Но оно не предназначено для разбора секундных аварий и не заменяет систему управления: контуры регулирования, блокировки и защиты выполняются в контроллере на месте.

Третья граница — человеческая. Архив ведётся, но причины остановок живут в голове мастера и в переписке. В справочнике причин на многих заводах всего две-три формулировки: «переналадка», «ожидание материала», «поломка». Под ними скрываются разные события с разной ценой, и по такой классификации нельзя ни сравнить площадки, ни понять, где теряется выработка. Как это устроено на уровне документов заказа и качества детали, разобрано в статье про ИИ-агента в К3-Мебель.

Что съедает время между сигналом и решением

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

1. Выгрузка архива. Мастер выбирает участок, период и параметры, выгружает несколько файлов XLSX. Если параметров много, выгрузка делается частями.
2. Приведение времени. Приборы и учётная система могут жить в разных часовых поясах и с разной дискретностью; перед сравнением ряды нужно выровнять.
3. Поиск остановок. Остановку видно по падению тока, расхода или скорости линии. Но не каждое падение — простой: короткие провалы при переналадке выглядят так же, как начало поломки.
4. Отделение плановых остановок от внеплановых. Плановое техническое обслуживание, переналадка и обед — не потери. Без графика ТО и справочника причин их не отделить.
5. Сопоставление с нарядами. Выработка и партия живут в 1С:ERP (ERP, Enterprise Resource Planning — планирование ресурсов предприятия), сменные задания — в MES (Manufacturing Execution System — система управления производством), а фактические параметры — в облаке. Связь между ними держится на номере партии и времени, и её приходится восстанавливать вручную.
6. Проверка параметров партии. Технолог смотрит, укладываются ли температура, давление и влажность в рецепт, и были ли отклонения внутри партии, а не только в среднем за смену.
7. Написание протокола. Итог собирается в одну страницу: что произошло, когда, с чем совпало, что проверить. Дальше эта страница обсуждается на планёрке и обычно живёт до следующей смены.

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

Что делает ИИ-агент поверх OwenCloud

ИИ-агент — программа, которая по заданному правилу сама читает данные, сопоставляет их и выполняет шаги. В этом контуре он не управляет процессом и не заменяет облако: он забирает то, что уже записано, и собирает из этого разбор. Вот его работа по шагам.

1. Читает архив. Забирает ряды через API или из выгрузки XLSX: параметры линии, состояние дискретных сигналов, события и уведомления. Если архив нужен глубже 90 дней, агент заранее складывает нужные ряды в собственное хранилище.
2. Приводит данные к одному времени. Выравнивает ряды по часовому поясу и шагу, помечает разрывы связи как «нет данных» и не заполняет их оценкой.
3. Строит события остановок. По правилам: ток двигателя упал ниже порога и держится дольше заданного времени, расход упал, скорость линии нулевая. Порог и длительность настраиваются на пилоте, а не берутся из головы.
4. Отделяет плановое от внепланового. Сверяет события с графиком технического обслуживания и переналадок, с обеденными перерывами и плановыми пусками. Всё, что осталось, попадает в список потерь.
5. Сопоставляет с нарядами и партиями. Находит в 1С:ERP (ERP, Enterprise Resource Planning — планирование ресурсов предприятия) наряд, партию и плановое задание, проверяет, сколько фактически выпущено и когда закрыт наряд.
6. Проверяет параметры партии против рецепта. Смотрит не среднее за смену, а распределение внутри партии: был ли выход за границы, сколько времени линия работала вне допуска, совпало ли это с остановкой или сменой сырья.
7. Собирает протокол смены. Отдаёт короткий документ: выработка против задания, внеплановые остановки с временем и длительностью, отклонения качества с точкой архива, версии причин и список того, что нужно проверить. Каждый вывод сопровождается ссылкой на исходные данные.
8. Пишет в журнал. Фиксирует, какие правила сработали, какие версии причин подтвердил мастер и какие отклонил. Журнал становится основой для уточнения правил и для разбора спорных партий.

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

Какие риски это снимает

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

Неустойка за срыв поставки

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

Возврат партии и переделка

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

Простой, списанный не на ту причину

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

Спор с заказчиком без доказательной базы

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

Зависимость от конкретного мастера

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

Отклонение, замеченное через неделю

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

Сколько часов это возвращает

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

Показатель	Вручную	С агентом
Разбор одной смены	25 мин	6 мин
Разбор смен за месяц (60 смен)	25 ч	6 ч
Учёт простоев и причин (40 остановок)	14 ч	3,3 ч
Разбор отклонений качества (25 партий)	7,5 ч	2,1 ч
Недельная сводка (4 сводки)	3,3 ч	1 ч
Итого в месяц	49,8 ч	12,4 ч

Арифметика открытая. Разбор смены: 60 × 25 минут = 25 часов, с агентом 60 × 6 минут = 6 часов. Простои: 40 остановок по 21 минуте = 14 часов, с агентом по 5 минут = 3,5 часа. Качество: 25 партий по 18 минут = 7,5 часа, с агентом по 5 минут = 2,1 часа. Сводки: 4 × 50 минут = 3,3 часа, с агентом 4 × 15 минут = 1 час. Итого 49,8 часа против 12,4 — возвращается 37,4 часа в месяц на одной площадке.

При стоимости часа 900 рублей это около 33 700 рублей в месяц на площадке и около 101 000 рублей на трёх площадках. В модель не входят потери от простоев и брака — они считаются отдельно и, как правило, крупнее. Границы измерения тоже нужно назвать честно: расчёт предполагает, что параметры уже пишутся в облако, справочник причин существует хотя бы в черновом виде, а наряд и партия в учётной системе связаны с линией и временем. Если справочника нет, первые две-три недели уходят на его сбор, и экономия появляется позже.

Что остаётся за человеком

• Подтверждение причины. Агент выдаёт версию с основанием, мастер — подтверждает или отклоняет. Отклонённая версия тоже полезна: она уточняет правило.
• Решение об остановке линии. Остановить, продолжить или перевести на резерв — решает человек, у которого есть контекст: заказ, запасы, состояние соседних участков.
• Изменение уставок и рецептов. Технолог, а не агент. У агента нет прав записи в приборы.
• Оценка качества лабораторией. Приборные данные и лабораторный анализ могут расходиться; арбитром остаётся лаборатория.
• Разбор с людьми. Дисциплинарные выводы и обучение — не задача агента. Он даёт факты, а не приговор.
• Ответственность за данные. Доступы, сроки хранения, персональные данные сотрудников и коммерческая тайна остаются в контуре компании.

Как это выглядит на практике

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

Метрик «до/после» по этому проекту в банке нет, и мы их не придумываем. Эффект в этой статье считается по отраслевому бенчмарку и по открытой модели, а не выдаётся за результат конкретного клиента. Названия компании и суммы не публикуются — это условие работы с такими проектами.

Как внедрить поэтапно

1. Инвентаризация данных. Выписать, какие параметры пишутся в OwenCloud, с каким периодом опроса, какие сигналы есть на контроллере, но не передаются в облако, и как часто бывают разрывы связи.
2. Справочник причин. Собрать 10–12 причин простоя, понятных мастерам, и привязать каждую к наблюдаемому признаку: падение тока, расхода, температуры, отсутствие сигнала.
3. Пилот на одной линии. Две-четыре недели на одном участке: агент читает архив, строит события, отдаёт протокол. Мастер подтверждает или отклоняет версии — это и есть настройка правил.
4. Связка с учётной системой. Подтянуть наряды, партии и плановые задания из 1С:ERP (ERP, Enterprise Resource Planning — планирование ресурсов предприятия), проверить, что связь по времени и номеру партии не рвётся.
5. Протокол и журнал. Зафиксировать формат протокола, точку доставки и журнал решений. Без журнала агент остаётся генератором текста, с журналом — становится инструментом, который учится на решениях мастеров.
6. Масштабирование. Перенести правила на остальные линии и площадки, добавить выгрузку истории глубже 90 дней в собственное хранилище, настроить недельные сводки для директора по производству.

Что в итоге

Главный результат — не сэкономленные часы, а снятые риски: срыв поставки с неустойкой, возврат партии, простой, списанный не на ту причину, спор без доказательств и зависимость от одного мастера. Часы идут вторым планом: 37,4 часа в месяц на площадке, около 33 700 рублей при стоимости часа 900 рублей и около 101 000 рублей на трёх площадках — это следствие того, что разбор перестал быть ручной работой.

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

Источники

• Информация о сервисе, тарифах и технических ограничениях: OwenCloud, описание продукта и тарифные планы — период опроса от 10 до 60 секунд, хранение архива 90 дней, выгрузка в XLSX, открытый API, реестр российского ПО № 29562, дата-центры Tier III, 50 тыс. приборов и 14 тыс. клиентов.
• Siemens, The True Cost of Downtime 2024: незапланированные простои стоят 500 крупнейшим компаниям мира 11% выручки — около 1,4 трлн долларов в год; в среднем крупный завод теряет 253 млн долларов в год, час простоя в FMCG — 36 тыс. долларов, у средних производителей — до 150 тыс. долларов в час. PDF отчёта.
• Deloitte, Predictive Maintenance Position Paper: предиктивное обслуживание повышает производительность на 25%, сокращает число поломок на 70% и затраты на обслуживание на 25%; время планирования работ — на 20–50%, доступность оборудования растёт на 10–20%. PDF.
• SBS Consulting, исследование уровня цифровизации предприятий обрабатывающей промышленности по итогам 2024 года: 53% предприятий называют барьером высокую стоимость цифровых решений по сравнению с выгодой, 49% — отсутствие необходимости, более 70% внедряют решения хаотично; внедрение АСУ ТП (автоматизированная система управления технологическими процессами) выросло на 3%, ERP — на 4%. Исследование.
• Данные Росстата об износе основных фондов на конец 2024 года: средний износ по экономике 46,7%, в добыче полезных ископаемых 53,0%, в информации и связи 56,8%. Публикация с данными Росстата.

Ещё по теме: ИИ-агент в MasterSCADA, ИИ-агент в 1С:MES, предиктивное обслуживание оборудования, как выбрать задачу для внедрения ИИ и измерить эффект., ИИ-агент в Global ERP