В статье подробно разбирается функционал BIM-системы Renga, который позволяет правильно подготовить информационную модель с учетом различных требований региональных госэкспертиз и успешно пройти экспертизу проекта.
Развитие информационных технологий в строительстве
К 2020 году цифровизация стала приоритетным направлением развития строительной отрасли. В планах Минстроя РФ — до 2030 года полностью перейти на обязательное применение технологии информационного моделирования (ТИМ) при создании и эксплуатации объектов капитального строительства (ОКС), а в первоочередном порядке уже к 2024 году — в социальной сфере.
В подготовленной «Стратегии развития отрасли»1 запланировано двукратное увеличение доли проектных организаций, применяющих на практике ТИМ, а кроме того, более чем в десять раз должна увеличиться доля проектов ОКС, имеющих цифровую информационную модель (ЦИМ) — табл. 1.
Таблица 1. Целевые показатели по направлению «Цифровизация строительной отрасли»
№ |
Наименование |
2020 |
2024 |
2030 |
1 |
Доля проектных организаций, применяющих на практике ТИМ, % |
24 |
45 |
50 |
2 |
Доля строящихся и реконструируемых ОКС, имеющих ЦИМ, % |
5 |
20 |
65 |
3 |
Удельный вес осуществления в электронной форме процедур, |
30 |
70 |
100 |
Таблица 2. Целевые показатели по направлению «Инновационное развитие института строительной экспертизы»
№ |
Наименование |
2020 |
2024 |
2030 |
1 |
Доля экспертных организаций, интегрированных в ЦС ИСЭ, % |
0 |
25 |
90 |
2 |
Доля проектов, по которым осуществляется комплексное экспертное сопровождение (для особо опасных, технически сложных и уникальных объектов капитального строительства) |
10 |
50 |
70 |
3 |
Доля документации, представленной на экспертизу и разработанная с применением ТИМ, % |
5 |
30 |
50 |
Уже сегодня развивается институт государственной экспертизы. Экспертиза начинает проверку проектов ОКС в формате ЦИМ. Согласно «Стратегии развития», доля проектов, представленных на госэкспертизу и разработанных с применением ТИМ, должна вырасти с 5% (на сегодняшний день) до 50% к 2030 году (табл. 2).
В настоящее время мы с вами находимся в самом начале этой трансформации. То, что она неизбежно произойдет, — нет никакого сомнения. Поэтому все мы должны быть к этому готовы. Вы, как проектировщики, — к применению ТИМ во всех сферах деятельности, а мы, как разработчики BIMсистемы Renga, — к созданию удобного и востребованного инструмента, который будет вам помогать.
В данной публикации мы рассмотрим очень важную тему: подготовку в Renga цифровой информационной модели (ЦИМ) к госэкспертизе согласно ее требованиям. Автор предполагает, что вы уже знакомы с ТИМ и владеете терминологией 2 . Но сначала рассмотрим проблематику вопроса в условиях текущих реалий.
Прохождение ИМ в госэкспертизе
На сегодняшний день законодательством еще не утверждены требования к составу и формату ИМ. Постановление Правительства РФ подготовлено и планируется к подписанию. Пока прохождение государственной экспертизы в формате ЦИМ является добровольным, за редким исключением из правил, когда заказчик сам включает это требование в договор (в случае больших и ответственных проектов и/или с привлечением государственного финансирования). В связи с этим требования к ЦИМ, проходящим государственную экспертизу, формируют сами органы госэкспертизы добровольно, с учетом специфики работы в собственном регионе РФ. Тут мы подходим к первой проблеме: требования разных экспертиз к составу ЦИМ различны. Но, прежде чем мы более детально посмотрим в глубь этих требований, стоит отметить схожие моменты:
- для прохождения государственной экспертизы в формате ЦИМ у всех экспертиз требуется предоставить модель в формате IFC (не ниже версии 4.0)3 ;
- требования различных экспертиз применяются только к моделям зданий социальной сферы, то есть к зданиям следующего функционального назначения (по моделям зданий иного назначения госэкспертиза в формате ЦИМ не проводится):
- административноделовые объекты,
- многоквартирные дома,
- амбулаторнополиклинические объекты,
- учебновоспитательные объекты.
Для наглядности возьмем актуальные (на дату написания статьи) требования двух госэкспертиз: ГАУ «Московская государственная экспертиза» и СПб ГАУ «Центр государственной экспертизы» — и на небольшом примере посмотрим, какие требования предъявляются к параметрам одного типа объектов — перекрытиям (рис. 1).
Рис. 1. Требования к параметрам перекрытий различных госэкспертиз
Обе экспертизы довольно четко указывают требования к составу атрибутов, группировке атрибутов по соответствующим наборам свойств, именованию атрибутов, типам данных и заполнению значений атрибутов. Но, как можно видеть на иллюстрации (см. рис. 1), атрибутивный набор и наполнение элементов различное. Нам, как разработчикам ПО, необходимо учитывать это при создании инструмента, который должен быть гибким, отвечать требованиям отдельных экспертиз, а также соответствовать другим сценариям экспорта модели.
Еще одним важным моментом в прохождении госэкспертизы является создание базовой модели, в которой должны быть смоделированы строительные объемы надземной и подземной части и размещены зоны для функционального зонирования и подсчета основных ТЭП (площади этажей, пожарные отсеки, общая площадь, площадь застройки и т.д.). Вообще, эта тема заслуживает отдельной статьи4 . Мы же рассмотрим требование к параметрам базовой модели5 , которое обязывает проектировщиков наполнять ЦИМ (далее — модель) сущностями, которые не имеют физического представления:
Эти сущности должны быть наполнены данными о самом проекте:
- общие данные;
- основные характеристики;
- требуемые показатели ОКС;
- проектные ТЭП;
- климатические и геотехнические данные и т.д.
О том, каким образом выполнять это требование, мы поговорим далее, а пока рассмотрим последнее (но не последнее у госэкспертизы), очень важное требование — это отсутствие коллизий между элементами модели. Цитата из требований Мосгосэкспертизы 6 : «…не допускаются проектные ошибки (коллизии), превышающие 15 мм, вызванные геометрическими пересечениями элементов…»
Этот момент тоже был учтен при разработке функционала по экспорту в IFC. И теперь самое время перейти к части, в которой речь пойдет о том, как выполнить названные требования в Renga с учетом нового функционала.
Решение в Renga
Мы подошли к сути статьи и начинаем рассмотрение нового функционала Renga. Поздравляю тех, кто дочитал до этого момента! Но впереди будет еще больше технической информации, поэтому будьте готовы! Прежде всего это касается BIMменеджеров и инженеров отделов САПР, тех, кто по роду своей деятельности будет готовить модели к экспорту.
Хочу сразу сказать, что решения, о которых пойдет речь, — не теория, а реальная практика. К моменту, когда вы читаете эту статью, у нас уже наработан опыт подготовки моделей к экспертизе по требованиям как Мосгосэкспертизы, так и СанктПетербургской госэкспертизы. Поэтому отнеситесь к этой статье как к инструкции по прохождению. Чтобы вся информация была понятна, згляните на схему работы с моделью (рис. 2). Мы пойдем постепенно — от первого пункта к последнему.
Рис. 2. Схема работы с моделью для экспорта в IFC4 по правилам госэкспертизы
I. Подготовка модели к экспорту
Информация о проекте
Как мы выяснили ранее, модель должна содержать данные по проекту. Для этого в Renga были добавлены следующие сущности (в скобках обозначены соответствующие классы IFC): Проект (IfcProject), Участок (IfcSite), Здание (IfcBuilding):
Доступ к этим сущностям можно получить через реорганизованное меню Управление стилями (рис. 3).
Рис. 3. Информация о проекте включает информацию о проекте, участке и здании
Параметры разделены по трем вкладкам: отдельно для проекта, участка и здания. Кроме того, у пользователей есть возможность расширять эти сущности произвольным количеством пользовательских свойств, тем самым внося всю информацию о проекте, требуемую госэкспертизой.
Работа с пользовательскими свойствами
В идеале мы стремимся к тому, чтобы экспертиза проекта проходила в автоматизированном режиме. Чтобы правильно интерпретировать данные модели, все ее атрибуты должны иметь определенный тип данных, которые описаны в IFC. Именно их и требует экспертиза. Создавая новое пользовательское свойство, мы должны назначить ему нужный тип данных.
С учетом вышесказанного, в Renga был расширен список типов данных, которые пользователь может использовать. К существующим ранее типам «Строка» и «Действительное число», добавились:
- Целое число;
- Длина;
- Площадь;
- Объем;
- Угол;
- Масса;
- Булевый (принимает только два значения: «Да» или «Нет»);
- Логический (три значения: «Да», «Нет», «Не определено»);
- Перечисление (список заранее определенных значений).
Имея под рукой такой набор типов, у пользователя не возникнут проблемы с интерпретацией данных его модели при экспорте в сторонние программы. Работа с пользовательскими свойствами осуществляется в меню Свойства объектов (рис. 4).
Рис. 4. Создание нового свойства в меню Свойства объектов
Свойства можно назначать как на экземпляры объектов (уникальные для отдельно взятого объекта, например «Сопротивление теплопроводности»), так и на стили объектов (общие для объектов данного стиля, например «Класс взломостойкости»). Добавив в проект свойства и назначив их на соответствующие типы объектов, переходим к заполнению этих свойств у каждого объекта. Это кропотливая работа, но в Renga предусмотрено достаточно функционала, чтобы максимально ускорить этот процесс. Об этом уже было много написано и сказано 7 , поэтому останавливаться на этом не будем.
Переопределение типов объектов при экспорте
Поскольку экспертиза ИМ проходит в формате IFC, то все объекты модели должны быть экспортированы по соответствующим классам, описанным в IFC. Стандартное модельное представление Reference View 1.2 (IFC4 RV1.2)8 , в соответствии с которым сформированы требования госэкспертизы, описывает 16 классов архитектурных элементов здания, 12 классов конструктивных, 65 классов элементов внутренних инженерных систем, в совокупности по основным специальностям (водоснабжение/водоотведение, отопление, вентиляция, электрика, автоматизация) и еще 18 дополнительных классов элементов, к которым относятся, например, помещения (IfcSpace) или уже рассмотренный нами класс — здание (IfcBulding). Итого более 100 классов! Возникает резонный вопрос: как всё это многообразие замоделировать имеющимися инструментами? Ответ простой — моделируйте так, как вам удобнее. Мы переопределим класс объекта при экспорте!
Рассмотрим пример, как мы это можем сделать с архитектурными элементами. Согласно требованиям, напольное покрытие (полы) должно быть выгружено в IFC под классом IfcCovering, а например, наружный навесной вентилируемый фасад — под классом IfcCurtainWall. Таких кнопок в Renga пока нет, но они и не нужны (для задачи прохождения госэкспертизы). Можно смоделировать полы отдельным перекрытием (даже нужно), а наружный фасад — второй стеной со своими слоями конструкции.
Затем для объектов модели, класс которых мы хотим переопределить, необходимо добавить следующие пользовательские свойства (тип данных — строка):
- IfcEntityType — свойство, необходимое для переопределения класса объекта;
- IfcObjectType — свойство задается только в том случае, если пользователь задал предопределенный тип USERDEFINED.
Эти два свойства в IFC описывают класс элемента и уточняют его тип (в соответствии с описанием класса). Эти свойства обязательны при переопределении, и если им будут присвоены значения, то объекты экспортируются под новым классом и типом (рис. 5).
Рис. 5. Свойствам IfcEntityType, IfcObjectType и IfcName заданы нужные значения, поэтому при экспорте у этих объектов будут переопределены класс, тип и имя
Кроме них, в Renga можно переопределять следующие параметры IFC:
- IfcTag — соответствует параметру объекта Марка;
- IfcName — применяется для указания короткого имени или номера объекта;
- IfcLongName — используется для указания полного имени объекта;
- IfcDescription — описание объекта.
Это очень мощный инструмент. Единственное, что от вас требуется, — это разобраться в описании классов IFC. Тут у вас под рукой обязательно должен быть справочник IFC9 .
II. Настраиваемый экспорт в IFC4
Мы подготовили модель к экспорту и подошли к моменту, когда нам уже нужно нажать кнопку «Экспорт в IFC», но не торопитесь! Далее нам потребуется сделать еще один очень важный шаг — указать Renga, по каким наборам свойств/параметров/расчетных характеристик будут выгружаться данные по тому или иному типу объектов.
Сопоставление параметров при экспорте (маппирование)
Помните иллюстрацию, где мы сравнивали требования к перекрытиям от двух экспертиз (см. рис. 1)? Мы должны не просто выгрузить заполненные свойства, но и указать, в каком наборе они должны находиться и под каким именем! Именно это и выполняет функция, которая называется маппирование (mapping), то есть сопоставление параметров, пользовательских свойств и расчетных характеристик моделей Renga и IFC (рис. 6).
Рис. 6. Схема маппинга параметров перекрытия из модели Renga в модель IFC
Каким же образом в Renga происходит маппирование? Все правила описываются в файле сопоставления параметров. При экспорте модели в IFC4 Renga обращается к нему и выполняет экспорт по описанным правилам. Путь к этому файлу указывается в настройках программы в меню Экспорт (рис. 7).
Рис. 7. Параметры настройки экспорта в IFC4
Мы остаемся приверженцами идеи, что программа должна оставаться инструментом проектировщиков, поэтому не стали нагружать интерфейс техническим функционалом. Описание правил происходит в файле формата JSON. В комплекте с дистрибутивом Renga идет подготовленный нами файл маппинга — export_attr_qto_pset.json. Он используется при экспорте по умолчанию и формирует модель IFC по нашим правилам.
Он подойдет для общих случаев экспорта данных в формат IFC4, но в случае подготовки модели на госэкспертизу необходимо сформировать собственный файл маппинга (по правилам госэкспертизы). Формат JSON широко распространен, поэтому в создании такого файла не возникнет трудности — для этого существует много редакторов, один из которых BIMменеджер может выбрать по своему вкусу.
Описание классов IFC выполняется так, как показано на рис. 8.
Рис. 8. Схема описания классов IFC
В наборах описываются параметры по правилу «ключ: значение». «Ключ» — это наименование атрибута модели IFC, в который будет экспортирован атрибут Renga. «Значение» — это наименование атрибута модели Renga, который будет экспортирован в IFC.
Рассмотрим эту процедуру на примере описания объектов «Стена» (IfcWall). Ниже представлена иллюстрация части файла маппинга, созданного по правилам Мосгосэскпертизы, сопоставленная со списком свойств объектов «Стена» модели Renga (рис. 9).
Рис. 9. Фрагмент файла маппинга и свойства стен в Renga (цветом выделены группы и относящиеся к ним параметры)
Класс IfcWall имеет три группы атрибутов: attributes (параметры), psets (наборы пользовательских свойств) и qsets (наборы расчетных характеристик). В attributes нами определены два параметра: «Имя», которое принимает при экспорте в IFC наименование «Name», и «Марка», которое принимает при экспорте в IFC наименование «Tag». Параметры определены по правилу «ключ: значение», то есть «Tag: Марка». Далее можно расширить список параметров по вашему усмотрению. В группе psets определены два набора пользовательских свойств: «Pset_WallCommon» и «ExpCheck_Wall», каждый из которых имеет набор атрибутов. Откуда они взялись? Из требований Мосгосэкспертизы10 . По той же причине в группе qsets определен набор расчетных характеристик «Qto_WallBaseQuantities».
На рис. 9 неслучайно приведен список свойств модели Renga: при переопределении того или иного параметра вы должны брать такое его название, какое он имеет в Renga.
Итак, мы и подошли к непосредственному экспорту модели. По созданному вами файлу маппинга можно выполнить экспорт вашей модели (не забыв указать его в настройках программы). И чтобы вы были уверены в правильности полученного результата, мы предусмотрели еще одну функциональность.
III. Проверка на ошибки
Журнал ошибок
В процессе экспорта модели IFC создается журнал (лог), в который записываются возникающие ошибки. Обязательно загляните в него. Он создается в той же папке экспорта и имеет то же имя, что и модель. Журнал без ошибок будет содержать только дату создания, а журнал с ошибками будет имеет структуру, показанную на рис. 10.
Рис. 10. Журнал ошибок экспортированной модели
В 1й колонке указывается уникальный идентификатор объекта GUID (это обращение к конкретному экземпляру, в котором произошла ошибка при экспорте). Во 2й колонке указывается имя объекта Renga. В 3й колонке указывается класс IFC экспортируемого объекта. В 4й — причина возникшей ошибки.
Если в вашем журнале есть ошибки — это повод заглянуть еще раз в файл сопоставления параметров. Возможно, вы просто разместили набор пользовательских свойств не в той группе атрибутов. Кроме того, необходимо проверить в модели Renga объекты, попавшие в журнал. По GUID вы сможете объект точно идентифицировать и проверить, все ли атрибуты правильно наименованы, создав, например, по нему фильтр или найдя объект по GUID через спецификацию.
В заключение осталось описать еще одну функциональность, которая решает проблему коллизий, упомянутую ранее. Эта функциональность работает автоматически при экспорте модели в IFC. Теперь все объекты модели экспортируются с учетом подрезок, возникающих от взаимодействия с другими объектами в Renga. Я говорю о взаимодействии между конструктивными элементами (стена — перекрытие, перекрытие — колонна, колонна — балка и т.д.). Эта логика существует в Renga уже довольно давно. Она определяет приоритет конструкций во взаимодействиях с другими элементами, например перекрытие вырезает объем у стены, если мы его заведем вовнутрь, смоделировав таким образом опирание, или крыша обрезает верх любых объектов, которые находятся под ней и пересекают ее, и т.д. (рис. 11).
Рис. 11. Экспорт в IFC с учетом подрезки объектов
Эта функциональность поможет вам избежать коллизий, вызванных взаимопересечением конструктивных элементов здания. Тем не менее она не заменит проверку модели в специализированном ПО (например, РусБИМЭксперт, Solibri Model Checker, Navisworks и т.п.). Некоторые экспертизы (например, СанктПетербургская госэкспертиза) вместе с предоставляемой моделью требуют отчет о коллизиях из вышеперечисленного ПО. Это традиционный вопрос, касающийся того, что информационная модель никогда и нигде во всем мире не создается с помощью одного инструмента. Понастоящему эффективная работа предполагает использование набора специализированного ПО.
***
Вот мы и подошли к концу статьи. Вся функциональность, о которой шла речь, родилась не просто так, а в процессе обсуждения с пользователями и экспертами и была подтверждена практикой! Мы надеемся, что она будет востребована вами и принесет вам пользу. Тема экспорта в IFC4 очень многогранна, и мы только начали погружение в этот мир. Поэтому остаемся на связи. До новых встреч!
1 http://www.стройстратегия.рф/#service.
2 Подробнее см. СП 333.1325800.2017 «Информационное моделирование в строительстве. Правила формирования информационной модели объектов на различных стадиях жизненного цикла».
3 Формат файлов IFC (Industry Foundation Classes) разработан компанией buildingSMART®. Это открытый международный стандарт (ISO 167391: 2018), позволяющий обмениваться данными между различными приложениями.
4 Пример создания строительного объема здания см. видео (https://youtu.be/aftyOTtWnb0).
5 Cм. п. 8.8 «Общих требований к ЦИМ СПб ГАУ «ЦГЭ» (редакция 2.0) или п. 9.2 «Общих требований к параметрам цифровых моделей ГАУ «МГЭ» (редакция 4.1).
6 См. п. 8.3 «Требование к отсутствию коллизий ГАУ «МГЭ» (редакция 4.1).
7 Имеется в виду выбор объектов, одинаковых по марке, по типу, по стилю через контекстное меню и спецификацию. Через спецификацию можно выбирать по любым схожим пользовательским свойствам. Более подробно о работе с атрибутами через спецификацию см. «Опыт применения BIMсистемы Renga для создания информационной модели общеобразовательной школы для эксперимента для прохождения госэкспертизы».
8 https://standards.buildingsmart.org/MVD/RELEASE/IFC4/ADD2_TC1/RV1_2/HTML/schema/views/referenceview/index.htm
9 https://standards.buildingsmart.org/MVD/RELEASE/IFC4/ADD2_TC1/RV1_2/HTML/schema/views/referenceview/index.htm.
10 См. п. 5.4.4.1 «Требования к параметрам стен и перегородок», «Требования к ЦИМ архитектурных решений зданий, ГАУ «МГЭ» (редакция 4.1).