2 июня 2021 г. |
В мае АСКОН выпустил новый релиз среды общих данных Pilot-BIM, в который вошли автоматические проверки модели на коллизии.
Если ошибки в проекте вскрываются после начала строительства или тогда, когда проект почти готов, стоимость их исправления возрастает – требуются значительные изменения в модели и дополнительное время на согласование. Если проводить проверки постоянно в процессе проектирования и сразу вносить корректировки, можно выиграть в качестве проекта и избежать расходов на устранение недочетов. Поэтому из всех новшеств мы так акцентируем внимание на автоматическом поиске коллизий.
Работу с консолидированной трёхмерной моделью можно разделить на несколько составляющих. Чем больше автоматизирована каждая из них, тем быстрее и удобнее происходит эта работа.
Первая составляющая – сама сборка консолидированной модели. В Pilot-BIM это происходит автоматически:
✓ автоматизировано
Консолидированная BIM-модель всегда хранится на сервере, поэтому к ней есть доступ у всех участников проектирования и строительства. Благодаря этому модель можно коллективно обсуждать и вносить правки. Возникает вопрос – как актуализировать модель, если над ней работают одновременно несколько специалистов? В Pilot-BIM это происходит так:
Все операции происходят на сервере Pilot-BIM, поэтому при актуализации модель не отчуждается из среды общих данных. Например, пока один специалист загружает на сервер изменённый файл, пока система считывает изменения и вносит их в модель, другие специалисты продолжают работу с ней. На рабочих местах модель обновляется автоматически.
✓ автоматизировано
Можно проверять BIM-модель вручную – «гулять» по ней, внимательно рассматривать и анализировать, а можно автоматически. В Pilot-BIM теперь предусмотрены оба варианта, второй – с помощью технологии ModelChecker. Эта функциональность включена в новый релиз Pilot-BIM версии 21.10.0.36234.
✕ визуальные ручные проверки
✓ автоматизировано
Есть два популярных алгоритма, на основе которых можно проверять объект на коллизии – учёт объёмов или учет габаритов пересечений элементов.
Если поиск выполняется на основе объёма, то пересечения крупногабаритных объектов с тонкими стенками будут считываться как слабые, хотя будут иметь большое значение в проектировании (пересечение полых труб со стенами, например).
Поэтому надёжнее заложить в алгоритм системы ориентирование на габариты – как это сделано в Pilot-BIM.
Посмотрим, как это работает на практике.
В обновленном Pilot-BIM в окне консолидированной модели пользователь увидит иконку «Проверки модели». Отсюда и начинается работа с коллизиями.
Пользователь сам задаёт настройки проверки, поэтому для проверки с новыми условиями нужно создавать новый журнал, где будут фиксироваться найденные ошибки.
В настройках нужно «сообщить» системе, как её проводить:
Есть такая проблематика, как выявление «лишних», то есть незначительных и отвлекающих внимание коллизий. Настройки проверки позволяют нивелировать эту проблематику, насколько это возможно.
Создать и настроить журнал – значит заложить основу для проверки. Далее её нужно запустить.
ModelChecker работает в фоновом режиме на сервере, то есть позволяет продолжить работу с моделью прямо во время проверки. Так как движок задействует мощности сервера, скорость проверки не зависит от клиентского компьютера, на котором активируется команда «начать проверку».
Настройкой атрибута «Считать слабыми пересечения до» можно избежать появления в журнале допустимых пересечений. Чтобы это проверить, создадим новый журнал и зададим этому параметру значение «30» – система обнаружит меньше проблем.
Итог проверки – это набор коллизий. Рассмотрим все способы того, как их просмотреть и проанализировать.
«Найдено» – это стандартный статус обнаруженной коллизии. После устранения он будет автоматически изменён на «Исправлено».
Чтобы посмотреть только актуальные ошибки или только исправленные, их можно отсортировать в строке поиска.
Статус ошибки можно менять вручную. Например, на «Не требует исправления». Это может оказаться полезным для того, чтобы отсортировать незначительные пересечения, которые система считала как ошибку.
После повторной проверки статус «Не требует исправления» сохранится – система запоминает, что пользователь счёл эту коллизию допустимой.
Чтобы посмотреть на ошибку из журнала, нужно два раза кликнуть на неё. При этом можно масштабироваться по объектам или по телу пересечения.
Тело выбранного в журнале пересечения подсвечивается на модели красным цветом.
Если объекты дублируются, тело пересечения совпадает с объектами.
2. При открытом журнале проверок в контекстном меню объекта отображаются все пересечения, в которых он участвует.
Сценарий устранения коллизий и контроля этого процесса зависит от того, кто и в какой момент проводит проверку. На практике возможны несколько вариантов:
Предположим, что проверку выполняет отдельный специалист, а устраняет коллизии проектировщик. Тогда этот специалист добавляет замечание к одному из пересекающихся объектов и назначает ответственного.
Ответственный получит уведомление, перейдёт по нему и увидит замечание.
Далее для исправления ошибки он сможет перейти к инструменту разработки прямо из окна просмотра модели.
Если проектировщик работает в Renga, ему сразу откроется точка взгляда на объект, от которого был совершён переход.
После устранения коллизии изменения в модели нужно будет отправить на сервер, и консолидированная модель обновится автоматически. При этом предыдущая версия модели сохранится.
Если проверку выполняет сам проектировщик, ему не нужно выставлять замечания – он просто вносит изменения, отправляет их на сервер и проводит повторные проверки.
Так как в настройках проверки была задана команда «Запускать автоматически после каждого изменения», после отправки изменений на сервер проверка запустилась автоматически. В обновлённой версии ModelChecker не нашёл пересечения и исправил статус проблемы с «Найдено» на «Исправлено».
Если не задавать команду «Запускать автоматически после каждого изменения», пользователь увидит оповещение о том, что журнал проверки неактуален. Тогда ему нужно зайти в журнал и вручную запустить проверку.
После устранения коллизии тело пересечения отображается, чтобы пользователь мог видеть полный жизненный цикл ошибки.
Для анализа количества ошибок или передачи информации о проверке в Pilot-BIM предусмотрены отчёты. Их можно строить как по одному журналу, так и по нескольким.
Матрицу можно сохранить в отдельный документ и вести с ней работу – передавать заказчику или в экспертизу, вести учет для себя и т.д. В ней отображается актуальная информация, то есть только коллизии со статусом «Найдено».
В зависимости от задач конкретного бизнес-процесса можно формировать отчёты разных форм и с разным наполнением.
Не все допустимые пересечения можно исключить с помощью настройки журнала коллизий. Например, когда кабель или тонкая труба пересекаются со стеной, система считывает габарит тела пересечения – длину элемента или её часть – и выдаёт это за ошибку.
Чтобы не сортировать такие коллизии вручную, можно оптимизировать отображение отдельных элементов модели – тех, которые не нужно учитывать при проверке.
Для этого нужно упростить профили по кривой до линии:
Далее, если проектировщик будет вносить изменения в модель или добавлять новые исходные файлы для дополнения модели, Pilot-BIM будет отображать все трубы и кабели диаметром меньше 25 мм как линию. А ModelChecker не будет фиксировать их пересечение с другими объектами как коллизию.
Pilot-BIM-Server обрабатывает модель в один или несколько потоков – как если бы проект проверял вручную один эксперт или несколько одновременно, распределив работу между собой.
Посмотреть количество потоков сервера можно во вкладке «Диспетчер серверных задач Pilot-BIM» – «Глобальные настройки BIM».
Количеством потоков можно управлять через командную строку с помощью утилиты pBimAdmin:
Это может быть полезно, когда кроме Pilot-BIM на сервере работает ещё программа, которая требует больших мощностей. Таким способом можно «забрать» у Pilot-BIM поток или несколько, чтобы ими могла воспользоваться другая программа.
Pilot-BIM – это не первая технология поиска коллизий на рынке BIM-моделирования. Но кое-что отличает её от остальных:
Что планируется добавить в ModelChecker в будущем: