Как оценить реальный эффект цифровизации? Как сохранить инженерный контекст при импортозамещении? Как превратить данные производственных обходов в инструмент для ТОиР и предиктивной аналитики? И что нужно для того, чтобы промышленная ИИ-модель стала частью производственной системы, а не осталась отдельным экспериментом?
Эти вопросы в разных формулировках звучали на сессии, посвящённой корпоративным информационным системам, цифровым платформам и управлению данными, на форуме SMART OIL & GAS.
Семь выступлений охватили широкий круг задач — от анализа бизнес-процессов и управления инженерными данными до рекомендательных систем, предиктивной диагностики и промышленного ИИ.
При этом за разными кейсами просматривалась общая проблема: цифровое решение само по себе ещё не делает производство цифровым. Его результат зависит от качества исходных данных, сохранности инженерного контекста, корректности измерений и того, насколько хорошо новая технология вписана в существующие производственные процессы.
Process mining позволяет восстановить процесс по цифровым следам, сопоставить его с целевой моделью и увидеть отклонения.
В одном из приведённых примеров заявка на платёж корректировалась 32 раза, а весь процесс мог занимать до двух месяцев. Анализ позволял искать причины таких отклонений. Среди характеристик заявок рассматривались срочность, наличие бизнес-единицы и инициатора, изменение суммы.
В другом случае мониторилось более 700 KPI примерно по 40–50 процессам. После анализа технического обслуживания и ремонта было принято решение расширить применение process mining примерно с 20 до 100 процессов.
Для специалистов по АСУ ТП здесь интересен сам подход. Анализ цифрового следа позволяет увидеть реальные действия пользователей и операции, которые могли не попасть в исходное техническое задание. Поэтому process mining может использоваться не только для оценки эффективности, но и для проверки того, как автоматизированный процесс действительно работает на практике.
При импортозамещении такой анализ может помочь восстановить фактическую логику работы старой системы перед переносом в новое решение.
В целевой системе PBS и технический документооборот объединили, а исторический архив на первом этапе сохранили отдельно. Структуру PBS оптимизировали с использованием CFIHOS, DBS приводили к российским стандартам. Для объектов и документов предусмотрена версионность.
Масштаб проекта — более 54 млн информационных объектов:
Для миграции потребовались отдельные инструменты загрузки и валидации данных, работы с версиями и прохождения бизнес-маршрутов. Для взаимодействия с подрядчиками использовались специальные «трансмиттлы».
При этом задача системы сформулирована достаточно просто: быстро найти актуальные инженерные данные и восстановить информацию о технологической установке в нештатной ситуации. Оценочное количество пользователей — 1,5–2 тыс. человек.
Этот пример хорошо показывает, почему импортозамещение инженерной системы нельзя сводить к переносу документов. Необходимо сохранить саму структуру инженерной информации — объекты, связи, версии и контекст.
Одной из проблем оказалось не столько написание кода, сколько согласование того, каким должен быть конечный результат. Для этого использовалась прослеживаемая цепочка:
ФТТ → проектное решение → задача → ТЗ → код → ревью → тест.
Каждый этап оставляет свой артефакт, а изменение требования должно находить отражение в связанных документах и тестах.
Для АСУ ТП такой принцип хорошо знаком: изменение функционального требования не должно теряться между постановкой задачи, архитектурой, реализацией и испытаниями. Чем сложнее система, тем важнее сохранить эту связь.
ИИ при таком подходе не отменяет инженерного контроля. Архитектурные решения принимает человек, код проходит ревью, а заказчик принимает результат и определяет приоритеты MVP.
Отдельно были обозначены ограничения на использование LLM. Проектные данные предприятий ТЭК не предполагается передавать в облачные модели; изменения проходят через Git и ревью, задачи имеют критерии приёмки, предусмотрены меры против инъекций и утечек контекста.
В одном из примеров ручной просмотр протоколов занимал 15–30 минут. Инструмент на основе транскрипции и ИИ формирует сводный контекст примерно за минуту: показывает задачи, ближайшие шаги и ответственных.
При этом технология не заменяет проектную дисциплину. Она помогает быстрее найти информацию, которая уже была создана в процессе работы.
Для промышленной автоматизации это ещё один источник контекста — наряду с инженерной документацией, журналами событий и производственными данными.
В результате формируется структурированный массив данных, который может использоваться в ТОиР, планировании ремонтов и предиктивной аналитике, а также передаваться в смежные системы.
По данным, приведённым в выступлении со ссылкой на заказчика, после внедрения время обходов сократилось в два раза. Максимальное время от выявления инцидента до взятия его в работу составляет 15 минут.
Интересен и опыт тиражирования: решение перенесли с нефтебаз на передвижные и стационарные лаборатории без доработок — за счёт использования конструкторов и шаблонов.
На вопрос об интеграции с лабораторной информационной системой и диспетчеризацией была обозначена техническая возможность через открытый API. При этом из материалов сессии не следует, что все такие интеграции уже реализованы.
В представленном кейсе рекомендательная система ориентирована на увеличение выработки и снижение удельного расхода газа на тонну продукции. В расчётах используются параметры реформинга, соотношение водорода и азота, параметры синтеза, температура конденсации, содержание инертов и другие характеристики процесса.
Предусмотрены режимы оптимизации удельного расхода газа, максимизации выпуска и гибридный режим. Для шести аммиачных цехов в устном выступлении называлось в среднем более 200 параметров. В презентации одновременно фигурирует показатель более 5000 параметров. По имеющимся материалам нельзя надёжно установить, что речь идёт об одном и том же показателе, поэтому эти цифры не следует объединять.
Рекомендация поступает оператору, который принимает решение о её использовании. В материалах заявлены более 1,5 млрд рублей накопленного экономического эффекта рекомендательных систем с 2023 года, более 1,5% среднего увеличения выработки, до 1% снижения удельного расхода газа и более 85% времени работы в оптимальном режиме.
В качестве критериев эффективности назывались удельный расход сырья на тонну продукции, сравнение показателя до и после внедрения и достижение максимально достижимого уровня производства.
Другой сценарий был связан с признаками лакообразования в масляной системе; потенциальный эффект оценивался в сотни миллионов рублей.
Здесь важен не сам факт обнаружения аномалии. Ценность появляется тогда, когда результат диагностики меняет дальнейшие действия: приводит к мероприятию, проверке ресурсов и корректировке плана ремонта.
Модели разрабатываются и тестируются в корпоративных ЦОД на исторических данных, проходят верификацию, а затем работают онлайн на производственных площадках. Такой подход используется для тиражирования решений.
Решение оказалось простым: точки измерения пронумеровали непосредственно на оборудовании. Для специалистов по АСУ ТП это, пожалуй, один из наиболее практичных выводов дискуссии. Качество модели начинается не с машинного обучения, а с того, как организованы измерения, идентифицирован объект и формируются первичные данные.
Если необходимый параметр на объекте вообще не измеряется, никакой алгоритм не сможет восполнить отсутствие исходных данных.
Представленная промышленная ИИ-платформа объединяет управление данными и моделями, API, базы данных, ML и LLM, мониторинг и аудит.
Для АСУ ТП принципиально, что речь идёт не просто о хранилище тегов. Производственные данные должны быть связаны с конкретным объектом и его контекстом.
Отдельный слой интеграции должен связывать события от ИИ с действиями в MES и ERP. Предусмотрена и «песочница» для проверки моделей на исторических данных и проигрывания сценариев «что, если».
Для промышленной среды с ростом связности систем становится важным не только обеспечить доступность данных, но и понимать, кто, к каким данным и в каком контексте получает доступ.
Для АСУ ТП здесь важны вполне конкретные вещи: качество первичных данных, сохранность инженерного контекста, связь с ТОиР и другими рабочими системами, контроль моделей и понятная роль человека в принятии решения.
Но есть ещё одна проверка — временем.
Что произойдёт с решением после завершения пилота? Кто будет отвечать за данные и новую версию модели? Как она будет работать на другом объекте? И останется ли результат частью производственного процесса, когда закончится проект внедрения?
Именно ответы на эти вопросы во многом определяют, станет ли очередная цифровая технология промышленным инструментом — или останется успешной демонстрацией.
_______________________________
Аналитический материал подготовлен на основе содержания докладов конференции с использованием инструментов искусственного интеллекта. Все выводы основаны исключительно на материалах представленных выступлений.
© СТА-ПРЕСС, 2026
Эти вопросы в разных формулировках звучали на сессии, посвящённой корпоративным информационным системам, цифровым платформам и управлению данными, на форуме SMART OIL & GAS.
Семь выступлений охватили широкий круг задач — от анализа бизнес-процессов и управления инженерными данными до рекомендательных систем, предиктивной диагностики и промышленного ИИ.
При этом за разными кейсами просматривалась общая проблема: цифровое решение само по себе ещё не делает производство цифровым. Его результат зависит от качества исходных данных, сохранности инженерного контекста, корректности измерений и того, насколько хорошо новая технология вписана в существующие производственные процессы.
Сначала разобраться, как процесс работает на самом деле
Одна из проблем цифровизации — понять, что на самом деле происходит с процессом после внедрения системы. Формального регламента для этого недостаточно: фактический процесс может заметно отличаться от того, как он был задуман.Process mining позволяет восстановить процесс по цифровым следам, сопоставить его с целевой моделью и увидеть отклонения.
В одном из приведённых примеров заявка на платёж корректировалась 32 раза, а весь процесс мог занимать до двух месяцев. Анализ позволял искать причины таких отклонений. Среди характеристик заявок рассматривались срочность, наличие бизнес-единицы и инициатора, изменение суммы.
В другом случае мониторилось более 700 KPI примерно по 40–50 процессам. После анализа технического обслуживания и ремонта было принято решение расширить применение process mining примерно с 20 до 100 процессов.
Для специалистов по АСУ ТП здесь интересен сам подход. Анализ цифрового следа позволяет увидеть реальные действия пользователей и операции, которые могли не попасть в исходное техническое задание. Поэтому process mining может использоваться не только для оценки эффективности, но и для проверки того, как автоматизированный процесс действительно работает на практике.
При импортозамещении такой анализ может помочь восстановить фактическую логику работы старой системы перед переносом в новое решение.
54 миллиона объектов — и дело не только в документах
Особенно хорошо эта проблема проявляется при замене систем управления инженерными данными. В одном из представленных проектов исходная информация была распределена между тремя импортными системами: PBS, DBS и электронным архивом.В целевой системе PBS и технический документооборот объединили, а исторический архив на первом этапе сохранили отдельно. Структуру PBS оптимизировали с использованием CFIHOS, DBS приводили к российским стандартам. Для объектов и документов предусмотрена версионность.
Масштаб проекта — более 54 млн информационных объектов:
- более 2,5 млн объектов PBS;
- более 22 млн связей PBS;
- более 10 млн документов DBS;
- более 19,5 млн связей между документами;
- данные по 16 производственным и инфраструктурным комплексам.
Для миграции потребовались отдельные инструменты загрузки и валидации данных, работы с версиями и прохождения бизнес-маршрутов. Для взаимодействия с подрядчиками использовались специальные «трансмиттлы».
При этом задача системы сформулирована достаточно просто: быстро найти актуальные инженерные данные и восстановить информацию о технологической установке в нештатной ситуации. Оценочное количество пользователей — 1,5–2 тыс. человек.
Этот пример хорошо показывает, почему импортозамещение инженерной системы нельзя сводить к переносу документов. Необходимо сохранить саму структуру инженерной информации — объекты, связи, версии и контекст.
Что происходит между требованием и работающей системой
В другом кейсе речь шла о внедрении ERP. Команда примерно из 150 человек работала над проектом около 20 месяцев. В контуре проекта — более 500 бизнес-процессов, 150 предприятий и 16 600 пользователей.Одной из проблем оказалось не столько написание кода, сколько согласование того, каким должен быть конечный результат. Для этого использовалась прослеживаемая цепочка:
ФТТ → проектное решение → задача → ТЗ → код → ревью → тест.
Каждый этап оставляет свой артефакт, а изменение требования должно находить отражение в связанных документах и тестах.
Для АСУ ТП такой принцип хорошо знаком: изменение функционального требования не должно теряться между постановкой задачи, архитектурой, реализацией и испытаниями. Чем сложнее система, тем важнее сохранить эту связь.
ИИ при таком подходе не отменяет инженерного контроля. Архитектурные решения принимает человек, код проходит ревью, а заказчик принимает результат и определяет приоритеты MVP.
Отдельно были обозначены ограничения на использование LLM. Проектные данные предприятий ТЭК не предполагается передавать в облачные модели; изменения проходят через Git и ревью, задачи имеют критерии приёмки, предусмотрены меры против инъекций и утечек контекста.
Когда нужное решение приходится искать среди писем и чатов
В промышленном проекте история решений часто оказывается разбросана по электронной почте, чатам, телефонным разговорам и протоколам встреч. Когда возникает инцидент, нужную информацию приходится собирать заново.В одном из примеров ручной просмотр протоколов занимал 15–30 минут. Инструмент на основе транскрипции и ИИ формирует сводный контекст примерно за минуту: показывает задачи, ближайшие шаги и ответственных.
При этом технология не заменяет проектную дисциплину. Она помогает быстрее найти информацию, которая уже была создана в процессе работы.
Для промышленной автоматизации это ещё один источник контекста — наряду с инженерной документацией, журналами событий и производственными данными.
Цифровой обход заканчивается там, где начинается ТОиР
Цифровой обход — это не просто бумажный журнал, перенесённый на планшет. В представленном решении используются чек-листы, фото- и видеофиксация, QR/NFC-метки, офлайн-режим, регистрация инцидентов и контроль времени прохождения.В результате формируется структурированный массив данных, который может использоваться в ТОиР, планировании ремонтов и предиктивной аналитике, а также передаваться в смежные системы.
По данным, приведённым в выступлении со ссылкой на заказчика, после внедрения время обходов сократилось в два раза. Максимальное время от выявления инцидента до взятия его в работу составляет 15 минут.
Интересен и опыт тиражирования: решение перенесли с нефтебаз на передвижные и стационарные лаборатории без доработок — за счёт использования конструкторов и шаблонов.
На вопрос об интеграции с лабораторной информационной системой и диспетчеризацией была обозначена техническая возможность через открытый API. При этом из материалов сессии не следует, что все такие интеграции уже реализованы.
От данных — к рекомендации оператору
Следующий шаг — использование производственных данных уже не только для наблюдения, но и для выбора режима работы.В представленном кейсе рекомендательная система ориентирована на увеличение выработки и снижение удельного расхода газа на тонну продукции. В расчётах используются параметры реформинга, соотношение водорода и азота, параметры синтеза, температура конденсации, содержание инертов и другие характеристики процесса.
Предусмотрены режимы оптимизации удельного расхода газа, максимизации выпуска и гибридный режим. Для шести аммиачных цехов в устном выступлении называлось в среднем более 200 параметров. В презентации одновременно фигурирует показатель более 5000 параметров. По имеющимся материалам нельзя надёжно установить, что речь идёт об одном и том же показателе, поэтому эти цифры не следует объединять.
Рекомендация поступает оператору, который принимает решение о её использовании. В материалах заявлены более 1,5 млрд рублей накопленного экономического эффекта рекомендательных систем с 2023 года, более 1,5% среднего увеличения выработки, до 1% снижения удельного расхода газа и более 85% времени работы в оптимальном режиме.
В качестве критериев эффективности назывались удельный расход сырья на тонну продукции, сравнение показателя до и после внедрения и достижение максимально достижимого уровня производства.
Аномалия обнаружена. Что дальше?
В другом кейсе система обнаружила отклонение температуры опорного подшипника компрессора от эталонной модели. После этого был сформирован план мероприятий, проверено наличие необходимых материалов, а ремонт совмещён с остановкой. Заявленный эффект — более 100 млн рублей. В конкретном примере температура достигала 118°C при пороге 125°C.Другой сценарий был связан с признаками лакообразования в масляной системе; потенциальный эффект оценивался в сотни миллионов рублей.
Здесь важен не сам факт обнаружения аномалии. Ценность появляется тогда, когда результат диагностики меняет дальнейшие действия: приводит к мероприятию, проверке ресурсов и корректировке плана ремонта.
Модели разрабатываются и тестируются в корпоративных ЦОД на исторических данных, проходят верификацию, а затем работают онлайн на производственных площадках. Такой подход используется для тиражирования решений.
Иногда лучший способ улучшить ИИ — изменить работу на объекте
Один из самых показательных примеров оказался связан вовсе не с алгоритмом. При разработке модели выяснилось, что обходчик выполнял измерения не в том порядке, который предполагался при формировании датасета. Это приводило к систематической ошибке.Решение оказалось простым: точки измерения пронумеровали непосредственно на оборудовании. Для специалистов по АСУ ТП это, пожалуй, один из наиболее практичных выводов дискуссии. Качество модели начинается не с машинного обучения, а с того, как организованы измерения, идентифицирован объект и формируются первичные данные.
Если необходимый параметр на объекте вообще не измеряется, никакой алгоритм не сможет восполнить отсутствие исходных данных.
Когда моделей становится много, нужна уже платформа
По мере роста числа моделей возникает другая задача — не разработать ещё один алгоритм, а управлять всем их жизненным циклом: данными, версиями, мониторингом, переобучением, безопасностью и интеграцией.Представленная промышленная ИИ-платформа объединяет управление данными и моделями, API, базы данных, ML и LLM, мониторинг и аудит.
Единая модель предприятия
В платформе предусмотрена универсальная объектная модель предприятия — единый источник данных для приложений. Она включает объектное, процессное, организационное, временное и продуктовое представления и связывает оборудование, сотрудников, материалы и производственные процессы.Для АСУ ТП принципиально, что речь идёт не просто о хранилище тегов. Производственные данные должны быть связаны с конкретным объектом и его контекстом.
MLOps и Edge
Заявлены MLOps, управление жизненным циклом моделей, включая Edge, трансферное и федеративное обучение, контроль снижения точности моделей, а также централизованное развёртывание и мониторинг контейнеризированных приложений на периферии.Отдельный слой интеграции должен связывать события от ИИ с действиями в MES и ERP. Предусмотрена и «песочница» для проверки моделей на исторических данных и проигрывания сценариев «что, если».
Безопасность
Архитектура предусматривает RBAC и ABAC, двухуровневый контроль доступа, концепцию Zero Trust, изоляцию приложений и принцип «всё, что не разрешено, запрещено».Для промышленной среды с ростом связности систем становится важным не только обеспечить доступность данных, но и понимать, кто, к каким данным и в каком контексте получает доступ.
Главный вопрос — что останется после пилота?
Семь кейсов показали разные стороны одной проблемы: путь от цифрового решения до производственного результата оказывается значительно сложнее, чем выбор технологии.Для АСУ ТП здесь важны вполне конкретные вещи: качество первичных данных, сохранность инженерного контекста, связь с ТОиР и другими рабочими системами, контроль моделей и понятная роль человека в принятии решения.
Но есть ещё одна проверка — временем.
Что произойдёт с решением после завершения пилота? Кто будет отвечать за данные и новую версию модели? Как она будет работать на другом объекте? И останется ли результат частью производственного процесса, когда закончится проект внедрения?
Именно ответы на эти вопросы во многом определяют, станет ли очередная цифровая технология промышленным инструментом — или останется успешной демонстрацией.
_______________________________
Аналитический материал подготовлен на основе содержания докладов конференции с использованием инструментов искусственного интеллекта. Все выводы основаны исключительно на материалах представленных выступлений.
© СТА-ПРЕСС, 2026
Если вам понравился материал, кликните значок — вы поможете нам узнать, каким статьям и новостям следует отдавать предпочтение. Если вы хотите обсудить материал —не стесняйтесь оставлять свои комментарии : возможно, они будут полезны другим нашим читателям!
