В статье рассматриваются требования к координационному ПО, предназначенному для работы с цифровыми информационными моделями. Требования основаны на опыте работы цифровых департаментов технического заказчика и базируются на процессах, указанных в «Рекомендациях по внедрению цифрового функционала технического заказчика» (выпущены Ассоциацией НОТЕХ в 2024 году). Наиболее важные этапы взаимодействия с цифровой информационной моделью для технического заказчика — это этапы проектно-изыскательских работ (ПИР) и строительно-монтажных работ (СМР). В связи с этим требования к ПО исходят из максимизации выгод для техзаказчика именно на этих этапах.
В нашей практике мы придерживаемся термина «цифровая информационная модель» — объектно-пространственная модель объекта, представляющая в цифровом виде его геометрические, функциональные и другие характеристики на всех этапах жизненного цикла.
Чтобы увидеть полноценную картину требований к программному обеспечению, используемому техническим заказчиком при работе с ЦИМ, прежде всего нам необходимо определиться со сферой его применения и бизнес-процессами. Поэтому обратимся к нашей карте цифровой активности — «Рекомендациям по внедрению цифрового функционала технического заказчика». Если выделить те процессы, в которых участвует ЦИМ, то мы увидим, что на этапах проектно-изыскательских и строительно-монтажных работ техническим заказчиком активно используется ЦИМ. Здесь необходимо сделать важное замечание: на всех этапах у технического заказчика на сегодняшний день есть лишь небольшая потребность работы с нативной моделью (ЦИМ, выполненная непосредственно в проприетарном формате среды разработки), для работы с которой необходимо программное обеспечение. Это обусловлено тем, что технический заказчик 90% времени работает с координационным ПО (программный продукт, позволяющий вести координацию между всеми моделями проекта) и с федеративными (сводными).
Однако в связи с зачастую низким уровнем компетентности в проектных организациях и, как следствие, низким качеством разрабатываемых ЦИМ, а также тем, что технический заказчик несет основную ответственность за передачу в производство рабочей документации, он вынужден формировать у себя собственные сводные (федеративные) модели, служащие для контроля за деятельностью проектных организаций.
Федеративные модели, в которых технический заказчик работает на этапах контроля качества разработки ЦИМ, извлекает объемы, необходимые для формирования смет или тендерных ведомостей, а также ведет учет объемов на этапе СМР, мы в своей практике называем «операционными моделями». Этим термином мы будем пользоваться в статье.
Сделаем одно допущение: в статье рассматривается именно «желаемое ПО», и все требования будут изложены к гипотетическому продукту, который цифровые департаменты технического заказчика хотели бы видеть у себя. В настоящий момент для обеспечения своих потребностей компаниями используются так называемые «стеки» — совокупность взаимосвязанных цифровых инструментов, платформ и сервисов, то есть, говоря проще, одновременно несколько программных продуктов. Это могут быть плагины, отдельные программные продукты, но тем не менее это не единая среда.
Отсюда следует простой вывод: координационное ПО, используемое техническим заказчиком для работы с ЦИМ, должно быть единым для всех этапов инвестиционно-строительного проекта (ИСП).
Прежде чем перейти к рассмотрению требований к ПО, необходимому техническому заказчику на этапах реализации инвестиционно-строительного проекта, давайте определим общие требования, кроме того, что ПО должно быть единым для всех этапов реализации ИСП. Базовый функционал, без которого существование подобного ПО немыслимо, такой, например, как работа с поисковыми системами, мы условно выведем «за скобки», как нечто само собой разумеющееся.
Итак, общие требования:
1. Открытое API (Application Programming Interface). Интерфейс программирования приложений — данное требование может расходиться с коммерческой политикой компаний-разработчиков, но оно звучит все чаще и чаще. Для чего оно нужно? Например, чтобы иметь возможность входа напрямую в BI-систему (систему бизнес-аналитики), используемую цифровым департаментом или всей компанией.
2. Возможность работы с популярными проприетарными форматами разработки ЦИМ и удобный механизм импорта ЦИМ из разных форматов. Это пожелание, конечно, в силу коммерческих причин, довольно трудно реализуемо, но специфика работы технического заказчика диктует свои условия. Когда у компании в работе десятки объектов, на которых работает множество различных проектных организаций, использующих собственные стеки для разработки моделей, появляется необходимость в продукте, способном работать со всеми форматами одновременно.
3. Гибкое управление версиями моделей и изменениями — функционал, применяемый довольно долгое время в координационном ПО зарубежных разработчиков и в настоящее время активно представленный в средах общих данных (СОД), однако при использовании координационного ПО многих функций не хватает.
В рамках этих требований ПО должно обеспечивать:
• версионирование модели с отслеживанием всех изменений;
• сравнение версий модели для выявления изменений конструктивных элементов, систем, параметров;
• ведение истории изменений с указанием автора, даты и причины изменения;
• контроль запретных изменений (изменения, которые влияют на критические параметры объекта и требуют согласования с техническим заказчиком).
Основной задачей работы с ЦИМ на этапе проектно-изыскательских работ для технического заказчика является контроль качества ЦИМ на этапе проектирования, разрабатываемого проектной организацией. На рисунке 1 приведена часть карты цифровой активности технического заказчика для этапа ПИР.
Чтобы успешно реализовать процедуры контроля качества, программный продукт должен содержать в себе автоматизированные инструменты проверок наличия коллизий в федеративной модели. В настоящее время для этого используются многочисленные плагины, в некоторых организациях такие плагины разрабатываются самостоятельно, а многие организации используют дополнительные программные продукты для автоматизации процесса.
В рамках этих требований ПО должно обеспечивать:
• импорт подготовленных шаблонов матрицы коллизий в инструмент проверки из таблиц или текстовых документов;
• возможность генерации и экспорта шаблонов проверок на коллизии или матрицы коллизий;
• автоматизированное создание проверок на коллизии на основе загруженных шаблонов или заданных непосредственно в инструменте правил;
• визуализацию коллизий с цветовым обозначением пересекающихся элементов, с возможностью настройки цветов и выбора отображаемых коллизий;
• сбор и отображение статистики по количеству и типу коллизий;
• возможность динамического отслеживания коллизий с учетом различных версий ЦИМ;
• генерацию отчетов на основании проверок, в том числе с указанием свойств элементов;
• возможность генерации замечаний к коллизиям, их назначение исполнителю, контроль сроков исправления;
• классифицирование коллизий по степени критичности, как минимум по принципу светофора (красный/желтый/зеленый).
Важнейшей из процедур контроля качества также является проверка на соответствие параметрического наполнения информационным требованиям заказчика. Параметрическое наполнение — это параметры, атрибуты (или, проще говоря, свойства элементов), которые позволяют извлекать из ЦИМ данные, необходимые для дальнейших действий, например, для проверки или извлечения объемов.
К сожалению, в этом случае мы сталкиваемся с подводными камнями, которых не помогает избежать автоматизация. Дело в том, что при проверке параметров, выполняемой программными средствами, наш максимум — проверка на то, заполнен параметр или нет. Чтобы оценить корректность заполнения параметров, необходим человек. Возможно, в будущем это можно будет осуществить с помощью использования нейросетей, причем с явно более глубокими возможностями машинного обучения, нежели имеются сегодня.
В рамках этих требований ПО должно обеспечивать возможность:
• импорта или генерации непосредственно в инструменте проверки правил и шаблонов проверок;
• формирования и экспорта статистики по заполнению параметров;
• генерации замечаний к элементам без заполненных параметров, назначения исполнителя и срока исправления;
• отслеживания изменений в параметрах в соответствии с версионностью ЦИМ;
• задания диапазона значений или маски для проверки заполнения определенного параметра;
• самостоятельного добавления или изменения тех или иных параметров и атрибутов, их сохранения и обновления.
Немаловажной и необходимой частью работы является получение объемов из ЦИМ, и, само собой, для технического заказчика важно, чтобы ПО имело функционал работы с объемами.
В рамках этих требований ПО должно обеспечивать возможность:
• загрузки (импорта) классификаторов, в том числе видов работ в ПО;
• мэппинга классификаторов и параметров элементов модели;
• создания и импорта ведомостей объемов, в том числе тендерных, непосредственно из ЦИМ;
• интеграции со сметным ПО для импорта значений объемов в сметы.
С развитием цифровой трансформации строительной отрасли применение ЦИМ на этапе СМР с каждым годом становится шире. Для технического заказчика использование ЦИМ в рамках строительного контроля гарантирует повышенную точность контроля и снижение рисков, возникающих при приемке работ. Использование данных, визуализируемых и консолидируемых в модели, позволяет повысить эффективность управления процессами на этапе СМР — на рисунке 2 приведена карта цифровой активности технического заказчика на этапе строительно-монтажных работ.
Операционная модель — это ЦИМ, полученная с этапа проектирования, расширенная атрибутами плановых и фактических дат, статусов выполнения и результатов контроля каждого элемента конструкции. Программное обеспечение должно обеспечивать:
• внесение данных «план/факт» с привязкой к элементам модели и их визуализацией в 3D;
• контроль выполнения работ через сравнение плановых дат по календарному графику с фактическими датами монтажа каждого элемента;
• проверку закрывающих объемов работ (КС-2, КС-6а) непосредственно в ЦИМ.
Операционная ЦИМ создается путем добавления к элементам проектной ЦИМ параметров-атрибутов:
• плановых дат начала и завершения работ для каждого элемента;
• фактических дат монтажа/установки;
• статусов элементов (планируется/в производстве/завершено/отклонено);
• результатов визуальной проверки и контрольных измерений;
• привязки к смете и актам КС-2.
Операционная ЦИМ создается в среде ТИМ (возможно, с использованием нативных моделей) с применением параметров семейств и типов элементов. Для визуализации плана/факта применяется цветовое кодирование элементов.
4D-визуализация интегрирует ЦИМ объекта с временной осью строительства, обеспечивая визуализацию последовательности производства работ. Программное обеспечение должно предоставлять:
• связь элементов ЦИМ с задачами календарного графика строительства;
• визуализацию хода выполнения работ с анимацией процесса построения объекта;
• выявление пространственно-временных коллизий (конфликты работ, использование одного пространства несколькими командами);
• контроль соответствия фактического выполнения работ плановому графику через визуализацию в 3D;
• отслеживание статусов элементов в ЦИМ (плановые, фактические сроки).
4D-визуализация создается путем связывания каждого элемента ЦИМ с соответствующей задачей календарно-сетевого графика (КСГ). Основной рабочий процесс:
1. Подготовка КСГ — разработка календарного графика в системах планирования с определением последовательности и сроков всех видов работ.
2. Привязка элементов к графику — каждому элементу ЦИМ присваиваются код работы из КСГ и плановые даты начала/завершения.
3. Создание временной оси — визуализация ЦИМ в программах, которые объединяют КСГ и ЦИМ.
4. Анимационная визуализация — создание роликов с пошаговым отображением строительного процесса с возможностью паузы, проигрывания в разной скорости, комментирования.
В 4D-визуализацию добавляются не только элементы здания, но и объекты строительного процесса: расположение кранов и зона их действия, маршруты движения материалов, расположение складских площадок.
Ключевая особенность: программное обеспечение должно поддерживать загрузку облака точек от лазерного сканирования и сравнение геометрии факта с ЦИМ для выявления коллизий и отклонений.
Исполнительная ЦИМ — это ЦИМ реально выполненных работ, создаваемая на основе фактических геометрических параметров построенного объекта. Техническому заказчику требуется программное обеспечение для:
• контроля соответствия фактического исполнения проектной и операционной ЦИМ;
• выявления дефектов и отклонений от проекта;
• сравнения геометрии факта с ЦИМ, полученной с этапа проектирования на уровне элементов;
• формирования отчетов об отклонениях с указанием типа, размера и местоположения дефектов.
Лазерное 3D-сканирование — основной метод создания исполнительной ЦИМ:
• лазерный сканер генерирует облако точек с точностью до 1−5 мм;
• одна станция сканирования захватывает до 360° окружающего пространства;
• множество облаков точек с разных станций объединяются в единое облако через регистрацию по маркерам или геометрическим особенностям;
• облако точек загружается в ТИМ-программы и сравнивается с ЦИМ, полученной с этапа проектирования;
• программное обеспечение автоматически выявляет расхождения между ЦИМ, полученной с этапа проектирования, и фактом и визуализирует их цветовым градиентом (зеленый — соответствие, желтый/красный — отклонения).
Современные решения должны обеспечивать:
• автоматическое связывание облака точек с ЦИМ;
• расчет отклонений по осям X, Y, Z;
• создание сечений и плоскостей для детального анализа;
• экспорт данных в IFC-формат для открытия в различных средах.
Фотограмметрия высокого разрешения — альтернатива лазерному сканированию:
• основана на обработке множества перекрывающихся фотографий высокого разрешения для создания трехмерной модели;
• эффективна для объектов со сложной геометрией, где лазерное сканирование затруднено;
• обеспечивает детализацию поверхностей с текстурами.
Панорамная фотосъемка 360° - дополнительный метод фиксации фактического состояния. Она:
• создает сферические панорамы для визуального контроля и наложения на ЦИМ;
• позволяет техническому заказчику отследить наличие скрытых дефектов до закрытия конструкций.
Программное обеспечение должно обеспечивать контроль на строительной площадке путем наложения (наслоения) ЦИМ на реальный объект через дополненную реальность (AR). Функционал должен включать:
• загрузку элементов ЦИМ в мобильное приложение с поддержкой основных форматов;
• позиционирование виртуальной ЦИМ в пространстве путем привязки к реальным объектам;
• визуальное сравнение ЦИМ, полученной с этапа проектирования, с реальным строением;
• выявление несоответствий (геометрические отклонения, пропущенные элементы, неправильное расположение);
• создание дефектных листов с привязкой отклонений к координатам в ЦИМ;
• сохранение данных контроля в формате для открытия замечаний непосредственно в ТИМ-программах.
1. Позиционирование ЦИМ:
• метод линейной привязки — построение модели по двум точкам с известными координатами на строительной площадке;
• использование QR-маркеров или специальных плакатов с кодами для быстрого позиционирования ЦИМ;
• применение приемников (в условиях открытых площадок) для геопривязки ЦИМ к реальному пространству.
2. Слои ЦИМ и управление видимостью:
• разделение ЦИМ на функциональные слои (конструктивные элементы, архитектурные элементы, инженерные сети, временные конструкции);
• возможность включения/отключения отдельных слоев для детального анализа конкретного типа работ.
3. Измерения и анализ отклонений:
• встроенные инструменты для измерения расстояний и углов между виртуальной моделью и реальным объектом;
• автоматический расчет отклонений и их визуализация прямо в приложении.
4. Документирование дефектов:
• фотосъемка через приложение с автоматической привязкой координат в ЦИМ;
• добавление комментариев, назначение ответственных лиц непосредственно в приложении;
• сохранение информации в формате, который содержит:
• координаты дефекта в пространстве ЦИМ;
• тип и описание проблемы;
• фотографии и видео;
• ответственного исполнителя и сроки устранения дефекта.
5. Синхронизация с информационными сервисами:
• техническому заказчику и проектировщикам должны быть видны все замечания с автоматической изоляцией проблемных элементов в ЦИМ;
• двусторонняя синхронизация — обновления в ТИМ-программе отражаются в мобильном приложении.
6. Автономная работа:
• мобильные приложения должны работать без постоянного подключения к интернету с указанием времени последней синхронизации;
• синхронизация данных происходит автоматически при наличии подключения.
Программное обеспечение должно позволять техническому заказчику:
• анализировать данные, хранящиеся в ЦИМ;
• извлекать спецификации элементов (объемы материалов, площади поверхностей, количество изделий);
• сравнивать плановые объемы (из ЦИМ) с фактическими объемами выполненных работ;
• визуализировать стоимость конструктивных элементов на основе параметров ЦИМ;
• отслеживать связи между конструктивными элементами ЦИМ и строками сметы КС-2.
1. Экспорт данных из ЦИМ:
• создание таблиц со спецификациями элементов непосредственно из ЦИМ;
• выгрузка параметров элементов в форматы Excel, CSV для дальнейшего анализа;
• применение инструментов для автоматизации извлечения данных, аналогичных как минимум функционалу Dynamo (Autodesk Revit).
2. Параметрическая оценка объемов:
• автоматический расчет объемов материалов на основе геометрии элементов в модели (бетон в колонне, площадь штукатурки на стене);
• сравнение расчетных объемов с объемами, указанными в актах КС-2;
• выявление расхождений и формирование отчетов.
3. 3D-визуализация смет:
• окрашивание элементов ЦИМ в зависимости от их стоимости или этапа выполнения работ;
• возможность отбора элементов по фильтрам (тип работ, смета, этап выполнения).
В целом программное обеспечение для технического заказчика на этапе строительства, сфокусированное на ТИМ, должно обеспечивать:
• работу с операционной ЦИМ — визуализацию плана/факта выполнения работ непосредственно в ЦИМ;
• 4D-визуализацию — управление временной осью строительства с анимацией процесса и выявлением коллизий;
• контроль исполнительной ЦИМ — сравнение фактического исполнения СМР с проектом через лазерное сканирование и фотограмметрию;
• AR-контроль качества — наложение ЦИМ на реальный объект для выявления дефектов на площадке;
• управление версиями — отслеживание всех изменений ЦИМ с визуализацией различий;
• аналитику данных ЦИМ — экстракцию спецификаций и сравнение объемов с фактом выполнения.
Техническая реализация требует применения открытых стандартов, интеграции с системами лазерного сканирования, разработки мобильных приложений с поддержкой AR и обеспечения высокой производительности при работе с ЦИМ большого объема. Только такой комплексный подход позволяет техническому заказчику получить достоверный контроль над соответствием факта проекту на всех этапах строительства.
Возможно, требования, изложенные в статье, могут показаться кому-то завышенными, кому-то — нереалистичными (и в этом, скорее всего, будет немалая доля правды), но есть немаловажный момент: несмотря на то что авторы сознательно избегали ссылок на конкретное ПО, каждая из указанных функций уже реализована в том или ином программном продукте (пусть это даже и плагины). Главное, что это разные продукты, разные лицензии, и между этими продуктами очень трудно наладить связь и обмен данными. Разработчик, который сможет реализовать все эти функции в едином продукте, мгновенно завоюет рынок ПО не только для технического заказчика, но и для девелоперских компаний.
Комментарий редакции: статья использует ряд терминов, которые не имеют законодательного закрепления в Градостроительном кодексе РФ и существуют лишь в виде различных трактовок в подзаконных актах. Редакция публикует материал с двумя целями:
1. Показать реальные отраслевые проблемы. Статья отражает точку зрения технического заказчика и на его примере показывает, с какими сложностями сталкиваются практики из-за отсутствия единых нормативных определений.
2. Проиллюстрировать последствия нормативного хаоса. Использование автором таких понятий, как «исполнительная ЦИМ», «операционная модель», «операционная ЦИМ» — яркое свидетельство того, что даже высококвалифицированные специалисты вынуждены создавать собственную терминологию, что вредит развитию всей отрасли информационного моделирования.
Позиция редакции совпадает с позицией законодателя: до момента возможного внесения понятия «ЦИМ» в Градкодекс, ответственность за состояние нормативного поля в этой сфере лежит на профильном регуляторе — Министерстве строительства и ЖКХ РФ.
Авторы:
Александр Викторович Рогов, руководитель BIM-отдела ООО «Генеральная дирекция «Центр», член Комитета по цифровизации управления инвестиционно-строительным проектом Ассоциации «НОТЕХ»
Вадим Андреевич Свириденко, руководитель департамента цифрового сопровождения проектов ООО «Инжиниринговая корпорация «ИРБИС», член Комитета по цифровизации управления инвестиционно-строительным проектом Ассоциации «НОТЕХ»
Список литературы: Рекомендации по внедрению цифрового функционала технического заказчика. — Текст: электронный. — URL: https://www.minstroyrf.gov.ru/docs/413516/ (дата обращения: 20.11.2025).
Источник: Журнал «Информационное моделирование». №1 2026 (8)
