Привет, друзья!

Сегодня поговорим о разных видах проверок информационной модели в среде общих данных Pilot-BIM. Среди них: поиск пересечений объектов модели, проверки атрибутов элементов на соответствие требованиям, вычислительные проверки и визуальный контроль модели.

Проверки модели на геометрические коллизии

Цель проверки — найти ошибочные пересечения элементов модели.

Задача: Проверить пересечения стен с сантехническим оборудованием.

Первым шагом является построение поисковых наборов, которые предназначены для выделения в дереве модели и в 3D-окне объектов, соответствующих заданным условиям поиска.

В условиях поиска мы должны задать:

• Логический оператор И или ИЛИ;

• Категорию IFC‑свойств;

• Атрибут, соответствующий выбранной категории;

• Оператор условия для сравнения;

• Значение.

Примечание: При формировании более сложных поисковых наборов добавляются вложенные группы, результаты журналов проверки на пересечения.

Условие поиска для всех стен консолидированной модели:

— И
  — <Все категории> ; Type [string ] ; равно ; IfcWall

Это условие найдет все стены, у которых IFC Type имеет значение IfcWall. Этот вариант является приемлемым, если в вашей модели стены и вправду имеют только такой тип и никакой больше, но на практике это не всегда так. Для обеспечения более надежного отбора целесообразно использовать оператор содержит:

— И
  — <Все категории> ; Type [string ] ; содержит ; Wall

Оператор условия "Содержит" отберет все элементы, у которых в свойстве IFC Type присутствует подстрока "Wall".

Шаг 2. Сохраняем первый поисковый набор под именем «Все стены».

Шаг 3. Задаем значения для второго поискового набора. В данном примере у нас модель с сантехническими приборами представлена в виде отдельной части консолидированной модели, следовательно мы можем представить поисковый набор в виде всей этой части.
Для этого в условиях поиска вводим:

— И
  — Общие свойства ; ModelPartName [string ] ; равно ; Plumbing

Примечание: В общих свойствах во всех элементах моделей, построенных в Pilot-BIM, отображаются GlobalId, ModelPartId, ModelPartName, Name, ParentId, PartOf, Type. ModelPartName - наименование части консолидированной модели. Подробнее см. в справке.

Шаг 4. Сохраняем второй поисковый набор под именем "Все сантехнические приборы".

Шаг 5. Переходим к созданию журнала пересечений.

В разделе "Проверки модели" создадим новый журнал, назовем его "Пересечение стен с сантехническим оборудованием". В поисковом наборе А добавим "Все стены", в поисковом наборе Б "Все сантехнические приборы", нажмем ОК и запустим проверку.

По окончанию проверки у нас сформируется журнал, каждая запись которого имеет следующий формат:

1 - Номер коллизии. Присваивается системой автоматически, является уникальным значением в пространстве данного журнала;
2 - Первый IfcType найденного элемента коллизии;
3 - Второй IfcType найденного элемента коллизии;
4 - Объем тела пересечения;
5 - Состояние коллизии.

Примечание: В Pilot-BIM обязательны два системных состояния — это "Найдено" и "Исправлено", которые не должны быть удалены. Ещё есть состояние "Не требует исправления" — оно может быть выставлено у коллизий, чьи статусы отслеживать не надо, а также мы можем создавать свои статусы, но у них обязательно должны быть обеспечены переходы в состояния "Найдено" и "Исправлено".

Выбор конкретной записи автоматически подсвечивает соответствующее пересечение в модели.

Шаг 6. После исправления коллизии в исходной BIM-модели мы загружаем в Pilot-BIM новую версию ifc-файла и перестраиваем журнал пересечений.
В журнале сохраняются все коллизии, которые мы получили изначально. Исправленные коллизии имеют статус "Исправлено". Это позволяет верифицировать факт устранения каждого конкретного пересечения.

Примечание: На основе журналов проверок на пересечения доступно построение отчетов. К базовым относятся «[BIM] Журнал проверок модели» и «[BIM] Матрица пересечений». Кроме того, для опытных пользователей предусмотрена возможность расширения функциональности журналов: с помощью скриптов на C# и форм DevExpress можно добавить дополнительные поля, такие как идентификаторы IFC пересекающихся объектов, расчетный объем пересечения и другие параметры.

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

Задача: Проверить пересечения стен, расположенных на уровне паркинга, с канализационной системой.

Шаг 1. Первый поисковый набор "Стены на уровне паркинга".

— И
  — Общие свойства ; PartOf [guid] ; равно ; 02a23a8b-94c1-452d-91fe-64065945a683
  — <Все категории> ; Type [string ] ; содержит ; Wall

Это условие найдет все стены, которые расположены на уровне, имеющем Globalld (readable) 02a23a8b-94c1-452d-91fe-64065945a683, в нашем случае этот уровень — "Паркинг".

Примечание:
PartOf[guid] позволяет выбирать все дочерние элементы указанного объекта по Globalld (readable).

Шаг 2. Второй поисковый набор "Канализационные системы".

— И
  — Общие свойства ; ModelPartName [string ] ; равно ; Plumbing
  — ИЛИ
    — <Все категории> ; Тип системы [string ] ; равно ; Sanitary
    — <Все категории> ; Классификация систем [string] ; равно ; Канализация

Это условие найдет объекты, которые относятся к части консолидированной модели с именем Plumbing, и при этом для него выполняется одно из условий по группе ИЛИ: значение свойства "Тип системы" равно "Sanitary" или значение свойства "Классификация систем" равно "Канализация".

Шаг 3. На основе созданных поисковых наборов формируется журнал проверки. Данный журнал фиксирует коллизии между стенами уровня паркинга и элементами канализационных систем.

При таком разделении коллизий по разным журналам уже на этапе создания условий для поискового набора мы имеем ряд преимуществ:

• Высокая эффективность и гибкость проверок. Например, можно создать два отдельных журнала проверки пересечений инженерных систем со стенами. В первом журнале будут отслеживаться только пересечения канализационных систем со стенами, а во втором - только пересечения водопроводных систем со стенами;

• Компактные журналы работают быстрее, чем огромные.

Проверки информационной наполненности модели

Этот вид проверок нужен для проверки атрибутивных данных BIM-модели на предмет их наличия, заполненности или соответствия установленным требованиям. Эти требования могут быть определены в документации заказчика (EIR) или регламентироваться стандартами.

Задача: Найти помещения, у которых не заполнены атрибуты: «Номер помещения», «Площадь помещения», «Отделка пола». Уровень помещения должен быть L1, L2, Ln или Parking.

Как и в случае с поиском геометрических коллизий, информационные проверки начинаются с формирования поисковых наборов.

Разберёмся по порядку:

1. Создаем поисковый набор для всех помещений «Все помещения„. Он будет служить нам базовой выборкой, к которой в дальнейшем будут применены проверки.“»

— И
  — Другая ; Категория [string] ; равно ; Помещения

2. Для выполнения проверок необходимо создать специализированные поисковые наборы для каждого атрибута — «Номер помещения», «Площадь помещения» и «Отделка пола». В эти наборы попадут только те помещения, у которых указанный атрибут заполнен.

• Помещения, у которых определен атрибут «Номер помещения»

— И
 — <Все категории> ; Категория [string] ; равно ; Помещения
 — Идентификация ; Номер [string] ; определено

• Помещения, у которых определен атрибут «Площадь помещения»

— И
 — <Все категории> ; Категория [string] ; равно ; Помещения
 — Размеры ; Площадь [double] ; определено

• Помещения, у которых определен атрибут "Отделка пола"

— И
 — <Все категории> ; Категория [string] ; равно ; Помещения
 — <Все категории> ; Отделка пола [string] ; определено

• Помещения, у которых уровень должен быть L1, L2, Ln или Parking

— И
 — Другая ; Категория [string] ; равно ; Помещения
 — ИЛИ
    — Зависимости ; Уровень [string] ; паттерн ; L*
    — Зависимости ; Уровень [string] ; равно ; Parking

Примечание: При составлении выражения при помощи паттерна используется символ "", заменяющий несколько любых символов подряд, и символ ?, заменяющий один любой символ.

Примечание: Для группировки поисковых наборов используйте папки поисковых наборов.

3. Создаем журнал проверки информационной наполненности.

В окне "Выборка элементов для проверки" добавляем поисковый набор "Все помещения";
В окне "Список проверок информационной модели" добавляем поисковые наборы созданные для проверки;
Нажимаем "ОК" и запускаем проверку.

Система найдёт вcе объекты по набору “Все помещения” и проверит их на условия, указанные в наборах для проверки (наличие атрибутов “номер”, “площадь” и т.д.). Технически Pilot-BIM сравнивает выборку элементов по набору “Все помещения” с элементами по всем наборам из списка проверок. Те элементы, которые не входят в общую выборку (то есть не соответствуют условиям всех указанных наборов) и считаются ошибочными.

Примечание: В технической терминологии данная операция называется разностью множеств.
Визуально это можно представить как:
{Все помещения} - {Помещения с номерами} = {Помещения без номеров}
{Все помещения} - {Помещения с площадью} = {Помещения без площадей}
{Все помещения} - {Помещения с отделкой пола} = {Помещения без отделки пола}
{Все помещения} - {Помещения с соответствующими уровнями} = {Помещения без соответствующих уровней}

Результат выполнения проверки:

• 2 объекта не имеют заполненного атрибута «Номер помещения»;

• 3 объекта не имеют указанной отделки пола;

• 1 объект не имеет заполненной площади;

• У 3 объектов значение атрибута уровня не соответствует заданным в условиях проверки.

Выбор конкретной записи автоматически подсвечивает соответствующий объект в дереве объектов модели. По результату проверки можем построить базовый отчет «[BIM] Журнал проверок информационной наполненности».

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

Вычислительные проверки

Под этим видом проверок подразумеваются проверки, которые требуют определенных вычислений с атрибутами объектов.

Задача: Определить квартиры, у которых соотношение жилой площади к общей отклоняется от диапазона 0.6-0.7

Для таких проверок могут быть использованы отчеты.
Для решения задачи был модифицирован базовый отчет "[BIM] Ведомость окон и дверей по модели". Исходники по скрипту с отчетом прикладываю на GitFlic по ссылке.

Скрипт анализирует помещения (IfcSpace), группируя их по номерам квартир (NumberFlat), рассчитывает для каждой квартиры соотношение жилой площади к общей (CalculatedRatio()) и отображает отклонение от нормы (DeviationStatus()).

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

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

Визуальный контроль модели

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

Задача: визуально оценить расположение оборудования и привлечь подрядчика для обсуждения, проверить ширину проходов между оборудованием.

Используем следующие инструменты:

• Плоскости и куб сечения — рассекаем модель, чтобы «добраться» до внутренней конфигурации конструкций и оборудования. С помощью клавиш QE и WASD перемещаемся по модели.

• Инструменты измерения размеров — измеряем кратчайшее расстояние между зданиями в местах проезда и ширину дверных проёмов.

• Точки взгляда — фиксируем вид на рассечённую модель, чтобы скопировать ссылку на него и поделиться с подрядчиком.

Комплексное применение всех видов проверок в среде Pilot-BIM выводит контроль качества BIM-модели на новый уровень. Система создает целостную картину: модель существует в неразрывной связи с результатами своих геометрических, информационных и вычислительных проверок.