Коллизии в проекте: виды, проверка модели и регламент устранения
Виды пересечений между разделами, порядок проверки информационной модели и регламент, который превращает список коллизий в закрытые замечания. Почему проверка в конце проекта не работает и как расставить приоритеты.
Коллизия — конфликт решений разных разделов: воздуховод проходит сквозь балку, кабельный лоток упирается в трубопровод, оборудование не проходит в дверной проём. На бумаге такие вещи прячутся в десятках листов, а на стройке всплывают в самый неудобный момент, и каждая находка стоит времени и денег.
Информационное моделирование позволяет искать пересечения заранее, но только если проверка выстроена как процесс, а не как кнопка в программе. Ниже — какие бывают коллизии, что из них находит программа, а что только человек, в каком порядке вести проверку и как расставлять приоритеты, чтобы список замечаний действительно закрывался.
Виды коллизий и кто их находит
Не все конфликты решений видны программе. Сравнение типов показывает, где автоматическая проверка помогает, а где нужен инженер:
| Вид коллизии | В чём проявляется | Кто находит |
|---|---|---|
| Геометрическая жёсткая | Элементы физически пересекаются | Программа проверки модели |
| Геометрическая мягкая | Нарушены нормативные зазоры, зоны обслуживания, проходы | Программа по заданным правилам и допускам |
| Информационная | В модели одна марка оборудования, в спецификации другая | Специалист при сверке атрибутов и ведомостей |
| Временная | Монтаж одного элемента блокирует доступ к другому | Специалист по организации строительства |
| Нормативная | Решение противоречит требованию, хотя геометрически всё сходится | Эксперт или проверяющий по разделу |
Программы проверки уверенно находят первые два типа. Остальные выявляются людьми, и это стоит помнить, когда исполнитель говорит, что модель «проверена на коллизии»: уточните, какие именно виды охватывала проверка.
Порядок проверки модели
Рабочая схема одинакова для большинства проектов, меняются только правила и частота:
- Сведите модели разделов в единый файл по установленному регламенту, в одной системе координат.
- Запустите проверку по заранее описанным правилам: какие разделы с какими сверяются и с какими допусками.
- Отфильтруйте ложные срабатывания. В первой итерации их обычно больше половины.
- Классифицируйте оставшиеся по критичности.
- Назначьте ответственного за каждую коллизию с указанием раздела и срока исправления.
- Проверьте устранение при следующем сведении и закройте замечание только после подтверждения.
Что делает проверку бесполезной
Чаще всего коллизии не устраняются не потому, что их не нашли, а потому, что процесс устроен неправильно:
- Разовая проверка в конце. Тысяча коллизий за неделю до сдачи не устраняется. Сведение делается регулярно, с самого начала — раз в одну-две недели.
- Отсутствие правил и допусков. Без настроенных правил отчёт содержит десятки тысяч срабатываний, и его никто не читает.
- Нет ответственных. Список коллизий без назначенного исполнителя и срока — просто документ.
- Проверяются не все разделы. Технологическое оборудование и его обвязка нередко остаются вне модели, а именно там больше всего конфликтов.
- Исправления вносятся в чертежи, а не в модель. Через неделю модель и документация расходятся, и следующая проверка бессмысленна.
Приоритизация замечаний
Исправлять всё и сразу невозможно, поэтому замечания делят по влиянию на проект. Критичные — те, что затрагивают несущие конструкции и прокладку магистральных сетей: чем позже их исправляют, тем дороже. Средние касаются зон обслуживания, проходов и доступа к оборудованию. Низкие — мелкие пересечения, которые решаются по месту при монтаже без последствий для проекта.
Разумно закрыть критичные коллизии до выпуска стадии «Проектная документация», остальные — в рабочей документации. Состав документации по стадиям определён постановлением Правительства РФ № 87, а правила и методические материалы по информационному моделированию публикует Минстрой России.
Типичные причины коллизий
Знать причины полезнее, чем собирать статистику пересечений: если убрать источник, число замечаний падает само. Чаще всего коллизии рождаются из нескольких повторяющихся ситуаций:
- Разные системы координат. Разделы построены от разных точек привязки, и при сведении модели смещены друг относительно друга.
- Работа по устаревшим заданиям. Смежник не получил уведомление об изменении и продолжает проектировать по прежним данным.
- Модель не отражает фактического решения. Трубопровод в чертеже проходит одним способом, а в модели нарисован упрощённо.
- Нет единых правил зон обслуживания. Каждая система резервирует место по-своему, и пространство вокруг оборудования достаётся тому, кто занял его раньше.
- Позднее подключение смежных разделов. Технология и вторичные системы приходят в проект, когда несущая часть уже выпущена.
На практике половину пересечений можно предотвратить за счёт простых договорённостей: единая точка привязки, общий план зон прокладки сетей, закрепление коридоров для магистралей до начала детальной проработки. Эти решения принимает ГИП или координатор модели в самом начале, а не после первого отчёта о коллизиях.
Важно и то, как формулируются замечания. Хорошее замечание содержит расположение (оси, отметка), участвующие элементы, раздел-владелец и желаемое действие. Плохое выглядит как скриншот с красными кружками: исполнитель теряет время на поиски места, а потом спорит, чья это зона ответственности. Дисциплина оформления замечаний сокращает цикл устранения заметнее, чем самые мощные средства проверки.
Как заказчику проверить, что коллизии действительно ищут
Заказчик не обязан разбираться в программах, но может требовать прозрачности. В задании на проектирование стоит указать периодичность сведения моделей, формат отчёта о коллизиях и порядок его передачи заказчику. На промежуточной приёмке попросите показать отчёт по последнему сведению: сколько коллизий найдено, сколько закрыто, кто отвечает за остальные. Если исполнитель показывает только итоговое «коллизий нет», без истории, это повод усомниться в процессе.
Как оформить отчёт о коллизиях
Отчёт — это инструмент управления, а не архив скриншотов. В нём должны быть дата сведения, версии моделей, количество найденных, закрытых и открытых коллизий по разделам и срокам. Для каждой открытой строки указывают ответственного, критичность и плановую дату исправления. Динамика по неделям показывает, сходится ли проект к выпуску: если число открытых критичных замечаний не снижается, проблема в процессе, а не в отдельных проектировщиках. Хорошая практика — короткая еженедельная встреча координатора с руководителями разделов, на которой разбираются только критичные и просроченные позиции.
Что сделать до начала проекта
Закрепите в договоре и регламенте несколько вещей. Определите, какие разделы входят в модель, включая технологическое оборудование. Согласуйте правила проверки и допуски, в том числе зазоры для обслуживания. Назначьте координатора, который собирает модели и ведёт реестр замечаний. Установите срок реакции на коллизию: например, критичные замечания получают исполнителя в течение рабочего дня. Предусмотрите повторное сведение после каждого исправления.
Проектировщиков, которые ведут проекты с регулярной проверкой коллизий, можно найти в разделе проектирования на площадке «Ресурс-Плюс». Заявка размещается бесплатно, исполнители откликаются с ценой и сроками, договор вы заключаете напрямую, без комиссии, а сама площадка проектные работы не выполняет. Опишите объект и требования к модели в форме ниже.
Обсуждение
Пока нет комментариев. Будьте первым!









