Представьте завод размером с маленький город.
Сотни тысяч единиц оборудования — от гигантских колонн высотой с пятиэтажку до мельчайших датчиков. Миллионы технических документов: чертежи, схемы, паспорта, спецификации. Несколько подрядчиков выпускает рабочую документацию, сотни поставщиков поставляет оборудование и сопроводительную документацию.
А теперь представьте, что всей этой информацией нужно управлять так, чтобы любой инженер за пару кликов мог найти нужный документ или параметр оборудования.
Чтобы быстро подобрать кран для перевозки, оперативно закупить деталь для ремонта или использовать данные для разработки ИИ-алгоритмов контроля оборудования.
До 2019 года в Сибуре не было управления инженерными данными: разная нумерация оборудования и тегов у разных подрядчиков и поставщиков, разные форматы документации, ручной сбор информации на каждой стадии реализации проекта. Пока объём данных был меньше, это работало. Но с ростом числа объектов стало понятно, что без единой системы дальше двигаться сложно.
Привет! Меня зовут Вероника Панайотова, я руководитель практики по управлению инженерными данными в Цифровом СИБУРе. Я расскажу, как мы прошли путь от хаоса разрозненных данных и документов до полноценной системы управления инженерными данными (СУИД) — первой отечественной разработки уровня, сопоставимого с мировыми гигантами в этой области, как AVEVA и Hexagon.
Дисклеймер: Статья написана на основе интервью с Вероникой Панайотовой. Мы сознательно упростили описание технических моментов, чтобы статья была понятна широкой аудитории.
Это история не только про технологии, но и про людей: про сопротивление подрядчиков, про небольшую команду, которая заменила дорогое западное решение, и про то, как мы научились собирать миллионы технических характеристик.
Как обычно строят нефтехимическое производство?
Завод появляется в проектах задолго до стройки. Над ним одновременно работают сотни команд: инженеры-проектировщики, строители, производители, закупщики и поставщики оборудования. Например, у нас на объекте АГХК на установке пиролиза только более 200 поставщиков оборудования.
С начала проектирования все участники формируют и используют для своих нужд собирают технические данные о самом заводе и обо всём оборудовании, которое в нём будет установлено. Централизованного места, где бы накапливалась вся информация — нет. Каждая команда работает и хранит эти данные в своих папках и программах.
Когда это необходимо — документы, перечни с данными передают друг другу по почте. В конце строительства остается несколько миллионов документов. Какую-то часть подрядчики отдадут, а какую-то забудут или не посчитают нужным прислать, когда нет четко описанных правил формирования документации.
А теперь покажу на насосе, что может произойти.
Представим, что проектировщики обозначили насос как 21-P-0101. Под него они выпустили чертежи и спецификации: определили тип насоса, производительность, материалы, модель, точки подключения и место в технологической схеме.
Дальше проект уходит в закупку и стройку. Поставщик не находит нужную модель или она оказывается слишком дорогой. Служба снабжения согласовывает замену на аналог. Формально насос остаётся тем же для той же точки процесса. Фактически же это уже другая модель, иногда другого производителя. И в документах службы снабжения он появляется под другим обозначением, например «НС-01А».
Дальше монтажник устанавливает этот насос и фиксирует это в актах и журналах — под третьим названием. Информации из проекта и закупки у него нет в связном виде: он получает оборудование как отдельную поставку и оформляет монтаж по тем документам, которые сопровождают изделие здесь и сейчас.
В результате один и тот же физический насос существует под разными именами:
в проекте — под проектным обозначением,
в закупке — под артикулом поставщика,
в паспорте — под заводским названием.
При этом предыдущие участники могут не знать о замене и ином названии.
И вот через 5 лет насос выходит из строя. Производство останавливается. Инженеру срочно нужно закупить запчасть.
Он открывает проект — там одна модель оборудования. Открывает паспорт — там другая. Смотрит закупку — третье название. И он не может быть уверен, что это всё про один и тот же насос, пока не проверит вручную. А каждый час простоя — миллионы рублей убытков.
Мы проходили через это сами. На ЗапСибНефтехиме базу оборудования собирала команда из 120 человек. Автоматизация была, но её возможностей не хватало для такого масштаба, поэтому значительную часть работы выполняли вручную.
Тысячи Excel и PDF, переводы паспортов, пересчёт единиц, переписка с поставщиками — всё это заняло больше двух лет.
В 2019 году мы начали строительство Амурского газохимического комплекса (АГХК) — одного из крупнейших в мире заводов по производству полиэтилена и полипропилена.
И тогда мы решили изменить подход — внедрить систему, которая собирает инженерные данные уже на этапе проектирования и сохраняет их без потерь на всём жизненном цикле завода. Начали с главного — с людей.
Первая сложность — собрать команду профессионалов. Область управления инженерными данными уникальная, крайне мало компаний занимаются этим в России.
Нужны были люди, которые одновременно понимают и инженерию, и ИТ. Инженеры, как правило, знают, как работает оборудование на заводе, но не занимаются структурой данных и архитектурой систем.
А айтишники, наоборот, отлично понимают архитектуру, базы данных и связи, но без инженерного контекста не могут правильно сформулировать, какие именно данные нужны и как они связаны между собой.
Поэтому команду собирали постепенно — искали везде: на Хабре, hh.ru, через знакомых. Нужен был человек, который одновременно понимает нефтехимическое производство и умеет работать с классификаторами, справочниками, моделями данных, а также знает программирование (например, T-SQL). Таких специалистов на рынке почти нет — их приходилось искать точечно или выращивать внутри. Начинали с двух человек, включая меня.
В итоге собрали команду из 18 человек. Мы не только разрабатываем и поддерживаем систему — мы координируем весь бизнес-процесс управления инженерными данными. Заключаем контракты с подрядчиками, объясняем требования, проводим обучение и даём обратную связь по качеству переданных данных.
Что такое СУИД и зачем она нужна
По сути, СУИД — это единая база данных, где собрана и поддерживается в актуальном виде вся техническая информация о заводе:
Технологическое оборудование — насосы, колонны, емкости, компрессоры. Всё, что участвует в технологическом процессе. С характеристиками каждой единицы.
Оборудование КИПиА -датчики давления, температуры, расходомеры и прочее, также собираются потегово вместе с техническими параметрами.
Инженерные системы и линии — трубопроводы, кабельные трассы, системы вентиляции, водоснабжения, электроснабжения. Всё, что соединяет оборудование между собой и содействует функционированию завода.
Строительные конструкции — здания, корпуса, эстакады, площадки, фундаменты. Не в строительных деталях вроде марки бетона, а как контекст: где какое оборудование стоит, где проходят линии.
К каждому объекту в системе привязаны документы — опросные листы, схемы, паспорта и руководства, а также 3D-модель. И тут же видно всю цепочку связей: к какой линии подключён насос, по какой эстакаде она проходит и в каком здании всё это находится.
СУИД — система управления инженерными данными. Например, кликаешь на насос в 3D-модели — видишь его паспорт, технические характеристики, к каким трубам подключён. Вбиваешь номер оборудования в поиск — получаешь всю документацию за пару секунд.
От идеи до запуска и дальнейшей работы завода этой системой пользуются все: проектировщики, закупщики, строители, сотрудники ПНР, инженеры ТОиР и эксплуатации. При этом, все опираются на одну и ту же актуальную информацию — и находят её за считаные минуты.
Первый опыт: купили западное решение
В 2020 году мы решили не изобретать велосипед и купили готовую систему — Aveva net от компании AVEVA, состоящую из нескольких модулей. Это мировой стандарт в управлении инженерными данными.
Прежде чем запустить систему, мы год выстраивали процессы с нуля:
Один объект — один тег
Я уже говорила, у каждого подрядчика существует обычно своя система нумерации документов и тегов. Поэтому мы ввели единые правила тегирования. Тег — это уникальный идентификатор, который появляется ещё на этапе проектирования и остаётся с объектом на всём его жизненном цикле, пока его не демонтируют или уничтожат. Насосы, датчики, задвижки, участки трубопроводов — у каждого есть свой тег по общему стандарту.
Причём тегируется не только физическое оборудование. Есть так называемые софт-теги — идентификаторы сигналов между устройствами. Например, датчик передаёт данные на контроллер — у этого сигнала тоже есть свой тег. Это не физические объекты, но они важны для понимания, как работает завод. Система учитывает всё — и оборудование, и связи между ним.
Обслуживают отдельно — значит и учитываем отдельно
Следующий вопрос — какие характеристики собирать для каждого класса оборудования?
Вроде все просто. Сначала фиксируем базовый тип — например, насос, потом уточняем вид, скажем, центробежный, и к нему уже подтягиваются свои параметры: мощность, давление, тип двигателя.
Но мы поняли, что для будущей эксплуатации важно отдельно учитывать привод/двигатель насоса или компрессора. Потому что насос обслуживают механики, а двигатель — электрики. Это разные службы, разные графики обслуживания. Значит, у мотора должен быть свой тег. Подобным образом, логику мы продумали для каждого класса оборудования.
Показываем, что внутри оборудования комплектной поставки
Обычно комплектное оборудование от вендора — например, компрессорная установка — в проекте выглядит как черный ящик. Внешний контур есть, а внутренней структуры: оборудования, обвязки, узлов, датчиков — нет.
Мы настояли, чтобы вендоры отдавали детальные 3D-модели своего оборудования. Споров было много — говорили, что это не их ответственность. Но мы объяснили, зачем это нужно дальше: для расчётов, обучения операторов и нормального понимания устройства. В итоге убедили. Теперь в модели отображается внутренняя структура комплектных поставок.
Что было не так?
Спустя год мы внедрили решение от AVEVA на проекте АГХК. Однако инженерные данные мы начали централизованно собирать еще в 2019 году, обучать подрядчиков, потом и поставщиков, и проверять качество передаваемой информации.
СУИД обеспечила единое хранилище данных, с помощью которого команда Управление инженерными данными (УИД) могла связывать документы с оборудованием и выдавать обратную связь подрядчикам там, где данных не хватало или они были некорректно классифицированы, пронумерованы или сформированы.
Но проблемы тоже были. Во-первых, отсутствие быстрой валидации данных. Требовалось долго ожидать результат на таком большом объеме данных.
Во-вторых, часть функций мы потеряли после 2022 года, когда лицензирование прекратилось, например полноценный просмотр 3D-моделей.
В-третьих, каждый новый проект (завод или производственная линия) — новая лицензия. Стоимость — от 40 до 100 миллионов рублей на проект. Плюс ежегодная техподдержка — 25% от стоимости лицензии.
А в 2022 году AVEVA из-за санкций прекратила поддержку, мы потеряли доступ к лицензированию.
Собственная разработка
К этому моменту у нас уже был действующий проект АГХК с накопленными инженерными данными. Параллельно запускались новые проекты — ДГП-2 в Тобольске и Стирольная цепочка в Нижнекамске.
Что делать?
На тот момент, в 2022 году, в России аналогов AVEVA не существовало, были решения слабо напоминающие СУИД. На территории СНГ тоже. Мы могли ждать, когда кто-то разработает, либо разработать самостоятельно.
Выбрали второй вариант. Мы решили не копировать, а сразу создать со всеми функциями, которые нам не хватало в AVEVA.
Команда разработки
Отдельный вызов — найти разработчиков для создания собственной платформы. Нужны были программисты, а не инженеры. Специалисты, которых мы нашли на рынке, не разбирались в предметной области и нуждались в постоянном сопровождении.
Нас выручил коллега с уникальным бэкграундом: разработчик, который до этого работал в AVEVA и понимал, что такое управление инженерными данными изнутри. Именно он взял на себя задачу детально писать технические задания для каждого разработчика — по каждому шагу. Это обеспечило контроль качества и позволило команде работать автономно, не теряя смысла задачи.
Этап 1. Анализ и проектирование (2022 — июнь 2023)
Поэтому первый этап был логичным — анализ и проектирование. Мы провели ревизию того, что работало в AVEVA и чего не хватало, и начали проектировать систему с нуля, сразу устраняя эти ограничения. Основные составляющие управления информацией — это люди, процессы и ИТ-решения. Одно без другого не имеет смысла.
Подрядчики
Когда предлагаешь что-то новое, всегда встречаешь сопротивление.
Сами представьте: есть крупная строительная компания, которая годами работает по своим стандартам. Тут мы приходим и говорим:
«Мы хотим сделать строительство прозрачным. Теперь вы будете передавать все данные по нашим правилам, регулярно, детально, а ещё и с проверками. Больше никаких чёрных ящиков.»
Естественно, никто не хочет меняться. Подрядчики говорили:
«Вы ничего не понимаете, мы лучше знаем. Строили раньше как-то без ваших систем, и тут построим.»
Мы настояли. Потому что без этого система теряет смысл. И в итоге прописали в контрактах, в каком формате подрядчики сдают информацию, как часто, что именно должно быть заполнено.
Архитектура системы
Система состоит из трёх основных модулей: ядра хранения данных на базе MDM-платформы, ETL-модуля для загрузки данных от подрядчиков и модуля 3D-визуализации. Плюс собственный модуль обработки PDF-документации.
Ядро для хранения данных
Первое, что нам нужно было — определиться, где хранить огромный объем информации.
Мы могли писать всё с нуля, но это долго и дорого. Решили взять готовую российскую MDM-платформу (Master Data Management) и доработать её под наши нужды совместно с подрядчиком, который также был заинтересован в развитии своего продукта.
Важной для нас особенностью данной MDM-системы, стало то, что она представляет собой целостную платформу для ведения модели данных, а также загрузки и управления самих данных. Другими словами, любые изменения в модели данных после их утверждения архитектором данных, сразу влияют на правила валидации загружаемых инженерных данных – нет необходимости тратить время на ручную синхронизацию различных модулей платформы, как это было в решении от AVEVA.
Физически же метаданные и данные разделены в части хранения: метаданные (классы и свойства оборудования) хранятся в графовой СУБД Apache Jena Fuseki, а данные – в СУБД PostgreSQL.
Покажем, как это работает на практике. На АГХК мы строим установку пиролиза, производство полиэтилена и производством полипропилена. По ходу реализации проекта состав оборудования или требования к данным могут измениться — крупная стройка –это живой организм. Раньше каждое такое изменение требовало ручной синхронизации между модулями: отдельно обновлялась модель данных, отдельно настраивались правила валидации. Сейчас архитектор данных вносит правку в модель — и правила валидации по всей платформе обновляются автоматически.
Доступ к системе настроили через единую систему управления доступом Цифровой платформы СИБУР на базе Keycloak. Каждый новый сотрудник получает учётную запись быстро, и у него есть только те права, которые нужны для его работы.
ETL-модуль
Чтобы загружать данные от подрядчиков без ручной обработки, мы разработали ETL-модуль на базе .NET.
Основа системы — единый стандарт передачи данных: какие поля заполнены, в каком порядке, в каких единицах измерения. Стандарт прописали в контрактах. Подрядчик выгружает данные из своей проектной системы в Excel или CSV строго по нашему шаблону.
Дальше ETL-модуль принимает эти файлы, разбирает их и загружает данные в MDM-систему.
В процессе загрузки модуль валидации данных MDM-системы проверяет их на соответствие стандарту и корректность заполнения значений характеристик оборудования. Если есть ошибки — данные не загружаются. Подрядчику уходит отчёт с указанием, что исправить. Он правит и присылает заново.
Модуль 3D-визуализации
Для 3D использовали российский движок «C3D Web Vision» от компании C3D Labs.
Модуль обработки PDF-документации
Собственная разработка на базе .NET и Python для поиска теговых номеров в тех. документации и добавления гиперссылок поверх них с тем, чтобы пользователь мог легко переходить из PDF-файла на карточку с деталями соответствующего оборудования в веб-интерфейсе СУИД в один клик.
Этап 2. MVP — минимально рабочий продукт (июнь 2023 — март 2024)
К июню 2023 года мы спроектировали архитектуру, собрали команду, с ИБ и подрядчиками договорились. И начали разработку MVP (Minimum Viable Product) — минимально работающей версии.
Мы не пытались сразу сделать идеальную систему. Сосредоточились на главном функционале:
Базовый поиск
Пользователь заходит в систему, вбивает номер оборудования — получает его характеристики, документы, привязку к 3D.
Интеграция 3D-модели в веб-интерфейс.
Больше не нужно запускать отдельные программы, чтобы посмотреть 3D-модель. Все видно во вкладке браузера
Пользователь открывает систему, видит карточку оборудования, кликает на кнопку «Показать в 3D» — и вот уже крутится модель установки, где этот объект подсвечен.
Загрузка и автоматическая проверка данных от подрядчиков
Например, в 3D-модели насоса предусмотрен клапан. У этого клапана есть собственный тег — 2101-HV-101.
Допустим, подрядчик загружает список комплектующих этого насоса, но этот клапан не указан. Система это видит и выдаёт ошибку. Подрядчик исправляет — досылает данные на клапан.
Система автоматически проверяет комплектность — без участия человека.
Просмотр PDF-документов в браузере
Вместо того чтобы скачивать PDF на компьютер и открывать в Adobe Reader, инженер кликает на документ прямо в СУИД — и файл открывается в той же вкладке браузера. Можно сразу листать, читать, масштабировать.
Внутри этих PDF встроены кликабельные гиперссылки. Видишь в чертеже тег насоса — кликаешь на него — переходишь на карточку этого насоса в СУИД. И наоборот: из карточки оборудования кликаешь на документ — он открывается на нужной странице.
Отображение структуры предприятия
Завод — это не просто куча оборудования. Это иерархия: цехи → установки → узлы → оборудование. В системе это всё видно в виде дерева. Можно раскрыть любой уровень и понять, что где находится.
В марте 2024, потом в марте 2025 года мы дали систему протестировать команде активных бизнес-пользователей и команде по управлению данными. Это были люди, которые реально работают с данными каждый день — инженеры проектов, специалисты по управлению информацией.
С каждым созванивались, приходилось объяснять вплоть до деталей: в какую колонку Excel какие данные заполнять, какой формат использовать.
В начале людям было сложно, но по итогу им понравилось. Один инженер сказал: «Раньше на поиск документа по оборудованию я тратил полчаса. Теперь — 30 секунд».
Этап 3. Доработка и запуск (март 2024 — конец 2025)
После успешного MVP мы расширили функционал:
Одно пространство для нескольких проектов.
Если инженер работает сразу на двух проектах — например, АГХК и ДГП-2 — ему не нужно заходить в разные системы. Он открывает один интерфейс, выбирает нужный проект из списка и работает. Чтобы переключиться на другой проект, достаточно пары кликов.
В AVEVA для каждого проекта требовался отдельный веб-портал, что усложняло работу.
Сложные формы поиска
В расширенном режиме поиска можно одновременно задавать несколько фильтров по любым характеристикам оборудования. Например:
«Найди все клапаны на установке А, где температура рабочей среды выше 200°C, а давление — от 20 до 40 атмосфер». Раньше для такого запроса пришлось бы вручную фильтровать Excel. Теперь — форма с полями, выбираешь параметры, получаешь результат.
Визуальные отчёты на основе 3D-модели
В системе можно отфильтровать оборудование по типу или состоянию и показать его прямо на 3D-модели. Например, вывести все датчики температуры или подсветить оборудование с критичным рейтингом. Такой вид помогает быстро оценить ситуацию и планировать обслуживание.
Мы также добавили функцию сборки: если проект состоит из нескольких 3D-моделей от разных подрядчиков, система объединяет их в одну общую модель. Это экономит вычислительные ресурсы и облегчает навигацию.
Это оказалось полезно не только для эксплуатации, но и для контроля подрядчиков. Бывали случаи, когда объёмы в расчётах по трубам или кабелю завышали в 2–3 раза. Без доступа к 3D-модели мы бы этого не увидели и заплатили бы за лишние объёмы. Теперь система автоматически сверяет расчёты подрядчика с 3D-моделью и сразу выявляет расхождения.
Дашборды и статистика
Они показывают, какой процент информации уже загружен, где есть отставания и по каким типам оборудования работа завершена. Руководители проектов видят картину в реальном времени и могут принимать решения.
К концу 2025 года платформа вышла в опытно-промышленную эксплуатацию. Система работает на двух крупных проектах. В 2026-м планируем мигрировать данные по проекту ДГП-2 в Тобольске, а также для проекта Стирольная цепочка НКНХ.
Результаты
Сейчас в системе работает уже более миллиона тегов и свыше 60 миллионов технических характеристик только по АГХК.
СУИД пользуются все, кто задействован в стройке. Это выглядит примерно так:
Проектировщики загружают данные по оборудованию, смотрят всю проектную документацию и сверяют 3D-модель с характеристиками
Закупщики по коду закупки видят статус заказа, оборудование и сроки поставки.
Строители заказывают грузоподъёмное оборудование: система выгружает отчёт по весу оборудования, и сразу понятно, какой кран нужен для монтажа колонны.
Специалисты по пусконаладке (ПНР) готовят чек-листы для запуска оборудования. Раньше неделями собирали данные из документов и Excel, теперь выгружают всё из СУИД за несколько минут.
Инженеры по эксплуатации ведут базу оборудования в SAP ТОРО для техобслуживания.
Первый заметный эффект для нас — экономия на лицензиях. На двух проектах мы уже сэкономили сотни миллионов только на лицензиях. Для всех следующих проектов система фактически обходится бесплатно — остаются только затраты на поддержку и развитие внутри команды.
Скорость работы выросла заметно. Инженеры перестали тратить дни и недели на поиск нужных данных. Теперь они занимаются своими непосредственными задачами, а не поиском документов и данных.
Загрузка и валидация данных стали быстрее на 50% по сравнению с AVEVA — не говоря уже о ручной обработке. Это значит, что подрядчики получают обратную связь вдвое быстрее, а значит — меньше ошибок и задержек в проекте.
За счёт того, что данные не собираются заново на каждом этапе — от проектирования до эксплуатации — сэкономили 279 млн рублей.
Ещё эффект — ранний поиск коллизий. Например, если труба проходит сквозь балку или кабельная трасса пересекается с вентиляционным коробом. В модели это просто ошибка проектировщика. А на стройке — реальная проблема: монтажники приходят, а труба физически не помещается. Приходится останавливать работу, переделывать проект, заказывать другие детали.
Система автоматически находит такие пересечения в 3D-модели до начала стройки. Проектировщик исправляет — и на площадку уходит уже проверенное решение.
И главное, мы сделали полностью прозрачным весь процесс от проектирования до эксплуатации. Это значит, что мы можем контролировать не только строительство, но и то, как завод будет работать дальше. Вся информация собрана, структурирована и доступна. Это основа для цифрового двойника — виртуальной копии завода, на которой можно моделировать процессы, планировать ремонты, обучать операторов.
Мы продолжаем развивать систему.
Сейчас мы пишем интеграцию с системой технического обслуживания и ремонта. Из СУИД туда автоматически уходит информация по оборудованию, а все изменения, которые появляются в эксплуатации — замены, модернизации, вывод из работы — возвращаются обратно. Пока обмен идёт через шаблоны, но мы постепенно переходим к полной автоматической интеграции.
У СИБУРа есть и другие заводы, которые строились раньше без системы. Постепенно будем оцифровывать и их — хотя это сложнее, чем вести данные с начала проекта. Legacy-данные разрознены, неструктурированы, на их оцифровку потребуются значительные усилия и средства нежели четко структурированное ведение данных от инициации проекта.
Подписывайтесь на наш тг-канал. Он полезен айтишникам, которые хотят понять, что реально происходит в промышленном ИТ.
Там мы рассказываем о цифровых технологиях для производства — от IIoT и аналитики до инженерных инструментов и ИИ. Делимся кейсами, экспериментами, новостями и выкладываем вакансии.
