isicad.ru :: портал САПР, PLM и ERP :: версия для печати

Статьи

5 июня 2025

Принципы разработки импортозамещающих САПР PlantLinker и СУИД «Плант-Навигатор» на основе опыта создания информационных моделей технологических и промышленных установок

А.А. Тучков, А.И. Сладковский, А.А. Рындин, И.Н. Чиковская, Д.В. Голованов, А.Н. Чиковский, В.А. Гончаров
ООО «Бюро ESG», г. Санкт-Петербург

Аннотация

В предыдущих презентациях и статьях [1] мы неоднократно рассказывали о десятилетнем опыте информационного моделирования сложных технологических установок. Понятно, что этот опыт базировался на ряде зарубежных САПР и СУИД.

Жизнь не стоит на месте, и, видимо, пришло время рассказать о наших разработках, предназначенных для решения задачи импортозамещения в области моделирования сложных технологических и промышленных установок. В этой статье мы расскажем о САПР PlantLinker и СУИД Плант-Навигатор, а также о вьюверах PlantViewer 3D и PlantViewer 2D.

Во всех вышеперечисленных разработках используется накопленный 25-летний опыт группы компаний «САПР-Петербург» при реализации проектов поставок и внедрения САПР сложных технологических установок и 11-летний опыт внедрения СУИД/СупрИД и наполнения ее интеллектуальным контентом.

Нашими компаниями были созданы и актуализированы информационные модели (ИМ) 38 объектов нефтепереработки, из них 27 эксплуатационных моделей и 11 проектных. В том числе:

  • 21 установка моделировалась с использованием САПР Smart 3D;
  • 12 установок — с использованием САПР PlantLinker;
  • 3 установки — с использованием САПР Autodesk Revit;
  • строительные конструкции на 20 установках — с использованием САПР Tekla Structures;
  • технологические схемы и схемы процессов на 30 установках — с использованием САПР Smart P&ID;
  • электронная версия генплана 13 установок — с использованием САПР nanoCAD GeoniCS.

С использованием САПР Autodesk Revit были созданы модели:

  • 2 газоизмерительных и 1 компрессорная станция Газпрома;
  • 4 объекта судостроительных верфей;
  • 5 поликлиник;
  • 4 станций метро.

Приведем количественные характеристики одной крупной работающей установки (комбинированная установка по производству ароматических углеводородов (КПА)):


  • площадь 15 гектаров,
  • количество уникального и стандартного оборудования — 590 единиц,
  • количество технологических трубопроводов — 3687 единиц,
  • количество приборов и устройств КИП — 10 626 единиц,
  • зданий/сооружений — 45 единиц,
  • грузоподъемного оборудования и вентиляционных систем — 163 единицы,
  • электрооборудования — 2127 единиц.

Из этого понятно, что, строя ИМ, мы будем оперировать огромным количеством объектов и документов и огромными по размеру моделями. Объем 3D-модели КПА в формате IFC составляет около 20 Гб.

I. Постановка задачи

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

Для чего нашим Заказчикам (нефтегазовым холдингам) нужны информационные модели технологических установок?

Возникла задача сокращения времени плановых и неплановых (аварийных) простоев технологических установок. Финансовый результат тут не обсуждается — простой установки в течение недели, не говоря уже о месяце, влечет за собой многомиллионные убытки. При этом многие установки функционируют не одно десятилетие и неоднократно подвергались реконструкции и ремонту. Стандартный подход ТИМ — строим модель от стадии проектирования — тут не работает.

Чего же мы пытаемся достичь, разрабатывая информационную модель объекта для эксплуатации?

Мы пытаемся собрать в одном месте всю достоверную информацию об объекте, включая:

  • проектную, строительную, эксплуатационную документацию;
  • трехмерную модель объекта;
  • панорамные фотографии объекта;
  • схемы процессов, технологические схемы (схемы P&ID), электрические схемы, схемы функционирования КИП, изометрические схемы;
  • электронную версию генплана территории объекта, включая подземные коммуникации;
  • технические паспорта компонентов объекта, включая трубопроводы, уникальное оборудование, стандартное (закупаемое) оборудование, огромное количество устройств «полевого» КИП;
  • регламенты обслуживания компонентов технологической установки;
  • исторические данные: где закупалось оборудование, кто его ремонтировал, что заменялось и т. п.;
  • данные о состоянии оборудования, подготавливаемого к плановому простою или находящегося в плановом простое;
  • PDM-информацию по машиностроительным изделиям, включая трехмерные модели изделий.

Для определенности будем называть компоненты технологической установки «проектными позициями» (также используется термин «ТЕГ»). Для того чтобы информационную модель можно было эффективно использовать, следует установить множество разнообразных связей.

Мы хотим видеть:

  • необходимую проектную позицию в трехмерной модели установки;
  • проектную позицию в технологических схемах и схемах процессов;
  • всю документацию, связанную с проектной позицией;
  • связь с проектной позицией внутри документации (это далеко не всегда реализуемо);
  • исторические данные, связанные с проектными позициями;
  • проектную позицию на панорамных фотографиях.

И, самое главное, мы хотим, чтобы поиск проектной позиции и переходы между моделями и документами происходили в идеале мгновенно.

Рис. 2. Цифровой двойник технологической установки

Рис. 2. Цифровой двойник технологической установки

Обратим внимание читателя на один очень важный момент. Мы строим информационные модели установок, которые эксплуатируются много лет (а иногда и десятков лет). За это время они неоднократно подвергаются ремонтам, модернизациям, замене оборудования. И далеко не всегда эти изменения отображаются в какой-бы то ни было документации.

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

II. Тегирование компонентов и стандарты KKS, CFIHOS и RDS (ISO 81346)

На рис. 2 мы уже применили термин «ТЕГ». В обсуждаемой тематике под ТЕГом понимается идентификатор (КОД), однозначно определяющий компонент технологической установки. В предыдущих публикациях [1,2] термин «ТЕГ» используется в основном для кодирования оборудования, приборов КИП, компонентов трубопроводных систем.

Но существует и более общая концепция, где «тегируются» (кодируются) и здания/строения/сооружения, и этажи/уровни/помещения, и строительные конструкции, и их компоненты, и иерархия системы/подсистемы, и разнообразная проектная и эксплуатационная документация. Такая концепция обеспечивает очень гибкие возможности классификации и поиска всего вышеперечисленного в Информационных и трехмерных моделях, в интеллектуальных схемах и документах, в поиске самих документов.

Рассмотрим существующие на данный момент стандарты кодирования компонентов промышленных, технологических и строительных объектов и установок.

Первым широко распространенным стандартом кодирования в РФ стал стандарт KKS VGN B105 (Kraftwerk-Kennzeichensystem) получивший серьезное внедрение в атомной отрасли РФ в связи с требованиями МАГАТЭ (Международное Агентство по Атомной Энергии). Из Атомной отрасли стандарт постепенно распространился в другие отрасли, как минимум в энергетические.

Другой стандарт, получивший в свое время популярность в нефтяной отрасли, — ISO 15926. Был переведен в РФ и получил название ГОСТ Р ИСО 15926-1-2008. Задумывался как стандарт обмена данными между независимыми информационными системами. Реально почти не был внедрен, но послужил основой для стандарта CFIHOS — Capital Facilities HandOver Specification. Дословно переводится как «Стандарт по передаче данных объектов капитального строительства». В настоящее время стандарт поддерживают около 70 организаций, включая крупнейшие нефтегазодобывающие компании (Shell, ENI, BP, Total и др.). К сожалению, сегодня российского аналога стандарта CFIHOS не существует и формально он не применяется.

И, наконец, самый интересный с нашей точки зрения стандарт IEC/ISO 81346 (ГОСТ Р 58908.1-2020) — претендует на роль самого минималистичного метода кодирования компонентов технологических/промышленных установок. Получил также сокращенное название RDS — Reference Designation System (Система Справочных обозначений).

Рассмотрим этот стандарт чуть подробнее:

  • Стандарт в первую очередь вводит понятие структуры технологического объекта.
  • Вводится понятие Класса, и, как следствие, производится классификация объектов.
  • Вводится понятие Аспекта. Стандарт RDS рассматривает любой промышленный объект (площадку, здание/строение/сооружение, этаж, помещение, строительные конструкции, установку, систему, оборудование, приборы КИП, трубопроводы и компоненты трубопроводов и пр.), исходя из четырех аспектов, определяющих префикс в предлагаемом коде:
    • "=" (равно) в отношении аспекта функции объекта;
    • "-" (минус) в отношении аспекта продукта объекта;
    • "+" (плюс) в отношении аспекта местоположения объекта;
    • "%" (процент) в отношении аспекта типа объекта.

На рис. 3 представлен принцип формирования многоуровневого кодового обозначения (ТЕГа) для объектов системы (ГОСТ Р 58908.1-2020).

Рис. 3. ТЕГ — Многоуровневое кодовое обозначение

Рис. 3. ТЕГ — Многоуровневое кодовое обозначение

На рис. 4 представлены структуры простейшей технологической системы в разных аспектах.

Рис. 4. Аспекты технологической установки

Рис. 4. Аспекты технологической установки

На рис. 5 представлена структура технологической системы с обозначенными (тегированными) подобъектами в разных аспектах.

Рис. 5. Структуры технологической установки с тегированными подобъектами

Рис. 5. Структуры технологической установки с тегированными подобъектами

Таким образом, подобъект Щит может получить уникальный код =WC1-UC1+B3+S3+R2+U1. Из кода ясно, что объект функционально относится к Электроснабжению (=WC1), представляет из себя щит определённого производителя (-UC1) и находится в здании B1, на этаже S3 в комнате R2 в части комнаты (пространстве) U1.

Общая система кодирования отраслевых и технических систем и компонентов представлена на рис. 6.

Рис. 6. Общая система кодирования (ТЕГирования) ISO 81346 — RDS

Рис. 6. Общая система кодирования (ТЕГирования) ISO 81346 — RDS

В таблицах 1 и 2 представлены примеры кодов классов для Функциональных (отраслевых) и Технических систем, заимствованные из ГОСТ Р 58908.12-2020.

Таблица 1. Односимвольные коды классов для Функциональных (отраслевых) систем

Таблица 2. Двухсимвольные коды классов для технических систем

В настоящее время на Западе стандарты разработаны для Энергетики, Строительных конструкций и общей классификации компонентов систем (рис. 7).

Рис. 7. Разработанные стандарты RDS

Рис. 7. Разработанные стандарты RDS

Также ведутся проработки стандарта для нефтяной и газовой промышленности (ведется инициативная работа в рамках норвежской Объединённой Отраслевой Программы READI JIP с привлечением заинтересованных сторон), для инфраструктурных объектов, самолётостроения и машиностроения (приостановлен) (рис. 8).

Рис. 8. Разрабатываемые стандарты RDS

Рис. 8. Разрабатываемые стандарты RDS

В России переведены и приняты стандарты ГОСТ Р 58908.1-2020 (ISO 81346-1:2009) и ГОСТ Р 58908.12-2020 (ISO 81346-12:2018), то есть Общие положения и Строительные конструкции. К сожалению, стандарт ISO/IEC 81346-2:2019 в русскоязычном варианте отсутствует. Он определяет таблицы кодирования для компонентов общего назначения и, по заявлениям авторов, закрывает 99.9% потребностей любой отрасли. Также не переведен стандарт ISO/IEC 81346-10:2016, посвященный энергетической отрасли.

Надо отметить достоинства рассматриваемого стандарта:

  • Возможность кодировать (присваивать ТЕГи) не только оборудованию и компонентам технологических систем, но и системам более высокого уровня.
  • Возможность кодировать здания/строения/сооружения, этажи/уровни, зоны/блоки, помещения/пространства, различные строительные конструкции.
  • Возможность кодирования как типа объекта или оборудования (насос центробежный), так и конкретного изделия, смонтированного на объекте.
  • Возможность использования кода для обозначения документации.
  • Возможность гибкой коннекции одноуровневых кодовых обозначений и при необходимости упрощения многоуровневого кодового обозначения с сохранением его уникальности.
  • Очень широкие возможности поиска объектов технологической установки и документации по различным комбинациям одноуровневых кодовых обозначений ТЕГа объектов.
  • Регулярная структура кода приводит к сокращению трудоемкости при его реализации в Информационных Системах.

В дальнейшем рассмотрении мы несколько раз вернемся к вопросу о ТЕГах.

III. Используемое программное обеспечение

Программные средства на стороне Исполнителя разделяются по направлениям:

  1. САПР строительных конструкций — Tekla Structures (компания Trimble) и Autodesk Revit (компания Autodesk).
  2. САПР технологических конструкций — Intergraph Smart 3D (компания Hexagon PPM), иногда AVEVA E3D (компания AVEVA).
  3. САПР технологических схем — Intergraph Smart P&ID (компания Hexagon PPM).
  4. САПР создания генплана и ИМ наружных коммуникаций — nanoCAD GeoniCS (компания «Нанософт») и Autodesk Civil 3D (компания Autodesk).
  5. Создание комплексной (объединенной) модели — Intergraph Smart 3D (компания Hexagon PPM).
  6. Средства работы с облаками точек — результата наземного сканирования объектов и сооружений — программные средства компании Leica Geosystems (корпорация Hexagon): Cyclone Register (первичная обработка); Cyclone Publisher (нарезка облаков точек и публикация); Smart Laser Data Engineer (SLDE) (хранилище облаков точек); CloudWorx for Intergraph Smart 3D (доступ к облакам из САПР); Truview Enterprise (хранилище панорамных туров и облаков точек); Truview (просмотр панорамных туров и облаков точек); JetStream Viewer (просмотр облаков точек).

Программные средства на стороне Заказчика, которые позволяют построить информационную модель, называются системами управления инженерными данными (СУИД, иногда СУпрИД). В настоящее время многие Заказчики используют SmartPlant Foundation (SPF и ее развитие SPO) компании Hexagon PPM. Часть Заказчиков использовали Aveva Net Portal (компания AVEVA).

Одним из инструментов Заказчиков является «верификационный стенд» (продукт Заказчика), который позволяет сравнить трехмерную модель (модели), технологические схемы и таблицы компонентов (1D-модель) установки на предмет:

  • соответствия задания ТЕГов используемому стандарту;
  • правильности задания ТЕГов во всех трех моделях;
  • полноты присутствия всех компонентов во всех трех моделях;
  • необходимого атрибутивного состава каждого компонента;
  • правильности заполнения атрибутивного состава.
Рис. 9. Схема верификационного стенда

Рис. 9. Схема верификационного стенда

IV. Импортозамещающее программное обеспечение

Для решения задач информационного моделирования сложных технологических установок наша компания (Бюро ESG) рассматривает приведенный ниже список импортозамещающего программного обеспечения.

Сразу хотим акцентировать, что этот список не охватывает всех продуктов на отечественном рынке.

  1. САПР строительных конструкций — nanoCAD BIM Конструкция (компании «Нанософт») и Renga (компания Renga Software),
  2. САПР промышленных установок, включая строительные конструкции, — PlantLinker (компания «ПлантЛинкер»),
  3. САПР технологических конструкций — PlantLinker (компания «ПлантЛинкер»),
  4. САПР технологических схем — nanoCAD (компания «Нанософт»),
  5. САПР создания генплана и ИМ наружных коммуникаций — nanoCAD GeoniCS (компания «Нанософт»),
  6. Создание комплексной (объединенной) модели — PlantLinker (компания «ПлантЛинкер») либо PlantViewer (компания «ПлантЛинкер») на базе IFC-формата,
  7. Средства работы с облаками точек — результата наземного сканирования объектов и сооружений — PlantLinker (компания «ПлантЛинкер»).

В качестве системы СУИД на стороне Заказчика мы предлагаем использовать СУИД «Плант-Навигатор» (компания «Бюро ESG») на платформе IPS Search (компания «Интермех»).

V. САПР PlantLinker — проектирование и моделирование сложных технологических установок

САПР проектирования сложных технологических и промышленных установок получили название Plant Design.

Наиболее известными и распространёнными можно считать всего четыре САПР Plant Design (причем первые две из них фактически уже устарели):

  • PDS (компания Intergraph);
  • PDMS (компания Aveva);
  • Smart 3D (компания Hexagon PPM — выросшая из компании Intergraph);
  • Everything3D-E3D (компания Aveva).

Попробуем сформулировать несколько положений, на базе которых разработаны вышеупомянутые САПР:

  • Объектно-ориентированный способ представления моделей. Каждый компонент модели хранится в системе как объект (символ), имеющий наименование, однозначно определяющее его геометрический образ и набор атрибутов (параметров): технологические параметры, размерные параметры, параметры положения. Геометрический образ в системе не хранится.
  • Создание моделей ведется на основе каталога, который включает в себя:
    • Каталог для систем трубопроводов на основе спецификаций (классов),
    • Каталог для систем воздуховодов на основе спецификаций,
    • Каталог для систем кабельных лотков на основе спецификаций,
      Спецификация трубопроводов (воздуховодов, лотков) представляет собой список компонентов, доступных для размещения на осевой линии, набор правил для корректного выбора этих компонентов и ссылки на таблицы размеров и обозначений. Это резко ускоряет процесс моделирования, в особенности редактирования, и позволяет избежать многих ошибок.
      Именно в каталогах предлагается реализовывать ранее рассмотренную концепцию ТЕГов на основе стандартов, а именно элементы одноуровневых кодовых обозначений.
    • Каталог типового оборудования с параметризацией,
    • Каталог опор и подвесок,
    • Библиотеки профилей сечений металлопроката и бетона.
  • Фактически внутри систем Plant Design присутствует табличное описание всей 3D-модели, что обеспечивает легкую генерацию любых отчетов (ведомостей, экспликаций, спецификаций и т. п.).
  • Ну и важнейшим свойством любых систем Plant Design является поиск коллизий, реализуемый или «на лету», или как отдельная процедура с большим количеством настроек.

Модели оборудования и нестандартных компонентов, используемых в этих системах, имеют упрощенную (фактически «оболочковую» графику) и разнообразные точки коннекции к этому оборудованию (фланцы различных типов, электрические клеммы и т. п.). В большинстве случаев геометрический образ этого оборудования определяется простейшими правилами в некотором формализованном описании.

Таким образом, объектная модель, построенная на заранее подготовленном каталоге спецификаций, обеспечивает очень компактное представление трехмерной модели (поскольку не хранятся сложные геометрические образы) и, как следствие, возможность моделировать очень большие и сложные установки.

САПР PlantLinker построен именно на таких принципах и обеспечивает проектирование и 3D моделирование промышленных объектов и сложных технологических установок непрерывного производственного цикла.

Важной особенностью САПР PlantLinker является возможность обмениваться моделями с различными системами Plant Design с использованием поставляемых интерфейсов (Intergraph Smart3D, Aveva E3D, TEKLA Structures, Smart P&ID, Smart Isometrics и другими).

Рис. 10. Пример информационной модели установки, созданной с помощью САПР Plantlinker

Рис. 10. Пример информационной модели установки, созданной с помощью САПР Plantlinker

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

Самое главное, что PlantLinker обеспечивает рендеринг облаков больших размеров (100+ миллиардов точек) путем загрузки и подкачки облаков с носителей по необходимости.

Специальный модуль PlantLinker PmPoints (работает автономно) предназначен для подготовки облаков точек для работы в Plantlinker — преобразование форматов, сжатие, прореживание, вырезка необходимых частей, управление комбинациями вырезок.

Дополнительный модуль PlantLinker PMCloud (работает в среде PlantLinker) реализует моделирование оборудования, строительных конструкций, трубопроводов и лотков по распознанным осевым линиям конструкций.

Рис. 11. Моделирование по облакам точек

Рис. 11. Моделирование по облакам точек

В этой части статьи мы попытались акцентировать те принципы создания САПР PlantLinker, которые обеспечивают создание информационных моделей огромных технологических установок, сравнимых с комбинированной установкой по производству ароматических углеводородов КПА, параметры которой приведены выше. Подробно ознакомиться с функциональными возможностями САПР PlantLinker можно в статьях [3] и [4] и на сайте www.plantlinker.ru.

VI. СУИД «Плант-Навигатор» — критерии выбора платформы

В этой части статьи мы попытаемся сформулировать самые важные, на наш взгляд, критерии выбора платформы Системы Управления Инженерными данными.

Довольно часто приходится слышать мнение, что СУИД и машиностроительные системы PDM/PLM (управление структурой изделия и управление жизненным циклом изделия) — это одно и то же. Действительно, архитектура этих систем очень близка, но есть несколько фундаментальных и очень важных отличий:

  • Системы PDM/PLM в основном работают с одной иерархической структурой изделия (Изделие-узел-сборка-подсборка-деталь). В СУИД необходимо работать со многими разнообразными структурами.
  • Системы PDM/PLM фактически всегда плотно интегрированы с машиностроительной САПР того же вендора и/или обеспечивают и работу с моделями в стандартных форматах (в первую очередь STEP, IGES, JT и других). Форматы, которые используются в СУИД и ПГС (в первую очередь IFC), эти системы не поддерживают.
  • В СУИД требуется поддержка интеллектуальных моделей и интеллектуальных схем. То есть, найдя компонент в одной из структур технологической установки, необходимо посмотреть, где он расположен в трехмерной модели и технологических схемах. В системах PDM/PLM это реализовано только для машиностроительных сборок.

Итак, критерии выбора платформы для СУИД.

6.1. Создание параллельных структур объектов и горизонтальных связей

При работе в СИУД нам необходимо вести ряд параллельных структур иногда на одних и тех же объектах, иногда на разных. Пример — «классическая» структура технологической установки — здание/сооружение → блок → зона → экземпляр оборудования (в западной терминологии — PBS). С другой стороны, оборудование входит в одну, а иногда и несколько систем, которые могут «пронизывать» разные здания/сооружения. Тогда структура может приобрести, например, такой вид: система → подсистема → тип оборудования (основное/вспомогательное) → экземпляр оборудования.

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

Между вышеперечисленными структурами (оборудование установки и документация) должны существовать горизонтальные связи (оборудование упоминается в документе).

Обратите внимание, что выше (рис. 5) мы уже показали простейшие примеры структур ИМ технологических установок в соответствии со стандартом ГОСТ Р 58908.1-2020 (ISO 81346-1:2009).

6.2. Отображение связей объектов в виде иерархических и паутинных графов

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

  • Просто отображение иерархической структуры объекта или документации, зафиксированное в системе;
  • Отображение, настраиваемое по атрибутам: например, первый атрибут — здание/сооружение, второй — этаж, третий — помещение (динамические структуры);
  • Отображение в виде паутинного графа (жаргонные названия — «паук», «молекула»), визуализирующего связи между различными объектами.

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

Рис. 12. Примеры структуры и паутинного графа

Рис. 12. Примеры структуры и паутинного графа

6.3. Форматы хранимых документов, интеллектуальных 3D-моделей и технологических схем

Мы уже упоминали о различных форматах, используемых в СУИД. При выборе платформы необходимо, чтобы она поддерживала работу с форматами, получившими в нашей стране статус «стандарта де факто». Это в первую очередь формат .PDF, в котором отображаются многостраничные документы фактически из любых систем. И несколько «условно открытых» форматов — Microsoft Office (.docx, .xlsx, .pptx) и Autodesk — .dwg.

Теперь самое главное — обеспечение «интеллектуальности» 3D-модели и различных схем. Под схемами в данном случае понимаются схемы процессов, технологические схемы (P&ID-схемы), электрические схемы и схемы контрольно-измерительных приборов (КИП), а также изометрические схемы. Под «интеллектуальностью» понимается возможность позиционироваться на любой объект в 3D-моделях и схемах. Связь осуществляется с помощью ТЕГа (уникального кода) любого компонента (существующего в структуре СУИД, 3D-моделях и схемах).

Рис. 13. Связь «интеллектуальных» 3D-моделей и схем со структурой установки и обычными

Рис. 13. Связь «интеллектуальных» 3D-моделей и схем со структурой установки и обычными

В статье [2] мы уже высказывали свою позицию — обсуждаемые и используемые в СУИД форматы должны быть открытыми. С нашей точки зрения, сегодня востребованы форматы IFC — для моделей строительных и технологических конструкций и STEP — для моделей оборудования.

Что касается разнообразных схем, то сегодня мы предлагаем использовать открытый формат SVG.

При этом, поскольку сами установки очень большие, то и 3D-модели в формате IFC тоже весьма велики (20-90 Гб), а количество технологических схем на одной установке может быть более 200. И СУИД должен уметь работать с такими объемами.

6.4. Поиск, сортировка и фильтрация объектов

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

Именно синергия платформы построения СУИД и правильная стратегия тегирования позволяет решить не только задачу поиска и фильтрации объектов, но и построение параллельных динамических структур, изначально не заложенных при проектировании СУИД.

6.5. Ведение версий документов, объектов и структур

Выше мы обсуждаем вопрос о различных форматах документов. То есть СУИД в качестве инженерных данных хранит документы. А это означает, что фактически СУИД должен реализовывать функциональность технического архива и документооборота (ТДО). Одним из важнейших требований к системам ТДО является необходимость хранить версии документов.

6.6. Документооборот и бизнес-процессы

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

Рис. 14. Пример бизнес-процесса согласования и утверждения комплекта документов

Рис. 14. Пример бизнес-процесса согласования и утверждения комплекта документов

6.7. Система планирования со связями с объектами и документами

Поскольку СУИД связана не только с поиском и обработкой тех или иных объектов и документов, касающихся технологических установок, но и с рядом работ, связанных с их обслуживанием, ремонтами, модернизацией, очень часто требуется «перевязать» работы в календарных планах-графиках с объектами и документами, находящимися в СУИД. Особенно это касается работ, требующих простоев установки (вывода из эксплуатации). Простои могут быть «плановыми» и «аварийными». В первом случае требуется подробный план-график работ, во втором в первую очередь — доступ к актуальной информации и план срочного устранения неисправностей.

6.8. Поддержка территориально распределенных систем

Достаточно часто мы сталкиваемся с необходимостью развертывать СУИД на промышленных площадках, территориально разнесенных друг от друга. Например, Москва, Санкт-Петербург, Омск.

Также в этих условиях необходимы территориально распределенные бизнес-процессы и документооборот.

6.9. Технологическая платформа

Требования импортозамещения накладывают ограничения на используемые операционные системы и СУБД. В идеале все должно работать на одном из клонов Linux (самые распространенные — Astra Linux, РЕД ОС, ALT Linux) и на отечественной СУБД (с нашей точки зрения. фактически безальтернативно для наших задач — СУБД Postgres Pro).

6.10. Использование PDM/PLM моделей оборудования

В настоящее время оборудование в СУИД представлено как один компонент, обладающий ТЕГом. В ряде случаев — как несколько компонентов, каждый из которых обладает ТЕГом (крупноблочная декомпозиция оборудования).

Но уже появляются запросы включить в состав СУИД и подробную информацию по оборудованию, машиностроительные 3D-модели оборудования, комплекты документов, то есть фактически включить в состав СУИД PDM/PLM систему с машиностроительным контентом по оборудованию.

VII. СУИД «Плант-Навигатор» — наш выбор платформы

Проанализировав состояние рынка отечественных PDM/PLM-систем, а также рынка систем технического документа оборота (ТДО) и сред хранения общих данных (СОД) в секторе промышленного и гражданского строительства, мы пришли к выводу, что девяти из десяти критериев, сформулированных выше (кроме пункта 6.3), отвечает система IPS Search (Компания ОДО «Интермех», г. Минск).

Самая главная особенность — это очень гибкое управление структурами объектов и изделий (пункты 6.1, 6.2, 6.4). Именно это востребовано при создании СУИД и не очень часто реализуется в альтернативных системах.

Вторая главная особенность — это возможность реализовать развитую систему тегирования. Для этого необходимо создать плагины, обеспечивающие реализацию того или иного стандарта тегирования и корректного присвоения ТЕГов объектам и документам.

И отметим, что пункт 6.10 — использование PDM/PLM моделей оборудования — при выборе в качестве платформы IPS Search реализуется фактически автоматически.

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

  • PlantViewer 3D — отображение 3D-моделей в файлах формата IFC и STEP, а также облаков точек. При этом поддерживается загрузка очень больших IFC-файлов (20 Гб и более);
  • PlantViewer 2D — отображение схем процессов, технологических схем (P&ID-схемы), электрических схем, схем контрольно-измерительных приборов (КИП) и изометрических схем в формате SVG.

Оба вьювера интегрированы с IPS Search (как на платформе Windows, так и на платформе Linux), поддерживают «Интеллектуальность» моделей и схем.

Функциональность PlantViewer 3D/2D подробно представлена на сайте https://esg.spb.ru/develop/.

Рис. 15. Визуализация трубопровода в 3D-модели в технологической (P&ID) схеме и интеграция с СУИД

Рис. 15. Визуализация трубопровода в 3D-модели в технологической (P&ID) схеме и интеграция с СУИД

Рис. 15. Визуализация трубопровода в 3D-модели в технологической (P&ID) схеме и интеграция с СУИД

Объем внедрения программных продуктов компании ОДО «Интермех» составляет более 4000 предприятий России и СНГ. При этом IPS Search внедрялся на крупнейших промышленных холдингах страны. Этот аргумент окончательно убедил нас в правильности сделанного выбора.

VIII. Выводы

Итак, на основе всего вышесказанного мы предлагаем использовать для информационного моделирования и проектирования технологических и промышленных установок:

  • САПР Plantlinker для моделирования строительных конструкций, оборудования, трубопроводов, вентиляции и электрических систем;
  • САПР Plantlinker для работы с облаками сканированных облаков точек и моделирования на основе облаков точек;
  • СУИД «Плант-Навигатор» на платформе IPS Search, дополненный вьюверами PlantViewer 2D/3D, обеспечивающими визуализацию «интеллектуальных» 3D-моделей установок в формате IFC (в том числе огромного размера!) и «интеллектуальных» схем процессов, технологических схем, электрических схем, схем КИП и изометрических схем.
Список литературы
  1. А. Тучков, А. Хабаров, М. Дементьева, И. Ваганов. «Опыт создания информационных моделей сложных технологических установок в интересах нефтегазовых холдингов», «Нефть. Газ. Новации» 4, 2024, https://esg.spb.ru/upload/iblock/f1d/qmw17aa3xntbch9d23vfiair77jf4ejc.pdf
  2. А. Тучков. «Открытые и закрытые форматы данных в САПР, СОД, СУИД/СУпрИД», «САПР и Графика», март 2024, https://esg.spb.ru/upload/iblock/b33/kmqtnke55khiulb6bor8yl3dz6i2rc8o.pdf
  3. А. Сладковский. «PlantLinker — автономная российская промышленная САПР», «САПР и Графика», май 2024, https://esg.spb.ru/upload/iblock/f84/m5vcec6b2cs0i6931p1penmgdehct95w.pdf
  4. Т. Ларина, А. Сладковский. «Как мы перешли от передачи данных к полноценной САПР для моделирования промышленных объектов с насыщенными технологическими трубопроводами», интервью с Андреем Сладковским, Сборник «Энергетика и нефтехимический комплекс Татарстана 2024», https://esg.spb.ru/upload/iblock/f2d/eauhxgot9ks2rp3ymi3a8a4cxx5x86g5.pdf


Реклама. ООО «Бюро ЕСГ». erid: 2SDnjbtCiAH


Все права защищены. © 2004-2025 Группа компаний «ЛЕДАС»

Перепечатка материалов сайта допускается с согласия редакции, ссылка на isicad.ru обязательна.
Вы можете обратиться к нам по адресу info@isicad.ru.