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

Производственная компания работала в MasterSCADA 4D несколько лет: линии выведены на мнемосхемы, параметры пишутся в архив, тревоги падают в журнал, оператор видит процесс в реальном времени. Но за пределами смены начинался ручной участок. Мастер смены открывал тренды, листал журнал тревог, звонил лаборанту, сверял выработку с заданием в 1С:ERP и к утру собирал одну страницу выводов — по памяти и по тому, что успел посмотреть. Система отвечала на вопрос «что было», а вопрос «почему смена недодала и что с этим делать» оставался за человеком.

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

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

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

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

Коротко

MasterSCADA 4D уже собирает всё нужное для разбора смены: историю параметров, тренды, журналы тревог и сообщений, данные по партиям. ИИ-агент не заменяет систему и не управляет процессом — он читает архив и журналы, сопоставляет отклонения по времени с партиями, выработкой и данными лаборатории и возвращает мастеру протокол смены с версиями причин, суммой потерь и списком проверок. Бесплатный разбор стратегии внедрения ИИ в компанию — по кнопке в начале статьи.

Содержание

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

Что такое MasterSCADA и какие процессы в ней живут

MasterSCADA — российская система диспетчерского управления и сбора данных (SCADA, Supervisory Control and Data Acquisition — диспетчерское управление и сбор данных), которую разрабатывает компания «ИнСАТ». Актуальная версия — MasterSCADA 4D: она зарегистрирована в реестре российского программного обеспечения под номером 13907, предыдущее поколение MasterSCADA 3.X — под номером 538. По данным вендора, на базе версии 3.X реализовано более 10 000 внедрений, включая системы с более чем 100 000 параметров на один сервер опроса и более чем 300 рабочими местами операторов.

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

Что система видит и чем управляет

• Мнемосхемы и рабочие места оператора. MasterSCADA 4D построена по клиент-серверной схеме: на рабочем месте запускается тонкий клиент, интерфейс реализован на HTML5, поэтому мнемосхему можно открыть с обычного компьютера, планшета или телефона — там, где есть браузер.
• Связь с оборудованием. Поддерживаются протоколы OPC (Open Platform Communications — открытый стандарт обмена данными между системами автоматизации) DA, HDA и UA, а также MODBUS RTU/TCP; есть открытое программное интерфейсное взаимодействие для подключения собственных программ.
• Логика управления. Поддерживаются языки стандарта МЭК 61131-3 (ST, LD, FBD, SFC), скрипты на C# и на JavaScript в графическом клиенте. Программы компилируются, а не интерпретируются, — это влияет на предсказуемость времени реакции.
• Архивы. Два типа хранения: архивы изменения технологических параметров и журналы — тревог, сообщений и событий информационной безопасности. Для небольших проектов есть встроенная база данных на SQLite, для средних и крупных — архивирование во внешние PostgreSQL и MS SQL; для больших объёмов есть интеграция с системой хранения временных рядов «АВАДС Сервер архивирования».
• Объектная модель. Проект делится на объекты, и типовой объект — насос, ёмкость, линия — описывается один раз, а потом тиражируется. Именно это качество и делает MasterSCADA похожей на платформу, а не на набор экранов: одинаковые участки описываются одинаково, и данные по ним сопоставимы.

Какие процессы реально живут в контуре

На производстве MasterSCADA обычно закрывает четыре слоя, и все они дают данные для разбора смены:

Слой	Что в нём происходит	Что остаётся в системе
Технологический	Регулирование, блокировки, аварийные защиты	Уставки, текущие значения, команды оператора
Диспетчерский	Смена, простои, пуски и остановки	Время события, автор события, причина из справочника
Учётный	Выработка, расход сырья и энергоресурсов	Почасовые и сменные итоги, тренды
Информационный	Тревоги, сообщения, действия персонала	Журналы с отметкой времени и уровнем важности

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

Где кончаются возможности системы

Это самый важный раздел для понимания, зачем вообще нужен агент. MasterSCADA — сильная система сбора и управления, но у неё другая задача. Она отвечает на вопросы «что происходит сейчас» и «что было», а не «почему это произошло и что делать».

Границы видны в четырёх местах.

1. Тренд показывает изменение, но не объясняет его. Архив параметров честно хранит, что температура росла сорок минут. Почему росла — не хранится: то ли теплообменник загрязнился, то ли оператор поздно открыл клапан, то ли сырьё пришло с другой влажностью.
2. Журнал тревог фиксирует событие, но не причину. Запись «остановка линии, 14:37» — это факт, а не разбор. Причину мастер восстанавливает по памяти и по расспросам, и восстановление зависит от того, кто был на смене.
3. Качество партии живёт вне контура. Результат лаборатории приходит в другую систему или на бумаге. Связь «партия — параметры процесса в момент её выпуска» не строится автоматически, поэтому брак обнаруживается на складе или у заказчика, а не в момент, когда его ещё можно было предотвратить.
4. Отчётность собирается вручную. Сменный отчёт, сводка простоев за неделю, анализ потерь — это работа человека с выгрузками. Она делается не потому, что полезна, а потому, что её требуют, и делается в конце смены, когда сил меньше всего.

Система не «плохая» — она ровно такая, какой должна быть система реального времени: быстрая, надёжная, с гарантированным временем реакции. Аналитика поверх архива — отдельная задача, и решать её силами SCADA значит либо перегружать контур, либо строить отчёты вручную. Об этом же говорит и рынок: по данным обзора TAdviser «Цифровизация промышленности в России 2025», рынок систем автоматизации в 2024 году вырос почти наполовину и превысил 120 млрд рублей, а отечественные решения заняли 50–70% против 30–40% ранее. Контуры собраны — теперь вопрос в том, что с их данными делать дальше.

Почему отклонение видно поздно

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

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

Второй барьер — шквал тревог. Это не метафора, а измеряемое явление. В отраслевом руководстве EEMUA Publication 191 по проектированию систем сигнализации устойчивым режимом считается примерно один сигнал в десять минут на оператора, а шквалом — более десяти сигналов за десять минут на одну рабочую позицию. В шквале оператор перестаёт различать важное и реагирует на то, что громче; часть сигналов гасится без разбора. Пороговые значения EEMUA 191 и стандарта ISA-18.2 разобраны прикладным образом — и они объясняют, почему «оператор видел тревогу» не равно «оператор понял, что произошло».

Третий барьер — разрыв контуров. Параметр процесса живёт в SCADA, партия — в ERP, результат анализа — в лаборатории. Чтобы связать их, нужен человек, который откроет три окна и сведёт данные вручную. Это делается раз в смену, а не в момент отклонения.

Четвёртый барьер — стоимость самого простоя. По исследованию Siemens «The True Cost of Downtime 2024» среднее промышленное предприятие теряет 27 часов в месяц из-за незапланированных простоев (в 2019 году было 39), это около 326 часов в год; среднее время восстановления производства после остановки выросло с 49 до 81 минуты за пять лет, а авторы связывают это в том числе с уходом опытных специалистов. У 500 крупнейших компаний мира совокупные потери оценены в 1,4 трлн долларов — около 11% выручки.

И ещё один фактор, объясняющий, почему такие проекты вообще становятся возможны именно сейчас: по данным ИСИЭЗ НИУ ВШЭ по сплошным обследованиям Росстата, технологии искусственного интеллекта применяют около 5,2% крупных и средних организаций (на 0,4 процентного пункта больше, чем годом ранее), в компаниях с численностью более 500 человек — 17%, и примерно каждая вторая организация-пользователь ИИ применяет его именно в производстве продукции. То есть база для пилота есть, а массовой практики ещё нет — и это аргумент начинать с узкого участка, а не с «цифрового завода» целиком.

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

Разберём смену по шагам. Пока без цифр — просто чтобы было видно, где именно теряется время.

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

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

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

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

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

Чего агент не делает

Границы важнее возможностей, поэтому перечислим их прямо.

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

Как это выглядит для родственных контуров, полезно сравнить: разбор системы TRACE MODE и MES-контура T-FACTORY — там та же логика, но на другой платформе; ИндаСофт MES — когда учёт исполнения уже есть, а разбора всё равно нет; Галактика ERP — вариант, когда планирование и учёт живут в ERP, а цех остаётся без оперативных данных.

Какие данные нужны на старте

Пилот не начинается с обещаний — он начинается с инвентаризации. Вот что стоит проверить до первого разбора.

• Список параметров для разбора. Не «все теги», а 20–40 параметров на участок, по которым действительно видно отклонение.
• Шаг записи и глубина архива. Для температуры часто достаточно записи по изменению, для вибрации и расхода нужен более частый шаг. Глубина должна покрывать хотя бы месяц — иначе не с чем сравнивать.
• Журнал тревог в выгрузке. Нужны уровни важности, время события и текст. Если причины в справочнике пишутся формально, это не блокер, но качество разбора будет ниже, пока справочник не уточнят.
• Связь партии с временем. Должно быть понятно, какая партия шла в интервале. Если связь только по дате смены, точность падает до смены — иногда этого достаточно, иногда нет.
• Данные лаборатории. Хотя бы по показателям, которые чаще всего дают рекламации.
• Стоимость часа. Одна цифра, без которой разбор потерь превращается в пересказ. Её даёт планово-экономический отдел, и она нужна до пилота, а не после.

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

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

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

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

Брак уходит заказчику

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

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

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

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

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

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

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

Потеря управляемости и прозрачности

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

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

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

Ниже — типовая модель для участка с двумя сменами, 30 днями в месяце и 60 сменами за месяц. Цифры входа — параметры конкретного участка; их надо подставить свои, а не принимать за результат.

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

Освобождается около 35,6 часа в месяц. При стоимости часа работы мастера и технолога 950 рублей это примерно 33 800 рублей в месяц на одном участке; на трёх участках — около 101 400 рублей в месяц.

Второй слой — простой. Если из 27 часов незапланированных простоев в месяц снять хотя бы пятую часть (это скромная оценка, а не обещание), освобождается около 5,4 часа работы линии. При добавленной стоимости часа работы линии 7 500 рублей это ещё около 40 500 рублей в месяц. Итого на одном участке эффект в модели — примерно 74 000 рублей в месяц, на трёх — порядка 220 000 рублей.

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

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

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

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

В нашей практике был проект с производственной компанией, где собирали индивидуальную программу под задачи предприятия: разбирали, какие данные уже есть в контуре, что реально можно автоматизировать и какой участок брать первым. Отдельной задачей шла работа с мастером смены — потому что разбор, который никому не нужен в 7 утра, не приживается независимо от качества модели.

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

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

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

1. Выбрать участок. Один участок, одна линия, две смены. Не завод целиком: пилот должен закончиться результатом, а не презентацией.
2. Инвентаризировать данные. Параметры, шаг записи, глубина архива, журналы, связь партии со временем, лаборатория, стоимость часа. Здесь же выясняется, чего не хватает.
3. Зафиксировать метрику. Время от остановки до названной причины. Сейчас она измеряется вручную по журналу, и это нормально — главное, чтобы точка отсчёта была.
4. Собрать первый протокол вручную. Две недели агент работает в режиме подсказки, мастер сверяет. Это этап калибровки, и его нельзя пропускать.
5. Включить протокол в ритуал смены. Разбор приходит до планёрки и обсуждается на ней. Если протокол живёт отдельно от планёрки, он умирает за месяц.
6. Расширять по участкам. После того как на первом участке причина называется быстрее, тот же контур переносится на соседние — объектная модель MasterSCADA здесь помогает: одинаковые объекты описаны одинаково.

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

Ниже — восемь вопросов, на которые стоит ответить до старта. Если ответ «нет» на первые три, начинать рано.

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

Что в итоге

MasterSCADA 4D делает свою работу: собирает данные, ведёт архив, показывает процесс и держит защиты. Но между архивом и решением о смене остаётся ручной участок, и именно там теряются и часы, и причины, и деньги. ИИ-агент закрывает этот участок: читает выгрузки, связывает параметры с партиями и качеством, возвращает протокол смены с версиями причин и суммой потерь. Риски снимаются первыми — растянутый простой, брак у заказчика, неустойка, спор без доказательств, зависимость от одного человека. Часы и рубли приходят следом, и в модели это около 35 часов и 74 000 рублей в месяц на участке.

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

Источники

• Среднее промышленное предприятие теряет 27 часов в месяц из-за незапланированных простоев (в 2019 году — 39 часов), около 326 часов в год; среднее время восстановления выросло с 49 до 81 минуты за пять лет; совокупные потери 500 крупнейших компаний — 1,4 трлн долларов, около 11% выручки: The True Cost of Downtime 2024 — Siemens (опрос специалистов по обслуживанию и ИТ на промышленных предприятиях).
• Пороги нагрузки на оператора по сигнализациям: в устойчивом режиме около одного сигнала в 10 минут, шквал — более 10 сигналов за 10 минут на одну рабочую позицию: EEMUA Publication 191 «Alarm Systems» — EEMUA (руководство для пользователей систем сигнализации, согласовано со стандартом ISA-18.2 / IEC 62682); прикладное изложение порогов — Alarm Flood Reduction: EEMUA 191 & ISA-18.2.
• Технологии искусственного интеллекта применяют около 5,2% крупных и средних российских организаций (+0,4 п.п. к 2024 году), в компаниях с численностью более 500 человек — 17%, примерно каждая вторая организация-пользователь ИИ применяет его в производстве продукции: Крупный бизнес наиболее активно внедряет ИИ — ИСИЭЗ НИУ ВШЭ по данным сплошных обследований Росстата, 2025–2026.
• Рынок систем автоматизации в России в 2024 году вырос почти наполовину и превысил 120 млрд рублей; отечественные решения занимают 50–70% против 30–40% ранее; рынок цифровых решений растёт на 15–20% в год: Обзор «Цифровизация промышленности в России 2025» — TAdviser (данные вендоров и экспертов рынка).
• Объём российского рынка систем управления исполнением производства (MES, Manufacturing Execution System — управление исполнением производства): 18 млрд рублей по итогам 2025 года, 65 систем в реестре отечественного программного обеспечения, машиностроение — 16% внедрений: Исследование IBS по рынку MES — IBS, ноябрь 2025.
• Возможности контура: объектный подход к разработке, клиент-серверная архитектура с тонким клиентом на HTML5, исполнительные модули для Windows, Linux, Android и QNX, протоколы OPC DA/HDA/UA и MODBUS RTU/TCP, языки стандарта МЭК 61131-3 (ST, LD, FBD, SFC), скрипты на C# и JavaScript, открытое программное интерфейсное взаимодействие; архивы двух типов — параметры и журналы (тревог, сообщений, информационной безопасности), встроенная база данных на SQLite, архивирование в PostgreSQL и MS SQL, интеграция с системой хранения временных рядов «АВАДС Сервер архивирования»; регистрация в реестре российского ПО: MasterSCADA 4D — № 13907, MasterSCADA 3.X — № 538, более 10 000 внедрений на базе версии 3.X, проекты с более чем 100 000 параметров на сервер опроса и более чем 300 рабочими местами операторов: MasterSCADA 4D — «ИнСАТ» (данные вендора).

Ещё по теме: ИИ-агент в Global ERP.