27 ноября 2024
А. Тучков, А. Сладковский, А. Рындин, И. Чиковская, Д. ГоловановВ предыдущих презентациях и статьях [1] мы неоднократно рассказывали о десятилетнем опыте информационного моделирования сложных технологических установок. Понятно, что этот опыт базировался на ряде зарубежных САПР и СУИД.
Жизнь не стоит на месте, и, видимо, пришло время рассказать о наших разработках, предназначенных для решения задачи импортозамещения в области моделирования ложных технологических и промышленных установок. В этой статье речь пойдет о САПР PlantLinker и СУИД «Плант-Навигатор», а также о вьюверах PlantViewer 3D и PlantViewer 2D.
Во всех вышеперечисленных разработках используется накопленный 25-летний опыт группы компаний «САПР-Петербург» при реализации проектов поставок и внедрения САПР сложных технологических установок и 11-летний опыт внедрения СУИД/СУпрИД и наполнения ее интеллектуальным контентом.
Нашими компаниями были созданы и актуализированы информационные модели (ИМ) 36 объектов нефтепереработки, из них 26 эксплуатационных моделей и 10 проектных. В том числе ИМ моделировались с использованием:
С применением САПР Autodesk Revit были созданы модели:
Позволим себе повторить раздел предыдущей статьи и еще раз акцентировать внимание наших читателей на задачах, которые мы пытаемся решить, строя информационную модель сложных технологических установок (рис. 1).
Рис. 1. Цифровой двойник технологической установки
В отличие от традиционно применяемых в сфере гражданского строительства ТИМ (BIM) технологий, в нефтегазовой отрасли потребность в информационных моделях технологических установок появилась не у проектировщиков (там уже не одно десятилетие применяются технологии, похожие на ТИМ), а у эксплуатантов.
Возникла задача сокращения времени плановых и неплановых (аварийных) простоев технологических установок. Финансовый результат тут не обсуждается — простой установки в течение недели, не говоря уже о месяце, влечет за собой многомиллионные убытки. При этом многие установки функционируют не одно десятилетие и неоднократно подвергались реконструкции и ремонту.
Стандартный подход ТИМ — строительство модели от стадии проектирования — тут не работает. Хотя постепенно ситуация меняется. Заказчик предъявляет требования проектировщикам и стремится к получению модели «как построено».
Мы пытаемся собрать в одном месте всю достоверную информацию об объекте, включая:
Для определенности будем называть компоненты технологической установки «проектными позициями ». Для того чтобы информационную модель можно было эффективно использовать, следует установить множество разнообразных связей.
Мы хотим видеть:
И самое главное, мы хотим, чтобы в идеале поиск проектной позиции и переходы между моделями и документами происходили мгновенно.
Обратим внимание читателя еще на один очень важный фактор. Мы строим информационные модели установок, которые эксплуатируются много лет (а иногда и десятки лет). За это время они неоднократно подвергались ремонтам, модернизациям, замене оборудования. И далеко не всегда эти изменения отображались в какой-бы то ни было документации.
Поэтому единственным источником гарантированно актуальной информации является сама установка. Современные средства лазерного сканирования, панорамной фотографии и просто цифровой фотографии обеспечивают специалистов, занимающихся информационным моделированием, доступом к оцифрованной информации в статусе «как эксплуатируется» (рис. 2).
Рис. 2. Результат наземного лазерного сканирования установки — облако точек
Программные средства на стороне исполнителя разделяются по специальностям:
Программные средства на стороне заказчика, которые позволяют построить информационную модель, называются системами управления инженерными данными (СУИД, иногда СУпрИД). В настоящее время многие заказчики применяют SmartPlant Foundation (SPF и ее развитие — SPO) компании Hexagon PPM. Часть заказчиков использовали Aveva Net Portal (компания AVEVA).
Одним из инструментов заказчиков является «верификационный стенд» (продукт заказчика), который позволяет сравнить трехмерную модель (модели), технологические схемы и таблицы компонентов (1D-модель) установки (рис. 3) на предмет:
Рис. 3. Схема верификационного стенда
Для начала просто приведем список импортозамещающего программного обеспечения, которое мы рассматриваем для решения задач информационного моделирования сложных технологических установок.
Сразу отметим, что этот список не охватывает всех продуктов на отечественном рынке — в него вошли те продукты, которые рассматривает наша группа компаний для решения вышеописанных задач:
В качестве системы СУИД на стороне заказчика мы предлагаем использовать СУИД «Плант-Навигатор» (компания «Бюро ESG») на платформе IPS Search (компания «Интермех»).
В качестве вышеупомянутого «Верификационного стенда» может служить либо существующий (потребуются доработки), либо созданный на платформе IPS Search ресурсами исполнителя или заказчика.
Несколько замечаний по вышеприведенному списку:
САПР проектирования сложных технологических и промышленных установок получили название Plant Design.
Наиболее известными и распространенными можно считать всего четыре САПР Plant Design (причем две первые из них фактически уже устарели):
На каких принципах построены вышеупомянутые САПР?
Приведем количественные характеристики одной крупной работающей установки (комбинированная установка по производству ароматических углеводородов (КПА)):
Эта информация дает представление о том, что, строя ИМ, мы будем оперировать огромным количеством объектов и документов и громадными по размеру моделями. Объем 3D-модели КПА в формате IFC составляет около 20 Гбайт.
Попробуем сформулировать несколько положений, на базе которых разработаны вышеупомянутые САПР:
1. Объектно-ориентированный способ представления моделей. Каждый компонент модели хранится в системе, как объект (символ), имеющий наименование, однозначно определяющее его геометрический образ и набор атрибутов (параметров): технологические параметры, размерные параметры, параметры положения. Геометрический образ в системе не хранится. За счет этого резко уменьшается объем модели в файловом виде и обеспечивается возможность создания огромных моделей.
2. Создание моделей ведется на основе каталога (рис. 4), который включает:
Рис. 4. Каталог классов трубопроводов САПР PlantLinker
3. Фактически внутри систем Plant Design присутствует табличное описание всей 3D-модели, что обеспечивает легкую генерацию любых отчетов (ведомостей, экспликаций, спецификаций и т.п.).
4. Важнейшим свойством любых систем Plant Design является поиск коллизий, реализуемый или «на лету», или как отдельная процедура с большим количеством настроек.
Таким образом, объектная модель, построенная на заранее подготовленном каталоге спецификаций, обеспечивает очень компактное представление трехмерной модели и, как cледствие, возможность моделировать очень большие и сложные установки.
САПР PlantLinker построен именно на таких принципах и обеспечивает проектирование и 3D-моделирование промышленных объектов и сложных технологических установок непрерывного производственного цикла.
САПР PlantLinker предназначен для работы проектных организаций и их филиалов, ПКО предприятий, групп авторского надзора, субподрядчиков, контрагентов, поставщиков оборудования и групп 3D-моделирования.
5. Коллективная работа над проектом с возможностью автономных рабочих мест.
6. Комбинирование и обмен моделей из различных систем Plant Design с использованием поставляемых интерфейсов (Intergraph Smart3D, Aveva E3D, TEKLA Structures, Smart P&ID, Smart Isometrics и др.).
Разница между генерацией компонентов «на лету» (Hardcoded) и из XML-описания в PlantLinker практически незаметна. Именно это позволяет работать только с объектами в формате XML, что кардинально уменьшает размеры файлов. В этом PlantLinker резко отличается от других систем.
В отличие от вышеупомянутых западных САПР, в которых объектная модель построена на основе баз данных, объектная модель САПР PlantLinker построена на основе XML-файлов, что резко снижает затраты на административную работу, фактически обеспечивая как коллективную деятельность над проектом, так и возможность индивидуальной (в том числе удаленной) работы над частями проекта.
Поясним этот тезис более подробно. Все, кто имеет отношение к работе на системах Plant Design, не понимают, как может подобная система работать, не используя СУБД. Однако важным здесь является не СУБД, а объектная модель установки, которая может быть получена самыми разными методами.
В реальной жизни никто не работает одновременно на одной и той же части модели. Кто-то делает строительные конструкции, кто-то размещает оборудование, кто-то занимается трассировкой трубопроводов, а кто-то — лотками и вентиляцией. Каждый трудится над своей частью модели, а остальные части загружает по мере необходимости как референсные (то есть нередактируемые) модели и регулярно производит обновления как своей, так и чужих частей.
Поскольку при описании используемой технологии XML-файлы получаются небольшого размера, можно придумать много стратегий их применения. Например, держать на общем сервере компании под управлением администратора, забирать их домой либо в удаленную локацию и возвращать по готовности либо даже обмениваться по электронной почте или через файлообменные механизмы (рис. 5).
Рис. 5. Примеры моделей, созданных на САПР PlantLinker 
Рис. 5. Примеры моделей, созданных на САПР PlantLinker
Особенно это важно при информационном моделировании существующих объектов и реконструкции. Тут надо разделить работу по управлению облаками точек и работу по моделированию по облакам точек.
Самое главное, что PlantLinker обеспечивает рендеринг облаков больших размеров (100+ млрд точек) путем загрузки и подкачки облаков с носителей по необходимости.
Специальный модуль PlantLinker PmPoints (работает автономно) предназначен для подготовки облаков точек для работы в PlantLinker: преобразование форматов, сжатие, прореживание, вырезка необходимых частей, управление комбинациями вырезок.
Дополнительный модуль PlantLinker PMCloud (работает в среде PlantLinker) реализует моделирование оборудования, строительных конструкций, трубопроводов и лотков по распознанным объектам (рис. 6), обеспечивая:
Рис. 6. Моделирование по облакам точек
В этой части статьи мы попытались отметить те принципы разработки САПР PlantLinker, которые обеспечивают создание информационных моделей огромных технологических установок, сравнимых с комбинированной установкой по производству ароматических углеводородов КПА, параметры которой приведены выше. Подробно ознакомиться с функциональными возможностями САПР PlantLinker можно в статьях [3] и [4] и на сайте www.plantlinker.ru.
В продолжении статьи мы попытаемся сформулировать самые важные, на наш взгляд, критерии выбора платформы системы управления инженерными данными (СУИД).
Довольно часто приходится слышать мнение, что СУИД и машиностроительные системы PDM/PLM (управление структурой изделия и управление жизненным циклом изделия) — это одно и то же. Действительно, архитектура этих систем очень близка, но есть несколько фундаментальных и очень важных различий:
Вернемся к критериям выбора платформы для СУИД.
При работе в СИУД нам необходимо вести ряд параллельных структур — иногда на одних и тех же объектах, иногда на разных. Пример — классическая структура технологической установки: здание/сооружение — блок — зона — экземпляр оборудования (в западной терминологии — PBS). Однако оборудование входит в одну, а иногда и несколько систем, которые могут «пронизывать» разные здания/сооружения.
Тогда структура может приобрести, например, такой вид: система — подсистема — тип оборудования (основное/вспомогательное) — экземпляр оборудования (в западной терминологии — FBS).
Примером совершенно параллельной структуры является структура документации на установку, и при этом их тоже несколько: проектная, рабочая, исполнительная, эксплуатационная (в западной терминологии — DBS).
Между вышеперечисленными структурами (оборудование установки и документация) должны существовать горизонтальные связи (оборудование упоминается в документе).
Имеющиеся структуры и горизонтальные связи между объектами необходимо отображать в интуитивно понятном виде. Существует несколько общепринятых механизмов отображения (рис. 7):
Рис. 7. Примеры разнообразных структур и списков атрибутов
Рис. 8. Примеры отображения структуры трубопровода в паутинном графе
При этом во всех случаях требуется настройка способа отображения, включая задание уровня вложенности, фильтрацию, сортировку на каждом уровне и т.п.
Мы уже упоминали о различных форматах, используемых в СУИД.
При выборе платформы необходимо, чтобы она поддерживала работу с форматами, получившими в нашей стране статус «стандарта де факто». Это в первую очередь формат PDF, в котором отображаются многостраничные документы фактически из любых систем.
И несколько «условно открытых» форматов — Microsoft Office (DOCx, XLSx, PPTx) и Autodesk — DWG. Опережая вопрос про импортозамещение — с этими форматами работает огромное количество отечественных систем (PDFChef, Р7-Офис,nanoCAD и др.).
Теперь самое главное — обеспечение «интеллектуальности» 3D-модели и различных схем. Под схемами в данном случае понимаются схемы процессов, технологические схемы (P&ID-схемы), электрические схемы и схемы контрольно-измерительных приборов (КИП), а также изометрические схемы. Под «интеллектуальностью » понимается возможность позиционироваться на любой объект в 3D-моделях и схемах. Связь осуществляется с помощью уникального кода любого компонента (существующего в структуре СУИД, 3D-моделях и схемах), обычно называемого ТЕГ (рис. 9).
Рис. 9. Связь «интеллектуальных» 3D-моделей и схем со структурой установки и обычными документами
В статье [2] мы уже высказывали свою позицию — обсуждаемые и используемые в СУИД форматы должны быть открытыми. С нашей точки зрения, сегодня востребованы форматы IFC — для моделей строительных и технологических конструкций и STEP — для моделей оборудования.
Что касается разнообразных схем, то сегодня мы предлагаем использовать открытый формат SVG, но в настоящее время прорабатываем и работу с форматом PDF. Кстати, работа с интеллектуальными схемами в формате PDF обеспечит возможность придания «интеллектуальности » любому документу в этом формате.
При этом, поскольку сами установки очень большие, то и 3D-модели в формате IFC тоже весьма велики (20-90 Гбайт), а количество технологических схем на одной установке может быть более 200. И СУИД должен уметь работать с такими объемами.
При эксплуатации очень часто возникают задачи поиска необходимого объекта или объектов по самым разнообразным критериям. На самом деле, именно благодаря решению вопроса мгновенного поиска того или иного объекта/объектов и появляется экономическая выгода от создания и использования таких систем. Но важно искать объекты по довольно сложным запросам, например, найти все насосы мощностью больше 50 кВт, перекачивающие бензин и расположенные в определенных установках. А затем отсортировать их по увеличению мощности. Ну и отобразить (отфильтровать) только насосы, поставленные определенной компанией.
Выше мы обсуждали вопрос о различных форматах документов. То есть СУИД в качестве инженерных данных хранит документы. А это означает, что фактически СУИД должен реализовывать функциональность технического архива и документооборота (ТДО). Одним из важнейших требований к системам ТДО является необходимость хранить версии документов. А расширив эту функциональность на объекты и модели, отметим, что нужно хранить и версии объектов и моделей.
На самом деле, могут появляться и версии хранимых структур объектов (например, один теплообменник во время ремонта заменили на два — структура изменилась). Но это далеко не всегда востребовано — корректировка единичного объекта (документа) обычно порождает только его версию, но не приводит к новой версии объектов, вышестоящих в иерархии.
Итак, раз есть документы и их версии, то должен быть и документооборот — совместная разработка, согласование, утверждение и сдача в архив. Если эти процессы очень сложные, то возникает и необходимость создания разветвленных бизнес-процессов с последовательными и параллельными шагами, а иногда и выходящими за рамки СУИД (рис. 10).
Рис. 10. Пример бизнес-процесса согласования и утверждения комплекта документов
Поскольку СУИД связана не только с поиском и обработкой тех или иных объектов и документов, касающихся технологических установок, но и с рядом работ, связанных с их обслуживанием, ремонтами, модернизацией, очень часто требуется «перевязать» работы в календарных планах-графиках с объектами и документами, находящимися в СУИД.
Особенно это касается работ, требующих простоев установки (вывода из эксплуатации). Простои могут быть «плановыми» и «аварийными ». В первом случае требуется подробный план-график работ, а во втором — в первую очередь доступ к актуальной информации и план срочного устранения неисправностей.
И идея, которая витает над миром, — автоматическое окончание этапа работы при изменении статуса какого-то объекта, связанного с этой работой. Например, согласование и утверждение комплекта документов автоматически приводит к закрытию работы в плане-графике.
Достаточно часто мы сталкиваемся с необходимостью развертывать СУИД на промышленных площадках, территориально разнесенных друг от друга, например Москва, Санкт-Петербург, Омск.
Идеальным решением в этом случае является разворачивание центра обработки данных (ЦОД) в равноудаленной точке и удаленный доступ со всех планируемых (а иногда и случайных) площадок. Но такой подход требует очень надежно работающих и высокоскоростных каналов передачи данных, что не всегда реализуемо. Тогда принимается решение о разворачивании ЦОД на нескольких площадках и проведение обмена данных между ними. Простейшая репликация баз данных обычно неприемлема, да и не требуется (далеко не вся информация должна быть на всех площадках), поэтому необходима «интеллектуальная» или «объектная» репликация, то есть с осознанием того, что надо передавать, а что нет.
Также в этих условиях необходимы территориально распределенные бизнес-процессы и документооборот.
Требования импортозамещения налагают ограничения на используемые операционные системы и СУБД. В идеале всё должно работать на одном из клонов Linux (самые распространенные — Astra Linux, РЕД ОС, Альт Линукс) и на отечественной СУБД (с нашей точки зрения, фактически безальтернативно для наших задач — СУБД Postgres Pro).
Поскольку большинство платформ СУИД развивалось в традиционной парадигме (ОС MS Windows и СУБД MS SQL или ORACLE), то переход на импортозамещающие ОС и СУБД, мягко скажем, нетривиален. Тем не менее требование никуда не исчезнет.
В настоящее время оборудование в СУИД представлено как один компонент, обладающий тегом. В ряде случаев как несколько компонентов, каждый из которых обладает тегом (крупноблочная декомпозиция оборудования).
Но уже появляются запросы о том, чтобы включить в состав СУИД подробную информацию по оборудованию, машиностроительные 3D-модели оборудования, комплекты документов, то есть фактически — PDM/ PLM-систему с машиностроительным контентом по оборудованию.
В этом разделе мы расскажем о нашем выборе платформы для создания СУИД. Мы уже упоминали, что архитектура СУИД очень близка к архитектуре машиностроительных PDM/PLM-систем. Кроме того, мы подробно описали и основные различия.
Проанализировав состояние ранка отечественных PDM/PLM-систем, а также рынка систем технического документооборота (ТДО) и сред хранения общих данных (СОД) в секторе промышленного и гражданского строительства, мы пришли к выводу, что девяти критериям из десяти сформулированных выше отвечает система IPS Search (компания ОДО «Интермех», г. Минск).
Самая главная особенность — это очень гибкое управления структурами объектов и изделий. Именно это востребовано при создании СУИД, но не очень часто реализуется в альтернативных системах.
Форматы «интеллектуальных» моделей, которые не менее важны, чем управление структурами. Здесь мы предлагаем использовать два вьювера разработки компании «ПлантЛинкер»:
Рис. 11. Визуализация трубопровода в 3D-модели и интеграция с СУИД
Оба вьювера интегрированы с IPS Search (как на платформе Windows, так и на Linux), поддерживают «интеллектуальность» моделей и схем.
Функциональность PlantViewer 3D:
Функциональность PlantViewer 2D:
Рис. 12. Визуализация трубопровода в технологической (P&ID) схеме и интеграция с СУИД
Следует отметить, что использование PDM/PLM-моделей оборудования при выборе в качестве платформы IPS Search фактически реализуется автоматически.
Объем внедрения программных продуктов компании ОДО «Интермех» составляет более 4 тыс. предприятий России и СНГ. При этом IPS Search внедрялся в крупнейших промышленных холдингах страны (https://intermech.ru/). Этот аргумент окончательно убедил нас в правильности сделанного выбора.
Итак, на основе всего вышесказанного мы предлагаем использовать для информационного моделирования и проектирования технологических и промышленных установок:
Список литературы
