Информационная модель объекта капитального строительства пример

ГрК РФ Статья 57.5. Информационная модель объекта капитального строительства (введена Федеральным законом от 27.06.2019 N 151-ФЗ) 1. Застройщик, технический заказчик, лицо, обеспечивающее или осуществляющее подготовку обоснования инвестиций, и (или)…

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

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

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

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

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

2020

2024

2030

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

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

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

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

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

2020

2024

2030

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

«…не допускаются проектные ошибки (коллизии) превышающие 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 есть достаточно функционала, чтобы максимально ускорить этот процесс. Об этом уже было много написано и сказано [8], поэтому мы не будем останавливаться на этом.

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

Поскольку экспертиза ИМ проходит в формате IFC, то все объекты модели должны быть экспортированы по соответствующим классам, описанным в IFC. Стандартное модельное представление Reference View 1.2 (IFC4 RV-1.2) [9], в соответствии с которым сформированы требования госэкспертизы, описывает 16 классов архитектурных элементов здания, 12 классов конструктивных, 65 классов элементов внутренних инженерных систем, в совокупности по основным специальностям (водоснабжение/водоотведение, отопление, вентиляция, электрика, автоматизация) и ещё дополнительно 18 классов элементов, к которым относятся, например, помещения (IfcSpace) или уже рассмотренный нами класс – здание (IfcBulding). Итого более 100 классов! Возникает резонный вопрос: как всё это многообразие замоделировать имеющимися инструментами? Ответ простой – моделируйте так, как Вам удобнее. Мы переопределим класс объекта при экспорте!

Вот пример, как мы можем это сделать с архитектурными элементами. Согласно требованиям, напольное покрытие (полы) должно быть выгружено в IFC под классом IfcCovering, а, например, наружный навесной вентилируемый фасад – под классом IfcCurtainWall. Таких кнопок в Renga пока нет, но они и не нужны (для задачи прохождения госэкспертизы). Можно смоделировать полы отдельным перекрытием (даже нужно), а наружный фасад – второй стеной со своими слоями конструкции.

Следующий шаг – на объекты модели, класс которых мы хотим переопределить, мы должны добавить следующие пользовательские свойства (тип данных — строка):

• • IfcEntityType – Свойство, необходимое для переопределения типа объекта.
  • IfcObjectType – Свойство задается только с том случае, если пользователь задал предопределенный тип USERDEFINED в свойствах экземпляра объекта.
  • IfcElementType – Свойство задается только с том случае, если пользователь задал предопределенный тип USERDEFINED в свойствах стиля объекта.

  Эти три свойства в IFC описывают класс элемента и уточняют его тип (в соответствии с описанием класса). Эти свойства обязательны при переопределении и если им будут присвоены значения, то объекты экспортируются под новым классом и типом (рис. 5).

  

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

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

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

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

  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», каждый из которых имеет набор атрибутов. Откуда они взялись? Из требований Мосгосэкспертизы [11]. По той же причине в группе «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 – очень обширна, и мы только начали погружение в этот мир. Остаемся на связи. А пока скачивайте Renga и учитесь создавать модель так, чтобы ее можно было передать на экспертизу.

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

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

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

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

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

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

  Требования к формированию информационных моделей объектов капитального строительства для эксплуатации многоквартирных домов, реализованных по проектам повторного использования». Разработка методических пособий. Методы классификации задач информационного моделирования. … Пример требования. Разрабатывая компоненты всегда надо иметь в виду, что они создаются для виртуального представления физического элемента в цифровой информационной модели , а не для его изготовления на заводе. Геометрия компонента должна быть минимально необходимая для его визуального определения в модели .

  Общая схема информационной модели объекта строительства

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

  

  Информационное моделирование – это процесс, результаты каждого этапа которого, то есть информационные модели здания, сильно отличаются друг от друга в зависимости от стадии жизненного цикла объекта и тех требований, которые предъявляются к моделированию при решении возникающих задач [2]. Да и сам строительный объект сильно зависит от стадии своего существования: если при проектировании он виртуален, а во время строительства постепенно обретает «телесный» вид, то на долгом этапе эксплуатации здание наконец входит в пору «стабильности» и уже не подвержено значительным изменениям [3]. Так что информационная модель – объект весьма переменчивый, зависящий от круга решаемых задач. И всё же наработанный опыт использования BIM позволяет говорить о некоторой общей структуре информационной модели здания.

  В работе [4] приводится структура информационной модели памятника архитектуры. Однако внимательное её рассмотрение позволяет сделать вывод, что такая схема построения модели с необходимыми пояснениями пригодна и для информационного моделирования любого объекта строительства, вне зависимости от того, на какой стадии жизненного цикла он находится.

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

  

  Рис. 1. Информационная модель объекта строительства: её составные части и связи между ними.

  Такая модель по общепринятой классификации считается гибридной, поскольку состоит из компьютерных объектов разной природы и предназначения [2]. Руководствуясь основными принципами BIM [5], дадим к этой схеме некоторые пояснения.

  Основная геометрически-информационая часть, основной раздел модели,является:

  1. Непосредственным хранилищем некоторой геометрически-схематической и иной информации об объекте.
  2. Основой для качественного и количественного анализа объекта.
  3. Интерфейсом доступа к информации модели, в том числе и находящейся в других её частях.

  Геометрически-информационная часть – основной «контейнер» модели, который наполняется информацией непосредственно или через привязанные ссылки. Главные задачи этого контейнера – организация структуры хранения информации и предоставление возможности интерактивной работы с ней, а также пространственная (преимущественно трехмерная) визуализация основной части этой информации. При этом инструментарий обработки информации в модели не содержится, он целиком представлен в программе (программах) работы с моделью (или её частями) и постоянно совершенствуется вне зависимости от модели. Это полностью соответствует основным принципам информационного моделирования [5].

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

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

  Во-вторых, геометрическая модель – это своеобразный трехмерный «путеводитель» по информации об объекте строительства, предоставляющий и облегчающий визуальный контакт пользователя с заложенными в модель данными.

  

  Рис. 2. Информационная модель Зашиверской церкви: один из элементов геометрической модели и открывающееся диалоговое окно доступа к его свойствам (заложенным в модель данным) [8].

  Основное облако точек – это результат лазерного сканирования или фотограмметрической обработки объекта. Такое облако точек, реализованное набором их трёхмерных координат — обязательный элемент информационной модели, являющийся носителем «реальных» данных о геометрии объекта. Технологически облако точек хранится отдельно и привязывается к геометрической модели ссылкой, но при необходимости оно может вставляться в геометрическую модель. Именно сравнение полученных в разное время облаков точек позволяет осуществлять геодезический контроль за объектом строительства, как существующим, так и возводимым, и количественно характеризовать динамику процессов строительства и эксплуатации.

  Что касается стадии проектирования или даже предпроектной проработки объекта, то и здесь облако точек при необходимости может присутствовать, например, в качестве съемки участка местности и объектов окружения.

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

  Аналогичным образом к модели присоединяются, например, схемы используемого в здании оборудования или регламенты по его обслуживанию. Эти документы вообще могут храниться на сайте производителя оборудования и прикрепляться к модели ссылками, что гарантирует актуальность всей перечисленной документации. Последнее особенно важно при совмещении BIMс концепцией «зеленого строительства» [9].

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

  

  Рис 3. Информационная модель храма Шенмудянь в Китае: узлы системы доугун первого и второго этажей из модели показывают «идеальную» схему сборки кронштейнов, но они не передают реального состояния каждого из них [10].

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

  Конечно, моделирование каждого объекта строительства весьма индивидуально как по специфике сооружения, так и по характеру решаемых задач. Но понимание общей схемы построения информационной модели здания позволяет как экономить время при организации индивидуального процесса моделирования, так и создает основу для объединения информационных моделей отдельных объектов в единую информационную систему, в частности, является обязательным шагом к реализации концепции «умного города».

  Пример информационной модели , созданной по разработанному шаблону проекта. Регламент работы. Подготовка файлов IFC. … СТРОИТЕЛЬСТВО . Кафедра информационных систем, технологий и автоматизации в строительстве . Исполнительная информационная модель . Строительного объекта . … И88 Исполнительная информационная модель строительного объекта [Электронный ресурс] : методические указания к выполнению курсовой работы/проекта для обучающихся по направлению подготовки 08.04.01 Строительство / сост.

  Источники

  • https://rengabim.com/stati/prohodim-gosekspertizu-informacionnoj-modeli-pravilno/
  • http://www.consultant.ru/document/cons_doc_LAW_51040/06616d8bc3e2a55716e03b389946a91b9c4554b6/
  • https://ardexpert.ru/article/8680