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

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

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

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

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

Наименование

2020

2024

2030

Доля проектных организаций, применяющих на практике ТИМ, %

24

45

50

Доля строящихся и реконструируемых ОКС, имеющих ЦИМ, %

5

20

65

Удельный вес осуществления в электронной форме процедур, включенных в исчерпывающие перечни процедур, %

30

70

100

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

Таблица 2 - Целевые показатели по направлению «Инновационное развитие института строительной экспертизы».

Наименование

2020

2024

2030

Доля экспертных организаций, интегрированных в ЦС ИСЭ, %

0

25

90

Доля проектов, по которым осуществляется комплексное экспертное сопровождение, (от нулевой стадии до завершения строительства), %

(для особо опасных, технически сложных и уникальных объектов капитального строительства)

10

50

70

Доля документации, представленной на экспертизу и разработанная с применением ТИМ, %

5

30

50

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

В этой статье мы рассмотрим очень важную тему: подготовку в Renga цифровой информационной модели (ЦИМ) к госэкспертизе, согласно ее требованиям. Автор предполагает, что Вы уже знакомы с ТИМ и владеете терминологией [2]. Но в начале рассмотрим проблематику вопроса в условиях текущих реалий.

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

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

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

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

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

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

 

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

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

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

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

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

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

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

Решение в Renga

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

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

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

 

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

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


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


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

 

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

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

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

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

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

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

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

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

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

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

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 имеет 3 группы атрибутов: «attributes» (параметры), «psets» (наборы пользовательских свойств) и «qsets» (наборы расчетных характеристик). В «attributes» определены нами 2 параметра: «Имя», которое принимает при экспорте в IFCнаименование «Name», и «Марка», которое принимает при экспорте в IFC наименование «Tag». Параметры определены по правилу «Ключ: значение», т.е. «Tag: Марка». Далее можно расширить список параметров по вашему усмотрению. В группе «psets» определены 2 набора пользовательских свойств:  «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 через спецификацию.

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

 

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

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

Вот мы и подошли к концу данной статьи. Вся функциональность, о которой шла речь, родилась не просто так, а в процессе обсуждения с пользователями и экспертами. И была подтверждена практикой! Мы надеемся, что она будет востребована Вами и принесет Вам пользу. Тема экспорта в IFC4 – очень обширна, и мы только начали погружение в этот мир. Остаемся на связи.  До новых встреч!

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

[4] Пример создания строительного объема здания см. видео.

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

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

[7] Имеется в виду выбор объектов одинаковых по марке, по типу, по стилю через контекстное меню и спецификацию. Через спецификацию можно выбирать по любым схожим пользовательским свойствам. Более подробно о работе с атрибутами через спецификацию см. Опыт применения BIM-системы Renga для создания информационной модели общеобразовательной школы для эксперимента для прохождения госэкспертизы

[8, 9] https://standards.buildingsmart.org/MVD/RELEASE/IFC4/ADD2_TC1/RV1_2/HTML/schema/views/reference-view/index.htm

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

 Автор: Евгений Кирьян, маркетинг-менеджер Renga Software