За последний год наша компания приняла участие в двух пилотных проектах по прохождению госэкспертизы в виде цифровой информационной модели (ЦИМ). Первый, организованный ФАУ «ФЦС» Минстроя России, – это школа в Чкаловском районе Екатеринбурга. Проектная документация объекта на тот момент прошла экспертизу, в рамках эксперимента нужно было провести экспертизу повторно, но уже по BIM-модели. Мы выполнили модели по 7-ми разделам в исходном формате Renga с последующим экспортом в формат IFC. Эксперимент был признан успешным: в ФАУ «ФЦС» отметили, что российское программное обеспечение отвечает современным требованиям, предъявляемым к программным продуктам для формирования и ведения информационных моделей зданий и сооружений. Второй проект был инициирован Департаментом градостроительной политики г. Москвы, который предложил создать BIM-модель жилого дома из программы реновации. Здесь мы выступали в качестве консультантов и при необходимости подключались к проектированию. На собственном опыте мы изучили детали процесса и погрузились в нюансы требований госэкспертизы. В этом статье представлены рекомендации, как подготовить модель к экспертизе и какие инструменты предлагает Renga для этой задачи.

Информационная модель школы в Renga

Прохождение BIM-модели в госэкспертизе

Пока прохождение государственной экспертизы в формате ЦИМ является добровольным, за редким исключением из правил, когда заказчик сам включает это требование в договор (в случае больших и ответственных проектов и/или с привлечением государственного финансирования). В сентябре Правительство РФ утвердило правила формирования и ведения информационной модели объектов капитального строительства (Постановление №1431). Сделан первый шаг к формированию единых требований к информационной модели, но работа в этом направлении еще ведется самим ФАУ «ФЦС». Соответственно, на сегодняшний день требования к ЦИМ, проходящим государственную экспертизу, формируют сами органы госэкспертизы, с учетом специфики работы в своем регионе. Тут мы подходим к первой проблеме: требования различных экспертиз к составу ЦИМ различны. Но прежде, чем более детально посмотреть вглубь этих требований, отметим схожие моменты:

1. Для прохождения государственной экспертизы в формате ЦИМ требуется предоставить модель в формате IFC (не ниже версии 4.0). Формат файлов IFC (Industry Foundation Classes) разработан компанией buildingSMART®. Это открытый международный стандарт (ISO 16739-1: 2018), позволяющий обмениваться данными между различными приложениями.
2. Требования применяются только к моделям зданий социальной сферы,  т.е. к зданиям следующего функционального назначения (по моделям зданий другого назначения госэкспертиза в формате ЦИМ не проводится):

• Административно-деловые объекты
• Многоквартирные дома
• Амбулаторно-поликлинические объекты
• Учебно-воспитательные объекты.

Для наглядности возьмем актуальные (на дату написания статьи) требования двух госэкспертиз ГАУ «Московская государственная экспертиза» и СПбГАУ «Центр государственной экспертизы» и посмотрим на небольшом примере, какие требования предъявляются к параметрам одного типа объектов – перекрытиям.

Требования к параметрам перекрытий различных госэкспертиз

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

Ещё одним важным моментом в прохождении госэкспертизы является создание базовой модели, в которой должны быть смоделированы строительные объемы надземной и подземной части и размещены зоны для функционального зонирования и подсчета основных ТЭП (площади этажей, пожарные отсеки, общая площадь, площадь застройки и т.д.). Рассмотрим требование к параметрам базовой модели (п. 8.8 Общих требований к ЦИМ СПб ГАУ «ЦГЭ» (редакция 2.0) или п. 9.2 Общие требования к параметрам цифровых моделей ГАУ «МГЭ» (редакция 4.1)), которое обязывает проектировщиков наполнять ЦИМ (далее – модель) сущностями, которые не имеют физического представления:

Эти сущности должны быть наполнены данными о самом проекте:

1. Общие данные.
2. Основные характеристики.
3. Требуемые показатели объекта капитального строительства.
4. Проектные технико-экономические показатели.
5. Климатические и геотехнические данные и т.д.

Каким образом выполнять это требование, мы объясним чуть позже, а пока рассмотрим последнее в этой части (но не последнее у госэкспертизы) очень важное требование – это отсутствие коллизий между элементами модели. Цитата из требований Мосгосэкспертизы (п. 8.3 Требование к отсутствию коллизий ГАУ «МГЭ» (редакция 4.1)):

«…не допускаются проектные ошибки (коллизии), превышающие 15 мм, вызванные геометрическими пересечениями элементов…»

Этот момент тоже был учтен при разработке функционала системы Renga по экспорту в IFC. И теперь самое время перейти к следующей части, в которой пойдет речь о том, как выполнить эти требования в Renga.

Представленные ниже инструкции адресованы прежде всего BIM-менеджерам и инженерам отделов САПР, кто по роду своей деятельности будет готовить модели к экспорту. Все технические решения отработаны нами на практике в пилотных проектах, во взаимодействии с Мосгосэкспертизой и Санкт-Петербургской госэкспертизой. Чтобы вся информация была понятна, взгляните на схему работы с моделью. Мы пойдём последовательно – от первого пункта к последнему

Схема работы с моделью для экспорта в IFC4 по правилам госэкспертизы

I. Подготовка модели к экспорту

1. Информация о проекте

Как мы выяснили, модель должна содержать данные по проекту. Для этого в Renga были добавлены следующие сущности (в скобках обозначены соответствующие классы IFC):

Доступ к ним можно получить через реорганизованное меню «Управление стилями».

Информация о проекте включает в себя информацию о Проекте, Участке и Здании

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

2-3. Работа с пользовательскими свойствами

В идеале мы стремимся к тому, чтобы экспертиза проекта проходила в автоматизированном режиме. Чтобы правильно интерпретировать данные модели, все атрибуты модели должны иметь определённый тип данных. Эти типы описаны в IFC, и их требует экспертиза. Создавая новое пользовательское свойство, мы должны назначить ему нужный тип данных.

С учетом вышесказанного, в Renga был расширен список типов данных, которые пользователь может использовать. К существующим ранее типам «строка» и «действительное число» добавились:

• Целое число
• Длина
• Площадь
• Объем
• Угол
• Масса
• Булевый (принимает только два значения: «Да» или «Нет»)
• Логический (три значения: «Да», «Нет», «Не определено»)
• Перечисление (список заранее определённых значений).

С таким набором типов под рукой у пользователя не возникнут проблемы с интерпретацией данных его модели при экспорте в сторонние программы. Работа с пользовательскими свойствами ведётся в меню «Свойства объектов».

Создание нового свойства в меню «Свойства объектов»

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

4. Переопределение типов объектов при экспорте

Поскольку экспертиза ИМ проходит в формате IFC, то все объекты модели должны быть экспортированы по соответствующим классам, описанным в IFC. Стандартное модельное представление Reference View 1.2 (IFC4 RV-1.2), в соответствии с которым сформированы требования госэкспертизы, описывает 16 классов архитектурных элементов здания, 12 классов конструктивных, 65 классов элементов внутренних инженерных систем, в совокупности по основным специальностям (водоснабжение/водоотведение, отопление, вентиляция, электрика, автоматизация) и ещё дополнительно 18 классов элементов, к которым относятся, например, помещения (IfcSpace) или уже рассмотренный нами класс – здание (IfcBulding). Итого более 100 классов! Возникает резонный вопрос – как всё это многообразие замоделировать имеющимися инструментами? Ответ простой – моделируйте так, как вам более удобно. Мы переопределим класс объекта при экспорте!

Вот пример, как мы можем это сделать с архитектурными элементами. Согласно требованиям, напольное покрытие (полы) должно быть выгружено в IFC под классом IfcCovering, а, например, наружный навесной вентилируемый фасад – под классом IfcCurtainWall. Таких кнопок в Renga пока нет, но они и не нужны (для задачи прохождения госэкспертизы). Можно смоделировать полы отдельным перекрытием (даже нужно), а наружный фасад – второй стеной со своими слоями конструкции.

Следующий шаг – на объекты модели, класс которых мы хотим переопределить, мы должны добавить следующие пользовательские свойства (тип данных – строка):

• IfcEntityType – свойство, необходимое для переопределения типа объекта.
• IfcObjectType – свойство задаётся только в том случае, если пользователь задал предопределённый тип USERDEFINED в свойствах экземпляра объекта.
• IfcElementType – свойство задаётся только в том случае, если пользователь задал предопределённый тип USERDEFINED в свойствах стиля объекта.

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

Свойствам IfcEntityType, IfcObjectType и IfcName заданы нужные значения, поэтому при экспорте у этих объектов будет переопределен Класс, Тип и Имя

Кроме них, в Renga можно переопределять следующие параметры IFC:

• IfcTag – соответствует параметру объекта Марка
• IfcName – используется для указания короткого имени или номера
• IfcLongName – используется для указания полного имени объекта
• IfcDescription– описание объекта.

Это очень мощный инструмент. Единственное, что от вас требуется – разобраться в описании классов IFC. Тут понадобится справочник IFC.

II. Настраиваемый экспорт в IFC4

Мы подготовили модель к экспорту и подошли к моменту, когда нужно нажать кнопку «Экспорт в IFC», но не торопитесь! Далее нам предстоит совершить ещё один очень важный шаг – указать Renga, по каким наборам свойств/параметров/расчётных характеристик будут выгружаться данные по тому или иному типу объектов.

5-6. Сопоставление параметров при экспорте (Маппирование)

Помните иллюстрацию в начале, где мы сравнивали требования к перекрытиям от двух экспертиз? Мы должны не просто выгрузить заполненные свойства, но и указать, в каком наборе они должны находиться и под каким именем. Именно это и выполняет функциональность под названием маппирование (mapping), т.е. сопоставление параметров, пользовательских свойств и расчётных характеристик моделей Renga и IFC.

Схема маппинга параметров перекрытия из модели Renga в модель IFC

Каким же образом в Renga происходит маппирование? Все правила описываются в файле сопоставления параметров. При экспорте модели в IFC4 Renga обращается к нему и выполняет экспорт по описанным правилам. Путь к этому файлу указывается в настройках программы в меню «Экспорт».

Параметры настройки экспорта в IFC4

Мы остаемся приверженцами идеи, чтобы программа оставалась для проектировщиков, поэтому не стали нагружать интерфейс техническим функционалом. Описание правил происходит в файле формата JSON. В комплекте с дистрибутивом Renga идёт подготовленный нами файл маппинга – «export_attr_qto_pset.json». Он используется при экспорте по умолчанию и формирует модель IFC по нашим правилам.

Файл подойдёт для общих случаев экспорта данных в формат IFC4, но в случае подготовки модели на госэкспертизу необходимо подготовить собственный файл маппинга (по правилам госэкспертизы). Формат JSON широко распространен, поэтому в создании такого файла не возникнет трудностей – существует много редакторов. BIM-менеджер может выбрать на своё усмотрение. Описание классов IFC выполняется следующим образом:

Схема описания классов IFC

В наборах описываются параметры по правилу «ключ: значение». «Ключ» – это наименование атрибута модели IFC, в который будет экспортирован атрибут Renga. «Значение» – это наименование атрибута модели Renga, который будет экспортирован в IFC.

Рассмотрим на примере описания объектов «Стена» (IfcWall). Ниже представлена иллюстрация части файла маппинга, созданного по правилам Мосгосэскпертизы, сопоставленная со списком свойств объектов «Стена» модели Renga.

Фрагмент файла маппинга и свойства стен в Renga (цветом выделены группы и относящиеся к ним параметры)

Класс IfcWall имеет три группы атрибутов: «attributes» (параметры), «psets» (наборы пользовательских свойств) и «qsets» (наборы расчётных характеристик). В «attributes» определены нами два параметра: «Имя», которое принимает при экспорте в IFC наименование «Name», и «Марка», которое принимает при экспорте в IFC наименование «Tag». Параметры определены по правилу «Ключ: значение», т.е. «Tag: Марка». Далее можно расширить список параметров по вашему усмотрению. В группе «psets» определены два набора пользовательских свойств: «Pset_WallCommon» и «ExpCheck_Wall», каждый из которых имеет набор атрибутов. Откуда они появились? Из требований Мосгосэкспертизы (п. 5.4.4.1 Требования к параметрам стен и перегородок, Требования к ЦИМ архитектурных решений зданий, ГАУ «МГЭ» (редакция 4.1)). По той же причине в группе «qsets» определен набор расчётных характеристик «Qto_WallBaseQuantities».

На рисунке не случайно приведен список свойств модели Renga. При переопределении параметров вы должны брать название такое, какое он имеет в Renga.

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

III. Проверка на ошибки

7. Журнал ошибок

В процессе экспорта модели IFC создаётся журнал (лог), в который записываются возникающие ошибки. Обязательно загляните в него. Он создаётся в той же папке экспорта и имеет то же имя, что и модель. Журнал без ошибок будет содержать только дату создания, а с ошибками будет имеет следующую структуру:

Журнал ошибок экспортированной модели

В первой колонке указывается уникальный идентификатор объекта GUID (это обращение к конкретному экземпляру, в котором произошла ошибка при экспорте). Во второй колонке указывается имя объекта Renga. В третьей колонке указывается класс IFC экспортируемого объекта. В четвёртой – причина возникшей ошибки.

Если в вашем журнале есть ошибки – это причина заглянуть ещё раз в файл сопоставления параметров. Возможно, вы просто разместили набор пользовательских свойств не в той группе атрибутов. И проверить в модели Renga объекты, попавшие в журнал. По GUID вы сможете точно его идентифицировать и проверить, все ли атрибуты правильно наименованы, создав, например, по нему фильтр или найдя объект по GUID через спецификацию.

Заключение

В заключении покажу ещё одну функциональность Renga, которая решает проблему коллизий и работает автоматически при экспорте модели в IFC. Теперь все объекты модели экспортируются с учётом подрезок, возникающих от взаимодействия с другими объектами в Renga. Я говорю о взаимодействиях между конструктивными элементами (стена – перекрытие, перекрытие – колонна, колонна – балка и т.д.). Эта логика существует в Renga довольно давно, она определяет приоритет конструкций во взаимодействиях с другими элементами, например, перекрытие вырезает объём у стены, если мы заведём его внутрь, смоделировав таким образом опирание, или крыша обрезает верх любых объектов, которые находятся под ней и пересекают её и т.д.

Экспорт в IFC с учётом подрезки объектов

Экспорт в IFC с учётом подрезки объектов поможет избежать коллизий, вызванных взаимопересечением конструктивных элементов здания. Но он не заменит проверку модели в специализированном ПО (например, РусБИМЭксперт, Solibri Model Checker, Navisworksи т.п.). Ряд экспертиз (например, Санкт-Петербургская госэкспертиза) вместе с предоставляемой моделью требуют отчёт о коллизиях из вышеперечисленного ПО. Это доказательство того, что информационная модель никогда не создаётся с помощью одного инструмента. По-настоящему эффективная работа предполагает использование набора специализированного ПО.

Автор: Евгений Кирьян
Источник: https://ardexpert.ru/

Понравилась статья? Тогда поддержите нас, поделитесь с друзьями и заглядывайте по рекламным ссылкам!