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

views
4784 просмотра
В статье подробно разбирается функционал BIM-системы Renga, который позволяет правильно подготовить информационную модель с учётом различных требований региональных госэкспертиз и успешно пройти экспертизу проекта.
Проходим госэкспертизу информационной модели правильно!

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

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

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

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

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

image-0

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

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

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

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

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

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

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

image-0

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

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

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

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

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

Решение в Renga

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

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

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

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

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

image-0

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

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

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

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

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

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

image-0 Рис. 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).

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

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

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

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

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

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

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

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

image-0 Рис. 6. Схема маппинга параметров перекрытия из модели Renga в модель IFC

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

image-0 Рис.7. Параметра настройки экспорта в IFC4

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

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

Описание классов IFC выполняется следующим образом (Рис. 8):

image-0 Рис. 8. Схема описания классов IFC

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

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

image-0 Рис. 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):

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

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

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

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

image-0 Рис.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.

0
0