Коллизии в модели: как проверять до того, как проверит экспертиза

«Нашли четыре тысячи коллизий» — фраза, которую произносят с гордостью, а стоило бы с тревогой. Четыре тысячи строк в отчёте не значат, что модель проверена. Обычно это значит, что кто-то первый раз запустил автоматический тест на всей сборке за две недели до сдачи.

Проверка на коллизии — не кнопка. Это регламент: что с чем сверяем, с каким допуском, как часто, кто отвечает и что считается закрытой позицией. Разберём, как это устроено по казахстанским нормам и как выглядит на практике.

Что вообще считается коллизией

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

Жёсткие — геометрия одного элемента заходит в другой. Воздуховод сквозь балку, стояк сквозь плиту. Такие правятся в первую очередь.

Зазорные — пересечения нет, но нарушен нормативный или монтажный зазор. Труба вплотную к стене, и обслуживать её нечем. Формально чисто, фактически проблема на объекте.

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

Отдельная категория, которую часто забывают, — коллизии между версиями. Смежник обновил модель, вы работаете со старой выгрузкой. Геометрически всё сходится, на площадке — нет. Это лечится не проверками, а порядком обмена в среде общих данных.

Что говорит норматив

Основной документ — СП РК 1.02-111-2017. Формулировки там аккуратные, и это важно понимать правильно.

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

А вот к результату требование сформулировано жёстко. Пункт 7.11: после проверки и устранения коллизий проектная информационная модель должна отвечать трём условиям — нет пересечений между конструктивными и архитектурными элементами, нет пересечений между конструкциями и инженерными системами, нет пересечений между инженерными подсистемами.

Разница принципиальная. Форму контроля вы выбираете сами, состояние модели на выходе — нет.

Ещё один пункт, который читают невнимательно: программное обеспечение, используемое при информационном моделировании, должно позволять проверку на коллизии. Это требование к инструментарию, а не пожелание.

Три этапа проверки сводной модели

Свод правил разбивает проверку сводной модели на три шага, и коллизии там — только третий.

1. Соответствие стандарту организации по ТИМСО. Внутренние правила: именование, структура, шаблоны.
2. Соответствие плану выполнения проекта (BEP). Делаем ли мы то, что сами описали заказчику.
3. Проверка на коллизии и изменения.

По первым двум этапам составляются отчёты о соответствии информационной модели стандарту организации и информационным требованиям заказчика. По третьему — журнал коллизий и журнал изменений. Про то, откуда берутся EIR и BEP и кто их пишет, у нас есть отдельный разбор.

И ключевая строчка, которую пропускают чаще всего: для контроля за осуществлением проверок должен быть назначен участник проекта с соответствующими навыками и квалификацией. Один человек. С именем.

Три вида проверок: не только автоматика

Свод правил называет три вида, и это удобная рамка для регламента.

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

Визуальная. Делает сам исполнитель: единицы измерения проекта, пространственная ориентация модели (базовая точка, точка съёмки), наличие служебных видов и конфигураций слоёв. Инструменты простые — таблицы нужной структуры, перекраска элементов. Результат — отчёт в электронном виде.

Экспертная, она же нормоконтроль. Соответствие принятым проектным решениям, действующим нормативам и информационным требованиям заказчика.

Честно говоря, большинство команд живёт только на первом виде. При этом половина замечаний на выходе — из зоны второго и третьего: не та базовая точка, единицы в миллиметрах против метров, помещения не размечены. Автоматический тест на коллизии про это молчит.

Типовые проверки и проектные

Полезное разделение из того же свода правил.

Типовые — параметры не меняются от проекта к проекту. Пересечение объектов, соответствие элементов архитектурной и конструктивной модели, свободное пространство перед дверьми и окнами, пересечение элементов инженерных систем.

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

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

Матрица коллизий — документ, которого обычно нет

Матрица отвечает на вопрос «что с чем сверяем и с каким допуском». По строкам и столбцам — разделы модели: архитектура, конструкции, отопление и вентиляция, водоснабжение, электрика, слаботочка, технология. На пересечении — нужна ли проверка, какой зазор считается нарушением, кто отвечает за разбор.

Свод правил прямо рекомендует перед проверкой составить список пунктов: номер проверки, содержание, раздел модели, примечания. Матрица — это тот же список, только в удобной форме.

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

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

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

Navisworks остаётся рабочей лошадкой координации. Clash Detective собирает сводную модель из разных форматов и гоняет тесты по парам наборов элементов. В версии 2027 модуль переработали: обновлённый интерфейс и папки для тестов — тесты можно группировать, а операции сброса, обновления и удаления выполнять на уровне папки, видя новые коллизии по группе целиком. Для матрицы на два десятка тестов это заметно удобнее плоского списка.

Revit закрывает проверки внутри раздела и часть визуальных: свои коллизии, параметры, именование, помещения. Ловить междисциплинарные пересечения в нём неудобно — для этого и нужна сводная сборка.

Autodesk Forma Model Coordination — облачный вариант. Модели разных разделов и форматов, загруженные в проект, проверяются на пересечения автоматически, коллизии группируются по системам, типам объектов или слоям, и из них создаются задачи с ответственным и сроком. Хорошо ложится на команды, где смежники внешние. Что именно поменялось в линейке после ребренда ACC, мы разбирали в сравнении сред общих данных.

Solibri работает в другой логике. Navisworks отвечает на вопрос «что с чем пересекается», Solibri — «соответствует ли модель заданному набору требований»: заполненность параметров, структура, пространства, соответствие правилам, валидация по IDS. Проверка по правилам тут первична, пересечения — частный случай.

Линейку в 2026 году перестроили. Solibri Office и CheckPoint ушли в legacy, вместо них четыре тарифа. В Starter результаты проверок только просматривают. С Essential появляется проверка по преднастроенным правилам, структурный клэш-контроль и работа с замечаниями в BCF. Advanced добавляет собственные правила, валидацию по IDS и подсчёт объёмов. Premium централизует управление правилами на всю организацию, чтобы одни и те же стандарты применялись на каждом проекте. Для закрытых контуров есть отдельный Security+.

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

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

Почему четыре тысячи коллизий — это не результат

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

Работающий регламент выглядит примерно так:

• частота прогонов зафиксирована — например, раз в неделю на активной стадии;
• у каждого теста есть ответственный за разбор, а не «отдел ОВ»;
• коллизия закрывается не в отчёте, а в модели, и следующий прогон это подтверждает;
• спорные позиции превращаются в задачу с решением, а не висят в статусе «согласовано устно»;
• журнал коллизий и журнал изменений ведутся в течение проекта, а не собираются задним числом.

Последний пункт особенно неприятно всплывает на сдаче. Журнал, написанный за вечер, видно сразу: даты кучкуются, изменения не бьются с версиями модели.

С чего начать, если регламента нет

1. Назначить ответственного за проверки. Одного, с квалификацией и полномочиями.
2. Собрать матрицу коллизий под типовой для вас объект. Хватит одного дня и электронной таблицы.
3. Настроить типовой набор тестов в шаблоне, чтобы не повторять настройку.
4. Договориться о частоте и точках синхронизации со смежниками.
5. Завести журналы коллизий и изменений в среде общих данных, а не в личной папке.

Если на первом шаге выясняется, что назначать некого, — это отдельный разговор про роли. Мы разбирали его в статье про BIM-менеджера в штате и на аутсорсе.

Что дальше

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

Хотите понять, что из этого уже есть у вас, — скачайте чек-лист готовности к BIM/ТИМСО. Больше ста пунктов по процессам, ПО, команде и инфраструктуре.

Нужно настроить координацию под конкретный проект или подобрать связку инструментов — оставьте заявку, разберём вашу ситуацию.

Частые вопросы

Обязательно ли проверять модель на коллизии по казахстанским нормам?

Сами процедуры проверок СП РК 1.02-111-2017 рекомендует, а шаблоны журналов вынесены в информационные приложения. При этом к готовой модели пункт 7.11 предъявляет требование: пересечений между архитектурой, конструкциями и инженерными системами быть не должно. Способ контроля вы выбираете сами, результат — нет.

Чем проверять, если бюджета на отдельный инструмент нет?

Начать можно с координации внутри Revit и ручной сводной сборки. Это медленнее и не закрывает всех сценариев, но лучше, чем не проверять. Свод правил при этом требует, чтобы используемое ПО в принципе позволяло проверку на коллизии, — этот пункт стоит учитывать при выборе.

Как часто гонять проверки?

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

Кто отвечает за разбор коллизий?

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

Что делать со спорными позициями?

Фиксировать как задачу с решением и сроком, а не закрывать устной договорённостью. Если позиция признана допустимой, это тоже решение — с обоснованием, чтобы через полгода не искать, почему труба проходит именно так.

Читайте также

• EIR и BEP: документы, без которых BIM-проект не примут
• Аудит готовности к BIM: что проверяют и что он показывает
• Autodesk Forma, SIGNAL или SODIS: как выбрать СОД
• Чем СОД отличается от облачного диска
• BIM-менеджер: брать в штат или отдать на аутсорс
• BIM и ТИМСО в 2026: что обязывает Строительный кодекс РК
• AEC Collection против отдельных лицензий
• BIM или AutoCAD: когда пора переходить