Проходим госэкспертизу информационной модели правильно!
Развитие информационных технологий в строительстве
2020 год. Цифровизация стала приоритетным направлением развития строительной отрасли. В планах Минстроя РФ к 2030 году полностью перейти на обязательное применение технологии информационного моделирования (ТИМ) при создании и эксплуатации объектов капитального строительства (ОКС) и в первоочередном порядке уже к 2024 году – в социальной сфере.
В подготовленной Стратегии развития отрасли[1] запланировано 2-х кратное увеличение доли проектных организаций, применяющих на практике ТИМ, а также более чем в 10 раз должна увеличиться доля проектов ОКС, имеющих цифровую информационную модель (ЦИМ) (Табл. 1).
Уже сейчас развивается институт государственной экспертизы. Экспертиза начинает проверку проектов ОКС в формате ЦИМ. Согласно Стратегии развития, доля проектов, представленных на госэкспертизу и разработанных с применением ТИМ, должна вырасти с 5% (на сегодняшний день) до 50% к 2030 году (Табл. 2).
Прохождение ИМ в госэкспертизе
На сегодняшний день законодательством ещё не утверждены требования к составу и формату ИМ. Постановление Правительства РФ подготовлено, и планируется к подписанию. Пока прохождение государственной экспертизы в формате ЦИМ является добровольным, за редким исключением из правил, когда заказчик сам включает это требование в договор (в случае больших и ответственных проектов и/или с привлечением государственного финансирования). Соответственно, формирование требований к ЦИМ, проходящих государственную экспертизу, формируют сами органы госэкспертизы добровольно, с учётом специфики работы в собственном регионе РФ. Тут мы подходим к первой проблеме: требования различных экспертиз к составу ЦИМ различны. Но прежде, чем мы более детально посмотрим вглубь этих требований, стоит отметить схожие моменты:
- Для прохождения государственной экспертизы в формате ЦИМ у всех экспертиз требуется предоставить модель в формате IFC (не ниже версии 4.0)[2].
- Требования различных экспертиз применяются только к моделям зданий социальной сферы, т.е. к зданиям следующего функционального назначения (по моделям зданий другого назначения госэкспертиза в формате ЦИМ не проводится):
- Административно-деловые объекты;
- Многоквартирные дома;
- Амбулаторно-поликлинические объекты;
- Учебно-воспитательные объекты.
Для наглядности, возьмем актуальные (на дату написания статьи) требования 2-х госэкспертиз ГАУ «Московская государственная экспертиза» и СПб ГАУ «Центр государственной экспертизы» и посмотрим на небольшом примере какие требования предъявляются к параметрам одного типа объектов – перекрытиям (Рис. 1).
Обе экспертизы довольно чётко указывают требования к составу атрибутов, группировке атрибутов по соответствующим наборам свойств, именованию атрибутов, типам данных и заполнению значений атрибутов. Но, как можно видеть на иллюстрации ниже, атрибутивный набор и наполнение элементов различное. Разработчики ПО должны учитывать это при создании инструмента, который должен быть гибким и отвечать требованиям как отдельных экспертиз, так и соответствовать другим сценариям экспорта модели.
Ещё одним важным моментом в прохождении госэкспертизы является создание базовой модели, в которой должны быть смоделированы строительные объёмы надземной и подземной части и размещены зоны для функционального зонирования и подсчёта основных ТЭП (площади этажей, пожарные отсеки, общая площадь, площадь застройки и т.д.) Пример создания строительного объёма здания в видео. Рассмотрим требование к параметрам базовой модели [3], которое обязывает проектировщиков наполнять ЦИМ (далее – модель) сущностями, которые не имеют физического представления:
Эти сущности должны быть наполнены данными о самом проекте:
- Общие данные
- Основные характеристики
- Требуемые показатели ОКС
- Проектные ТЭП
- Климатические и геотехнические данные и т.д.
Каким образом выполнять это требование мы поговорим в третьей части статьи, а пока рассмотрим последнее в этой части (но не последнее у госэкспертизы) очень важное требование – это отсутствие коллизий между элементами модели. Цитата из требований Мосгосэкспертизы [4]:
«…не допускаются проектные ошибки (коллизии) превышающие 15 мм, вызванные геометрическими пересечениями элементов…»
Этот момент тоже был учтён при разработке функционала по экспорту в IFC. И теперь самое время перейти к третьей части, в которой пойдет речь о том, как выполнить эти требования в Renga с учётом нового функционала.
Решение в Renga
Решения, о которых пойдет речь – не теория, а реальная практика. На сегодняшний день уже наработан опыт подготовки моделей к экспертизе как по требованиям Мосгосэкспертизы, так и Санкт-Петербургской госэкспертизы. Чтобы вся информация была понятна взгляните на схему работы с моделью (рис. 2).
1. Подготовка модели к экспорту
Информация о проекте
Модель должна содержать данные по проекту. Для этого в Renga были добавлены следующие сущности (в скобках обозначены соответствующие классы IFC): Проект (IfcProject), Участок (IfcSite), Здание (IfcBuilding)
Доступ к этим сущностям можно получить через реорганизованное меню «Управление стилями» (рис. 3). Параметры разделены по трём вкладкам: отдельно для проекта, участка и здания. Кроме этого, у пользователей есть возможность расширять эти сущности произвольным количеством пользовательских свойств, внося тем самым всю информацию о проекте, требуемую госэкспертизой.
Работа с пользовательскими свойствами
В идеале мы стремимся к тому, чтобы экспертиза проекта проходила в автоматизированном режиме. Чтобы правильно интерпретировать данные модели, все атрибуты модели должны иметь определенный тип данных. Эти типы описаны в IFC и их требует экспертиза. Создавая новое пользовательское свойство необходимо назначить ему нужный тип данных.
С учётом вышесказанного, в Renga был расширен список типов данных, которые пользователь может использовать. К существующим ранее типам «строка» и «действительное число», добавились:
- целое число;
- длина; площадь;
- объём;угол; масса;
- булевый (принимает только 2 значения: «Да» или «Нет»);
- логический (3 значения: «Да», «Нет», «Не определено»);
- перечисление (список заранее определённых значений).
Имея под рукой такой набор типов, у пользователя не возникнут проблемы с интерпретацией данных его модели, экспортируя в сторонние программы. Работа с пользовательскими свойствами осуществляется в меню «Свойства объектов» (рис. 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).
Кроме них, в Renga можно переопределять следующие параметры IFC:
- IfcTag – Соответствует параметру объекта Марка.
- IfcName – Используется для указания короткого имени или номера объекта.
- IfcLongName – Используется для указания полного имени объекта.
- IfcDescription – Описание объекта.
Это очень мощный инструмент. Единственное, что требуется – это разобраться в описании классов IFC.
2. Настраиваемый экспорт в IFC4
Перед тем как нажать кнопку «Экспорт в IFC» необходимо совершить ещё один очень важный шаг – указать Renga по каким наборам свойств/параметров/расчетных характеристик будут выгружаться данные по тому или иному типу объектов.
Сопоставление параметров при экспорте (Маппирование)
Помните иллюстрацию сравнения требований к перекрытиям от двух экспертиз (рис. 1)? Необходимо не просто выгрузить заполненные свойства, но и указать в каком наборе они должны находится и под каким именем. Именно это и выполняет функциональность под названием маппирование (mapping), т.е. сопоставление параметров, пользовательских свойств и расчётных характеристик моделей Renga и IFC (рис. 6).
Каким же образом в Renga происходит маппирование? Все правила описываются в файле сопоставления параметров. При экспорте модели в IFC4, Renga обращается к нему и выполняет экспорт по описанным правилам. Путь к этому файлу указывается в настройках программы в меню «Экспорт» (рис. 7).
Интерфейс программы не нагружен техническим функционалом – это в первую очередь, инструмент проектировщиков. Описание правил происходит в файле формата JSON. В комплекте с дистрибутивом Renga идёт подготовленный нами файл маппинга – «export_attr_qto_pset.json». Он используется при экспорте по умолчанию и формирует модель IFC по нашим правилам.
Он подойдёт для общих случаев экспорта данных в формат IFC4, но в случае подготовки модели на госэкспертизу необходимо подготовить собственный файл маппинга (по правилам госэкспертизы). Формат JSON широко распространён, поэтому в создании такого файла не возникнет трудности – существует много редакторов. BIM-менеджер может выбрать по своему вкусу.
Описание классов IFC выполняется следующим образом (Рис. 8):
В наборах описываются параметры по правилу «ключ: значение». «Ключ» – это наименование атрибута модели IFC, в который будет экспортирован атрибут Renga. «Значение» – это наименование атрибута модели Renga, который будет экспортирован в IFC.
Рассмотрим на примере описания объектов «Стена» (IfcWall). Ниже представлена иллюстрация части файла маппинга, созданного по правилам Мосгосэскпертизы, сопоставленная со списком свойств объектов «Стена» модели Renga (Рис. 9)
Класс 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):
В 1-й колонке указывается уникальный идентификатор объекта GUID (это обращение к конкретному экземпляру, в котором произошла ошибка при экспорте). Во 2-й колонке указывается имя объекта Renga. В 3-й колонке указывается класс IFC экспортируемого объекта. В 4-й – причина возникшей ошибки.
Если в журнале есть ошибки – это причина заглянуть ещё раз в файл сопоставления параметров. Возможно, вы просто разместили набор пользовательских свойств, не в той группе атрибутов. И проверить в модели Renga объекты, попавшие в журнал. По GUID вы сможете точно его идентифицировать и проверить все ли атрибуты правильно наименованы, создав, например, по нему фильтр или найти объект по GUID через спецификацию.
В заключении осталось описать ещё одну функциональность, которая решает проблему коллизий, упомянутой во 2-й части статьи. Эта функциональность работает автоматически при экспорте модели в IFC. Теперь все объекты модели экспортируются с учётом подрезок, возникающих от взаимодействия с другими объектами в Renga (взаимодействие между конструктивными элементами: стена – перекрытие, перекрытие – колонна, колонна – балка и т.д.). Эта логика существует в Renga довольно уже давно, она определяет приоритет конструкций во взаимодействиях с другими элементами, например, перекрытие вырезает объём у стены, если мы его заведём во внутрь, смоделировав таким образом опирание, или крыша обрезает верх любых объектов, которые находятся под ней и пересекают её и т.д. (рис. 11).
Эта функциональность поможет избежать коллизий, вызванных взаимопересечением конструктивных элементов здания. Но она не заменит проверку модели в специализированном ПО (например, РусБИМЭксперт, 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.