Проходим госэкспертизу информационной модели правильно!

Развитие информационных технологий в строительстве

2020 год. Цифровизация стала приоритетным направлением развития строительной отрасли. В планах Минстроя РФ к 2030 году полностью перейти на обязательное применение технологии информационного моделирования (ТИМ) при создании и эксплуатации объектов капитального строительства (ОКС) и в первоочередном порядке уже к 2024 году – в социальной сфере.

В подготовленной Стратегии развития отрасли^[1] запланировано 2-х кратное увеличение доли проектных организаций, применяющих на практике ТИМ, а также более чем в 10 раз должна увеличиться доля проектов ОКС, имеющих цифровую информационную модель (ЦИМ) (Табл. 1).

Таблица 1. Целевые показатели по направлению «Цифровизация строительной отрасли»

Уже сейчас развивается институт государственной экспертизы. Экспертиза начинает проверку проектов ОКС в формате ЦИМ. Согласно Стратегии развития, доля проектов, представленных на госэкспертизу и разработанных с применением ТИМ, должна вырасти с 5% (на сегодняшний день) до 50% к 2030 году (Табл. 2).

Прохождение ИМ в госэкспертизе

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

1. Для прохождения государственной экспертизы в формате ЦИМ у всех экспертиз требуется предоставить модель в формате IFC (не ниже версии 4.0)^[2].
2. Требования различных экспертиз применяются только к моделям зданий социальной сферы, т.е. к зданиям следующего функционального назначения (по моделям зданий другого назначения госэкспертиза в формате ЦИМ не проводится):
3. Административно-деловые объекты;
4. Многоквартирные дома;
5. Амбулаторно-поликлинические объекты;
6. Учебно-воспитательные объекты.

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

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

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

Ещё одним важным моментом в прохождении госэкспертизы является создание базовой модели, в которой должны быть смоделированы строительные объёмы надземной и подземной части и размещены зоны для функционального зонирования и подсчёта основных ТЭП (площади этажей, пожарные отсеки, общая площадь, площадь застройки и т.д.) Пример создания строительного объёма здания в видео. Рассмотрим требование к параметрам базовой модели ^[3], которое обязывает проектировщиков наполнять ЦИМ (далее – модель) сущностями, которые не имеют физического представления:

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

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

Каким образом выполнять это требование мы поговорим в третьей части статьи, а пока рассмотрим последнее в этой части (но не последнее у госэкспертизы) очень важное требование – это отсутствие коллизий между элементами модели.  Цитата из требований Мосгосэкспертизы ^[4]:

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

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

Решение в Renga

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

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

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

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

Модель должна содержать данные по проекту. Для этого в Renga были добавлены следующие сущности (в скобках обозначены соответствующие классы IFC): Проект (IfcProject), Участок (IfcSite), Здание (IfcBuilding)

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

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

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

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

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

• целое число; 
• длина; площадь; 
• объём;угол; масса; 
• булевый (принимает только 2 значения: «Да» или «Нет»); 
• логический (3 значения: «Да», «Нет», «Не определено»); 
• перечисление (список заранее определённых значений).

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

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

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

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

Поскольку экспертиза ИМ проходит в формате IFC, то все объекты модели должны быть экспортированы по соответствующим классам, описанным в IFC. Стандартное модельное представление Reference View 1.2 (IFC4 RV-1.2), в соответствии с которым сформированы требования госэкспертизы, описывает 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. 

2. Настраиваемый экспорт в 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 имеет 3 группы атрибутов:

• «attributes» (параметры);
•  «psets» (наборы пользовательских свойств);
• «qsets» (наборы расчётных характеристик).

В «attributes» определены нами 2 параметра: «Имя», которое принимает при экспорте в IFC наименование «Name», и «Марка», которое принимает при экспорте в IFC наименование «Tag». Параметры определены по правилу «Ключ: значение», т.е. «Tag: Марка». Далее можно расширить список параметров по вашему усмотрению. В группе «psets» определены два набора пользовательских свойств: «Pset_WallCommon» и «ExpCheck_Wall», каждый из которых имеет набор атрибутов. Откуда они взялись? Из требований Мосгосэкспертизы ^[6]. По той же причине в группе «qsets» определён набор расчётных характеристик «Qto_WallBaseQuantities».

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

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

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

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

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

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

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

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

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

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

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

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

[1] http://www.стройстратегия.рф/#service.

[2] Формат файлов IFC (Industry Foundation Classes) разработан компанией buildingSMART®. Это открытый международный стандарт (ISO 16739-1: 2018), позволяющий обмениваться данными между различными приложениями.

[3] Cм. п. 8.8 Общих требований к ЦИМ СПб ГАУ «ЦГЭ» (редакция 2.0) или п. 9.2 Общие требования к параметрам цифровых моделей ГАУ «МГЭ» (редакция 4.1).

[4] См. п. 8.3 Требование к отсутствию коллизий ГАУ «МГЭ» (редакция 4.1).

[5] Имеется в виду выбор объектов одинаковых по марке, по типу, по стилю через контекстное меню и спецификацию. Через спецификацию можно выбирать по любым схожим пользовательским свойствам. Более подробно о работе с атрибутами через спецификацию.

[6] См. п. 5.4.4.1 Требования к параметрам стен и перегородок, Требования к ЦИМ архитектурных решений зданий, ГАУ «МГЭ» (редакция 4.1).

В настоящем материале представлена авторская точка зрения. Мнение автора может не совпадать с позицией редакции BIMLIB.