BIM-технологии

Сводная модель в Revit: как собрать федеративную модель для проверки коллизий

2026-05-01 · 13 мин чтения · ЛЭНДПРОДЖЕКТ

Сводная модель в Revit: как собрать федеративную модель для проверки коллизий

# Сводная модель в Revit: как собрать федеративную модель для анализа коллизий

Когда над проектом одновременно работают пять-восемь дисциплин — архитектура, конструктив, отопление, водоснабжение, электрика, слаботочные системы, технология — каждая ведёт свою отдельную RVT-модель. Пока эти модели существуют изолированно, проектная команда не видит реальной картины: воздуховод спокойно «протыкает» железобетонную балку в АР, потому что в МР-разделе про эту балку никто не знает. Чтобы поймать такие конфликты до выхода рабочей документации в производство, проект нужно собрать в сводную модель — единое цифровое пространство, где все разделы видят друг друга.

В архитектурном бюро ЛЭНДПРОДЖЕКТ сборка сводной модели — обязательный этап выпуска BIM-проекта. На наших коммерческих объектах (жилые комплексы у крупных девелоперов, многофункциональные центры, реконструкция) каждая выдача проходит через автоматизированный конвейер: detach центральной модели, публикация NWC по дисциплинам, формирование NWD-федерации, прогон clash detection и выгрузка отчётов. В этой статье разбираем процесс шаг за шагом — как мы делаем это на реальных проектах и почему этот путь оказался самым стабильным.

Что такое сводная модель и зачем она нужна

Сводная модель (по-английски — *federated model*, в нормативке часто встречается как *совмещённая* или *объединённая модель*) — это BIM-модель, в которой ссылочно объединены отдельные модели разных дисциплин или подрядчиков. В отличие от единого RVT-файла, где всё лежит в одной центральной модели, сводная модель не редактируется напрямую: каждая дисциплина продолжает работать в своём файле, а сводная только показывает, как всё это сосуществует в пространстве.

Для чего нужна именно федеративная сборка:

Принципиальная разница с центральной моделью: сводную модель никто не «ведёт» — она пересобирается перед каждой проверкой из актуальных версий разделов. Это значит, что её процесс сборки должен быть быстрым, повторяемым и автоматизируемым.

Из чего собирается сводная модель

В типовом проекте у нас участвуют следующие RVT-модели (на примере жилого комплекса 6 секций):

Все они хранятся в общем хранилище — это может быть BIM 360 / Autodesk Construction Cloud (для проектов, начатых до отключения сервиса) или собственный Revit Server / файловый сервер. На практике у бюро формата ЛЭНДПРОДЖЕКТ чаще встречается локальный Revit Server плюс облачный обмен через WebDAV или Yandex.Disk для передачи заказчику.

Сводная модель собирается в Autodesk Navisworks Manage — это инструмент Autodesk, специально заточенный под объединение моделей разных форматов (RVT, IFC, DWG, NWC, IFC, DGN) в единое пространство и анализ коллизий между ними. Альтернатива — Solibri Office, но в большинстве российских бюро исторически используется Navisworks.

Шаг 1. Detach центральной модели

Первая операция в нашем pipeline — отделение рабочей копии (*detach from central*) каждой дисциплины. Зачем это нужно:

Правильная команда detach — *Detach and discard worksets* (отделить и сбросить рабочие наборы). Это убирает все права на запись и обнуляет историю синхронизации. Файл становится «фотокопией» текущего состояния.

В ЛЭНДПРОДЖЕКТ эта операция автоматизирована: скрипт `a101_bim.ps1` (живёт у нас в `Agents/АРХИТЕКТОР/`) принимает на вход список центральных моделей, открывает каждую через Revit API, выполняет detach with discard, сохраняет в подкаталог выгрузки. Один проект из десяти моделей собирается примерно за 25–30 минут — основное время уходит на загрузку связанных RVT (linked models).

Важный нюанс: при детаче моделей с linked-связями нужно перезапускать Revit между файлами. Если этого не делать, накапливаются ссылки на уже закрытые документы, и в какой-то момент Revit падает с ошибкой памяти. Мы выяснили это на проекте 163-ЦК-МФЦ: после восьмого detach'а подряд процесс умирал. Решение — между моделями выполнять полный перезапуск приложения через bridge-команду.

Шаг 2. Экспорт NWC по каждой дисциплине

NWC (Navisworks Cache) — это лёгкий формат-«срез» модели специально для Navisworks. По размеру NWC-файл обычно в 5–10 раз меньше исходного RVT, потому что в нём нет 2D-видов, листов, аннотаций — только геометрия 3D с привязанными параметрами.

Экспорт NWC выполняется внутри Revit через плагин Navisworks Exporter (устанавливается вместе с Navisworks Manage). После установки в меню Revit появляется команда *Add-Ins → External Tools → Navisworks*, которая выгружает текущую модель в NWC.

В нашем конвейере NWC-экспорт автоматизирован через Revit API — скрипт открывает detach-копию, проверяет, что в модели задана корректная общая система координат (Project Base Point + Survey Point), запускает экспорт с настройками:

Результат — папка с десятью NWC по числу дисциплин. Имена файлов привязаны к коду раздела по СПДС (`AR.nwc`, `KR.nwc`, `OV.nwc` и так далее) — это критично для следующего шага.

Шаг 3. Сборка федеративной NWD-модели

NWD (Navisworks Document) — финальный формат сводной модели. В отличие от NWF (project file, который ссылается на исходные NWC), NWD содержит всю геометрию внутри себя — это самодостаточный архив, который можно отдать заказчику и быть уверенным, что он откроет проект на любом компьютере.

Сборка NWD выполняется так:

  1. Открывается Navisworks Manage, создаётся пустой проект
  2. Через *Append* добавляются все NWC из папки экспорта
  3. Каждой дисциплине настраивается видимость через *Selection Tree* (например, можно временно скрыть слаботочку для проверки конфликтов архитектуры с конструктивом)
  4. Проверяется правильность координатной привязки — все модели должны лежать в общей системе, без сдвигов
  5. Сохраняется как `.nwd` через *File → Save As → Navisworks NWD Document*

Здесь важна автоматизация. Когда дисциплин десять и более, ручная сборка занимает 15–20 минут и оставляет место для ошибок (забыли добавить раздел, не та версия NWC). Мы используем COM-API Navisworks Manage: PowerShell-скрипт открывает приложение в фоновом режиме, через `Application.OpenFile()` подгружает каждый NWC, через `SaveAs()` сохраняет результирующий NWD.

Технический нюанс, который мы выяснили эмпирически: COM-вызовы Navisworks стабильно работают только в session 0 (системная сессия Windows). Если запустить скрипт в активной пользовательской сессии — Navisworks может зависать на стадии загрузки моделей. Поэтому конвейер запускается через Task Scheduler с настройкой *Run whether user is logged on or not*.

Шаг 4. Прогон clash detection

Сводная модель собрана — теперь по ней нужно прогнать тесты на коллизии (clash tests). Navisworks Manage умеет искать как геометрические пересечения (hard clashes), так и нарушения нормативных зазоров (soft / clearance clashes).

В ЛЭНДПРОДЖЕКТ для каждого проекта определён базовый набор clash-тестов:

Каждый тест запускается в Navisworks через панель *Clash Detective*. Современные версии умеют сохранять результаты в формате XML и выгружать набор скриншотов с ракурсами по каждому конфликту. Один прогон по жилому комплексу средних размеров обнаруживает от 200 до 1500 коллизий — большинство из них дубликатные или несущественные (зазор 5 мм между трубой и стеной, который потом закроется штукатуркой).

Главная задача BIM-координатора после прогона — отфильтровать критичные конфликты от шума. Здесь помогают сохранённые наборы (*Search Sets*) — фильтры, которые автоматически отбирают только те клэши, которые попадают в зону ответственности конкретной дисциплины и превышают пороговое значение по объёму пересечения.

Шаг 5. Выгрузка отчёта и BIM Issues

Финальная стадия — превратить найденные коллизии в задачи для проектировщиков. Просто отправить XML с тысячей строк нельзя — никто не будет это разбирать. Каждая критичная коллизия должна стать BIM Issue: задача в системе с описанием, скриншотом, ракурсом камеры в модели и привязкой к ответственному разделу.

В ЛЭНДПРОДЖЕКТ мы используем гибридный подход:

Формат BCF поддерживается всеми основными платформами и сохраняет:

Это означает, что проектировщик, открыв BCF в Revit или Navisworks, может одной кнопкой подгрузить нужный ракурс, увидеть конкретные элементы и понять, что нужно поправить — не разглядывая статичный PDF.

Автоматизация: где AI-агенты заменяют ручную работу

Описанный процесс — detach, NWC, NWD, clash, BCF — занимает у живого BIM-координатора 4–6 часов на каждую выдачу. Если выдач в неделю две-три, координатор тратит на это половину рабочего времени. Эту работу мы перенесли на агента.

В нашем конвейере (агент АРХИТЕКТОР в составе системы AI-агентов ЛЭНДПРОДЖЕКТ) автоматизированы:

Время сборки сокращается до 30–45 минут полностью без участия человека. Координатор включается на этапе фильтрации результатов — сводный отчёт ему уже падает в Telegram через CEO-бота с превью количества коллизий и ссылкой на NWD.

Что ещё пробуем подключить:

Типовые ошибки при сборке сводной модели

За три года ведения BIM-проектов мы накопили список ошибок, которые повторяются у разных бюро и подрядчиков. Делимся, чтобы вам не пришлось наступать на те же грабли.

Ошибка 1: модели в разной системе координат. Самый частый случай. Архитектор работает в *Project Internal*, инженер ОВ — в *Shared Coordinates* без привязки к Project Base Point. Результат — модели в Navisworks разъезжаются на сотни метров. Профилактика: до начала проекта BIM-координатор фиксирует в BEP (BIM Execution Plan) общую СК и Project Base Point. Все дисциплины обязаны привязаться к одному файлу-эталону через *Acquire Coordinates*.

Ошибка 2: NWC экспортируется со скрытыми элементами. В Revit можно временно скрыть какие-то категории через *Visibility/Graphics*. Если на момент экспорта что-то скрыто — оно не попадёт в NWC, и в сводной модели появится «дыра». Профилактика: перед каждым экспортом сбрасываются все temporary view overrides, и используется полный 3D-вид типа `{3D}_NAVIS_EXPORT` со включённым Reveal Hidden Elements.

Ошибка 3: разные версии NWC в одной NWD. Координатор собирает NWD, а кто-то из проектировщиков уже выпустил новую версию своего раздела. Сводная модель показывает устаревшие данные, а конфликты в ней — несуществующие. Профилактика: регламент по выдачам — фиксированная дата и время cut-off, до которой все обязаны опубликовать актуальную версию. После этого координатор делает сборку.

Ошибка 4: linked-модели «забывают» внутренние ссылки. Если в RVT есть вложенные linked-файлы (например, шахта лифта как отдельная модель), при detach без аккуратной настройки они могут потеряться. NWC получится без шахты, и в сводной модели её не будет. Профилактика: в скрипте detach перед экспортом проверяется список linked документов и принудительно подгружается каждый.

Ошибка 5: тесты на коллизии без фильтров по объёму. Если запустить clash без минимального порога по объёму пересечения — Navisworks выдаст десятки тысяч случаев типа «гипсокартон касается стены на 0,5 мм». Это шум. Профилактика: каждый тест настраивается с порогом *Tolerance* от 5 до 50 мм в зависимости от дисциплины. Архитектура × конструктив — 10 мм. ИОС × ИОС — 25 мм. ИОС × конструктив — 50 мм с учётом нормативных зазоров.

Сводная модель и экспертиза

Отдельный вопрос — формат, в котором сводная модель сдаётся в экспертизу. Государственная экспертиза (Мосгосэкспертиза, Главгосэкспертиза) с 2024 года требует BIM-модель в формате IFC4 в составе экспертного комплекта. Negativ-экспертиза по ст. 49 ГрК тоже всё чаще запрашивает BIM, особенно по объектам выше 6 этажей.

Что важно понимать:

Если ваш проект сдаётся одновременно в формате NWD девелоперу и в формате IFC экспертизе — закладывайте на это два отдельных pipeline. Они частично пересекаются (общий detach, общая система координат), но дальше расходятся: NWD идёт в Navisworks, IFC — в стандартный IFC-экспортёр Revit с post-process.

Когда стоит начинать собирать сводную модель

Распространённая ошибка — собирать сводную модель только перед сдачей проекта. К этому моменту в моделях накапливаются сотни конфликтов, исправлять которые поздно: чертежи готовы, ведомости выпущены, проектировщики уже на следующем объекте.

Правильный подход:

Регулярность — главный фактор успеха. Сводная модель раз в неделю с ста коллизиями — это управляемая ситуация. Сводная модель раз в три месяца с двумя тысячами коллизий — это катастрофа, которую разгребают полквартала.

Подведём итог

Формирование сводной модели — это не разовая операция, а регулярный технологический процесс, который должен быть встроен в производственный цикл проектирования. Грамотно собранный pipeline — detach → NWC → NWD → clash detection → BCF — позволяет находить конфликты на стадии модели, а не на стройке, экономя 5–15% бюджета объекта и недели графика.

В ЛЭНДПРОДЖЕКТ мы прошли путь от ручной сборки сводных моделей к полностью автоматизированному конвейеру на базе AI-агентов. Сегодня сборка сводной модели для жилого комплекса средних размеров занимает у нас 30–45 минут вместо 4–6 часов — и это время мы тратим на то, что действительно требует экспертизы: фильтрацию найденных коллизий и принятие решений о способе их устранения.

Если вы планируете BIM-проект и хотите, чтобы сводная модель не стала головной болью на стадии РД, обратитесь к нам. Мы спроектируем и согласуем процесс сборки с учётом специфики объекта, требований заказчика и используемого софта — от классического Revit + Navisworks до гибридных стеков с российскими системами.

Архитектурно-проектное бюро ЛЭНДПРОДЖЕКТ

Москва, проектирование жилых и общественных зданий, посёлков, реконструкции

landproject.net · mail@landproject.net · +7 903 523 60 92

Обсудить ваш проект

Расскажите о задаче — предложим решение за 24 часа

Оставить заявку

📐 Подписывайтесь на канал ЛЭНДПРОДЖЕКТ в MAX →