SIMATIC S7: загрузка цехов, качество и простои с ИИ-агентом

Завод металлоизделий работал на контроллерах SIMATIC S7: линии механообработки и сборки управлялись S7-1500, вспомогательные участки — S7-1200, сигналы и тревоги с оборудования писались в архив, сменные задания и выработка жили в 1С:MES (Manufacturing Execution System — система оперативного управления производством), а данные по партиям и результатам контроля — в журналах качества. Автоматика работала исправно: линия останавливалась и запускалась по программе, датчики писали значения, тревоги фиксировались с точностью до секунды. Но вопрос «почему третью смену подряд линия стоит по 40 минут и из-за чего пошла партия с отклонением» решался не в системе, а в разговоре: мастер вспоминал, наладчик объяснял, технолог сверял бумажный журнал, и к утру появлялась версия причины. Версия почти всегда была правдоподобной — и далеко не всегда верной. Закрывает этот разрыв ИИ-агент — программа, которая по заданному правилу сама читает данные и выполняет шаги.

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

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

Ниже — почему данные с контроллера есть, а управленческой картины нет; что съедает время между сигналом и решением; что именно делает агент поверх SIMATIC S7; какие риски это снимает и сколько часов возвращает; где проходят границы ответственности; как это выглядит на практике и как внедрить такой контур поэтапно, не останавливая производство.

Коротко

Контроллеры SIMATIC S7 фиксируют сигналы и тревоги, но причину простоя и брака по ним собирают руками на следующий день. ИИ-агент читает журналы S7 и данные партий, разбирает каждую остановку по времени, линии и параметрам и возвращает результат мастеру и директору по производству. Проверить это на своих линиях можно на бесплатном разборе стратегии внедрения ИИ в компанию.

Содержание

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

Почему данные есть, а картины нет

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

Контроллер видит сигнал, но не видит причину

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

Отсюда типичная картина: журналы есть, отчёт есть, а разбор причин — нет. По отчёту Siemens True Cost of Downtime, средняя крупная площадка теряет 25 часов в месяц на внеплановых остановках, при этом фиксируется в среднем 20 остановок за месяц. Двадцать эпизодов — это ровно столько, сколько можно разобрать руками только при одном условии: если разбор идёт в ту же смену, а не задним числом.

Сменный отчёт собирают руками

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

Отклонение видно, когда партия уже уехала

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

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

Время уходит не на «аналитику», а на цепочку ручных сверок. На заводе с двумя линиями и двумя сменами она выглядит так:

1. Мастер в конце смены вручную выписывает из журнала тревог эпизоды остановок и пытается вспомнить, чем каждый закончился.
2. Наладчик добавляет то, что помнит: меняли привод, чистили датчик, ждали заготовку, вызывали электрика.
3. Технолог отдельно поднимает записи по партиям и сверяет их с замечаниями службы качества.
4. Начальник участка сводит три источника в один отчёт — обычно в таблице, часто в конце недели.
5. Директор по производству читает сводку, задаёт вопросы, и часть времени уходит на перепроверку цифр, а не на решение.
6. Отдельно, раз в месяц, кто-то пытается объяснить, почему загрузка линий упала: материал, люди, поломки или качество.
7. Итог разбора живёт в переписке и в голове участников — до следующего месяца, когда всё начинается заново.

Ни один шаг не сложный. Проблема в том, что они повторяются каждую смену, делаются разными людьми и почти не оставляют следа: через месяц никто не помнит, почему по этой остановке решили не поднимать вопрос. Смежная задача — свести сменные задания и выработку без ручной сверки — разобрана в материале про ИИ-агента в 1С:MES: там про план и факт выпуска, здесь — про причину остановки и связь брака с процессом.

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

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

1. Читает журналы диагностики и тревог. Забирает из контроллеров эпизоды остановок с метками времени, коды тревог, состояние узлов и значения ключевых параметров — температуры, давления, тока привода, циклов. Это сырьё, из которого собирается всё остальное.
2. Собирает данные партий. Подтягивает из производственного контура сменные задания, номера партий, выработку и результаты контроля, связывая их с интервалами работы линии. Так партия перестаёт быть абстрактной строкой и получает своё время и свои параметры.
3. Склеивает эпизод остановки. По времени и оборудованию собирает цепочку: что происходило за минуту до остановки, что сработало, сколько длилось, чем закончилось. На выходе — не тревога, а эпизод с началом, концом и контекстом.
4. Ставит причину и оценивает достоверность. Относит эпизод к типу: ожидание заготовки, переналадка, отказ узла, срабатывание защиты, ошибка оператора, плановое обслуживание. Там, где данных мало, ставит «требует подтверждения» — и это важнее, чем красивая догадка.
5. Связывает брак с процессом. Сопоставляет отклонения по качеству с параметрами и остановками, которые были в это время, и показывает интервал, в котором процесс вышел за границу. Не «партия плохая», а «отклонение пошло с 14:20 после срабатывания защиты, затронуто 60 изделий».
6. Считает загрузку и потери. По сменам и линиям считает часы работы, часы простоя по причинам и долю потерь, объяснённых и необъяснённых. Это то, из чего складывается загрузка цеха — не по ощущению, а по журналам.
7. Возвращает результат в привычное место. Эпизоды, причины и цифры ложатся в сменный отчёт и в сводку директору по производству — в той форме, в какой их читают сегодня. Отдельно формируется короткий перечень того, что стоит посмотреть в первую очередь: повторяющиеся остановки и партии с подтверждённым отклонением.

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

Главное здесь — не часы, а незакрытые риски. Часы и деньги идут вторым планом, но они тоже посчитаны — и вынесены в отдельный раздел ниже.

Простой, который считают «мелочью»

Остановка на 12 минут не попадает в отчёт: кажется, что это шум. За месяц таких эпизодов набирается 20, и вместе они дают 25 часов, то есть больше полной смены на площадку — цифра из отчёта Siemens. Дальше арифметика жёсткая: час простоя в обследованных отраслях стоит в среднем от 39 тысяч долларов, а на автомобильных производствах превышает 2 млн. Даже если ваша линия дешевле на порядок, каждый неразобранный эпизод — это деньги, которые уже потеряны и про которые никто не помнит.

Брак, который ушёл в партию

Брак редко бывает случайным: почти всегда ему предшествует отклонение процесса, которое видно в контроллере. Когда связка «параметр → партия» собирается в смену, бракованные изделия останавливают на участке. Когда связка появляется через неделю, партия уже упакована, а часть — у заказчика. По оценке Deloitte, предиктивное обслуживание, то есть работа по состоянию оборудования, снижает количество поломок на 70% и затраты на обслуживание на 25% — механизм тот же: сигнал используется до того, как он превратился в потерю.

Срыв отгрузки и неустойка по договору поставки

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

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

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

Потеря управляемости и «отчёт красивее реальности»

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

Решение на следующий день вместо этой смены

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

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

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

| Показатель | Вручную | С агентом | | Сводка простоев за месяц по трём линиям и двум сменам | 40 часов | 10 часов | | Разбор причин остановок по журналам контроллеров | 24 часа | 6 часов | | Сверка брака с параметрами процесса по партиям | 18 часов | 5 часов | | Подготовка отчёта директору по производству | 8 часов | 2 часа | | Итого в месяц | 90 часов | 23 часа |

Арифметика открытая: 67 часов разницы при ставке 750 рублей в час — это около 50 000 рублей в месяц на одной площадке и примерно 100 000 рублей на двух, то есть порядка 1,2 млн рублей в год. На одной линии экономия — около 22 часов, то есть примерно 16 500 рублей в месяц. Ставку и объёмы подставляйте свои: в расчёте взята средняя стоимость часа мастера и технолога, а не чья-то конкретная зарплата.

Границы измерения, чтобы цифра не выглядела рекламой: часы взяты по типовому месячному циклу сборки отчёта и хронометражу операций «снять эпизод», «определить причину», «сверить партию»; расхождение оценок — в пределах плюс-минус 20%; публичных замеров «до и после» по конкретному заводу у нас нет, поэтому таблица — расчётная модель, а не чужой результат. Что действительно стоит проверять на пилоте: сколько эпизодов простоя разобрано в ту же смену, какая доля брака подтверждается параметрами процесса, сколько остановок повторяется из месяца в месяц и на сколько быстрее закрывается разбор после изменения.

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

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

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

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

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

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

1. Выбрать одну линию и один месяц. Лучше всего подходит линия, по которой уже есть вопросы: там видно и пользу, и пределы метода. Материал — журналы контроллера, сменные отчёты, записи по партиям и результаты контроля за месяц.
2. Собрать эталон руками. Мастер и технолог выписывают по этому месяцу, что считают простоем, а что переналадкой, и какие партии они считают проблемными. Это точка сравнения — нужна один раз и никуда не публикуется.
3. Подключиться на чтение. Агент забирает данные через штатные интерфейсы контроллера и из производственного контура. Программа контроллера не меняется, в управление агент не вмешивается.
4. Проверить на истории. Прогнать разбор по шести-двенадцати месяцам архивов и сравнить с эталоном мастеров. Здесь видно, где правило слишком широкое, а где линия действительно ведёт себя иначе.
5. Ввести разбор в смену. Когда история сходится, эпизоды начинают приходить по ходу смены: остановка, причина, параметры, партия. С этого момента решение принимается в ту же смену, а не на следующий день.
6. Расширять по одной линии. Затем вторая линия, вторая площадка, сводка по загрузке цехов и отчёт директору по производству. Каждый следующий шаг — после того, как предыдущий подтвердился на живом месяце и мастера согласились с разбором.

Что в итоге

Риски идут первыми, потому что они измеряются не часами. Неразобранный простой складывается в 25 часов в месяц на площадку. Брак, обнаруженный после отгрузки, — это возврат партии и разговор с заказчиком. Срыв сроков — неустойка по договору поставки. Знание, живущее в одном наладчике, — риск на день его отпуска. Отчёт, собранный по памяти, — потерянная управляемость: где именно теряется загрузка, не знает никто.

Деньги и часы идут вторым планом, но они есть: около 67 часов в месяц на двух площадках и примерно 100 000 рублей при ставке 750 рублей в час, то есть порядка 1,2 млн рублей в год. Это расчётная модель на открытых вводных, а не отчёт по чужому заводу: объёмы, ставка и состав потерь подставляются свои.

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

Источники

• Стоимость внеплановых простоев: отчёт Siemens True Cost of Downtime — Fortune Global 500 теряют около 11% годового оборота (порядка 1,5 трлн долларов), средняя крупная площадка теряет 25 часов в месяц при 20 остановках, годовые потери на площадку около 129 млн долларов, час простоя в обследованных отраслях стоит в среднем от 39 тыс. долларов; там же примеры снижения внеплановых простоев вдвое: assets.new.siemens.com.
• Эффект работы по состоянию оборудования: позиционный документ Deloitte по предиктивному обслуживанию — рост производительности в среднем на 25%, снижение количества поломок на 70%, снижение затрат на обслуживание на 25%; внеплановые простои обходятся промышленности примерно в 50 млрд долларов в год: beekeeper.io (PDF Deloitte).
• Российская практика применения ИИ: данные обследования Росстата по методологии ИСИЭЗ НИУ ВШЭ (свыше 15 тыс. крупных и средних организаций, 2025 год) — 51% компаний, работающих с ИИ, применяют его в производстве продукции и оказании услуг, 57% отметили повышение качества и эффективности процессов, 66% используют технологии обработки визуальных данных, а 58% назвали главным барьером высокие затраты: ict.moscow.
• Первоисточник исследования и серия публикаций по мониторингу применения ИИ в российских компаниях: issek.hse.ru.