Россия
с 01.01.2019 по настоящее время
Южно-Российский государственный политехнический университет (НПИ) имени М.И. Платова (Общеинженерные дисциплины, профессор)
с 01.01.1980 по 01.01.2019
Москва, г. Москва и Московская область, Россия
В статье рассмотрен способ выгрузки цифровых информационных моделей по разделам, с помощью разработки IFC маппинга, состоящего из файлов сопоставления, с учётом требований нормативно-технических документов и Московской государственной экспертизы, из консолидированной модели, выполненной в Renga.
информационное моделирование зданий (BIM), Renga, IFC, Json, маппинг, требования к моделям
ВВЕДЕНИЕ
В данной статье рассмотрена автоматизация выгрузки цифровых информационных моделей (ЦИМ) по основным дисциплинам проектирования из консолидированной модели, выполненной в Renga на стадии проектирования. Также предлагаемая методика может быть использована и на других этапах жизненного цикла объекта капитального строительства.
Renga становится всё более популярным программным обеспечением (ПО) в среде проектировщиков. Её функциональность сравнима с устоявшимися решениями на рынке BIM в России, а в некоторых аспектах даже лучше. Это в первую очередь связано с тем, что Renga более молодой продукт и технологии, используемые в основе архитектуры программы, гораздо современнее и более оптимизированные.
Разделение консолидированной модели на разделы по проектной документации возможно с помощью создания IFC маппинга, который позволяет выгрузить только заранее прописанные элементы и их атрибутивные свойства. С помощью IFC маппинга можно настроить сопоставление типов, параметров и слоёв. При экспорте в формат IFC данные файлы сопоставления будут выступать в роли инструкций по тому, как интерпретировать объекты, выполненные инструментами Renga, на языке открытой спецификации IFC. Создание и общий доступ к таким файлам станет ещё одной причиной перехода на отечественный программный продукт для компаний проектировщиков. Что в свою очередь простимулирует экономический рост, так как инвестиции и затрачиваемые средства на ПО, останутся в стране и простимулируют рост отечественных разработчиков программного обеспечения. Разработка такого IFC маппинга решит задачи для ТИМ-специалистов организации, многократно ускорив процесс выдачи ЦИМ заказчику. Написание IFC маппинга ведётся на языке Json с помощью любого текстового редактора или специализированных программных продуктов.
Технический регламент о безопасности зданий и сооружений (с изменениями на 2 июля 2013 года) [1] — один из основополагающих нормативных документов в Российской Федерации в области строительства, даёт несколько важных определений, которые в дальнейшем используются в государственных стандартах по теме ТИМ, а Министерство Строительства Российской Федерации поддерживает развитие и внедрение технологий информационного моделирования. При этом важен учёт требований Московской государственной экспертизы к ЦИМ объектов капитального строительства (ОКС) при разработке файлов сопоставления
Целью работы является ускорение выдачи информационных моделей (ИМ), выполненных в Renga, по разделам проектной и (или) рабочей документации с помощью разработки IFC маппинга, на языке Json в программном продукте Visual Studio Code.
Анализ требований к информационному моделированию объектов капитального строительства в нормативно-технических документах
Основной нормативный документ, описывающий геометрические и атрибутивные требования к ЦИМ ОКС, это СП 333.1325800.2020 «Информационное моделирование в строительстве. Правила формирования информационной модели объекта на различных стадиях жизненного цикла» [2]. Данный свод правил распространяется на ИМ ОКС производственного и непроизводственного назначения, а также линейных объектов, размещаемых в государственной информационной системе обеспечения градостроительной деятельности (ГИСОГД) Российской Федерации и (или) в ГИСОГД субъектов Российской Федерации. Данный документ содержит в себе требования к разработке ЦИМ, а именно: уровням проработки, атрибутивному составу элементов, геометрической детализации элементов и цветовой идентификации элементов и групп элементов.
Анализ требований, предоставляемых Московской государственной экспертизой (МГЭ) к проектной документации
Комитетом города Москвы по ценовой политике в строительстве и государственной экспертизе проектов были утверждены:
- Требования к информационным моделям объектов капитального строительства;
- Классификаторы для информационного моделирования.
Данные требования и классификаторы стали одними из первых требований к ИМ ОКС от органов экспертизы в строительстве, наравне с СПб ГАУ «Центр государственной экспертизы» и ФАУ «Главное управление государственной экспертизы». Было выпущено шесть документов с требованиями и двенадцать документов с классификаторами. Применение подобных требований и классификаторов к ИМ ОКС в перспективе многократно увеличит скорость и качество прохождения экспертизы проектной документацией за счёт автоматизированных проверок решений органами, осуществляющими экспертизу проектов.
Требования к архитектурным решениям
Требования к ЦИМ раздела АР сформулированы для ЦИМ ОКС непроизводственного назначения нескольких назначений. Данный документ включает в себя следующие примеры требований:
- Требования к ЦИМ архитектурных решений здания. Структура требований к ЦИМ архитектурных решений здания приведена на Рис. Все элементы ЦИМ должны быть однозначно классифицированы с помощью кодов классификаторов МССК. Требования к моделированию, на примере колонны: колонны должны иметь точное местоположение и ориентацию в модели, точные места примыкания, иметь фактическую конструктивную форму и размеры. Колонны должны быть смоделированы, включая дополнительные несущие и объемные декоративные элементы (капители и пр.). Колонны должны быть представлены классом (IfcColumn).
Рис. 1. Требования к ЦИМ архитектурных решений
- Требования к информационному наполнению ЦИМ раздела АР. Данные требования к параметрам представляют из себя перечень необходимых параметров для следующих основных категорий элементов цифровой информационной модели: Помещения и зоны; Вспомогательные 3D-тела; Стены и перегородки; Навесные фасады; Перекрытия; Покрытия, отделка; Колонны; Двери; Окна; Лестницы; Пандусы и рампы; Ограждения; Сборки.
Итог анализа требований
Согласно приведённым выше примерам требований к ЦИМ ОКС можно сделать следующие выводы:
- Требования к геометрической проработке элементов цифровой информационной модели не столь обширны и строги как требования к атрибутивной составляющей. Их можно обобщить следующим образом:
- Должны быть определены границ элементов и границ материалов элементов. Должны быть проработаны узлы сопряжения с другими элементами;
- Элементы цифровой информационно модели должны быть выполнены с определённым минимальным уровнем детализации;
- В цифровой информационной модели должны быть проверены и исправлены коллизий пересечения, открывания и рабочей зоны;
- Требования к атрибутивной проработке элементов ЦИМ представлены строже и детальнее, чем требования к геометрии элементов. Есть обязательные требования к атрибутам элементов ЦИМ как со стороны нормативно-технических документов, так и со стороны требований Московской государственной экспертизы;
- Основной упор при разработке IFC маппинга будет направлен на проработку требований к атрибутивной составляющей ЦИМ ОКС административного значения.
Разработка скриптов для выгрузки модели
Одними из целей применения ТИМ/BIM-технологий в строительстве являются: уменьшение времени на выпуск проектной документации, и увеличение её качества в связи с использованием технологий информационного моделирования (ТИМ). Эти цели не достижимы при использовании старого, последовательного проектирования, когда проектировщики инженерных систем должны были ждать, пока будут согласованны архитектурные планы и разрезы, чтобы приступить к разработке собственного раздела проектной документации. Современный, последовательно-параллельный подход к разработке разделов позволяет проектировщикам инженерных систем начать работу, когда архитектурная часть находится ещё в проработке. Такое возможно благодаря ТИМ/BIM-подходу в проектировании, который позволяет максимально быстро и с минимальными трудозатратами исправить проектное решение.
Работа всех специалистов над информационной моделью объекта капитального строительства производится совместно, это подразумевает параллельное наполнение модели информацией всеми участниками проектирования. Сценарий совместной работы в Renga предполагает работу проектировщиков различных специальностей в едином, синхронизованном файле проекта, через собственные локальные копии файла проекта (Рис. 2). При таком способе организации совместной работы у каждого проектировщика есть возможность редактирования всей модели, то есть доступно редактирование разделов другой специальности.
Рис. 2. Совместная работа в Renga
Существует несколько подходов для организации параллельной работы в любом, не только строительном, программном обеспечении:
- Оптимистичный контроль параллелизма (Optimistic concurrency control). Предполагается, что изменения, полученные от разных пользователей при работе приложения, могут применяться, не мешая друг другу. Именно этот подход используется в Renga.
- Пессимистичный контроль параллелизма (Pessimistic concurrency control). Предполагается, что два или более пользователя обновляют одни и те же данные одновременно, что приводит к конфликту.
- Выигрывает последний (Last writer wins). В этой стратегии данные просто перезаписываются последним.
После завершения работы над ЦИМ ОКС всеми участниками проектирования, проектировщик отправляет модель заказчику для её участия на следующих этапах жизненного цикла здания. Модель передаётся в объеме и форматах, предусмотренных заранее в информационных требованиях заказчика (EIR), в котором зачастую прописывается разделение модели по разделам проектной документации на отдельные файлы ЦИМ.
Выполнить такое разделение консолидированной модели в Renga можно как раз с помощью IFC маппинга, который состоит из файлов сопоставления, написанных на скриптовом языке Json. На Рис. 3 приведён скриншот окна настроек Renga для экспорта ЦИМ в формат IFC, где как раз видны файлы сопоставления, которые идут первыми тремя строками.
Рис. 3. Окно настроек экспорта в формат IFC в Renga
IFC маппинг и файлы сопоставления
Industry Foundation Classes (IFC, отраслевые базовые классы) — формат данных с открытой спецификацией, которая не контролируется ни одной компанией или группой компаний. Формат файла разработан buildingSMART (International Alliance for Interoperability, IAI) для упрощения взаимодействия в строительной промышленности.
Renga поддерживает на импорт оба официальных формата, а на экспорт только IFC4. Такое решение принято на основании того, что отечественная экспертиза принимает ЦИМ только в формате IFC4.
IFC маппинг заключается в том, чтобы сопоставить два описания объекта и его свойств: описание в соответствии с открытой спецификации IFC и описание в инструменте разработке, в данном случае в Renga. Большая часть такого сопоставления выполняется автоматически. Пользователи Renga могут задавать какие свойства объектов передавать в IFC в зависимости от цели, а также при необходимости переопределять типы объектов. Такой подход позволит при создании проекта выполнить все требования. предъявляемые государственной экспертизой к цифровой модели или определить модельный вид для других задач.
Определение модельного вида (Model View Definition (MVD)) — определяющее подмножество схемы IFC, которое необходимо для удовлетворения одного или нескольких требований по обмену информацией в строительстве.
Все, представленные на рынке, ТИМ/BIM-системы, в том числе и отечественные, содержат в себе инструменты объектного моделирования, которые в большей или меньшей степени соответствуют классам в спецификации IFC. Но не в одной из них не представлен полный список всех инструментов в соответствии со всеми классами IFC, что логично, поскольку, например, IFC4 состоит более чем из 800-та классов. Такое большое количество инструментов в любой BIM-системе сделает его совершенно не пригодной в работе с ЦИМ.
Файл сопоставления типов позволяет сопоставить целиком все объекты, выполненные определённым инструментом Renga, соответствующим классам IFC, например Стена – IfcWall, Колонна – IfcColumn, Перекрытие – IfcSlab и т.д. Данная операция возможна, благодаря тому, что в Renga есть соответствующие константы инструментов объектного моделирования (идентификатор на все объекты, выполненные определённым инструментом). Синтаксис Json в данном случае использует форму – массив. Пример файла сопоставления типов приведён на Рис. 4.
Рис. 4. Пример Файла сопоставления типов
Файл сопоставления параметров (Рис. 5) позволяет сопоставить свойства, параметры и расчётные характеристики объектов Renga со спецификацией IFC. Синтаксис Json в данном случае использует форму – объект. Пример файла сопоставления параметров представлен на Рис. 5.
Свойства (атрибуты) — это информация, с различными типами данных (действительное число, целое число, строка, длина, площадь, объём, масса, угол, булевый, логический, перечисление), об объекте.
Параметры — это информация, которая влияет на форму объекта (высота, ширина, наклон и т.д.), а также на некоторые расчётные характеристики (материал влияет на массу).
Расчётные характеристики — это информация, которая получается исходя из геометрических и параметрических составляющих объекта (объём, площадь поверхности, масса и т.д.).
Рис. 5. Пример файла сопоставления параметров
Файл сопоставления объектов слоям (Рис. 6) позволяет сопоставить определённые типы объектов в слой IFC. Разделение объектов по слоям поможет в навигации и поиске при последующей работе с цифровой информационной моделью. Синтаксис Json в данном случае использует форму – массив. Пример файла сопоставления объектов слоям представлен на Рис. 6.
Рис. 6. Пример файла сопоставления объектов слоям
Данные три файла сопоставления, работая вместе, представляют собой IFC маппинг в Renga при экспорте цифровой информационной модели в формат IFC4.
Синтаксис Json
Json — текстовый формат обмена данными, основанный на JavaScript. Как и многие другие текстовые форматы, JSON легко читается людьми, а машины легко анализируют и генерируют его.
Json построен на двух структурах:
- Коллекция пар имя/значение. В различных языках это реализуется как объект, запись, структура, словарь, хэш-таблица, список с ключами или ассоциативный массив.
- Упорядоченный список значений. В большинстве языков это реализовано в виде массива, вектора, списка или последовательности.
Это универсальные структуры данных. Практически все современные языки программирования поддерживают их в той или иной форме. Имеет смысл, чтобы формат данных, взаимозаменяемый с языками программирования, также основывался на этих структурах.
В Json структуры принимают следующие формы:
- Объект представляет собой неупорядоченный набор пар имя/значение. Объект начинается с левой фигурной скобки и заканчивается правой фигурной скобкой. За каждым именем следует двоеточие, а пары имя/значение разделяются запятой.
- Массив — это упорядоченный набор значений. Массив начинается с левой квадратной скобки и заканчивается правой квадратной скобкой. Значения разделяются запятой.
- Значение может быть строкой в двойных кавычках, или числом, или true, или false, или null, или объектом, или массивом. Эти структуры могут быть вложенными.
- Строка — это последовательность из нуля или более символов Unicode, заключенная в двойные кавычки и использующая символы обратной косой черты. Символ представлен в виде одной строки символов. Строка очень похожа на строку C или Java.
- Число очень похоже на число C или Java, за исключением того, что восьмеричный и шестнадцатеричный форматы не используются.
- Пробелы могут быть вставлены между любой парой токенов. За исключением нескольких деталей кодировки, это полностью описывает язык.
Разработка скрипта выгрузки модели архитектурных решений административного здания
В качестве основы для написания файлов сопоставления были взяты шаблоны из дистрибутива Renga. Мною были написаны следующие файлы сопоставления:
- Файл сопоставления параметров архитектурного раздела;
- Файл сопоставления типов архитектурного раздела.
Файл сопоставления параметров архитектурного раздела
Файл сопоставления параметров будет рассмотрен на примере сопоставления класса IfcCurtainWall, то есть на примере навесной стены. Он представляет из себя набор из трёх основных категорий:
- Атрибуты (attributes). Категория не содержит в себе наборы, атрибуты IFC сразу сопоставляются с атрибутами Renga (Рис. 7);
Рис. 7. Атрибуты навесного фасада
- Наборы свойств или параметры (pset – Property Sets). Категория содержит в себе набор из спецификации IFC и специальный набор, требуемый московской государственной экспертизой (Рис. 8). Набор Pset_CurtainWallCommon содержит в себе общие свойства или параметры навесной стены. Свойства в наборе ExpCheck_CutrainWall имеют специальный префикс в виде «MGE_» для наименований свойств в файле IFC и префикс «МГЭ_» для наименований свойств в инструменте разработки. Собственно и сам набор имеет специальный префикс «ExpCheck_», поскольку является пользовательским, то есть не входит в стандартную спецификацию IFC, использования префикса «Pset_» в данном случае не допустимо;
Рис. 8. Наборы свойств навесной стены
- Наборы геометрических характеристик (qsets – Quantiti Sets). Категория содержит в себе наборы в соответствии со спецификацией IFC. Конкретно навесная стена содержит один набор базовых геометрических составляющих Qto_CurtainWallBaseQuantities (Рис. 9).
Рис. 9. Набор геометрических характеристик навесной стены.
Файл сопоставления типов архитектурного раздела
Файл сопоставления типов архитектурного раздела представляет из себя сопоставление классов IFC и констант элементов в Renga. На Рис. 10 приведён фрагмент кода сопоставления типов архитектурного раздела. В данном файле приведены элементы, относящиеся к архитектуре в соответствии со спецификацией IFC и общие элементы, например, уровень (IfcBuildingStorey) или материал (IfcMaterial).
Рис. 10. Фрагмент кода сопоставления типов архитектурного раздела
Апробация результатов выгрузки информационных моделей
Для апробации результатов разработки скриптов выбрана ЦИМ повторного применения административного назначения — Дворец бракосочетаний. Данный проект включён в Реестр экономически эффективной проектной документации Минстроя России, и представляет из себя проектную документацию, по которой была создана ИМ в Renga в формате «.rnp», которая может быть адаптирована или использована в качестве основы при разработке нового проекта.
В ЦИМ (Рис. 11) осуществлено моделирование следующих разделов документации: Архитектурные решения; Конструктивные решения; Силовая электрическая сеть; Осветительная сеть; Водоснабжение и канализация; Отопление вентиляция и кондиционирования.
Рис. 11. Дворец бракосочетаний в Renga
Поскольку данный проект является проектом повторного применения, существует его возведённый в 2018 г. вариант в городе Бобров Воронежской области, представленный на Рис. 12.
Рис. 12. Дворец торжеств в городе Бобров
Выбирая соответствующие файлы сопоставления параметров и файлы сопоставления типов в настройках экспорта Renga были выгружены следующие цифровые информационные модели в формате IFC: ЦИМ архитектурных решений; ЦИМ конструктивных решений; ЦИМ всего инженерного оборудования и сетей; ЦИМ электрических систем; ЦИМ вентиляционной системы; ЦИМ систем, работающих с водой. В данной статье описана методика выгрузки архитектурных решений.
Цифровая информационная модель архитектурных решений
Цифровая информационная модель архитектурных решений в формате IFC представлена на Рис. 13, в специальном средстве просмотра IFС-моделей (вьювере) BIMvision.
Рис. 13. IFC-модель архитектурных решений
Атрибуты, параметры и геометрические характеристики, которые были указаны в файле сопоставления параметров видны как во вьювере (Рис. 14) так и в самом IFC-файле (Рис. 15).
Рис. 14. Атрибуты, параметры и геометрические характеристики, видимые во вьювере
Рис. 15. Атрибуты, параметры и геометрические характеристики, видимые в самом IFC-файле
Консолидированная цифровая информационная модель
Выгруженные цифровые информационные модели по основным дисциплинам были собраны в отечественной среде общих данных Pilot-BIM (Рис. 16).
Среда общих данных (СОД, Common Data Enviroment – CDE) — единый источник информации для любого отдельно взятого проекта или актива, предназначенный для сбора, управления и распространения каждого информационного контейнера с помощью управляемого процесса.
Рис. 16. Цифровые информационные модели в СОД Pilot-BIM
В СОД Pilot-BIM были выполнены выборочные проверки на коллизии пересечения ЦИМ различных разделов. Проверки на коллизии в Pilot-BIM осуществляются с помощью журналов проверки, который представлен на Рис. 17. В разделе «Проверяемые части модели» можно выбрать два набора IFC-файлов, которые будут проверяться на пересечение. Раздел «Только для указанных классов IFC» предназначен для точного указания интересуемых классов IFC, если поле остаётся пустым, то проверяться будут все классы. В разделе «Считать слабыми пересечения до» можно указать значение пересечений, которые не будут считаться за коллизию. Согласно слабыми пересечениями можно считать пересечения меньше 80 мм.
Рис. 17. Настройки журнала проверки на коллизии пересечения
ЗАКЛЮЧЕНИЕ
По итогам выполненной работы можно сделать несколько выводов:
- Текущее состояние нормативно-технической документации предоставляет больше атрибутивных требований к цифровым информационным моделям, чем геометрических. Такая же тенденция наблюдается в требованиях Московской государственной экспертизы;
- Уменьшение времени подготовки цифровых информационных моделей, полученных из Renga, к прохождению экспертизы, напрямую влияет от правильно написанного IFC маппинга;
- Выгрузка цифровых информационных моделей по основным дисциплинам проектной документации позволяет более гибко использовать преимущества технологии информационного моделирования на последующих жизненных циклах здания.
В ходе работы были изучены основные синтаксические конструкции скриптового языка Json.
Были поставлены и решены следующие задачи:
- Разработан IFC маппинг под основные дисциплины проектной и (или) рабочей документации ЦИМ ОКС административного назначения;
- Были учтены требования Московской государственной экспертизы к ЦИМ ОКС административного назначения при разработке файлов сопоставления;
- Были выгружены IFC-модели по основным дисциплинам проектной и (или) рабочей документации.
1. Федеральный закон «Технический регламент о безопасности зданий и сооружений (с изменениями на 2 июля 2013 года)» №384-ФЗ. Принят Государственной Думой Федерального собрания Российской Федерации 30.12.2009 [Электронный ресурс] Режим доступа: https://minstroyrf.gov.ru/docs/1241/ Дата обращения 03.04.2022;
2. СП 333.1325800.2020 Информационное моделирование в строительстве. Правила формирования информационной модели объектов на различных стадиях жизненного цикла. Принят Минстроем России 31.12.2020 [Электронный ресурс] Режим доступа: https://www.minstroyrf.gov.ru/docs/120028/ Дата обращения 03.04.2022;
3. Кирьян, Е. Проходим госэкспертизу информационной модели правильно! / Е. Кирьян // САПР и графика. - 2020. - № 11(289). - С. 28-35. - EDN WTYGQW;
4. Экспертиза проектов на основе информационной модели / Н. А. Шушкевич, А. И. Мохов, А. Ю. Крупский, А. С. Нургазиева // Интернет-журнал Науковедение. - 2010. - № 3(4). - С. 14. - EDN TEUIBH;
5. Лазарева, Н. В. Регламентация выполнения работ при помощи информационных моделей в составе строительно-технической экспертизы / Н. В. Лазарева, А. Ю. Зиновьев // Промышленное и гражданское строительство. - 2020. - № 11. - С. 105-109. - DOIhttps://doi.org/10.33622/0869-7019.2020.11.105-109. - EDN VISFKF;
6. Нечипоренко, М. Опыт создания информационной модели общеобразовательной школы для эксперимента по прохождению экспертизы / М. Нечипоренко // Сантехника, Отопление, Кондиционирование. - 2020. - № 6(222). - С. 10-12. - EDN PIBSTZ;
7. Давыдов, Д. Н. Каковы будут главные требования к цифровым информационным моделям для прохождения экспертизы? / Д. Н. Давыдов // АВОК: Вентиляция, отопление, кондиционирование воздуха, теплоснабжение и строительная теплофизика. - 2018. - № 2. - С. 70-75. - EDN TETXBD;
8. Лазарева, Н. В. Использование информационных моделей при проведении строительно-технических экспертиз / Н. В. Лазарева, А. Ю. Зиновьев // Инженерно-строительный вестник Прикаспия. - 2022. - № 1(39). - С. 105-111. - DOIhttps://doi.org/10.52684/2312-3702-2022-39-1-105-110. - EDN CZARQA;
9. Белоносов, Д. Н. Экспертиза цифровых моделей и контроль проектных решений по технологии информационного моделирования / Д. Н. Белоносов // Современные инновации. - 2019. - № 1(29). - С. 36-39. - EDN FUQPPW.
