TRACE MODE и T-FACTORY: ИИ-агент для планирования, качества и простоев

Производственная компания вела технологический процесс и учёт выпуска в двух связанных контурах: SCADA TRACE MODE (Supervisory Control and Data Acquisition — диспетчерское управление и сбор данных) компании АдАстра собирала телеметрию с оборудования, вела архив значений и сигнализировала об отклонениях, а T-FACTORY, система класса MES (Manufacturing Execution System — управление исполнением производства), держала сменные задания, наряды, материальные потоки, себестоимость и паспорта партий. Учёт был настроен: теги с контроллеров читались, задания выдавались в цех, отчёты о смене закрывались в системе. Но всё, что происходит между «сигнал попал в архив» и «смена получила решение», делали люди вручную: мастер восстанавливал причину остановки по памяти, технолог искал связку партии, режима и станка на следующий день, а сводку простоев за месяц собирали из переписки.

Речь не о замене TRACE MODE или T-FACTORY и не о «модернизации» их силами ИИ. Речь о тонком слое поверх работающего контура: агент читает архив сигналов и данные производственных заданий, связывает остановку с партией и оборудованием, готовит разбор причин и проект сменного задания. ИИ-агент — программа, которая по заданному правилу сама читает данные и выполняет шаги; он не принимает решений вместо мастера и диспетчера, не отдаёт команды оборудованию и не отменяет систему, в которой живёт учёт.

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

Коротко: что добавляет ИИ-агент к TRACE MODE и T-FACTORY

Агент читает архив сигналов и трендов из TRACE MODE и производственные задания, партии и данные о браке из T-FACTORY, связывает остановку с оборудованием и партией, собирает причины простоев в одну картину и готовит проект сменного задания — со ссылками на документы и время. Мастер, технолог и диспетчер подтверждают решения. Система остаётся контуром учёта и управления, агент закрывает участок между её данными и решением на смену.

Содержание

• Что такое TRACE MODE и T-FACTORY и какие процессы в них живут
• Где граница контура: архив есть, объяснения нет
• Что съедает время между сигналом и решением
• Что делает ИИ-агент поверх TRACE MODE и T-FACTORY
• Какие риски это снимает
• Сколько часов это возвращает
• Расчёт эффекта на вашем объёме
• Что остаётся за человеком
• Как это выглядит на практике
• Чеклист перед стартом
• Как внедрить поэтапно
• Чем измеряется эффект

Что такое TRACE MODE и T-FACTORY и какие процессы в них живут

TRACE MODE — российская SCADA-система компании АдАстра (Москва). Это 64-разрядная платформа для автоматизации технологических процессов, телемеханики, диспетчеризации и учёта ресурсов, работающая под Windows и Linux. По данным вендора, у системы более 134 000 реальных инсталляций в России, она применяется в 50 отраслях, сертифицирована на совместимость с отечественными операционными системами (Astra Linux, РЕД ОС, ALT Linux) и входит в реестр российского программного обеспечения.

В контуре предприятия SCADA отвечает за нижний уровень: опрос контроллеров, датчиков и счётчиков; архив значений и трендов по каждому параметру; сигнализацию, когда параметр вышел за границы; экраны оператора; отчёты о ходе технологического процесса; программируемую логику управления (SOFTLOGIC). Именно здесь появляется первичный факт: что происходило с линией, когда и с какой скоростью.

T-FACTORY — MES-контур того же вендора, который стоит над телеметрией и связывает её с производственным учётом. В описании системы заявлены:

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

Для руководителя практический вывод такой: система уже хранит полную картину — что заказано, по какой технологии, с какими нормами, что реально сделано за смену и сколько это стоило. Проблема не в отсутствии данных, а в скорости их превращения в решение. И в объёме: по нормам управления сигнализациями (EEMUA Publication 191) в устойчивом режиме на одного оператора должно приходить около одного сигнала в 10 минут, а больше 10 сигналов за 10 минут на одну рабочую позицию считается шквалом, в котором настоящая авария теряется среди сообщений. Человек физически не успевает разбирать их вручную.

Где граница контура: архив есть, объяснения нет

TRACE MODE точно отвечает на вопрос «что происходило с параметрами и когда», T-FACTORY — «сколько выпущено, из чего, какая себестоимость и по какому заданию». Факт фиксируется в обоих контурах: время простоя есть, отклонение по размеру есть, брак по документу есть.

Чего эта связка по своей природе не делает — и не должна:

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

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

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

Типовой круг ручной работы на среднем производстве выглядит так:

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

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

Что делает ИИ-агент поверх TRACE MODE и T-FACTORY

Агент ставится рядом с контуром и работает с его данными. Ниже — сценарий для производства, где уже есть TRACE MODE, T-FACTORY и планово-диспетчерский отдел.

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

Границы сценария проговариваются на старте: агент не пишет в контур управления, не меняет уставки и технологические карты, не отдаёт команды контроллерам и не останавливает линию. Всё, что он делает, — читает, связывает, предлагает и фиксирует.

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

Риски идут первыми, потому что они и есть предмет разговора: часы и деньги — уже следствие. Формулировки ниже — не «снижение рисков вообще», а конкретные сценарии.

Настоящая авария теряется в шквале сигналов

По нормам управления сигнализациями (EEMUA Publication 191) в устойчивом режиме на одну рабочую позицию оператора должно приходиться около одного сигнала в 10 минут, а более 10 сигналов за 10 минут считаются шквалом. На практике во время сбоя сигналы идут пачкой: часть из них — следствие одного события. Пока оператор разбирает список, линия уже стоит. Агент выделяет первичное событие и показывает сопутствующие как следствие — картина сбоя читается сразу.

Простой, который растягивается на полсмены

Компания Siemens опубликовала оценку потерь от незапланированных остановок: в среднем крупное предприятие теряет 27 часов в месяц из-за незапланированных простоев (в 2019 году — 39 часов), то есть около 326 часов в год; при этом среднее время восстановления производства выросло с 49 минут до 81 минуты за пять лет. Причина, по мнению авторов отчёта, не в оборудовании, а в знаниях: опыт уходит вместе с людьми. Агент не ремонтирует линию, но передаёт наладчику историю: что делали в прошлый раз, какой узел отказывал, кто и когда это закрыл.

Брак, который находят у заказчика, а не в цехе

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

Срыв сроков по заказу и санкции по договору

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

Спор о причинах остановки

Через месяц невозможно восстановить, почему линия стояла 12 числа, если запись сделана по памяти. Спор с заказчиком или между подразделениями превращается в поиск правды в переписке. Сводка простоев с причинами, длительностью и ссылками на эпизоды снимает эту категорию споров.

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

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

Отчётность, которая не сходится

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

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

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

Показатель	Вручную	С агентом
Разбор остановок и причин (40 остановок × 45 и 6 минут)	30 часов	4 часа
Сверка сменного задания с фактом выпуска (60 смен × 20 и 3 минуты)	20 часов	3 часа
Разбор отклонений качества по партиям (20 разборов × 40 и 5 минут)	13,3 часа	1,7 часа
Сводка простоев и потерь за месяц (4 сводки × 100 и 20 минут)	6,7 часа	1,3 часа
Итого в месяц на площадке	70 часов	10 часов

Расчёт в минутах: 40 остановок × 45 минут = 1 800 минут, то есть 30 часов; 60 смен × 20 минут = 1 200 минут, то есть 20 часов; 20 разборов × 40 минут = 800 минут, то есть 13,3 часа; 4 сводки × 100 минут = 400 минут, то есть 6,7 часа. С агентом остаётся проверка выводов: 40 × 6 минут, 60 × 3 минуты, 20 × 5 минут и 4 × 20 минут — около 10 часов.

Высвобождается примерно 60 часов в месяц на одной площадке. При оценке стоимости часа в 1 000 рублей это около 60 000 рублей в месяц; на трёх площадках одного предприятия — порядка 180 000 рублей. Часы — уже следствие снятых рисков: главный эффект в том, что причина остановки разбирается в первые минуты, а не в конце смены.

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

Расчёт эффекта на вашем объёме

Модель собирается из четырёх чисел, которые у вас уже есть:

1. Объём операций в месяц. Сколько раз в месяц разбираются остановки, сколько сменных заданий сверяется с фактом, сколько разборов качества и сводок по простоям нужно закрыть.
2. Минуты на операцию. Сколько времени занимает одна такая операция вручную и сколько занимает проверка вывода агента.
3. Число сотрудников, у которых это в работе. Мастера, технологи, диспетчеры — и какая доля их времени действительно уходит на разбор, а не на управление производством.
4. Стоимость часа. Полная стоимость часа с учётом взносов и накладных по данным вашей учётной системы.

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

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

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

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

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

Так же строится работа и с действующим контуром на TRACE MODE и T-FACTORY: сначала считаем на ваших выгрузках, сколько часов в месяц уходит на ручной разбор, затем проверяем сценарий на одной линии или цехе, и только потом тиражируем на остальные. Смежные разборы по производственному контуру: планирование производства и пересборка графика, производственный блок 1С:ERP, контроль качества, входной контроль и рекламации, простои, смены и брак, роль диспетчера и технолога, ИИ в машиностроении, системы того же класса на другом контуре, MES «ИндаСофт» на данных I-DS и порядок внедрения ИИ-агентов от аудита до сопровождения.

Чеклист перед стартом

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

• Теги в SCADA актуальны: параметры, по которым считается качество, читаются с оборудования, а не вводятся руками.
• Архив сигналов хранится достаточно долго, чтобы сравнивать эпизоды между собой (месяц и больше).
• Сменные задания в MES закрываются в день смены, а не «к концу недели».
• Отметки о наладках, переналадках и ремонтах фиксируются хотя бы в одном месте.
• Партии материалов и готовой продукции имеют связь с заданием и оборудованием.
• Есть человек, готовый отвечать за правила: какие отклонения считать значимыми и при каком повторе поднимать сигнал.
• Руководство согласно принимать решения по предложенному разбору, а не разбирать каждую смену заново на совещании.

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

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

1. Аудит данных. Смотрим, что реально есть в контуре: архив сигналов, задания, наряды, партии, отметки о наладках и ремонтах. Фиксируем, чего не хватает для сценария.
2. Замер ручной работы. Считаем по вашим числам, сколько часов в месяц уходит на разбор остановок, сверку заданий, качество и сводки. Здесь же считаем бесплатный разбор стратегии внедрения ИИ.
3. Один процесс, одна линия. Берём самый частый сценарий — обычно разбор остановки и причин — и делаем его на данных одной линии.
4. Правила и границы. Формулируем, что агент делает сам, где требуется подтверждение человека и при каком повторе поднимается сигнал.
5. Пилот на смене. Агент работает параллельно с привычным порядком: мастер видит и ручной разбор, и вывод агента. Сравниваем, где вывод точнее.
6. Тиражирование и метрики. Расширяем на сверку заданий и качество, переносим на другие линии и цеха, ведём ежемесячный отчёт по метрикам.

Чем измеряется эффект

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

Что в итоге

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

ИИ-агент поверх TRACE MODE и T-FACTORY закрывает именно этот участок и не трогает ни контур управления, ни технологию. Сначала риски — потерянная в шквале сигналов авария, простой на полсмены, брак у заказчика, срыв сроков, споры о причинах; затем часы и деньги как следствие. Проверить это на своей площадке можно за один разбор: посмотрим ваши выгрузки и покажем, какие решения агент подготовит в первые минуты сбоя, а какие останутся за диспетчером и мастером.

Источники

• Средние потери предприятия от незапланированных простоев — 27 часов в месяц (в 2019 году — 39 часов), около 326 часов в год; среднее время восстановления производства после остановки выросло с 49 до 81 минуты за пять лет, что авторы объясняют разрывом в знаниях после ухода опытных специалистов; совокупные потери 500 крупнейших компаний мира — 1,4 трлн долларов в год: The True Cost of Downtime 2024 — Siemens (данные по промышленным предприятиям, опрос специалистов по обслуживанию и ИТ).
• Пороги нагрузки на оператора по сигнализациям: в устойчивом режиме около одного сигнала в 10 минут, шквал — более 10 сигналов за 10 минут на одну рабочую позицию: EEMUA Publication 191 «Alarm Systems: A Guide to Design, Management and Procurement» — EEMUA (руководство для пользователей систем сигнализации, стандарт ISA-18.2 / IEC 62682); числовые пороги в прикладной форме — Alarm Flood Reduction: EEMUA 191 & ISA-18.2.
• В крупных и средних российских организациях технологии искусственного интеллекта применяют порядка 5,2% (на 0,4 п. п. больше, чем в 2024 году), в компаниях с численностью более 500 человек — 17%; примерно каждая вторая организация-пользователь ИИ применяет его в производстве продукции, а 56% внедряют готовое коммерческое программное обеспечение: Крупный бизнес наиболее активно внедряет ИИ — ИСИЭЗ НИУ ВШЭ по данным сплошных обследований Росстата, 2025–2026.
• Рынок систем автоматизации в России вырос практически наполовину и превысил в 2024 году 120 млрд рублей; отечественные решения занимают порядка 50–70% (ранее 30–40%); глобальные затраты на промышленное ПО с применением ИИ — 6,79 млрд долларов, что даёт оценку расходов российских предприятий примерно в 88 млн долларов (около 7 млрд рублей); в 2025 году рынок цифровых решений растёт в пределах 15–20% в год: Обзор «Цифровизация промышленности в России 2025» — TAdviser (данные вендоров и экспертов рынка).
• Состав контура: SCADA TRACE MODE — 64-разрядная российская система для автоматизации технологических процессов и диспетчеризации, работающая под Windows и Linux, более 134 000 инсталляций в России, применение в 50 отраслях, сертификаты совместимости с отечественными ОС и включение в реестр российского ПО: SCADA TRACE MODE — AdAstrA; функции MES-контура T-FACTORY — материальные и энергетические потоки, балансы и анализ потерь, производственные задания и наряды, сетевое планирование, контроль исполнения, контроль качества, себестоимость по этапам, выявление узких мест, трассировка партии по оборудованию и персоналу: MES-система T-FACTORY — AdAstrA (данные вендора).