Clash detection в Navisworks Manage: правила, отчеты, итерации

Зачем делать clash detection как процесс, а не разовую проверку

Коллизия в BIM-модели - это конфликт объектов: воздуховод пересекает балку, труба попадает в кабельный лоток, оборудование не помещается в нишу. На стройке такие вещи превращаются в переделки, простои и споры о том, «чья это зона ответственности». Если находить коллизии заранее, вы платите временем в модели, а не деньгами на площадке.

Коллизии почти никогда не возникают «по одной причине». Обычно они вырастают из мелочей: у разделов разные версии моделей, кто-то выгрузил не тот файл, элементы неверно классифицированы (лотки попали в «общие»), системы названы по-разному и не попадают в нужные наборы. Разовый запуск проверки в конце фиксирует последствия, но не предотвращает их.

Процесс clash detection в Navisworks Manage - это повторяемый цикл с понятными правилами. Вы заранее договариваетесь, что именно проверяете, что исключаете (временные элементы, условные габариты, мелкий крепеж), какие допуски применяете и как разбираете результаты. Тогда каждая итерация дает список задач, а не «простыню» из сотен срабатываний, где половина - шум.

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

Обычно в работе участвуют проектировщики разделов (АР, КР, ОВ, ВК, ЭОМ), BIM-координатор и заказчик или технадзор. Проектировщики исправляют свои модели, координатор настраивает тесты и ведет статусы, заказчик помогает согласовать спорные решения и подтверждает закрытие важных коллизий.

Когда clash detection становится процессом, вы получаете не просто отчет, а управляемую координацию: меньше сюрпризов на стройке и быстрее согласования между разделами.

Подготовка моделей перед поиском коллизий

Качество clash detection в Navisworks Manage почти всегда упирается не в настройки тестов, а в входные модели. Если они разные по версии, в разных координатах или с мусорной геометрией, список коллизий получится длинным, но бесполезным.

Сначала договоритесь, какие файлы считаются входными и что такое актуальная версия. Рабочая практика: фиксировать дату среза, ответственного по каждой дисциплине и единый формат именования (дисциплина, объект, стадия, дата или ревизия). Тогда на встрече по коллизиям не будет споров в духе «это уже исправлено, у меня другая модель».

Дальше проверьте единицы измерения и координаты. Частая причина ложных коллизий - разные единицы (мм и м) или модели, которые «живут» каждая в своем нуле. Нужен общий базис: выбранный ноль проекта, согласованный угол поворота и единая система координат для всех дисциплин. Если на проекте несколько корпусов или очередей строительства, заранее решите, как вы разделяете их по координатам и как это отражается в файлах.

Структура файлов влияет и на скорость работы. Удобнее, когда модели разделены по дисциплинам, а внутри есть понятная логика: этажи, зоны, этапы или пусковые комплексы. Это помогает делать точечные проверки (например, только 3 этаж, только зона А) и не гонять тяжелые файлы целиком.

Перед импортом сделайте короткую проверку качества. Она занимает 10-15 минут, но экономит часы на разборе «коллизий», которые не нужно исправлять. Уберите лишнюю детализацию, которая не влияет на координацию (визуальная мебель, резьба, мелкие фаски), проверьте дубли и повторно подключенные ссылки, убедитесь в корректных категориях (трубы должны быть трубами, воздуховоды - воздуховодами), уберите временные элементы, если вы их не проверяете, и поймайте явные ошибки: нулевые размеры, «улетевшие» на километры объекты, сломанные семейства.

Пример из практики: модель ОВ приходит с детальным крепежом и решетками, а часть воздуховодов помечена неверной категорией. В результате тесты находят сотни пересечений по крепежу и пропускают реальные конфликты с конструкциями. Такое часто всплывает там, где несколько подрядчиков работают по разным правилам: проще навести порядок на входе, чем потом «лечить» ситуацию фильтрами в Navisworks.

Итог простой: чем жестче вы стандартизируете версии, координаты и состав моделей до загрузки, тем короче будет список коллизий и тем быстрее команда перейдет от поиска к исправлению.

Правила поиска коллизий: что проверяем и что исключаем

Чтобы clash detection в Navisworks Manage давал пользу, правила лучше фиксировать заранее. Иначе команда получит сотни «коллизий», где половина - шум, а важные пересечения потеряются.

Что проверяем

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

Практичный базовый набор часто включает:

• Конструкции vs инженерия: балки, стены, плиты против воздуховодов, труб, лотков.
• Инженерия vs инженерия: пересечения сетей между собой, особенно в коридорах, шахтах и узких техзонах.
• Зазоры вокруг оборудования: установки, щиты, насосы, стойки (с учетом зон обслуживания).
• Проходы и высоты: коридоры, техпомещения, зоны над подвесным потолком.

Чтобы проверки были управляемыми, наборы (Selection Sets) лучше строить не только по дисциплинам, но и по зонам. Например: «Вентиляция - Этаж 3 - Ось 1-6» или «Слаботочка - Серверная - Зона А». Тогда проще назначать ответственных и повторно проверять только изменившиеся участки.

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

Что исключать и какие допуски ставить

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

Чаще всего исключают крепеж и мелкие деталировки, временные элементы (леса, ограждения, подмости), декоративные детали, а также дубли и случайно экспортированные 2D-элементы в 3D.

С допусками важно не «перестараться». Слишком маленький зазор даст тысячи ложных коллизий из-за округлений и особенностей экспорта, слишком большой - пропустит реальные проблемы.

Рабочие ориентиры на старте такие: для жестких пересечений допуск обычно ставят близко к нулю, а для зазоров делают отдельные тесты под разные задачи. Например, один тест «минимум 25-50 мм» для трасс в потолке, и отдельный тест «зона обслуживания 600-900 мм» для оборудования. После 1-2 итераций допуски корректируют: если большая часть результатов оказывается «погрешностью модели», либо увеличивают допуск, либо чистят наборы.

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

Пошаговый цикл в Navisworks Manage: от запуска до списка задач

Чтобы clash detection работал как управляемый процесс, в Navisworks важно повторять один и тот же цикл. Тогда результаты сравнимы между итерациями, а команда получает понятный список задач.

Цикл проверки, который стоит закрепить

Начинайте с обновления сводной модели (federated model) из актуальных выпусков дисциплин. Проверьте, что версии файлов подписаны одинаково (дата или номер ревизии), и что модели загрузились без смещений и дублей.

Дальше работайте по матрице дисциплин: какие модели с какими проверяем. В Navisworks это набор сохраненных Tests, которые живут в проектном файле, а не «в голове» координатора.

Удобно держать цикл как короткую процедуру:

• Собрать сводную модель и убедиться, что загружены нужные дисциплины и зоны.
• Создать или обновить Tests по матрице и сохранить настройки.
• Запустить тесты и убрать очевидный шум (дубли, повторы, временные элементы).
• Сгруппировать результаты так, чтобы их было удобно раздавать (этаж, зона, тип конфликта).
• Зафиксировать решение: статус, ответственный и что именно нужно поменять в модели.

Как быстро превратить результаты в задачи

На фильтрации не пытайтесь добиться «идеального нуля» любой ценой. Цель - выделить коллизии, которые реально требуют правки, а не спорить о допусках.

Группировка - ключевой шаг. Если оставить список как есть, одна проблема (например, трасса воздуховодов через балку) разложится на десятки одинаковых коллизий. После группировки команда видит одну задачу: «переложить трассу в зоне А, этаж 3», а не 47 отдельных пересечений.

В конце итерации убедитесь, что по каждой группе есть минимальные данные для работы: понятное имя теста и группы (дисциплины плюс зона/этаж), сохраненный viewpoint с удобным ракурсом, короткий комментарий «что не так и что ожидаем», статус и назначенный ответственный.

Если цикл повторяется раз в неделю или две, clash detection перестает быть «разовой проверкой» и становится системой: нашли, сгруппировали, назначили, проверили исправление на следующей итерации.

Приоритизация коллизий: как не тратить время на мелочи

Если делать clash detection в Navisworks Manage без приоритетов, список быстро превращается в шум. Команда тратит часы на мелкие пересечения, а реальные риски по срокам и эксплуатации остаются внизу.

Логика простая: сначала устраняем то, что может привести к аварии, остановке работ на площадке или дорогим переделкам. Лучше заранее договориться, что считается «критичным», чтобы у всех разделов было одно понимание.

Критерии, которые помогают принимать решения

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

Часто хватает трех уровней: «Критично», «Важно», «Можно отложить». «Можно отложить» не значит «не исправлять», это про время и способ закрытия.

Полезное правило: если коллизия повторяется десятки раз как типовой узел, не плодите сотню задач. Делайте одну типовую задачу с пометкой «применить ко всем аналогам» и фиксируйте, какие зоны она покрывает.

Модель или рабочая документация

Не все коллизии обязаны решаться изменением геометрии модели. Выбирайте путь по смыслу:

• В модели - если меняется трасса, отметка, габариты, или решение влияет на другие разделы.
• В РД - если нужен локальный разрез, узел крепления, уточнение зазора, а геометрия уже корректна.

Пример: воздуховод «цепляет» лоток на 5 мм. Если отметка лотка фиксирована из-за оборудования, это обычно «Важно» и решается в модели переносом трассы воздуховода. Если же пересечение связано с условным габаритом изоляции и на монтаже допускается сдвиг подвеса, это можно отнести в «Можно отложить» и закрыть узлом в РД, но только по согласованному правилу и с фиксацией в комментарии.

Отчеты по коллизиям: как оформлять, чтобы их реально исправляли

Хороший отчет по коллизиям нужен для одного: чтобы инженер, который не открывает Navisworks, понял проблему и исправил ее без длинной переписки. Запись вида «clash 1542» почти всегда зависает.

В каждой коллизии нужна короткая «карточка», которая отвечает на вопросы: где, что пересекается, кто владелец, и что делать дальше. В нее обычно входят: местоположение (этаж, оси, помещение или зона), элементы (ID/Mark или понятные имена, тип, размер при необходимости), дисциплины и ответственный, ожидаемое решение (сместить трассу, поднять отметку, согласовать отверстие), а также доказательство - снимок и сохраненный viewpoint.

Снимки и точки обзора экономят больше времени, чем любые тексты. Делайте два кадра: общий (где в здании) и крупный (что пересекается). Viewpoint сохраняйте так, чтобы при открытии были видны оба элемента и место конфликта.

По форматам обмена обычно хватает двух уровней. Для руководителя и смежников, которые не работают в Navisworks, подходит таблица или PDF-отчет с фильтрами по дисциплине и статусу. Для тех, кто исправляет в авторских BIM-системах, удобнее BCF: он переносит комментарий, снимок и точку обзора в задачу, и ее проще вести по статусам.

Чтобы отчет читался быстро, держите структуру простой: сначала сводка (сколько всего, сколько новых, сколько закрыто), затем сортировка по приоритету и зоне, дальше короткие формулировки «одно действие - один ожидаемый результат», и явный срок (итерация), в которую вы ждете исправление.

Пример записи: «Этаж 2, оси Б-В/4-5. Воздуховод 600x300 пересекает балку B-24. ОВ: поднять трассу на +150 мм или согласовать отверстие 650x350 с КР. Приоритет: высокий. Итерация: 03. Приложены общий снимок, крупный снимок, viewpoint “L2_BV_4-5_OV-KR_duct-beam”.»

Контроль исправлений по итерациям: статусы и повторные проверки

Контроль коллизий работает только тогда, когда у команды есть ритм: фиксируем срез моделей, проверяем, выдаем задачи, проверяем снова. Без итераций список быстро превращается в «кладбище» проблем: непонятно, что уже правили, что устарело, а что вернулось.

Статусы и правила переходов

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

• New: коллизия впервые найдена на текущем срезе.
• Active: назначен ответственный и есть понятное действие.
• Resolved: исполнитель внес правку в свою модель и передал обновленную версию на следующий срез.
• Approved: на повторной проверке коллизия не воспроизводится и решение соответствует договоренности.
• Rejected: коллизия осталась, исправление формальное или возник новый конфликт рядом.
• Not an Issue: ложное срабатывание, закрыто с объяснением почему.

Практичное правило: статус меняет тот, кто «держит мяч». Исполнитель переводит в Resolved, координатор проверяет и переводит в Approved или Rejected.

Как вести итерации, чтобы не спорить «у кого правильная модель»

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

Критерий «исправлено» должен быть одинаковым для всех. Исправлением считается, когда на новом срезе коллизия исчезла в том же тесте и в той же зоне, не нарушены базовые допуски (например, минимальные зазоры), и не появилось новых очевидных пересечений как следствие переноса.

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

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

Метрики, которые реально помогают управлять

Чтобы видеть прогресс, хватит нескольких цифр по каждой итерации: сколько закрыто (Approved) и сколько осталось в работе (Active), сколько новых появилось по сравнению с прошлым срезом, доля Rejected (если растет, значит задачи ставятся размыто или проверка слабая), и где копится долг (дисциплина или зона, которая стабильно дает больше всего коллизий).

Реалистичный пример: одна коллизия от обнаружения до закрытия

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

Коллизия попадает в тест, вы открываете результат и фиксируете контекст. Быстрее всего локализовать место так: включить только два набора (например, HVAC и конструкции), приблизиться к узлу, затем добавить окружение вокруг, чтобы увидеть этаж, зону, оси или помещение.

Дальше делаете один рабочий вид (Saved Viewpoint) с правильным ракурсом: видно пересечение воздуховода с балкой и положение клапана относительно потолка, стены или короба. Добавьте redline-пометки, чтобы исполнитель не тратил время на догадки.

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

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

Частые ошибки и ловушки в clash detection

Самая частая ошибка - один огромный тест «все со всем». Он дает тысячи пересечений, где тонут реальные проблемы. Лучше разбивать проверки по дисциплинам и типам элементов (воздуховоды vs балки, трубы vs стены) и заранее исключать то, что не должно участвовать в проверке.

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

Третья - отсутствие версионности. Если не фиксировать, какую сборку модели и какие настройки тестов проверяли, через неделю невозможно понять, почему коллизия снова появилась или почему она считается закрытой. Привычка «итерация = дата, версии моделей, набор тестов, краткое описание изменений» решает половину конфликтов в переписке.

Четвертая - отчеты без контекста. Фраза «есть коллизия в модели» не помогает проектировщику. Нужны понятная привязка (этаж, оси, зона), скриншот или два, viewpoint, короткое действие и владелец.

И наконец - закрывать коллизии без повторной проверки. Исправление часто переносит проблему на соседний участок или создает новый конфликт. Поэтому Resolved без перепрогона теста по тем же правилам почти всегда означает, что проблема стала «невидимой в списке», а не исчезла.

Быстрый чеклист и следующие шаги для команды

Регулярность важнее разового «героического» прогона. Проще каждый раз пройти короткий чеклист, чем потом разбираться, почему коллизии появились из-за старой модели или неверных координат.

Чеклист перед запуском проверки

Перед тем как нажать Run, проверьте базовые вещи:

• Актуальность файлов: версии, дата выгрузки, состав моделей.
• Координаты и уровни: общий базовый ноль, ориентация, единицы.
• Матрица тестов: по дисциплинам и зонам, а не «все со всем».
• Допуски: отдельно для касаний и технологических зазоров.
• Исключения и правила группировки: что не считаем коллизией и как объединяем повторы.

Чеклист по управлению исправлениями

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

• Статус и понятное правило, кто его меняет.
• Ответственный по дисциплине и срок.
• Комментарий «что поменять» и привязка (уровень, зона, помещение, ось).
• План повторной проверки: дата следующей итерации и список тестов.
• Правило закрытия: что считается исправлением, а что - обходом.

Дальше шаги простые: закрепите регламент на 1-2 страницы (кто запускает тесты, как называем наборы, как задаем допуски, как ведем статусы), сделайте общий шаблон тестов и шаблон отчета.

Если нужно быстрее поставить процесс на рельсы, иногда проще привлечь внешнюю поддержку: настроить шаблоны Navisworks, правила координации, а также закрыть вопросы лицензирования Autodesk и интеграции в ИТ-контур. Такие задачи можно вести через GSE.kz как системного интегратора и поставщика ПО, чтобы у команды был единый источник правил, инструментов и поддержки.