Подход Tangl к автоматизации проверок BIM‑моделей

Введение

Современные информационные модели — это уже давно не просто трехмерная геометрия. Каждая модель представляет собой сложный «клубок данных», где каждый элемент несет в себе десятки атрибутов и взаимосвязей. Без системного подхода этот колоссальный объем информации остается набором неструктурированных, «сырых» данных, полных потенциальных ошибок. Проблема BIM‑координации сегодня — это не столько поиск геометрических коллизий, сколько обеспечение достоверности данных.

Для решения этой фундаментальной проблемы я предлагаю рассматривать любую BIM‑модель как базу данных, которую можно и нужно программно валидировать. Ключевая идея подхода — автоматизированное преобразование хаоса данных в строгие, понятные и запрашиваемые структуры. Так работает Tangl Control, последовательно распутывая сплетённые данные через создание многоуровневых проверок. В этой статье я подробно разберу, как именно мы реализуем этот подход — от базовой философии до механизмов возврата замечаний проектировщику.

Философия: от хаоса данных к структурированной информации

Любая попытка автоматизации проверок BIM‑моделей обречена на провал, если сначала не решить проблему структуры данных. Нельзя проверить то, что невозможно надёжно найти. Это фундаментальный принцип, который упускают из виду многие разработчики инструментов проверки, и именно с него начинается подход Tangl. Прежде чем проверять модель на соответствие требованиям, необходимо научиться однозначно идентифицировать и классифицировать каждый её элемент.

Мы рассматриваем любую BIM‑модель как набор первичных данных, которые требуют автоматической обработки и рекомпозиции в логичные структуры. Специализированным инструментом для решения этой задачи выступает сервис Tangl Control, предназначенный для глубокой проверки и тестирования данных информационных моделей.

В основе лежит двухэтапный процесс проверки каждого элемента:

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

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

«Привязки»: как работает ядро автоматизации

Эффективность любой автоматизированной проверки напрямую зависит от гибкости и мощности инструмента для создания запросов к данным. В Tangl эту роль выполняют «привязки» — система, которая является не просто аналогом фильтров, а полноценным механизмом для запросов к свойствам элементов и их одновременного тестирования.

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

Ключевые возможности «привязок» можно описать следующими тезисами:

• Поиск по всему дереву свойств. Привязка способна искать нужные параметры не только на верхнем уровне, но и во всех вложенных структурах, проходя по всей иерархии данных элемента

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

• Гибкая логика. Привязки могут комбинироваться с использованием логических операторов «И» (когда должны выполниться все дочерние условия) и «ИЛИ» (когда для успеха достаточно выполнения хотя бы одного условия)

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

Именно на этом гибком механизме «привязок» и строится весь конвейер проверок в Tangl Control.

Строим конвейерную линию...

Конвейер проверок в Tangl Control можно сравнить с производственной сборочной линией. Сначала элементы модели сортируются по разным «контейнерам» в зависимости от их характеристик, а затем каждый «контейнер» проходит свой этап контроля качества. Такая структура позволяет эффективно отсеивать элементы и применять к ним релевантные наборы правил.

Этап 1. Отбор элементов с помощью справочников

Справочники отбора — по сути, это библиотеки предварительно настроенных привязок, организованные в бизнес-релевантную иерархию (классификатор). Каждая позиция такого справочника описывает определённую группу элементов.

Пользователи настраивают привязки для позиций справочника, определяя, какие именно элементы модели (например, все стены из бетона B25 на первом этаже) попадут в данную позицию для дальнейшего анализа. Таким образом, вся модель раскладывается по нужным категориям, подготавливаясь к следующему этапу.

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

Этап 2. Валидация по контрольным точкам

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

Технически контрольная точка — это та же «привязка». Например, она может проверять наличие у стены параметра «Класс огнестойкости» и его значение, которое должно быть не ниже «REI 60». Элементы, не прошедшие хотя бы одну такую проверку, помечаются в системе как ошибочные и выделяются в отчётах.

Этап 3. Анализ коллизий

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

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

Этап 4. Комплексные проверки для контроля нормативных и продуктовых требований

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

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

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

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

...и ставим проверки на поток

В конвейере важна бесперебойность и автономность. Совсем без BIM‑координатора никакой инструмент работать не будет, но исключить человека из каждой итерации по проверкам можно и нужно. За это отвечает опция автостарта анализа по триггеру, если флажок активен, то при обновлении модели в системе новая версия сразу начнёт проходить проверку по предустановленной схеме проверок. Результат будет сохранён и доступен участникам проекта.

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

Анализ результатов и обратная связь

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

• Наглядное представление: в трёхмерном вьювере элементы модели окрашиваются в зависимости от статуса проверки. Например, зелёный цвет означает, что элемент прошёл все тесты, а красный — что были найдены несоответствия
• Структурированные отчеты: в интерфейсе все элементы группируются по статусу («Прошли все тесты», «Прошли не все тесты»), что позволяет быстро отфильтровать только проблемные объекты
• Детализация ошибок: пользователь может выбрать любой некорректный элемент и увидеть, какую именно контрольную точку он не прошёл, какое свойство было проверено и какое значение ожидалось

Ключевым этапом, замыкающим цикл проверки, является возможность возврата замечаний напрямую в Revit с помощью плагина Tangl. Это избавляет проектировщика от необходимости вручную искать элементы по ID или скриншотам. Плагин загружает список ошибок прямо в интерфейс Revit. Проектировщик может выбрать элемент с ошибкой в списке, и плагин автоматически найдёт и покажет его на модели. После исправления замечаний проектировщик может самостоятельно, также с помощью плагина, отправить актуальную версию на новую проверку и снова получить анализ прямо в свою рабочую среду. Control открывать для этого не требуется.

Заключение

Подход Tangl к автоматизации проверок — это гибкая, управляемая правилами система, которая трансформирует процесс BIM‑координации от простого поиска коллизий к полноценному обеспечению качества данных. Она основана на мощном механизме запросов и тестирования (привязки) и структурированных классификаторах (справочники), покрывая весь цикл от массовой настройки правил до бесшовного возврата замечаний проектировщику в его рабочую среду.

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