В 2025-м Sarex реализовал НИОКР-проект по созданию автоматизированного инструмента для анализа отклонений между тремя основными типами данных: 3D-моделями, облаками точек, полученными с помощью лазерного сканирования, и графической документацией — проектной и исполнительной. В этой статье руководитель команды алгоритмов Sarex делится целями, техническими вызовами, методологией и результатами этого инновационного проекта.
Цели проекта
Основной целью НИОКР было подтверждение возможности создания автоматизированной системы, способной выявлять несоответствия между различными типами данных, используемыми в строительных проектах. Мы стремились разработать алгоритм, который сравнивает:
- 3D-модели: цифровые представления запланированного объекта, часто в форматах Autodesk (nwd/rvt), IFC или в нашем собственном формате Sarex — S3D.
- Облака точек: плотные наборы данных, или «облака факта», полученные с помощью наземного лазерного сканирования (НЛС) и отражающие реально построенную среду.
- Графическую документацию: 2D-проектные чертежи (стадии РД, т.е. “как должно быть построено”) и исполнительную документацию (“как построено по факту, с учетом измерений на объекте”).
Гипотеза состояла в том, чтобы выяснить — можно ли создать инструмент, который автоматически выявляет отклонения между этими наборами данных с высокой точностью.
Сохранить высокую точность была крайне важно — по условиям проекта, результаты должны были соответствовать ожиданиям в более чем 97% случаев.
Актуальность проекта вызвана, с одной стороны, подтвержденной высокой эффективностью технологии контроля отклонений с помощью лазерного сканирования, а с другой - барьерами в ее широком применении вследствие отсутствия BIM-моделей, соответствующих стадии РД (по которой выполняются строительно-монтажные работы). Соответственно, высока потребность в инструменте, который позволяет сравнить облако точек с 2D-документацией и подсветить несоответствия BIM-модели и рабочей документации.
Технические вызовы
Сравнение 2D-чертежей, 3D-моделей и облаков точек осложнялось их разной природой. 2D-чертежи описывают геометрию линиями, 3D-модели представляют объемные объекты с богатой семантикой, а облака точек — это сотни миллионов координат, где форма не задана явно из-за шумов, лазерных теней и пропусков.
Для анализа требовалось привести данные к единому формату, обрабатывая файлы DWG, IFC, E57 и LAS с учетом их особенностей.
Облака точек, достигающие объемов до 1.5 ТБ, создавали сложности из-за отсутствия четких контуров. Мы разработали метод аппроксимации, воссоздающий формы объектов, таких как стены или колонны, с помощью объемного сечения: 2D-контур вытягивался в 3D-объем, из которого вырезались соответствующие точки для точного расчета отклонений.
2D-документация добавляла вызовов, так как содержала неструктурированные элементы — аннотации, подчеркивания, нестандартные обозначения. Извлечение фактических измерений требовало тщательной обработки, чтобы обеспечить надежное сравнение с проектными данными.
Ключевым было не только выявить отклонения, но и представить их понятно: где возникло расхождение, к какому элементу оно относится и насколько оно критично.
Это потребовало оптимизации алгоритмов, чтобы сбалансировать вычислительные затраты и точность на стандартном оборудовании.
Методология разработки
Для достижения цели наша команда структурировала решение на три основных компонента, каждый из которых решает ключевую задачу процесса анализа.
Сбор и стандартизация данных
Первой задачей было приведение разнородных форматов данных к единому виду. Строительные проекты генерируют данные в различных форматах, каждый из которых имеет свои особенности.
2D-документация часто поступает в формате DWG, облака точек — в LAS или E57, а 3D-модели — в форматах IFC или S3D. Мы разработали модуль, который способен принимать эти данные и преобразовывать их в унифицированный формат, пригодный для сравнения.
В дополнение мы разработали специализированные инструменты для обработки DWG-файлов, 2D-документации и LAS-файлов — облаков точек. 3D-модели, будь то в форматах Autodesk, IFC или нашем S3D, обрабатывались для обеспечения совместимости с нашей платформой. Этот этап стандартизации был критически важен, так как позволил привести все данные к «общему знаменателю», упрощая последующий анализ.
Алгоритм сравнения
Основой проекта стал модуль сравнения, который анализировал отклонения между стандартизированными данными. Этот модуль был разработан для обработки трех различных сценариев, каждый из которых решал определенные задачи сравнения:
Сценарий 1: Анализ отклонений в конкретных точках
В первом сценарии мы сосредоточились на измерении отклонений в заданных точках, определенных исполнительной документацией. На рисунке 1 рассмотрим ровную стену в складском помещении, спроектированную как идеально прямую в проектной документации (белый контур в 2D-чертеже).
Исполнительные измерения на объекте показали отклонения: например, 20 мм в одной точке, 30 мм в другой и 15 мм в противоположную сторону. Наш алгоритм построил красный контур, отражающий фактическую геометрию стены на основе измерений исполнительной документации, и сравнил его с проектным контуром, вычислив точные отклонения.
Сложность возрастала при сравнении 2D-контуров с облаками точек. В отличие от четких 2D-линий облака точек содержат шум из-за ограничений лазерного сканирования. Даже визуально прямая стена может выглядеть как набор разбросанных точек вдоль прямой линии с небольшими отклонениями (рисунок 2).
Для решения этой задачи мы разработали метод аппроксимации контура из данных облака точек, фактически воссоздавая реальную геометрию. Этот контур затем сравнивался с проектной документацией, что позволяло точно вычислить отклонения в указанных пользователем точках (рисунок 3).
Сценарий 2: Сегментация и сравнение элементов
Второй сценарий был ориентирован на анализ целых элементов, а не отдельных точек. Например, представьте шесть конструктивных колонн, зафиксированных в облаке точек. Заказчику нужно было понять, построены ли эти элементы согласно проекту, включая их наличие, положение и геометрические размеры. Это потребовало сегментации облака точек на отдельные элементы, каждому из которых присваивался свой цвет для наглядности, например: красный, зеленый, синий (рисунок 4).
Процесс сегментации осложнялся такими явлениями как лазерные тени, когда часть конструкции не попадала в зону сканирования, что приводило к неполным данным. Наш алгоритм успешно выделял и изолировал эти элементы, а затем сравнивал их контуры с данными 2D-проектной документации и 3D-модели.
Построив ограничивающие рамки вокруг каждого сегментированного элемента, мы могли оценить отклонения в положении и размерах, выявляя, например, небольшие повороты или смещения относительно проектного плана.
Сценарий 3: Анализ сложных элементов
Третий сценарий касался более сложных элементов, таких как двутавры (это металлическая или железобетонная балка с поперечным сечением в форме буквы «Н» или латинской «I»). Эти элементы могли присутствовать, отсутствовать или быть построены со смещением в положении, но не в размерах.
Аналогично первому сценарию, мы извлекали контур из 3D-модели, расширяли его по вертикали для создания объемного сечения и использовали это сечение для «вырезания» соответствующего участка из облака точек (рисунок 5). Это позволяло выравнивать проектный (синий) и фактический (красный) контуры, вычисляя отклонения с высокой точностью.
Сложность заключалась в наличии близлежащих конструкций, таких как стены, которые могли искажать данные облака точек. Тщательно определяя объем сечения, мы минимизировали эти помехи, обеспечивая точное сравнение. Алгоритм автоматически определял наличие элементов и количественно оценивал их позиционные смещения, предоставляя заказчику ценные данные.
Визуализация результатов
Для каждого сценария наша команда создавала визуальные выходные данные, демонстрирующие отклонения между наборами данных (рисунок 7).
Например, в первом сценарии белый контур (проектная документация) накладывался на красный контур (фактическая конструкция), подчеркивая отклонения в конкретных точках. Во втором сценарии сегментированные элементы обозначались разными цветами, а ограничивающие рамки показывали их реальные размеры. В третьем сценарии отображались выровненные контуры двутавров с аннотациями, указывающими позиционные смещения (например, отклонение на 155 мм).
Таким образом, заказчик мог просмотреть результаты, при необходимости сравнить их вручную и убедиться, что автоматизированный инструмент точно выявляет несоответствия.
Результаты
Проект успешно подтвердил гипотезу: наш автоматизированный инструмент способен сравнивать 3D-модели, облака точек и графическую документацию с точностью более 97%, как указано в технических требованиях.
Во всех трех сценариях алгоритм продемонстрировал способность:
- точно принимать и стандартизировать различные форматы данных;
- выявлять отклонения в конкретных точках и по целым элементам;
- обрабатывать сложные геометрии и шумные данные облаков точек;
- представлять результаты в ясном визуальном формате.
«Благодаря успешно реализованному НИОКР-проекту нашей командой заказчик получил надежное доказательство гипотезы, подтверждающее потенциал автоматизированного анализа отклонений в строительстве. Мы смогли превратить разрозненные данные в понятные выводы и показать, что автоматизация анализа отклонений между разными типами данных с высокой точностью реальна и достижима», — Максим Рогожкин, руководитель отдела алгоритмов Sarex
Что покажем?
Автор
Спикеры
.webp)
