Технологии

CheckUp — система автоматизированной проверки BIM-моделей на наличие коллизий

Привет, Хабр! На связи команда BIM-координации в ПИК, ранее мы уже рассказывали о себе в статье «Мы создали сервис для координации BIM-моделей. Как он работает?». Сегодня мы расскажем о одном из важных инструментов в нашей работе, без которого не обходится ни один рабочий день — CheckUP. CheckUP — это система автоматизированной проверки BIM-моделей на наличие коллизий, основанная на фоновой проверке средствами Navisworks и обработке результатов в среде Revit. 1. История создания продукта CheckUP ПИК CheckUp (1.0) С внедрением и развитием BIM-технологий в ПИКе появилась необходимость в тщательной проверке BIM-моделей до начала их использования, чтобы получить на выходе качественную модель здания. Одной из главных проблем при проектировании жилых зданий являются коллизии — это пересечения между инженерными коммуникациями, конструктивными и архитектурными элементами. Несвоевременное обнаружение таких пересечений может привести к пересмотру проектных решений, увеличению сроков строительства и дополнительным финансовым затратам. Для обнаружения коллизий в выпускаемых BIM-моделях мы обратились к одному из наиболее популярных решений — Autodesk Navisworks. В шаблонах, на которых создаются рабочие модели для проектировщиков, был настроен 3D-вид, с которого координаторы экспортировали модели проекта для последующей проверки в формат NWC. Экспортированные модели объединялись в общую сводную модель NWF. Встроенный модуль Clash Detective в Autodesk Navisworks предоставляет возможность поиска коллизий в 3D-модели по определенным параметрам поиска. На пилотных объектах была сформирована матрица коллизий и настроены поисковые наборы скрытия, а также утверждены допуски пересечений. По результатам проверки формируется отчет в формате HTML или PDF, который передается всем участникам проекта, поскольку обнаруженные коллизии требуют согласования и решения. Практически сразу стало понятно, что слабым звеном в этом процессе является ручной экспорт моделей. Увеличение объемов проектирования и сжатые сроки выпуска документации приводили к увеличению числа заявок на проверку моделей от проектировщиков. Координаторы не успевали обрабатывать запросы и выдавать отчеты, как поступали повторные просьбы на перепроверку. Это показало необходимость автоматизации процесса и сокращения времени проверок. В 2020 году была разработана первая версия плагина ПИК CheckUp(1.0). Изначально продукт представлял из себя плагин для Revit. К основным задачам проекта можно отнести: Разработку технологии проверок моделей; Формирование системы проверок; Внедрение массовых проверок (100% моделей); Разработку рыночного продукта по проверке на коллизии; Повышение качества выпускаемой документации. В плагине из Revitа можно было выбирать и отправлять нужные модели на конвертацию (RVT to NW), отслеживать статус конвертации (Панель конвертации) и настраивать параметры экспорта (Настройки). Ниже показан интерфейс плагина для Revit: По кнопке «RVT to NW» открывалось окно выбора Revit-серверов, и можно было галочками отметить нужные для конвертации модели. Список моделей полностью отображал папочную структуру сервера и показывал дату последней синхронизации в модели: По кнопке «Панель конвертации» можно было отследить статус задач — как своих, так и других BIM-координаторов: Для удобства все задачи группировались по номеру площадки и корпуса, но также можно было получить детальную информацию по каждой задаче: По кнопке «Настройки» мы получали доступ к окну настроек конвертации модели, которое дублировало стандартные функции экспорта Revit: В первых версиях плагина, с началом использования, был выявлен ряд неудобных моментов, которые удалось исправить с выпуском обновлений: Раньше получить сконвертированные модели и приступить к проверке можно было только после того, как конвертер обработает каждую модель из задачи. Это вызывало неудобство, потому что конвертер не показывал оставшееся время конвертации, а мы в свою очередь не могли запланировать время и сроки выполнения проверки; При обновлении «зависших» в очереди моделей вручную не было возможности отменить их конвертацию в плагине, что тоже приводило к увеличению времени проверки; Еще одним недостатком плагина можно было назвать длительную загрузку окна выбора моделей для конвертации, что приводило к дополнительной нагрузке на сервера. Поэтому в утренние часы, когда проектировщики приступали к работе в моделях, был введен запрет на использование плагина; Плагин не мог обработать модели, которые содержали в себе загруженные связи не с Revit сервера или при открытии которых возникали всплывающие предупреждения от Revit (например, об ошибках в координации); Также возникали проблемы с конвертацией моделей, содержащих lib-файлы (это отдельные rvt-файлы, которые повторно используются в разных проектах как элемент повторного применения. Lib-файлы вставляются в основную модель в качестве связанного файла с типом связи «Прикрепление»); Иногда случались системные сбои в работе плагина, и все модели «оперативно» приходилось выгружать ручным способом. Следующим шагом в развитии и улучшении продукта стала разработка плагина для Navisworks. Важно было исключить ошибки, возникающие в случае «человеческого фактора», соблюсти стандарты в наименовании проверок и сократить время на настройку новых сборок. Команды плагина располагались на ленте во вкладке ПИК-CheckUP: По кнопке «Загрузить проверку» открывалось окно с матрицей коллизий, а доступные для проверки разделы определялись автоматически по названиям файлов моделей, содержащихся в текущей сборке. Например, если в сборку были подгружены только модели ОВ (отопления и вентиляции) и ВК (водоснабжения и канализации), то были доступны для загрузки проверки, содержащие только эти разделы: Преднастроенные правила проверок, наименования и допуски были собраны в отдельном файле в формате xml и подвергались корректировке по мере необходимости c нашей стороны. Например, согласованное изменение допусков на пересечения или внесение правок в поисковые наборы скрытия. Загрузка наборов скрытия производилась вручную, через стандартную команду «Импортировать наборы поиска…», но позже была добавлена возможность загружать их по кнопке «Поисковые наборы скрытия»: Команда «Выгрузить коллизии» становилась активна, если в текущей модели была проведена проверка на коллизии. Прогресс выгрузки коллизий отображался в всплывающем окне: Команда «Выгрузить проектную» ошибку позволяла создать и выгрузить в БД проектную ошибку (Проектная ошибка – ошибка, выявленная в проекте при визуальном осмотре). Проектные ошибки создавались на основе точек обзора и прогресс выгрузки коллизий отображался аналогично выгрузке коллизий в БД: Команда «Настройки» позволяла установить URL базы данных и расположение файлов проверок: Для повышения качества, поступающих на проверку моделей, было разработано дополнение к плагину в Revit. Перед отправкой модели на конвертацию, координаторы могли видеть % готовности модели по нескольким результатам инспекций в BIM Inspector: корректность наименования, координаты, статус используемых семейств, заполнение параметров Class и ClassCode, на которых были настроены поисковые наборы скрытия в Navisworks. Если результат какой-то из инспекций был ниже определенного значения, то модель не проверялась и возвращалась на доработку проектировщику. Также было разработано дополнение, позволяющее проводить проверки по расписанию. Оно являлось частью Revit-приложения, но его запуск возможен без открытия Revit. Оно позволяло настроить интервалы проверок для моделей, которые проверялись чаще остальных. При запуске приложения появлялась заглавная панель с тремя блоками: проекты, проверки, параметры выбранной проверки. Для формирования проверки необходимо было нажать на кнопку «Добавить проект», в появившемся окне задать имя проверки. По кнопке «Добавить проверку» можно было выбрать проверяемые модели (логика выбора моделей была идентична логике заложенной в Revit приложение) и выбрать разделы из матрицы коллизий: Затем необходимо было настроить периодичность и время расписания проверок. Для этого по кнопке «Изменить расписание» в появившемся окне задавалась дата начала, дата окончания проверки и расписание проверки: После завершения всех настроек в главном окне приложения отображалась вся настроенная информация: Первая версия плагина ПИК CheckUp (1.0) во многом упростила работу BIM-координаторов, но не отличалась стабильностью и не имела технической возможности для дальнейшего развития. 2. Развитие продукта CheckUP и его полная перезагрузка. ПИК CheckUp (2.0) В июле 2024 года вышла новая версия продукта ПИК CheckUp (2.0). Продукт перешел с десктопной версии на веб-оболочку. Сервис содержал в себе 2 ключевых направления: облачную конвертацию моделей из RVT в NWC; плагин в Navisworks для автоматизации проверок на коллизии — подгрузка поисковых наборов скрытия и преднастроенных проверок на коллизии в ClashDetective. Давайте подробнее рассмотрим основной функционал. На главной странице мы можем задать интересующие нас сервера и проекты, модели которых будут доступны в окне конвертации: Список моделей полностью отображает папочную структуру хранения их на сервере. Предоставляется информация о дате последней синхронизации, версии Revit и весе модели. Нужные модели отмечаются галочками слева и по кнопке «Добавить» отправляются на конвертацию: Статус конвертации можно отследить на Панели конвертации NWC. Можно увидеть сколько времени осталось до конца конвертации, узнать статус, имя координатора, создавшего задачу, и дату отправки моделей на конвертацию. Переключение между вкладками доступно с помощью бокового меню: В сентябре 2024 года появилась функция Автоконвертации моделей. Она позволила настроить для каждого проекта автоматическую отправку неактуальных моделей на конвертацию, когда координатору поступает заявка в Jira на проверку модели этого проекта: Модели, по которым настроена Автоконвертация, в Панели конвертации отображаются следующим образом. В столбце Тип указан вид проверки и номер заявки, по которой модели отправились на конвертацию: В том же месяце произошел релиз функции «100% конвертация». 100% конвертация — это процесс экспорта модели, который максимально приближен к формату ручной конвертации: открыть модель -> выгрузить все связи -> настроить 3д вид -> конвертировать со стандартными настройками экспорта. В случае, если модель при стандартной выгрузке упала в ошибку, автоматически запускается процесс «100% конвертации», и для данного файла rvt фиксируется пометка в базу данных, что в следующий раз эту модель конвертировать именно так. В ноябре 2024 года в плагине была разработана функция по настройке конвертации моделей. Теперь каждому файлу индивидуально стало можно настроить тип конвертации «Со всеми связями» и «С lib-связями». Конвертация файла «Со всеми связями» — если нужно сконвертировать модель и все связанные в ней файлы. Конвертация файла только «С lib-связями» — если необходимо сконвертировать только lib-связи совместно с основной моделью: Пометки о типе конвертации моделей также отображаются в Панели конвертации: В мае 2025 года вышло новое обновление. Появилась возможность конвертации моделей в форматы IFC и FBX. Также стало возможным конвертировать файлы других версий Revit (отличных от 2019): Летом 2025 года была реализована функция конвертации локальных файлов. По кнопке «Загрузить файлы» можно выбрать необходимые модели и отправить их на конвертацию. Эта функция удобна при работе с подрядными организациями, когда их версия Revit отличается от той, в которой работают наши проектировщики: Новая версия плагина отличается большей стабильностью чем предыдущая. Модели намного реже попадают в «ошибочные конвертации», что позволяет сэкономить трудозатраты на экспорт моделей. Плагин не нагружает сервера, потому что конвертация выполняется на универсальных выделенных фермах. 3. CheckUP в повседневной работе Теперь давайте рассмотрим, как мы используем в своей работе приложение и как устроен процесс поиска коллизий в ПИК подробнее. Все проверки на коллизии можно разделить на три вида: первичная — проверка моделей инженерных сетей, находящихся в работе, перед выдачей задания смежным дисциплинам (архитекторам и конструкторам); текущая — промежуточная проверка запрошенной модели с моделями всех разделов данного объекта; финальная — проверка запрошенной модели с моделями всех разделов данного объекта перед выдачей комплекта. Перед началом проверки BIM координатору нужно экспортировать модели в Navisworks. Как происходит экспорт моделей, было описано ранее. Если модель уже прошла проверку на коллизии, т.е. получен финальный отчет и модель выдана заказчику, то в столбце «Выпуск» она помечается галочкой и конвертировать ее не нужно (т.е. в дальнейших проверках мы эту модель не обновляем и используем последнюю сконвертированную версию). Если галочки в столбце «Выпуск» нет и в столбце «Актуальность» тоже, то модель нужно обновить для проведения проверки. Галочка в столбце «Актуальность» отображается, когда дата сконвертированной модели старше даты последней синхронизации в модели. Так CheckUp позволяет нам избежать возможной работы с неактуальной моделью NWC. Перед началом проверки в Navisworks мы загружаем поисковые наборы скрытия и нужные проверки из матрицы к0оллизий с помощью плагина CheckUp, которые затем отображаются в окне Clash Detective: Наборы скрытия помогают нам сразу исключить из проверки лишние элементы, например, оси, уровни, формы, УГО (условнографические элементы), вспомогательные фиктивные элементы, которые заранее обговорены со всеми участниками процесса. Матрица коллизий — это специальная таблица, которая содержит в себе все критерии проверок между выбранными в модели объектами. Она показывает, на какие пересечения между различными элементами необходимо обратить внимание. Ниже представлен пример матрицы коллизий между разделами ЭОМ — СС. Все элементы модели разбиты по категориям и указано, что попадает под исключения: После полной настройки и подготовки сборки в Navisworks начинается этап анализа выявленных пересечений. Согласно матрице коллизий, мы можем исключить некоторые пересечения, например, между соединительными деталями кабельных лотков и самими кабельными лотками. Мы группируем коллизии по типовым пересечениям (как вариант — на всех типовых этажах потолки пересекают трубы кондиционирования) или по множеству пересечений с одним элементом (пересечения инженерных коммуникаций в одном месте). Результатом всех проверок является отчет, выдаваемый проектировщику. Стандартный отчет Navisworks — это HTML файл с последовательным перечислением конфликтов. Все ошибки, указанные в отчёте, обязательно должны быть исправлены. Контроль отработки выставленных замечаний — ответственность BIM-координатора. Проверки на коллизии проводятся до тех пор, пока не будет получен финальный отчет с отсутствием геометрических пересечений. 5. Планы на ближайшее будущее: Развитие ПИК CheckUp не стоит на месте, в наших планах — улучшить и расширить функционал, повысить стабильность, подключить к использованию плагина ГИПов и проектировщиков. Среди ожидаемых функций: Настройка и администрирование наборов скрытия/правил исключения напрямую в CheckUp, минуя дополнительных файлов настроек в формате xml; Автогруппирование обнаруженных коллизий. Перед выдачей отчета анализ и группирование пересечений происходит в ручном режиме и отнимает достаточно большое количество времени у координаторов, особенно при первых итерациях проверок. Для ускорения анализа коллизий будет реализовано их автоматическое группирование по типу элементов или местоположению; Настройки экспорта и публикация результатов проверок в БД. Экспорт данных, собранных в БД для получения статистики проверок и отчета по выявленным/исправленным коллизиям; Настройки экспорта и публикация результатов проверок в Revit. Экспорт выполненных проверок напрямую в Revit проектировщику, минуя отчеты в формате HTML 6. Польза и результат Новая и актуальная версия ПИК CheckUp сейчас закрывает практически все потребности BIM-координаторов: Конвертация rvt файлов в форматы nwc, ifc, fbx на выделенный фермах. Данная выгрузка не задействует трудозатраты bim-координатора и ресурсы его ПК. Во время выполнения выгрузки файлов координатор может заняться другими задачами (Помогло сократить от 1 до 3 часов ручной выгрузки); Общий подход к формированию результата проверки. Благодаря единым набором поиска, скрытия и правилам исключения (разграничены по дирекциям) смогли уйти от выдачи разных результатов по проверкам одних и тех же моделей; Время предоставления решения по проверке модели значительно уменьшилось, что полностью удовлетворило проектировщиков (Время проверки сократилось в несколько раз, от начальных 3-4 часов до 30–60 минут).

Фильтры и сортировка