Navisworks Manage является продуктом компании Autodesk, который позволяет выполнять контроль выполнения проекта при помощи проверки его сводной модели. Стоит отметить, что Navisworks работает не только с линейкой продуктов Autodesk, но и многими другими форматами моделей. Это позволяет добавлять в проект Navisworks модели даже если вы взаимодействуете с подрядчиками, которые используют другие BIM решения. Считывание каждого из этих форматов можно настроить, ведь Navisworks не работает с исходными файлами а создает удобный для внутренней работы кэш уже собственного формата
.
Начнем погружаться в среду Navisworks. Для примера загружаю сюда несколько моделей из Revit. Это будет проект многоэтажного дома, полные модели АР и КЖ + часть модели отопления на 3 и 4 этажах. Это позволит нам не получать километровые отчеты о коллизиях и наглядно разобрать формирование проверки.

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

Часто я слышу от пользователей вопрос: «А зачем нужен Navisworks если в Revit тоже есть функционал по поиску пересечений в модели?». Такой функционал действительно есть, и выполнять эти проверки тоже нужно, но Revit позволяет выполнять поиск, во-первых, только между файлами Revit. Во-вторых, искать только между категориями элементов. В этом плане функционал Navisworks намного шире.
Чтобы создать проверку нам необходимо предварительно создать наборы, которые мы будем проверять. Смысл создания наборов заключается именно в том, что мы на этапе их создания отсеиваем элементы, которые не будут нас интересовать. Например, в проверке со стяжкой мы не хотим учитывать мелкие трубы. В Navis есть два вида наборов: это обычные наборы выборки, которые сохраняют выбранные ранее вами элементы и это поисковые наборы, которые ориентируются на определенный составленный запрос или условие. Преимуществом таких наборов является автоматическое пополнение элементов в наборе при обновлении файлов отдельных дисциплин. Именно эти наборы мы и будем использовать.
Давайте создадим в части ОВ два набора для труб больше 20мм и труб не более 20мм. Затем создадим наборы, с которыми мы будем их проверять. Для того, что бы определиться сколько наборов вам потребуются и в каких категориях, вы можете обратиться к приложению Е, п. 4.1 из документа ADSK_ШАБЛОН BIM-стандарта организации Площадные объекты_v2_AM 28 10. В соответствии с матрицей коллизий мы будем проверять нашу модель. Количество проверок и размер матрицы зависит от конкретного плана выполнения проекта (BEP).
Создадим проверку в которой, к примеру, мы будем проверять на пересечения перекрытия в составе модели КЖ с трубами диаметром более 20 мм из модели ОВ. Для этого открываем специальный модуль ClashDetective. Выполним проверку и получаем логичные 6 конфликтов между элементами. В этом модуле вы можете вести активную работу: назначение статусов конфликта, ответственных за устранение, формирование отчета. Можно даже открывать конфликтные места при помощи функции SwitchBack прямо в Revit, но это уже совсем другая история…
После того как ваша проверка полностью отфильтрована и вы добавили необходимые комментарии необходимо создать отчет, причем в этот отчет можно добавить только конфликты с нужным вам статусом. Отчеты по разным проверкам идут к разным исполнителям и проектировщик видит только те пересечения, за которые он ответственен.
Действительно, при создании даже самой подробной матрицы хочется быть до конца уверенным в том, что между целыми моделями не разделенными на поисковые наборы точно нет «жестких» коллизий. Тогда нам нужно сделать общую проверку и из нее исключить мягкие коллизии при помощи тех же поисковых наборов.
Проверим целые модели АР_Многоэтажный_жилой_дом_R22 с ОВ_Многоэтажный_жилой_дом_R22. Заведомо зная о том, что трасса отопления лежит в стяжке я не хочу видеть сотни конфликтов, которые напомнят мне об этом и будут мешать анализировать действительно важные пересечения. Чтобы этого не происходило мне потребуется добавить правило в эту проверку по которому если один элемент находится в наборе А а другой в наборе Б, то их пересечение не считается коллизией.
После этого можно запустить проверку. Стоит помнить, что помимо труб в стяжке находятся и соединительные детали трубопроводов, поэтому они также могут дать коллизию.
На этом сегодня заканчиваем. Если у вас есть интересный вопрос в тему координации вы сможете задать его в комментариях.