Всем привет!
Нечасто вижу на Хабре статьи про BIM-технологии, особенно в формате реального инженерного сервиса вокруг BIM-процессов. Поэтому решил рассказать про внутренний инструмент, который вырос из вполне бытовой боли: коллизии в проектах есть, отчёты по ним есть, люди их даже исправляют, но управлять всем этим как нормальным процессом неожиданно сложно.
Сразу зафиксирую контекст: речь пойдёт про стек Autodesk, а именно Revit и Navisworks. Да, у многих к Autodesk накопилось много вопросов, особенно в последние годы, но это отдельная дискуссия. В реальности эти продукты всё ещё занимают сильные позиции на рынке проектирования, и значительная часть BIM-процессов в компаниях продолжает крутиться именно вокруг них.
У меня за плечами около 6 лет в BIM: от небольшой проектной компании примерно на 20 человек до крупного девелопера. И почти везде я видел одну и ту же картину: Navisworks исправно находит коллизии, BIM-специалист выгружает отчёты, инженеры что-то правят, руководители периодически спрашивают «ну как там?», а между всем этим лежит смесь из HTML-отчётов, Excel-файлов, сообщений в мессенджерах, ручного копирования ID элементов и памяти конкретного BIM-специалиста.
Самое неприятное, что проблема не в одном конкретном инструменте. Navisworks хорошо делает проверки, а Revit хорошо подходит для исправления модели. Но между «коллизия найдена» и «коллизия управляемо доведена до исправления или допуска» часто не хватает отдельного слоя: с историей, аналитикой, ответственными, комментариями и быстрым переходом к месту проблемы в модели.
Так у меня постепенно появился web-сервис Clash Analytics — внутренний инструмент для работы с коллизиями из Navisworks: импорт XML-отчётов, аналитика по проектам, сравнение отчётов, работа со статусами и комментариями, назначение коллизий отделам и локальный Revit-плагин, который позволяет из браузера открыть проблемное место прямо в модели.
Сначала опишу боли, из которых всё выросло, а потом покажу, какие решения получились и какие технические нюансы пришлось учесть.
Проблема 1. Аналитика
В ролях: руководитель проекта, далее РП, и BIM-специалист по объекту, далее BIM.
РП: Ало,BIM, слушай, что у нас по проекту X? Сколько там коллизий?
BIM: Привет, я проверял на неделе, точно не помню, где-то тысяч 5.
РП: А точно сколько?
BIM: Подожди, сейчас Navisworks открою. Так. Если быть точным, 4967.
РП: А что так много, там вообще правят? Сколько было на той неделе?
BIM: Это надо отчёты выгруженные смотреть, сейчас гляну. Блин, их тут много, так не скажу, нужно суммировать сидеть.
РП: Ладно, а вообще, как прогресс движется? Сколько за месяц поправили? А сколько коллизий КЖ-АР всего?
BIM: …
Знакомо?
В классической цепочке никто не ведёт статистику, сколько поправлено за неделю, сколько за месяц, следят только за итогом. Частично это вопрос квалификации BIM-специалиста и регламентов, описывающих еженедельную фиксацию результатов проверки.
Но давайте честно: никто не делает красивые дашборды в пустоту, особенно на еженедельной основе, ради того, чтобы два раза за проект кто-то спросил: «Ну как там с коллизиями?».
Проблема 2. Путь коллизий
Проблема не в самом процессе отработки коллизий конкретными специалистами. Эта проблема, мне кажется, неистребима. Проблема в цепочке:
BIM-специалист проверил модели на коллизии в Navisworks → выдал результат в табличном формате HTML всем причастным к моделированию → инженеры поправили → BIM-специалист снова проверяет модель.
Так цепочку воспринимают многие, кто заинтересован в качественном проекте, но под капотом она куда сложнее.
Если максимально расширять процесс, получается примерно так:
BIM-специалист проверил модели на коллизии в Navisworks → выдал результат в табличном формате HTML всем причастным к моделированию → инженеры открывают Revit, копируют ID элементов в модель для поиска, правят то, что могут и считают важным → если не могут или считают несущественным, пишут BIM-специалисту, что по каким-то коллизиям нужно договориться с заказчиком, или что «коллизии 15-128 не мои, это должен править архитектор» → BIM-специалист агрегирует обратную связь, чаще всего из мессенджеров, или, если повезло, из единой таблицы по проверке/объекту → через неделю BIM-специалист снова проверяет модель.
На первый взгляд всё логично. Но не хватает контроля, удобства и единого окна для всего процесса.
Проблема 3. «Коды следующих элементов некорректны и не могут использоваться…»
Если вы реально отрабатывали коллизии, то обязательно сталкивались с тем, как это трудоёмко:
-
выделить мышкой ID из отчёта;
-
найти в интерфейсе Revit кнопку «Код выбора»;
-
вставить скопированный ID;
-
получить ошибку «Коды следующих элементов некорректны и не могут использоваться…», потому что взял ID не из того столбца;
-
снова скопировать уже корректный ID;
-
снова найти кнопку «Код выбора»;
-
вставить ID;
-
нажать «Рамка выбора».
Это от 4 до 6 шагов в зависимости от внимательности и удачи. А и то, и другое всегда убывает пропорционально количеству коллизий, которые приходится отрабатывать руками.
А теперь перейдём к найденным и реализованным мной решениям этих проблем.
Решение проблемы 1. Дашборды и ещё немного сверху
В очередной раз столкнувшись с проблемой аналитики на проекте, я решил создать web-сервис с динамичными дашбордами по проектам. Идея простая: BIM-специалисты загружают отчёты по коллизиям, а сервис показывает готовую аналитику прогресса по проекту.
Базовые требования выглядели так:
-
парсинг отчётов в формате XML — это единственное нормальное машиночитаемое представление из Navisworks;
-
ведение базы данных по проектам для дальнейшей аналитики;
-
готовая страница с дашбордом, один взгляд на которую закрывает большинство вопросов по коллизиям.
HTML-отчёт удобен человеку, но почти бесполезен как источник данных для истории, сравнения и автоматической аналитики. Поэтому основой стал именно XML.
Импорт отчётов
Можно загружать папки, можно загружать конкретные XML-документы.
Если загружается папка, то за дату отчёта применяется имя папки. По нашему регламенту имя папки с отчётами — это дата проверки в формате дд.мм.гггг.
Если загружается конкретный XML-документ, то за дату отчёта применяется дата создания XML-файла.
Важно было не просто распарсить XML и получить число строк. Я разделил импорт на несколько сущностей:
отчёт за конкретную дату└── проверки внутри отчёта └── отдельные экземпляры коллизий └── метаданные отдельных экземпляров коллизий
После успешного парсинга обновлённые данные попадают в дашборд. KPI-карточки всегда отражают состояние на дату последнего загруженного отчёта.
На этом этапе уже можно быстро отвечать на базовые вопросы по проекту.
Но почти сразу захотелось более подробной аналитики:
-
какие отчёты несут наибольшее число коллизий;
-
сколько коллизий по дисциплинам, например КЖ-АР;
-
сколько коллизий по уровням;
-
какие коллизии не правятся из раза в раз;
-
как двигается прогресс по разделам;
-
что изменилось между двумя отчётами.
Все это реальные запросы по проектам и просто полезная информация, которая помогает сделать акцент на проблемных местах.
Самое важное оказалось не в парсинге XML
Самая важная часть оказалась не в том, чтобы прочитать XML. Настоящий вопрос был другой:
Эта коллизия из нового отчёта — действительно новая, или это старая проблема, которая просто снова попала в выгрузку?
Для этого пришлось разделить конкретное появление коллизии в отчёте и её устойчивую идентичность во времени.
Условно:
ClashOccurrence - конкретное появление коллизии в конкретном отчётеClashIdentity - устойчивая идентичность этой коллизии во времени
Именно это позволяет считать повторяемость, динамику исправлений и сравнивать отчёты без ручной сводной таблицы в Excel.
Теперь меня уже сложнее застать врасплох вопросом: «Ну как там с проектом?».
Решение проблемы 2. Работа в одном окне
Может быть, вы заметили, что некоторые коллизии на предыдущих скриншотах были в статусе «Исправлено». Если заметили — отлично. Если нет — это потому, что я ещё не рассказал про работу с коллизиями внутри сервиса.
Помните цепочку с HTML-отчётами, мессенджерами и ручной агрегацией обратной связи? Я решил, что отчёты не должны жить только в формате XML и не должны лежать просто в сетевой папке. Они должны превращаться в рабочие сущности внутри единого сервиса.
Так дашборд постепенно вырос в Clash Analytics. Рабочее название, обязательно переведу на русский как «Аналитика столкновений».
Теперь каждая коллизия отображается в сервисе. Их можно:
-
фильтровать;
-
сортировать по датам;
-
группировать по имени проверки;
-
смотреть по дисциплинам;
-
фильтровать по статусу;
-
сортировать по количеству повторений;
-
массово менять статус у выбранных коллизий.
Статусов три:
АктивнаяИсправленаДопущена
Статусы меняются в сервисе, но также подхватываются из XML.
Каждую коллизию можно открыть в карточке и посмотреть подробности.
Да, детская кроватка пересекается со стеной ГКЛ. Ну ничего, пусть с детства привыкает спать у стенки.
Работа по старым отчётам
Один из неожиданных сценариев — работа по старым отчётам.
Инженер может открыть выгрузку недельной давности, исправить коллизию и поставить статус «Исправлено», хотя в системе уже есть более свежий отчёт.
Если менять статус только у строки старого отчёта, в актуальном отчёте эта же проблема останется активной, и кто-то может начать разбирать её повторно.
Поэтому статус в сервисе привязан не только к строке отчёта, но и к идентичности коллизии. Это позволяет аккуратно протягивать изменение на более свежие появления той же проблемы и снижать риск двойной работы.
Сопоставление коллизий между отчётами
Отдельной задачей стало сопоставление коллизий между отчётами.
В идеальном мире можно было бы просто взять пару ID и считать её уникальной. Но в реальных BIM-данных всё сложнее.
Что если элемент А и элемент Б поменялись местами? Это другая коллизия? Нет.
Что если коллизия попала в несколько проверок сразу? Это несколько разных проблем или одна и та же? Зависит от контекста.
Что если в середине проекта изменили имена уровней или переименовали оси, но остальные данные остались без изменений? Коллизия новая? Тоже не всегда.
Поэтому пришлось делать более осторожную схему: учитывать источник объекта, сторону коллизии, имя проверки, дополнительные признаки и иметь страховку на случай, если часть данных изменилась или не приехала из XML.
Комментарии
Довольно очевидным следующим шагом стали комментарии к каждой коллизии, чтобы фиксировать договорённости, причины допуска и прочий контекст.
Так как вход в сервис происходит через внутреннюю систему авторизации, сервис всегда знает, кто оставляет комментарии.
Комментарии я специально не стал хранить как «текст где-то рядом с отчётом». Это отдельная история действий:
кто написалкогда написалк какой устойчивой коллизии относится комментарий
Так проще не потерять контекст, когда приходит новый отчёт, а старая строка из XML уже формально перестала существовать.
И тут мы подходим к самому интересному — к двум кнопкам в карточке каждой коллизии:
Revit 3D-обрезкаRevit-изоляция
Они решают проблему ручного поиска элементов в Revit.
Решение проблемы 3. Магия плагинов
Кто-то может возразить:
Да никто уже ID не копирует из HTML, у всех есть свои плагины для просмотра коллизий напрямую в Revit через подгрузку XML.
И частично вы будете правы.
Но, во-первых, такое есть далеко не у всех. А во-вторых, во всех подобных разработках, которые я видел, элементы из связанных моделей по ID не выделялись. Поэтому я написал свой плагин.
Плагин для Revit в этой системе — это локальный мост между web-сервисом Clash Analytics и открытой моделью Revit.
Снаружи всё выглядит просто: пользователь открыл коллизию в браузере, нажал «Revit 3D-обрезка», и Revit сам:
-
открывает 3D-вид;
-
находит элементы;
-
строит вокруг них section box;
-
при необходимости изолирует элементы.
Всё, что нужно пользователю, это открытая модель Revit с установленным плагином.
К слову, если один из элементов находится в связи, section box всё равно строится вокруг объединённого bounding box двух элементов. А выбор ID элемента из связанного файла штатным инструментом «Код выбора» невозможен.
Как работает Revit Bridge
Отдельная часть системы — локальный Revit Bridge. Это небольшой add-in для Revit, который поднимает HTTP endpoint на 127.0.0.1 и принимает команды от web-интерфейса.
Сам сервис не управляет Revit напрямую. Он только знает, какие элементы участвуют в коллизии, и передаёт эти данные в локальный bridge.
Дальше уже плагин внутри Revit:
ищет элементы в активной модели и связанных файлах→ учитывает смещение связей относительно друг друга→ строит общий bounding box→ открывает 3D-вид с section box вокруг проблемного места
Для режима изоляции поверх этого применяется временная изоляция найденных элементов.
Важный технический момент: Revit API нельзя безопасно вызывать из произвольного HTTP-потока. Поэтому bridge использует стандартную для Revit схему через ExternalEvent:
HTTP-запрос приходит в локальный bridge→ запрос складывается в очередь→ вызывается ExternalEvent→ фактическое действие выполняется уже в контексте Revit
Без такого плагина web-сервис мог бы только показать пользователю ID и картинку из Navisworks. Но перейти из браузера прямо в нужное место открытой Revit-модели, особенно если один из элементов находится в связанной модели, без add-in практически невозможно.
В интерфейсе есть индикатор состояния Revit Bridge: frontend периодически проверяет локальный endpoint /ping. Если bridge отвечает, то индикатор зелёный, если нет, то красный.
Отдельный нюанс: ElementId и UniqueId
Тут есть потенциально хрупкий момент — это идентификаторы элементов Revit.
Тот ID, который я часто упоминается в отчётах и интерфейсе, строго говоря, называется ElementId. В документации Revit API он описывается как project-wide identifier, то есть уникальный внутри проекта, но не уникальный между разными файлами Revit.
Кроме того, UniqueId стабильнее для хранения во внешней базе, а ElementId в некоторых сценариях может измениться.
В своём решении я пока не стал доставать UniqueId из Navisworks. Вместо этого в HTTP-запросе используется имя связи (фактически имя источника из Navisworks), и ElementId. Это снижает риск ложных срабатываний, потому что один и тот же числовой ID в разных Revit-файлах может указывать на разные элементы.
Назначение коллизий отделам
Для полного счастья не хватало назначения коллизий.
Сделать назначение конкретным людям казалось очевидным: учетные записи есть, коллизии есть, сервис единый. Но в этом сценарии быстро появляется дополнительная сложность в администрировании:
-
люди часто переходят между проектами;
-
состав исполнителей меняется;
-
часть задач могут отдавать студентам или временным специалистам;
Поэтому я пришёл к другой схеме: у каждой учётной записи есть поле «Отдел» и список доступных проектов.
При выборе нескольких коллизий или в окне подробностей каждой коллизии можно назначить отдел, которому эта коллизия отправляется.
Например: по проекту 1 я назначаю две коллизии отделу АР. Все пользователи с отделом АР и доступом к проекту 1 получают уведомление о том, что им назначены коллизии.
При назначении коллизий отделам создаётся новая запись в комментариях у каждой назначенной коллизии. Так сохраняется история «перекидывания» коллизий между отделами.
При первичном парсинге отчётов пользователи тоже получают оповещения, но автоматически коллизии отделам не назначаются. Это просто информирование.
Автоматический импорт из сетевой папки
Не хотелось каждый раз загружать отчёты вручную, даже папками. Но раз существует регламент на проверки коллизий, с указанием структуры и нейминга папок, то почему бы этим не воспользоваться. Поэтому реализован парсинг из сетевой папки.
Один раз для проекта настраивается источник данных, и дальше сервис сам забирает новые отчёты.
Такой сценарий хорошо ложится на регламент: BIM-специалист продолжает выгружать результаты из Navisworks привычным способом, но дальше сервис сам забирает новые отчёты из сетевого источника, ставит импорт в очередь и обновляет аналитику.
Для инженера это выглядит так, будто новые отчёты просто появляются в сервисе сами.
Отдельная боль — нормализация
В реальных проектах уровни, дисциплины, имена файлов и типы элементов редко называются идеально. Да, это решается EIR, BEP, иными приложениями к договору, но зачастую работа начинается на своем шаблоне, а «подгонка» под требования — финальный этап.
Например:
Этаж 101_ЭтажLevel 01+0.000АРARАрхитектура
Для человека это часто одно и то же. Для базы данных — разные значения.
Если не решать эту проблему, аналитика быстро превращается в кашу:
коллизии по уровню «Этаж 1» - 100коллизии по уровню «01_Этаж» - 80коллизии по уровню «Level 01» - 40
Формально график построен правильно, но управленчески он бесполезен.
Поэтому часть логики вынесена в настраиваемые правила, чтобы не переписывать код под каждый новый проект и не превращать аналитику в набор исключений.
Что получилось в итоге
Если коротко, Clash Analytics вырос из простого дашборда, стал не просто просмотрщиком XML-отчётов, а отдельным рабочим слоем между Navisworks, Revit и участниками проекта.
Сейчас сервис закрывает несколько сценариев:
-
хранит историю отчётов по проектам;
-
показывает актуальные KPI по последней загруженной проверке;
-
строит динамику коллизий во времени;
-
показывает аналитику по проверкам, дисциплинам, уровням и типам;
-
позволяет сравнивать отчёты между собой;
-
помогает находить повторяющиеся и «зависшие» коллизии;
-
отображает каждую коллизию как отдельную рабочую сущность;
-
хранит статусы, комментарии и историю действий;
-
позволяет массово менять статусы и назначать коллизии отделам;
-
отправляет уведомления ответственным пользователям;
-
автоматически забирает новые отчёты из сетевого источника;
-
через Revit Bridge открывает проблемное место прямо в Revit;
-
строит 3D-обрезку вокруг элементов коллизии;
-
умеет работать не только с host model, но и со связанными моделями;
-
позволяет временно изолировать элементы коллизии на 3D-виде;
-
выгружает отчёты в удобных форматах для дальнейшего использования.
Самое важное для меня — сервис начал отвечать не только на вопрос «сколько сейчас коллизий?», но и на более полезные вопросы:
-
что изменилось с прошлого отчёта;
-
какие проверки дают основной объём проблем;
-
какие коллизии повторяются из недели в неделю;
-
какой раздел сейчас является узким местом;
-
какие задачи уже были назначены;
-
где по конкретной коллизии велась переписка;
-
можно ли быстро открыть проблему в Revit и исправить её.
В итоге BIM-специалисту не нужно каждый раз вручную собирать сводку из Navisworks, Excel и переписок. Руководитель проекта или ГИП получает понятную картину по проекту, а инженер может перейти от строки отчёта к месту проблемы в модели за один клик.
Что сейчас происходит с сервисом
На данный момент система раскатывается на специалистов внутри компании: проводятся обучения, собирается обратная связь, постепенно появляются новые сценарии использования.
Тестирование BIM-отделом уже проведено, в сервис загружено около 20 проектов. Руководители проектов и ГИПы особенно оценили аналитику: ответы на вопросы вроде «что у нас по коллизиям?», «где больше всего проблем?» и «что изменилось с прошлого отчёта?» теперь занимают не часы ручной подготовки, а пару минут.
Конечно, сервис не решает все проблемы магически. Качество аналитики всё равно зависит от регламента выгрузки, стабильности именования файлов, дисциплины заполнения статусов и того, насколько аккуратно ведутся модели, но это я постарался решить нормализацией данных.
Если в исходных данных хаос, его нельзя полностью победить красивым интерфейсом. Но его можно сделать видимым, измеримым и управляемым.
Если есть проблемы — значит, рядом есть место для инженерного решения. А если это решение ещё и избавляет BIM-специалиста от еженедельного исполнения роли живого Excel-дашборда, значит, оно точно было не зря.
ссылка на оригинал статьи https://habr.com/ru/articles/1033602/