Привет, друзья и коллеги по инженерному делу и проектированию! Меня зовут Сергей Погорельский, и я работаю в компании КРОК в качестве эксперта по автоматизации инженерных систем. Работаю с BIM-технологиями 6 лет и недавно защитил диссертацию на эту тему.
В этой статье я расскажу вам о том, как мы пришли к разработке собственного плагина по работе с коллизиями и как научились их побеждать в десятки раз быстрее, чем раньше.
Предыстория и проблемы устранения коллизий
Тема борьбы с коллизиями не нова, и когда раньше все проектировали инженерные системы на кульманах, а потом в CAD, при строительстве порой возникали ошибки: инженерные системы пересекались друг с другом и приходилось решать проблемы уже на месте. Одной из задач, заложенной в БИМ, является исключение этих ошибок на этапе проектирования. Не всякая коллизия – это коллизия: можно выделить релевантные и нерелевантные коллизии. Релевантные коллизии — это те, которые требуют разрешения. В отличие от них нерелевантные коллизии не требуют разрешения, поскольку они могут быть элементами, которые соединяются друг с другом в рамках одной системы. Например, в системе электроснабжения — гофрированная труба с кабелем и распределительная коробка. Поэтому первым пунктом на пути победы над коллизиями является установка допусков для каждой из проверяемых систем, что позволит исключить лже-коллизии. Эти допуски все обычно устанавливают на этапе проверки систем на пересечения в Navisworks.
Вторым важным пунктом в этой борьбе является расстановка приоритетов при проверке коллизий (и при проектировании тоже, чтобы уже тогда не создавать лишние пересечения). Элементы моделирования должны быть расположены в следующем порядке по системам:
конструктивные и архитектурные решения;
вентиляционные системы;
канализационные системы;
системы водоснабжения и отопления;
системы электроснабжения и коммуникационные сети.
Инженеры последовательно работают в заранее определенных областях проекта, моделируя основные объемы модели в рамках структурных и архитектурных разделов. Далее специалисты по вентиляции начинают проектирование в этой области, поскольку значительный объем занимают воздуховоды, соединительные элементы и оборудование в помещении.
Затем очередь переходит к инженерам канализационных систем, так как трубопроводы на этом участке проектируются под значительным уклоном, и изменение их трассы — трудоемкий процесс. После этого проектируются сети водоснабжения и отопления, а сети электроснабжения и связи моделируются в последнюю очередь. Инженеры каждого участка должны учитывать работу своих коллег и предусматривать места для систем других участков по предварительному согласованию при моделировании своей части, а также на этапе проверки коллизий. В противном случае, когда все делают свои разделы, одновременно возникают тысячи ненужных пересечений. И случается вот такой результат: небольшая кроссовая в туалете.
Третьим пунктом на пути к устранению коллизий является сам способ работы с ними. Наиболее распространена работа по устранению коллизий напрямую из Revit, когда инженер сравнивает две системы и последовательно отрабатывает коллизию за коллизией. Но такой подход имеет один весомый недостаток – устраняя коллизии между одними системами, можно невольно создать новую коллизию. Также довольно сложно быстро визуализировать область «пересечки», чтобы работать с ней быстро и эффективно.
Как правило, отчеты о коллизиях и сама модель «пересечек» создаются в Navisworks, но устранять коллизии все равно придется в Revit. Важно, что каждый элемент в модели имеет координаты в 3Д, и при формировании отчета о коллизиях в Navisworks в таблице должны быть перечислены результаты коллизии x-объекта с y-объектом. И наоборот. В результате одна и та же коллизия появится в отчете дважды, но в разных его частях. Когда же один объект пересекается с несколькими другими, например, воздуховод пересекается с несколькими трубами, количество коллизий, естественно, значительно возрастает.
Столкнувшись со всеми этими трудностями в работе, BIM-эксперты КРОК создали плагин, с помощью которого можно эффективно работать с коллизиями и отрабатывать отчеты. Но обо всем по порядку.
Что из себя представляет наш плагин
Плагин для BIM писался на C#. Последующее тестирование он проходил на нескольких больших ЦОДах, спроектированных и строящихся в последние два года. При проверке коллизий мы ввели три уровня: уровень кода (разработчик плагина), уровень алгоритмов (BIM-координатор) и уровень пользователей (инженеры, выполняющие проверку). На уровне разработчика создаются формы для визуализации данных и код для логики взаимодействия пользователя с базой данных.
Взаимодействие с базой данных можно рассмотреть на примере работы с коллизией. Информация, содержащаяся в отчете об этой конкретной коллизии, имеет два состояния: текущее и историческое. А значит, в базе нужно хранить всю историю с самого начала. Постоянно добавлять строки с одной и той же информацией – не круто. Поэтому принята следующая структура: в таблице TBD_Clash хранятся все уникальные коллизии, которые когда-либо возникали на объекте. В ней есть атрибут date, он позволяет получать данные для текущего состояния. Есть таблица TBD_Clash_date. В ней хранятся данные о том, случилась ли коллизия в конкретную дату. В ней содержится лишь ссылка на коллизию и дата, т.е. исторические данные.
Уникальность коллизии определяет 4 поля:
id элемента 1
id модели элемента 1
id элемента 2
id модели элемента 2
При этом, если коллизия существовала ранее, переписывается только дата в таблице TBD_Clash.
Форма ClashResult отображает текущие коллизии, относящиеся к открытой модели в текущий момент времени. Текущими считаются коллизии с самой последней датой. При загрузке последующего отчета о коллизиях в качестве даты используется дата сохранения файла. Если же коллизия уже существует в таблице, дата считываемого отчета подставляется вместо даты коллизии.
На алгоритмическом уровне функция плагина может быть представлена следующей последовательностью действий:
- назначение BIM-координатором последовательности проверки различных систем и допусков на пересечение и стыковку;
- формирование отчета о коллизиях в формате XML;
- загрузка отчета в плагин.
Казалось бы, причем тут отчеты по коллизиям, если для этих целей уже есть Navisworks? Ответ прост. Navisworks хорошо ищет коллизии, но данные, которые можно получить – это txt, html, XML. В ручную искать каждую коллизию в html и создавать отчет под каждую модель затратно по времени. Для того чтобы подружить navisworks и Revit, приходится парсить данные из отчета XML и писать их в базу. Это приводит к необходимости унификации отчетов xml в рамках конкретной организации.
Пользователь непосредственно работает с формой для поиска и визуализации коллизий и устранения одиночных пересечений. Его задача заключается в проверке коллизий в определенной последовательности и их пошаговом устранении. После устранения ставится идентификатор в виде галочки для занесения в базу данных информации об устранении той или иной уникальной коллизии, о дате устранения и имени пользователя, который последний раз выполнял данное действие.
Вышеперечисленные уровни (код, алгоритм и пользователь) неразрывно связаны между собой и в совокупности являются основой плагина.
Как пользоваться нашим плагином инженерам
Меню плагина представляет собой панель, встроенную в окно Revit и состоящую из кнопок, доступных пользователям разных уровней.
Пример работы нашего плагина по работе с коллизиями можно посмотреть в статье моего коллеги Кирилла Якименко.
В этой таблице с коллизиями необходимо выбирать, какие системы сравниваются, и начинать отработку коллизий, например, по категориям. Для каждой уникальной коллизии есть свой 3Д вид, который автоматически создается при нажатии в меню.
Важным моментом является то, что каждая коллизия имеет свой уникальный ID, что помогает точно идентифицировать ее в базе данных. Также скорость отображения нужной коллизии на экране относительно стандартных возможностей Revit увеличивается в 20 раз (с 20 секунд до 1 секунды на операцию). Это является существенным плюсом в ускорении работы инженеров.
После устранения коллизии ставится галочка и статус по коллизии, что в последующем записывается в лог.
Теперь хочется раскрыть немного матчасть, а именно, с какими БД работает плагин. Ведь работа с коллизиями — это, по сути, работа с данными.
Структура плагина
Информационная модель плагина может быть представлена в виде взаимосвязанных баз данных, показанных на рисунке ниже.
Результаты использования плагина
Поскольку коллизии могут привести к ошибкам при строительстве, очень важно устранить все коллизии между инженерными системами на этапе проектирования и моделирования. Наш плагин способствует выявлению и исправлению пересечения примерно в десять раз быстрее стандартных способов, а также исключению дублирующих пересечений и отслеживаний истории каждого из них. Кроме того, оптимизирован процесс формирования отчетов о пересечениях инженерных систем.
Теперь о результатах в деталях:
Плагин удобно использовать инженерам всех типов инженерных систем.
Сокращение времени поиска и идентификации одной коллизии. В пересчете на рабочее время это выглядит следующим образом. Предположим, в обычной ситуации для устранения одной коллизии инженеру надо сделать 50 кликов, а с плагином лишь пять. Когда коллизий в списке 10 тыс., число кликов возрастает 500 000 против 50 000 (с плагином).
Появляется возможность собирать отчеты в динамике и статике. Чтобы собрать такую инфографику вручную, используя только стандартные инструменты, на один отчет ушло бы несколько часов, с плагином — до нескольких минут. В центрах обработки данных в ходе выполнения проектирования обычно готовится около 150 отчетов, что составляет 450 часов без использования плагина, или 38 часов — с плагином. Основными базами данных, из которых загружаются отчеты, являются TBD_Clash_Date и TBD_Clash. В этих базах содержится информация обо всех пересечениях за весь период проверок, включая уникальные идентификаторы коллизий и информацию о рабочих наборах, в которых находятся пересекающиеся системы.
Становится доступным совместное устранение коллизий в рамках одной модели без дополнительной координации между сотрудниками. Это экономит время на общение в проектной команде.
Истории изменений для каждой коллизии собираются в единую базу данных, что позволяет отслеживать каждую из них по мере необходимости.
Почему это не просто плагин
Целью создания этого плагина было облегчение и автоматизация работы инженеров. Но пока работали над ним, стало понятно, что:
сильно улучшаются проектные коммуникации (все стараются моделировать свои системы в определенной последовательности, занимать ранее оговоренные пространства под системы);
внутренняя кастомная автоматизация точно нужна, и она может постепенно вырасти во что-то большое;
у инженеров появилось чуть больше свободного времени на более углубленное изучение BIM-инструментов.
Постепенно BIM в комплексе со скриптами и плагинами становится таким же незаменимым и обязательным инструментом проектировщика, как раньше был циркуль и карандаш. Возможно в перспективе станет уже нормой, когда инженер будет разрабатывать небольшие скрипты и создавать плагины для своих задач самостоятельно.
