Рекламодатель: АО «Топ Системы»

ИНН 7726601967 ОГРН 1087746953557

Рекламодатель:
ООО «С3Д Лабс»

ИНН 7715938849 ОГРН 1127747049209

6 - 2021

Автоматические проверки на коллизии в Pilot-BIM


Юлия Захарова,
маркетинг-менеджер по решениям Pilot, АСКОН


Марина Шишкина, менеджер по продукту
Pilot-BIM, АСКОН

В мае этого года АСКОН выпустил новый релиз среды общих данных Pilot­BIM, в который вошли автоматические проверки модели на коллизии.

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

Рис. 1. Сборка файлов разных форматов

Рис. 1. Сборка файлов разных форматов

Работу с консолидированной трехмерной моделью (рис. 1) можно разделить на несколько составляющих. Чем больше автоматизирована каждая из них, тем быстрее и удобнее происходит эта работа:

1 Сборка —  автоматизировано.

Первая составляющая — сама сборка консолидированной модели. В Pilot­BIM это происходит автоматически:

  • разные специалисты загружают исходные файлы в систему (на виртуальный диск);
  • система собирает все файлы в одну модель.

2 Внесение изменений —  автоматизировано.

Консолидированная BIM­модель всегда хранится на сервере, поэтому к ней есть доступ у всех участников проектирования и строительства. Благодаря этому модель можно коллективно обсуждать и вносить правки. Возникает вопрос — как актуализировать модель, если над ней работают одновременно несколько специалистов? В Pilot­BIM это происходит так:

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

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

3 Проверка на коллизии —  автоматизировано.

Можно проверять BIM­модель вручную — «гулять» по ней, внимательно рассматривать и анализировать, а можно автоматически. В Pilot­BIM теперь предусмотрены оба варианта, второй — с помощью технологии ModelChecker. Эта функциональность включена в новый релиз Pilot­BIM версии 21.10.0.36234.

Подробнее о ModelChecker

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

Если поиск выполняется на основе объема, пересечения крупногабаритных объектов с тонкими стенками будут считываться как слабые, хотя по факту будут иметь большое значение в проектировании (например, пересечение полых труб со стенами).

Поэтому надежнее заложить в алгоритм системы ориентирование на габариты — как это сделано в Pilot­BIM.

Посмотрим, как это работает на практике.

С чего начать проверку

В новой редакции Pilot­BIM в окне консолидированной модели пользователь увидит иконку Проверки модели. Отсюда и начинается работа с коллизиями.

Пользователь сам задает настройки проверки, поэтому для проверки с новыми условиями нужно создавать новый журнал, где будут фиксироваться найденные ошибки (рис. 2).

Рис. 2. Чтобы начать проверку, нужно создать журнал проверок

Рис. 2. Чтобы начать проверку, нужно создать журнал проверок

В настройках нужно «сообщить» системе, как ее проводить:

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

Есть такая проблематика, как выявление «лишних», то есть незначительных и отвлекающих внимание коллизий. Настройки проверки позволяют нивелировать эту проблематику, насколько это возможно (рис. 3).

Рис. 3. Параметры проверки

Рис. 3. Параметры проверки

Создать и настроить журнал — значит заложить основу для проверки. Далее ее нужно запустить (рис. 4).

Рис. 4. Журнал, по которому еще не выполнялась проверка

Рис. 4. Журнал, по которому еще не выполнялась проверка

ModelChecker работает в фоновом режиме на сервере, то есть позволяет продолжить работу с моделью прямо во время проверки. Так как движок задействует мощности сервера, скорость проверки не зависит от клиентского компьютера, на котором активируется команда «начать проверку» (рис. 5).

Рис. 5. Запуск проверки (а); ход проверки (б); отображается дата и автор создания журнала (в)

Рис. 5. Запуск проверки (а); ход проверки (б); отображается дата и автор создания журнала (в)

Рис. 5. Запуск проверки (а); ход проверки (б); отображается дата и автор создания журнала (в)

Рис. 5. Запуск проверки (а); ход проверки (б); отображается дата и автор создания журнала (в)

Настройкой атрибута Считать слабыми пересечения до можно избежать появления в журнале допустимых пересечений. Чтобы это проверить, создадим новый журнал и зададим этому параметру значение «30» — система обнаружит меньше проблем (рис. 6).

Рис. 6. Управление параметрами проверки

Рис. 6. Управление параметрами проверки

Как узнать, какие коллизии нашел ModelChecker

Итог проверки — это набор коллизий. Рассмотрим все способы того, как их просмотреть и проанализировать.

1 Журнал проверок — кликабельный список коллизий (рис. 7).

Рис. 7. «IfcWall*IfcPipeSegment» — системные названия классов объектов

Рис. 7. «IfcWall*IfcPipeSegment» — системные названия классов объектов

Найдено — это стандартный статус обнаруженной коллизии. После устранения он будет автоматически изменен на Исправлено.

Чтобы посмотреть только актуальные ошибки или только исправленные, их можно отсортировать в строке поиска (рис. 8).

Рис. 8. Выборка коллизий по состоянию

Рис. 8. Выборка коллизий по состоянию

Статус ошибки можно менять вручную. Например, на Не требует исправления. Это может оказаться полезным для того, чтобы отсортировать незначительные пересечения, которые система считала как ошибку (рис. 9).

Рис. 9. Изменение статуса коллизииРис. 9. Изменение статуса коллизии

Рис. 9. Изменение статуса коллизии

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

Чтобы посмотреть на ошибку из журнала, нужно два раза кликнуть на нее. При этом можно масштабироваться по объектам или по телу пересечения (рис. 10 и 11).

Рис. 10. Ракурс — полностью на объекты

Рис. 11. Ракурс — на тело пересечения

Рис. 11. Ракурс — на тело пересечения

Тело выбранного в журнале пересечения подсвечивается на модели красным цветом (рис. 12).

Рис. 12. Режим отображения: 
а — без окружающего контекста; 
б — с окружающим контекстом

Рис. 12. Режим отображения: 
а — без окружающего контекста; 
б — с окружающим контекстом

Рис. 12. Режим отображения:
а — без окружающего контекста;
б — с окружающим контекстом

Если объекты дублируются, тело пересечения совпадает с объектами (рис. 13).

Рис. 13. Дубль объектов также считывается как коллизия

Рис. 13. Дубль объектов также считывается как коллизия

2 При открытом журнале проверок в контекстном меню объекта отображаются все пересечения, в которых он участвует (рис. 14).

Рис. 14. Пересечения обозначаются по названию типов 
пересекающихся объектов

Рис. 14. Пересечения обозначаются по названию типов пересекающихся объектов

Как устранить коллизии

Сценарий устранения коллизий и контроля этого процесса зависит от того, кто и в какой момент проводит проверку. На практике возможны несколько вариантов:

  • менее эффективный — выделенный специалист в конце проектирования;
  • более эффективный — выделенный специалист во время проектирования/проектировщик в конце проектирования;
  • самый эффективный — проектировщик во время проектирования.

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

Рис. 15. Захарова поручила Павленко устранить коллизию

Рис. 15. Захарова поручила Павленко устранить коллизию

Ответственный увидит уведомление, перейдет по нему и увидит замечание (рис. 16). Далее для исправления ошибки он сможет перейти к инструменту разработки прямо из окна просмотра модели (рис. 17).

Рис. 16. Павленко получила уведомление

Рис. 16. Павленко получила уведомление

Рис. 17. Переход от объекта в Pilot к объекту в Renga

Рис. 17. Переход от объекта в Pilot к объекту в Renga

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

Если проверку выполняет сам проектировщик, ему не нужно выставлять замечания — он просто вносит изменения, отправляет их на сервер и проводит повторные проверки.

Как ModelChecker среагирует на изменение модели

Так как в настройках проверки была задана команда Запускать автоматически после каждого изменения, после отправки изменений на сервер проверка запустилась автоматически. В обновленной версии ModelChecker не нашел пересечения и исправил статус проблемы с Найдено на Исправлено (рис. 18).

Рис. 18. Статус устраненной коллизии

Рис. 18. Статус устраненной коллизии

Если не задавать команду Запускать автоматически после каждого изменения, пользователь увидит оповещение о том, что журнал проверки неактуален. Тогда ему нужно зайти в журнал и вручную запустить проверку (рис. 19).

Рис. 19. Неактуальный журнал

Рис. 19. Неактуальный журнал

После устранения коллизии тело пересечения отображается, чтобы пользователь мог видеть полный жизненный цикл ошибки (рис. 20).

Рис. 20. Тело пересечения после устранения коллизии

Рис. 20. Тело пересечения после устранения коллизии

Как еще можно работать с результатом проверки

Для анализа количества ошибок или передачи информации о проверке в Pilot­BIM предусмотрены отчеты. Их можно строить как по одному журналу, так и по нескольким (рис. 21 и 22).

Рис. 21. Выбор отчета

Рис. 21. Выбор отчета

Рис. 22. Отчет «Матрица пересечений» (а); отчет «Журнал проверок» (б)

Рис. 22. Отчет «Матрица пересечений» (а); отчет «Журнал проверок» (б)

Рис. 22. Отчет «Матрица пересечений» (а); отчет «Журнал проверок» (б)

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

В зависимости от задач конкретного бизнес­процесса можно формировать отчеты разных форм и с разным наполнением.

Лайфхак: как еще можно исключать незначительные пересечения

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

Чтобы не сортировать такие коллизии вручную, можно оптимизировать отображение отдельных элементов модели — тех, которые не нужно учитывать при проверке (рис. 23).

Рис. 23. Пересечение тонкой трубы с объектом (а); пересечение кабеля с объектом (б)аб

Рис. 23. Пересечение тонкой трубы с объектом (а); пересечение кабеля с объектом (б)

Для этого нужно упростить профили по кривой до линии:

  • зайти в настройки оптимизации модели — правила, которые определяют, как информация из IFC­файла будет обрабатываться BIM­сервером;
  • задать команду Упрощение профиля по кривой и указать, что определенные типы объектов (трубы и кабели — IfcPipeSegment и IfcCableSegment), которые имеют габарит меньше заданного значения (25 мм), должны быть упрощены до линии (рис. 24);

Рис. 24. Общие настройки отображения модели

Рис. 24. Общие настройки отображения модели

  • выполнить полное перестроение модели — BIM­сервер прочитает те же файлы IFC, но согласно новым настройкам оптимизации, и отобразит модель по­новому (рис. 25 и 26);

Рис. 25. Труба отображается как линия, видно тело пересечения

Рис. 25. Труба отображается как линия, видно тело пересечения

Рис. 26. Кабель отображается как линия

Рис. 26. Кабель отображается как линия

  • зайти в журнал проверок и выполнить проверку заново; коллизии останутся в списке, но изменят состояние с Найдено на Исправлено (рис. 27).

Рис. 27. Изменение статуса коллизии после оптимизации

Рис. 27. Изменение статуса коллизии после оптимизации

Рис. 27. Изменение статуса коллизии после оптимизации

Далее, если проектировщик будет вносить изменения в модель или добавлять новые исходные файлы для дополнения модели, Pilot­BIM будет отображать все трубы и кабели диаметром меньше 25 мм как линию. А ModelChecker не будет фиксировать их пересечение с другими объектами как коллизию.

Немного о работе Pilot­BIM­Server

Pilot­BIM­Server обрабатывает модель в один или несколько потоков — как если бы проект проверял вручную один эксперт или несколько одновременно, распределив работу между собой.

Посмотреть количество потоков сервера можно во вкладке Диспетчер серверных задач Pilot­BIM — Глобальные настройки BIM (рис. 28).

Рис. 28. Глобальные настройки BIM

Рис. 28. Глобальные настройки BIM

Количеством потоков можно управлять через командную строку с помощью утилиты pBimAdmin (рис. 29).

Рис. 29. Было четыре потока, стало триРис. 29. Было четыре потока, стало три

Рис. 29. Было четыре потока, стало три

Это может быть полезно, когда кроме Pilot­BIM на сервере работает еще программа, которая требует больших мощностей. Таким способом можно «забрать» у Pilot­BIM поток или несколько, чтобы ими могла воспользоваться другая программа.

Отличия и развитие

Pilot­BIM — это не первая технология поиска коллизий на рынке BIM­моделирования. Но кое­что отличает ее от остальных:

  • единое решение для среды общих данных, автоматической серверной сборки консолидированных моделей и проверок на коллизии;
  • автоматическое отслеживание жизненного цикла коллизии;
  • отображение геометрии тел пересечений;
  • возможность перейти от элемента модели к коллизиям, в которых он участвует.
  • Вот чего можно ожидать от ModelChecker в будущем:
  • определения объема пересечений;
  • исключения из проверки труб диаметром меньше заданного значения;
  • расширенной категоризации объектов;
  • новых видов проверок (столкновение при открывании дверей и окон, проверка помещений на площадь и т.д.);
  • возможности добавить свои проверки.

Регистрация | Войти

Мы в телеграм:

Рекламодатель:
ООО «Нанософт разработка»

ИНН 7751031421 ОГРН 5167746333838

Рекламодатель: АО «Топ Системы»

ИНН 7726601967 ОГРН 1087746953557