Для BIM‑координаторов и проектировщиков, работающих с Navisworks
Введение
При проектировании инженерных систем (и не только) координация разделов почти всегда идёт через Navisworks Clash Detective, особенно на крупных проектах. Проектировщики создают модели, координатор загружает их в Navisworks и ищет междисциплинарные коллизии: трубы через воздуховоды, лотки электрики через слаботочное оборудование и т.д.
Большинство координаторов, кто хоть раз работал с отчётами Navisworks, знают (наверное): даже при идеальном BEP и строгой логике первая проверка выдаёт сотни «фиктивных» коллизий.
Фиктивная коллизия — это любое пересечение, которое не влияет на монтаж и качество проекта. Именно такое определение сейчас всё чаще встречается в BIM-документах.
Фильтруя подобные коллизии, мы резко сокращаем объём отчёта и направляем время специалистов только на действительно критичные конфликты. На такие коллизии в моделях, как правило, экспертиза и заказчик обращают внимание в первую очередь.
В данной статье я продемонстрирую подход к работе со сводной моделью и инструменты Navisworks, которые позволяют быстро находить и исключать фиктивные коллизии. Фокус будет не на самих инструментах «Поисковые наборы» и «Правила исключения» (стандартные инструменты для исключения), а на алгоритме анализа и подходах максимально эффективного применения данных инструментов.
В конце статьи оставлю ссылку на свой телеграм-канал, в нем я выложу сводную модель из статьи.
Примеры типовых фиктивные коллизии
- Врезки и клапаны у воздуховодов, в самопересечения вентиляции почти всегда вызывают фиктивные коллизии. Но для каждого проекта могут содержать уникальные названия семейства и другие параметры, поэтому почти нереально исключить заранее.
- Аналитические объемы — зоны обслуживания (для любого оборудования), схемы орошения (для спринклеров), объемная зона видеонаблюдения у камер (для систем безопасности).
- Оборудования слаботочных систем и автоматики почти всегда вызывают фиктивные коллизии. Т. к. зачастую элементы данных систем зависят от оборудования смежных разделов.
- Вложенные общие семейства — они также практически всегда вызывают фиктивные коллизии, т. к. Navisworks не учитывает иерархию семейств, а воспринимает вложенные семейства как отдельные элементы. Что приводит к коллизии между вложенным и основным.
Все эти случаи не требуют изменения проекта и не создадут проблем на стройке. Их исключение из отчёта позволяет сосредоточиться на настоящих конфликтах.
При этом важно помнить, подобные исключения необходимо обсуждать с заказчиком и вносить в BEP (если для заказчика это необходимо). Для формирования общего видения критериев оценки качества модели, для успешного завершения проекта.
Основные инструменты
Далее в статье я буду исходить из того, что вы уже овладели данными инструментами. Базовые элементы управления конкретно в этой статье описываться не будут.
Navisworks — программа, который нам нужен для анализа моделей.
ClashDetective — инструмент для поиска коллизий в программе Navisworks.
Поисковые наборы — правила поиска для определения элементов в сводном файле проекта Navisworks.
Правила исключений — настройка, позволяющая исключить созданные поисковые наборы из проверки.
Алгоритм поиска и исключения фиктивных коллизий.
Предварительная подготовка.
Во-первых, начало работы всегда должно отталкиваться от сбора исходных данных на проекте. Какие разделы участвуют в отработке коллизий, есть ли разделы, чьи сети желательно не менять, все ли модели актуальны и прочие вопросы, которые позволят выполнить работу по анализу коллизий эффективнее. По ходу работы также нужно поддерживать контакт с ГИПами, РП, исполнителями, всеми заинтересованными в процессе лицами.
Создание сводной модели и проверок
Далее мы подготавливаем сводную модель Navisworks. Как правило, за основу для создания проверок в ClashDetective используется матрица по требованиям заказчика либо внутренняя матрица организации. Зачастую для конкретного проекта матрица проверок на коллизии дополняется новыми проверками или исключаются существующие, по мере необходимости на проекте.
Для примера возьму за основу стандартные проекты Revit по разделам ВИС (ОВ, ВК, ЭОМ).
Матрицу проверок я сделаю в упрощенном виде по разделам. Отдельно проверки внутри раздела и отдельно со смежными. Итого 5 проверок:
Проверки, созданные по матрице, допуск 15 мм, тип «По пересечению (консервативно)».
Работа с коллизиями
После первого запуска проверок на коллизии обычно в отчеты ClashDetective попадают сотни, а иногда тысячи коллизий. Исходя из моего опыта, реальных (критических) коллизий, которые влияют на процессы монтажа и координации сетей, не более 15%. При этом чем выше требования к проверкам (низкий допуск + консервативные проверки), тем выше процент фиктивных коллизий.
Запускаю все проверки и вижу наибольший объем коллизий в проверке «02_ОВ - ОВ» — 414 шт.
Для проведения визуального анализа коллизий группирую все найденные 414 шт. в одну группу.
Вижу большой объем типовых коллизий — воздуховоды и элементы внутри, скорее всего, это воздухораспределители.
Выбираю один из типовых элементов, вызывающих коллизию. После нажимаю «Выбрать то же/То же имя». На виде у меня попадают в выбор все подобные элементы.
Пока у меня выбраны все подобные элементы, я включаю фильтр коллизий в режиме «Включающий».
После выполнения данных манипуляций у меня на экране остаются все подобные типовые коллизии. На этом этапе я провожу визуальный контроль по всей модели либо прохожусь по каждой коллизии, оставшейся в списке.
Далее, если я убежден, что все эти коллизии являются фиктивными и могут быть исключены из проверки, я переношу их в новую группу. Для этого убеждаюсь, что исключаемые элементы все еще выделены, проверяю наличие фильтра «Включающий», то есть все коллизии в окне результатов принадлежат выбранным элементам. После создаю с ними новую группу по кнопке с тремя кружками «Группировать выбранные конфликты».
Созданную группу переименовываю в «Воздухораспределители», выключаю фильтр. И вижу новую группу с фиктивными коллизиями и старую группу с оставшимися.
Возвращаюсь к основной группе. Вижу, что основной объем коллизий существенно сократился.
Продолжаю дальше визуально осматривать оставшиеся коллизии, вижу, что много коллизий с гибкими воздуховодами. Они не связаны с проектными ошибками, а вызваны особенностями построения.
Чтобы найти все подобные коллизии, делаю поисковой набор на «Гибкие воздуховоды» и включаю фильтр коллизий.
После того как мы выбрали все элементы и отфильтровали коллизии, выбираем их в списке и создаем новую группу.
Возвращаемся к нашей основной группе и проверяем, что же еще осталось. Мы видим, что осталось только 4 конфликта.
Это 4 однотипных пересечения, их нельзя считать фиктивными, они должны быть выданы как задание на устранение коллизии.
Делаем вывод, что мы нашли все фиктивные коллизии в нашей проверке. Далее создаем поисковые наборы. Для воздухораспределителей и гибких решил сделать поиск по категории.
Дополнительно я создам поисковой набор для воздуховодов и для всех элементов, они нам будут нужны для создания правил.
Создаем правило для исключения.
Воздухораспределители я буду исключать на коллизии с воздуховодами.
Гибкие воздуховоды исключаю со всеми элементами.
Включаем созданные правила.
Для контроля запускаем еще раз проверку «Повторить проверку». Видим, что созданные группы перешли в статус «Исправлено», значит, исключения работают корректно.
На этом считаем, что проверку мы настроили и подготовили к дальнейшему анализу моделей.
Заключение
В результате нашего анализа и исключения фиктивных коллизий мы сократили количество с изначальных 414 шт. до 4 шт. Получается, что фиктивных коллизий в изначальном отчете было больше 99%.
По аналогии необходимо выполнить анализ коллизий для всех остальных проверок. В конце мы получим максимально качественный отчет, его уже можно выдавать в работу специалистам, работающим с моделями.
Если вы дочитали данную статью и сочли ее полезной, прошу поставить лайк. Также, если вам было бы интересно увидеть процесс в формате видо, прошу сообщить в комментариях.
Сводную модель можно скачать из моего телеграмм канала: