Технология и методология работы с 3D-моделями в среде общих данных строительного проекта

Перечень сокращений

ОКС - объект капитального строительства

ИМ - информационная модель

ТИМ - технологии информационного моделирования

СОД - среда общих данных

ОКС - объект капитального строительства

ИСП - инвестиционно-строительный проект

ЦИМ - цифровая информационная модель

ИИ - инженерные изыскания

SaaS, software as a service - программное обеспечение как сервис

ПО - программное обеспечение

ИТ - информационные технологии

ЦОД - центр обработки данных

СКУД - система контроля и управления доступом

CAD - система автоматизированного проектирования (САПР) (англ. Computer-aided design (CAD))

Введение

Технологии информационного моделирования (ТИМ) находят всё большее применение в строительной отрасли России и мира. ТИМ предполагают формирование информационных моделей объекта капитального строительства (ОКС). Информационная модель (ИМ) ОКС может быть представлена в виде 3D-модели.

О способах формирования и работы с 3D-моделью в среде общих данных (СОД) проекта ОКС пойдет речь в данной статье.

Существует два принципиально разных способа формирования 3D-модели ОКС в СОД.

Первый способ предполагает передачу в СОД уже собранной сводной 3D-модели, для последующей работы (рассмотрения и согласования). Модель предварительно собирается внутри CAD-системы, в которой она была подготовлена, или в специализированных инструментах, и целиком передается в СОД. Такой способ работы предлагается, ныне ушедшей с рынка РФ, компанией Autodesk.

Второй способ предполагает сборку сводной модели непосредственно в СОД. Части 3D-модели передаются из различных CAD-систем, в которых они были подготовлены, в IFC-формате. Сборка сводной 3D-модели производится средствами СОД, предлагающей инструменты для дальнейшей работы со сводной моделью.

Рассмотрим подробней достоинства и недостатки каждого из способов.

Первый способ формирования сводной трехмерной цифровой информационной модели - сборка в САПР

Этот способ работы присущ методике, предлагаемой некоторыми иностранными вендорами. Рассмотрим его на примере методики наиболее популярного в строительной отрасли вендора Autodesk.

Сборка модели объекта строительства происходит в CAD-системе на этапе, следующем за этапом ее моделирования.

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

Далее сотрудник производит синхронизацию моделей с удаленным сервером и, таким образом, передает их в СОД в готовом виде, с определенным набором моделей, их атрибутов и элементов.

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

Схема работы с использованием продуктов компании Autodesk, в общем виде, представлена на рисунке 1.

Достоинства

1. Одинаковые наборы моделей для всех пользователей

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

2. Внесение изменений напрямую в исходных файлах

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

3. Централизованная модель

Настройка синхронизации и обновления моделей позволяет исполнителю обновлять модели, находящиеся в общем доступе централизованно - одновременно для всех пользователей, их устройств и доступных им моделей.

Недостатки

Эта модель работы, используемая иностранными вендорами (в первую очередь, компанией Autodesk, продукты которой получили наибольшее распространение) имеет ряд критических недостатков.

1. Необходимость в мощных аппаратных средствах

Это обусловлено тем, что ПО линейки Autodesk, и других иностранных вендоров, имеющих в своем ряду САПР, нагружает работой с графикой и расчетами рабочий компьютер довольно сильно. Происходит это в случае работы по изменению моделей (моделирование). Не каждый компьютер в состоянии воспроизвести профессиональные 3D-модели строительных объектов и быть использованным для внесения изменений в эти модели. Даже в случае использования системы BIM 360 вендора Autodesk рекомендуется использовать компьютер с выделенной видеокартой, в случае же работы с CAD-системами этого вендора потребуется профессиональное оборудование.

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

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

2. Высокая нагрузка на каналы связи

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

Согласно ПП РФ № 331, технологии информационного моделирования обязательно должны использоваться во всех строительных проектах с государственным участием, а это, в числе прочих, объекты, чрезвычайно удаленные от комфортных условий для создания каналов высокой пропускной способности. Трудно представить, как можно организовать коллективную работу с такими большими моделями в СОД между строителями и проектировщиками в условиях крайнего севера при строительстве объектов северного широтного хода, например.

Это касается и жилых объектов. Нестабильное покрытие мобильной сети, которое может быть использовано для работы с СОД, наблюдается даже на стройках в черте городов.

3. Работа с проприетарными форматами данных

Описываемый подход требует использования одной и той же модели одного и того же формата каждым участником проекта. Следовательно, потребуется закупать линейку продуктов именно того вендора, которому принадлежит конкретный формат. Это касается и САПР для моделирования, и СОД, и всего прочего ПО, которое может понадобиться в работе над стройпроектом. Все это существенные затраты, причем эти затраты ложатся на каждого из участников проекта. Дополнительная сложность заключается в том, что состав участников проекта может меняться даже в то время, когда проект уже идет. Поэтому требование по наличию одинакового набора программных средств у каждого участника очень сложно реализовать на практике. Для осуществления такой схемы работы придется закладывать требования по наличию определенного программного обеспечения в тендерные условия, что противоречит законодательству..

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

4. Угроза информационному суверенитету

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

5. Большие временные затраты на загрузку моделей

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

6. Риск работы с неактуальными данными

Схема работы при обновлении моделей на общем сервере построена на действиях человека, соответственно, она подвержена рискам вследствие человеческого фактора.

Есть риск не обновить вновь измененную модель и тогда актуальные данные не поступят в работу остальным участникам проекта.

7. Громоздкость при версионировании моделей

Каждое малое изменение данных порождает новую версию всей модели, которая размещена в одном файле.

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

На стадии активного проектирования и согласования поток изменений будет порождать много значимых версий моделей. Поскольку все их необходимо хранить в СОД вместе с историей их разработки, это приводит к появлению большого количества моделей, которые требуют регулярного увеличения объема дискового пространства для хранения.

Подытожим, очертив круг основных проблем, имеющихся у применимого сегодня варианта работы с 3D в СОД. Эти проблемы требуется решить:

• необходимость мощных аппаратных средств для работы с 3D внутри СОД

• высокая нагрузка на каналы связи во время передачи больших 3D-моделей

• работа с проприетарными форматами данных

• зависимость от иностранных поставщиков

• высокие затраты времени на загрузку и открытие моделей

• риск работы с неактуальными данными

• объемные модели при версионировании моделей

Представители:

Autodesk Construction Cloud (BIM 360).

Второй способ формирования сводной трехмерной цифровой информационной модели - сборка в СОД

Ответом на перечисленные выше вызовы является принципиально иная модель работы с высоконагруженными 3D-моделями.

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

Ключевая идея подхода заключается в том, чтобы собирать и просматривать сводную междисциплинарную модель универсального формата (IFC) внутри СОД в том виде и количестве моделей, которое необходимо в конкретный момент времени. Это означает, что нет необходимости передавать коллегам всю большую модель для того, чтобы попросить их проверить или внести изменения в какие-то конкретные ее части. Достаточно предоставить доступ сотруднику к определенному файлу, который хранится в СОД сам по себе, без привязки к центральной модели.

Центральной модели в том смысле, под которым понимаются такие модели в Autodesk, в описываемой методике не существует. Вместо этого предлагается работать с файлами моделей, хранящимися на сервере в любых папках, любых разделах и в документах любых рабочих групп. Достаточно выборочно предоставить доступ пользователям или группам пользователей к необходимым им моделям. Это значительно повышает уровень безопасности информации в проекте.

В отличие от работы по методике Autodesk, в этом случае не нужно регулярно обновлять свои модели и переживать об актуальности данных центральной модели на сервере, с которыми будут работать коллеги. Именно обеспечение работы исключительно с актуальными данными является краеугольным камнем и целью предлагаемой методики. Эта работа обеспечивается правильно настроенными цепочками поставок данных.

Достоинства

1. Возможна работа в любой САПР

Прежде всего стоит отметить, что работа по созданию модели происходит в любой удобной исполнителю САПР. Нет никаких обязательств по использованию одного единственного инструмента всеми участниками проекта. При этом необходимо отметить, что в реальной практике сложные проекты производятся в разных САПР-системах. Главное, что результаты труда должны быть экспортированы в независимом от вендоров формате. Например, это может быть IFC, который на сегодняшний день является наиболее применимым форматом для подобных данных. Он постоянно совершенствуется и большинство САПР предоставляют возможность экспорта в этом формате.

Далее, созданная модель, а точнее конкретная часть общей модели, за которую отвечал конкретный сотрудник, отправляется в общий доступ - в СОД. На этом этапе привлекаются коллеги для проверки и согласования, а также иные участники проекта для совместной работы. Сейчас не будем останавливаться на процессе работы внутри СОД, это тема освещена в статье «Формирование экономических обоснованных требований к средам общих данных». Нам же важно отметить, что модели, загружаемые в СОД, являются частями общей модели и их объем небольшой.

2. Работа доступна на любых непрофессиональных устройствах

Проблемы, связанные с необходимостью в мощном аппаратном и программном обеспечении, могут быть решены за счет технологий СОД.
В случае если это сервис, предоставляемый по модели SaaS, то исчезает необходимость в закупке, настройке и обеспечении работоспособности серверных мощностей для работы с высоконагруженными моделями.
Если СОД это web-сервис, то можно использовать его на любых устройствах, избежав закупки мощных гаджетов. Достаточно поддержки работы браузера.

3. Возможность размещения системы в полностью закрытом цифровом контуре

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

Эти продукты должны соответствовать высоким требованиям к безопасности хранения информации, которые предъявляются российскими службами и ведомствами: ФСБ, ФСТЭК, Минкомсвязи.

Ни один из иностранных продуктов не способен соответствовать этим требованиям.

4. Быстрая передача моделей по имеющимся каналам связи

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

5. Сокращение времени, необходимого на открытие сводных междисциплинарных моделей

Также мы экономим время на открытие моделей, т.к. можем выбирать для отображения именно те элементы модели, с которыми планируем работать непосредственно в данный момент.

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

6. Высокий уровень безопасности данных

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

Недостатки

1. Отсутствие бесшовной интеграции САПР-СОД-САПР

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

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

Со временем новые интеграции будут появляться для всех продуктов.

2. Потеря данных при экспорте в IFC

На сегодняшний день формат IFC является наиболее универсальным и приемлемым для экспорта данных из САПР-систем.

Этот формат не является идеальным и при экспорте возможны потери данных. Однако, с этим же форматом работают все вендоры, это не недостаток именно российских систем, иностранные тоже работают с ним. Сам этот формат постоянно развивается и модернизируется и в будущем потери данных должны минимизироваться.

Если будет разработан новый более качественный формат, то все СОД должны перейти на работу с ним. В любом случае, универсальные форматы являются более верным способом работы с данными, чем проприетарные.

Представители

К представителям можно отнести многих российских вендоров с их продуктами: «Ингипро», CSoft (CADLib), Аскон (Pilot BIM), Sarex и др.

Заключение

В статье мы рассмотрели 2 принципиально разных подхода к работе со сводной 3D-моделью внутри СОД строительного проекта.

Проанализировав преимущества и недостатки каждого из подходов можно сделать вывод:

• первый подход больше подходит для небольших команд и проектов, когда все виды работ от проектирования до строительства сосредоточены внутри одной компании. При этом требования по безопасности отсутствуют. Если не брать в расчет то, что Autodesk ушел с рынка РФ и запретил использование своих решений, возможно какие-то компании смогут использовать решения этого вендора на свой страх и риск или найти иного поставщика.

• второй подход является более универсальным, при этом он ближе к реальным требованиям, которые возникают в практической работе. В больших комплексных проектах используется широкая номенклатура САПР для различных дисциплин от разных вендоров. В таких проектах работать в САПР от одного вендора с моделями не представляется возможным. Этот подход позволяет заказчикам и исполнителям выбирать тот софт, который им больше подходит и выстраивать требуемый уровень автоматизации работ и безопасности данных. При этом он более предпочтителен по затратам на ПО и техническое оснащение участников проекта. Фактически для строительной отрасли РФ он становится безальтернативным.