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 минут).