Сергей Голуб,
заместитель генерального директора по проектированию
ООО «Волгограднефтепроект»
Чем больше мы говорим об информационном моделировании, тем отчетливее становится видна разница между двумя основными подходами в этой работе: моделирование самого объекта и моделирование реализации этого объекта. Можно рассматривать как связанные задачи, можно идти независимо. Но есть единый источник, на котором базируются оба подхода — декомпозиция. И от качества этой декомпозиции во многом зависит применимость и использование результата моделирования как при проектировании и реализации объекта, так и при эксплуатации.
Первая ассоциация, зачастую возникающая не только у обычного человека, но и моделировщика «в законе», связанная с информационным моделированием, — это графическая модель объекта, в основе которой лежит некая иерархия или структура, из которых ее по кусочкам собирают или визуализируют, с правильным интегрированием в нее элементов и оборудования из трехмерных каталогов, с некими заполненными атрибутами. Следом напрашивается еще один вопрос: «А кто потребитель этой модели?» Отвечая на него, начинаешь по цепочке раскручивать нить желаемой информации, которую нужно разместить в модели. И не просто информации, а определенным образом подготовленной. Тут же многим приходит на ум оригинальная мысль: «Можно делать, как умеешь или как хочешь, потом алгоритмы искусственного интеллекта всё разложат по полочкам!» А вот по каким полочкам, кто их должен определить и на основании чего… В общем, пока что можно с уверенностью утверждать, что если на входе в любую информационную систему у вас будут терабайты макулатуры, то на выходе будут те же терабайты той же самой макулатуры. Даже для алгоритмов искусственного интеллекта нужны отправные точки, на основании которых будут накапливаться база знаний и строиться языковые модели.
Вернемся к потребителям модели. Сразу выведем за скобки чисто визуальную составляющую, поскольку с красивыми «трехмерками» работать уже научились многие. Но немногие готовы выйти из парадигмы, что трехмерная модель и есть цель моделирования. Изначально нацеленность моделирования была на эксплуатацию. Выглядит всё логично — изучение объекта службами эксплуатации, возможность видеть через модель оборудование и его параметры, необходимую документацию, строить планы по обслуживанию и перемещению оборудования при ремонтах, готовить задание на перевооружение и реконструкцию. Но в основе этой цели лежит та же визуализация.
Работа с моделью данных
Работа с конструктором связей
Работа с конфигуратором иерархии проекта
Давайте же объективно посмотрим, какая модель обычно приходит в эксплуатацию и что с ней происходит дальше. Проектировщик сформировал прежде всего модель, которая решает его задачи по выпуску документации и закрытию выполненных им этапов работ. А потом идут тендерные и закупочные процедуры, строительство, наладка и… множество изменений. Что-то из них может быть отражено в модели, что-то — нет. Но задаваемые темпы разработки документации и строительства зачастую не дают возможности адекватно актуализировать модель — у всех свои KPI. Но вот некая модель все-таки добралась до служб эксплуатации. И ею даже научились пользоваться — ходить по модели, искать нужные элементы, оборудование и параметры, открывать документацию, использовать ее в качестве исходных данных для системы технического обслуживания и ремонтов оборудования. Но эксплуатация прежде всего должна работать с физическим объектом, на котором зачастую происходят изменения, улучшения, реконструкции, поэтому модель требует актуализации и начинает устаревать. А для актуализации моделей нужен ресурс и, кроме того — проект на техническое перевооружение, реконструкцию, расширение производства и т.д. А там вновь проектировщик, вновь документация… Конечно, есть механизмы лазерного сканирования, фотометрии. Но тут каждый выбирает сам, готов ли он этим пользоваться и ждать необходимого результата.
Теперь давайте посмотрим на подрядчика по строительству. Что для него важно: объемы работ, планирование и минимизация простоя, понимание ресурса и инструментов и т.д.? Дает ли эту информацию модель проектировщика? В общем случае в ней что-то есть, и даже в чем-то она может быть полезна. Но без доработок не обходится, а также без поддержания ее в актуальном состоянии при строительстве. Примерно то же можно говорить и про закупки.
Работа со структурой проекта
Работа со справочником
Журнал событий
Остается у нас проектировщик, на которого в итоге ложится груз ответственности по разработке модели и которому предъявляются требования по ее доработке. И получается, что, помимо своей части принятия проектных решений, моделирования и выпуска документации, ему необходимо в этот же период времени (который, как мы знаем, имеет свойство еще и ужиматься ради ускорения «на бумаге» сроков реализации проекта) выполнить дополнительные и не очень ему понятные требования. Можно ли как-то совместить эту работу, чтобы она не вызывала подобной реакции? Безусловно. Нужно всего лишь рассматривать проектировщика как такое же звено в цепочке реализации проекта, как и службу закупок, подрядчика по строительству, наладчиков. То есть исходная информация для проектирования и реализации проекта должна быть единой и лежать в основе всех активностей. Отсюда простой, но фундаментальный вывод — моделирование начинается не с разработки трехмерной модели, а с понятной декомпозиции объекта на составляющие элементы, зоны, системы, сооружения и т.д., которыми будут оперировать при выполнении работ все участники реализации проекта, включая заказчика. Кто будет делать эту декомпозицию: проектировщик или отдельная специализированная компания, а может, и сам заказчик или его службы — не так важно. Главное — она для всех должна быть единой. При этом должно четко отслеживаться, чего не хватает, чтобы выполнить те или иные задачи. Таким образом, декомпозиция в какой-то мере закладывает механизм реализации и контроля реализации проекта. Тогда можно просто и наглядно проследить соответствие: линия технологического процесса — узел (зона или выделенное место будущего объекта, часть линии техпроцесса) — комплект разрабатываемой документации — единица (или файл, в зависимости от программного обеспечения) трехмерной модели — монтажная спецификация — ведомость заказа материалов и оборудования — лот (партия или несколько партий) на поставку материалов, изделий — строка в графике выполнения строительно-монтажных работ — фиксированный, понятный объем работ — стоимость работ — приемка и закрытие работ — часть объема работ по наладке (опять же в графике) — пакет исполнительных документов — приемка в эксплуатацию. А если эта приемка сопровождается еще и наличием трехмерной модели, актуализированной по всем изменениям в процессе строительства, то мы получаем цифровой актив объекта. О чем мы и писали в наших предыдущих публикациях.
Так что же мы все-таки моделируем? Как бы это громко ни звучало, но моделируем мы именно процесс, механизм реализации проекта, механизм мониторинга состояния проекта в любой момент времени при его реализации. При этом моделирование самого объекта — это часть общего механизма. Более того, само проектирование при таком подходе также является частью этого механизма. То же самое можно проделать и в части поставок, строительства… Не самих, конечно, физических процессов, а их организации, анализа результатов и оперативных корректировок, если что-то пошло не так.
В таком свете информационное моделирование играет новыми красками. И ООО «Волгограднефтепроект» с уверенностью смогло доказать, что не просто играет, это действительно работает, это действительно помогает каждому участнику реализации проекта вести свою деятельность и взаимодействовать между собой, поскольку всё вписывается в общую стратегию получения искомого результата.
Планирование СМР в формате 4D
Чем сложнее объект, чем насыщеннее он инженерными коммуникациями, чем больше в нем участников (проектировщиков, подрядчиков), тем эффективнее и востребованнее становится применение таких технологий информационного моделирования. Звучит и выглядит очень заманчиво. И, с высокой степенью вероятности, последует справедливый вопрос: «В чем же здесь подвох?» Этот вопрос можно и нужно переформулировать: «Что для этого необходимо сделать?» Ответ уже звучал в данной статье, и он очень прост. Начинать нужно с декомпозиции объекта, то есть с разделения его на простые и понятные составляющие части по двум основным признакам: технологическому и территориальному. Технологическое разделение основано на технологическом процессе, его автоматизации, обеспечении ресурсами, его безопасности и пр. Территориальный признак определяется технологией и технологичностью монтажа, возможностью вести работы одновременно или последовательно, готовностью определенных частей к последующим работам и т.д. Получив две иерархии объекта, мы благополучно соединяем их и кладем в основу всей информации и всех работ по объекту, начиная с проектных и заканчивая пусконаладкой. И на это нужно время, причем работа может быть (а в идеальном случае и должна быть) совмещена с разработкой основных технических решений. На практике это может происходить и на более поздних стадиях — после разработки проектной документации в рамках реинжиниринга проекта, например. Но цель остается неизменной — подготовить основу для организационного взаимодействия участников и прозрачности движения по проекту.
Работа с замечаниями в ИМАК
Именно такой подход ООО «Волгограднефтепроект» и реализует при выполнении своих проектных работ. При этом стоит учитывать, что в данном случае компания после разработки проекта и документации на строительство сопровождает СМР и закупочные процедуры до самого ввода объекта в эксплуатацию. И здесь подобный уровень декомпозиции очень востребован. Так, после того как была выстроена иерархия морской добывающей платформы по функциональному (технологическому) и территориальному признаку, был сформирован состав документации для разработки. Каждому комплекту такой документации соответствовал конкретный файл 3D-модели, из которого выгружалась спецификация. Часть спецификаций собиралась в ведомости заказа материалов, по которым проводились тендерные процедуры и определялись партии поставок. Сами файлы 3D-модели, а также разработанная на их основании документация еженедельно публиковалась на доступном для заказчика и подрядчика портале (ИМАК — информационная модель актива. Об этой платформе, разработанной ООО «Волгограднефтепроект», было рассказано в предыдущих публикациях журнала). Помимо онлайн-мониторинга разработки проекта на основе ИМАК, проводились совещания и принимались необходимые решения.
Наложение 3D-модели на физический объект
Далее каждый комплект документации, а соответственно, и файл 3D-модели, и спецификация соотносились с конкретной записью в графике СМР, с конкретными объемами работ. Это означает, что видна четкая зависимость между необходимостью поставки материала, выпуском документации и возможностью выполнять те или иные строительные работы. График в виде 4D-модели, с объемами и составом материалов для выполнения каждой работы, постоянно актуализировался в разрезе план/факт.
На этом этапе как раз и произошло расширение функционала ИМАК возможностью вести онлайн и актуализировать 4D-модель с отражением плана работ на неделю и выполненного за этот период «факта». Всё в интуитивно понятной цветовой гамме по статусам.
Изменения сопровождают всю нашу жизнь, включая и проектную деятельность. В 2023 году ООО «Волгограднефтепроект» приобрело инструментарий смешанной реальности отечественной компании «БРИО МРС», основанный на наложении проектной 3D-модели на физическую модель построенного (или находящегося в процессе строительства) объекта с отображением результата наложения на экране устройства. И в этом году ИМАК был снова расширен функционалом БРИО: произведена интеграция платформ и доказана эффективность применения такого решения. Осуществлялись периодические выезды на объект со съемкой фактически построенных частей объекта с наложением на 3D-модель, созданием пометок к элементам модели и последующим их отображением в ИМАК у сотрудников в офисе. Это позволило оперативно решать вопросы, не только возникающие в процессе монтажа, но и те, что только предстояло получить. Далее прорабатывались решения с публикацией на портале и обсуждением дальнейшего движения по подобным вопросам.
Описанный процесс показывает применение уже сформированной декомпозиции объекта. Процесс же формирования самой декомпозиции, включая состав необходимых для разработки документов, 3D-моделей и, может, для кого-то это будет неожиданным, структуры графика СМР (известной как WBS), происходит уже после проработки основного технологического процесса и необходимых для него ресурсов с присутствием элементов творчества занимающихся данной работой специалистов. И этот процесс тоже оказалось возможным оптимизировать и автоматизировать.
Сегодня в ООО «Волгограднефтепроект» совместно с компанией ООО «Эмбедика» активно разрабатывается автоматизированная система формирования декомпозиции по объекту и генерирования на основании этой декомпозиции состава документации. Рабочее название будущего продукта — СтРИМ (структурная разметка инженерной модели). Результат использования данного алгоритма будет служить отправной точкой для всех вышеописанных процессов, в том числе и для настройки визуализации в ИМАК.
Подходы и механизмы информационного моделирования не стоят на месте, с каждым реализованным проектом возникают новые идеи, появляются новые возможности. Так, например, получилось с БРИО или СтРИМ, с расширением возможностей и функционала ИМАК. Но и существующие механизмы моделирования, и работы с моделями заслуживают более детального повествования. Там тоже много интересного. Но это уже совсем другая история, о которой вы, возможно, узнаете в следующих выпусках.
