Коллизии в проекте: виды, проверка модели и регламент устранения

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

КоллизииКонтроль качестваПроектирование

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

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

Виды коллизий и кто их находит

Не все конфликты решений видны программе. Сравнение типов показывает, где автоматическая проверка помогает, а где нужен инженер:

Вид коллизииВ чём проявляетсяКто находит
Геометрическая жёсткаяЭлементы физически пересекаютсяПрограмма проверки модели
Геометрическая мягкаяНарушены нормативные зазоры, зоны обслуживания, проходыПрограмма по заданным правилам и допускам
ИнформационнаяВ модели одна марка оборудования, в спецификации другаяСпециалист при сверке атрибутов и ведомостей
ВременнаяМонтаж одного элемента блокирует доступ к другомуСпециалист по организации строительства
НормативнаяРешение противоречит требованию, хотя геометрически всё сходитсяЭксперт или проверяющий по разделу

Программы проверки уверенно находят первые два типа. Остальные выявляются людьми, и это стоит помнить, когда исполнитель говорит, что модель «проверена на коллизии»: уточните, какие именно виды охватывала проверка.

Порядок проверки модели

Рабочая схема одинакова для большинства проектов, меняются только правила и частота:

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

Что делает проверку бесполезной

Чаще всего коллизии не устраняются не потому, что их не нашли, а потому, что процесс устроен неправильно:

  • Разовая проверка в конце. Тысяча коллизий за неделю до сдачи не устраняется. Сведение делается регулярно, с самого начала — раз в одну-две недели.
  • Отсутствие правил и допусков. Без настроенных правил отчёт содержит десятки тысяч срабатываний, и его никто не читает.
  • Нет ответственных. Список коллизий без назначенного исполнителя и срока — просто документ.
  • Проверяются не все разделы. Технологическое оборудование и его обвязка нередко остаются вне модели, а именно там больше всего конфликтов.
  • Исправления вносятся в чертежи, а не в модель. Через неделю модель и документация расходятся, и следующая проверка бессмысленна.

Приоритизация замечаний

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

Разумно закрыть критичные коллизии до выпуска стадии «Проектная документация», остальные — в рабочей документации. Состав документации по стадиям определён постановлением Правительства РФ № 87, а правила и методические материалы по информационному моделированию публикует Минстрой России.

Типичные причины коллизий

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

  • Разные системы координат. Разделы построены от разных точек привязки, и при сведении модели смещены друг относительно друга.
  • Работа по устаревшим заданиям. Смежник не получил уведомление об изменении и продолжает проектировать по прежним данным.
  • Модель не отражает фактического решения. Трубопровод в чертеже проходит одним способом, а в модели нарисован упрощённо.
  • Нет единых правил зон обслуживания. Каждая система резервирует место по-своему, и пространство вокруг оборудования достаётся тому, кто занял его раньше.
  • Позднее подключение смежных разделов. Технология и вторичные системы приходят в проект, когда несущая часть уже выпущена.

На практике половину пересечений можно предотвратить за счёт простых договорённостей: единая точка привязки, общий план зон прокладки сетей, закрепление коридоров для магистралей до начала детальной проработки. Эти решения принимает ГИП или координатор модели в самом начале, а не после первого отчёта о коллизиях.

Важно и то, как формулируются замечания. Хорошее замечание содержит расположение (оси, отметка), участвующие элементы, раздел-владелец и желаемое действие. Плохое выглядит как скриншот с красными кружками: исполнитель теряет время на поиски места, а потом спорит, чья это зона ответственности. Дисциплина оформления замечаний сокращает цикл устранения заметнее, чем самые мощные средства проверки.

Как заказчику проверить, что коллизии действительно ищут

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

Как оформить отчёт о коллизиях

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

Что сделать до начала проекта

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

Проектировщиков, которые ведут проекты с регулярной проверкой коллизий, можно найти в разделе проектирования на площадке «Ресурс-Плюс». Заявка размещается бесплатно, исполнители откликаются с ценой и сроками, договор вы заключаете напрямую, без комиссии, а сама площадка проектные работы не выполняет. Опишите объект и требования к модели в форме ниже.

Была полезна статья?
6

Обсуждение

Пока нет комментариев. Будьте первым!

Смотрите также