Передача данных из строительства в эксплуатацию без повторного ввода: BIM и IFC

Андрей Отинов -

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

Источник: bentley.com

Эта статья — о том, как не попасть в такую ситуацию. Разберём рабочий подход: данные о здании собираются один раз в ходе строительства и передаются в эксплуатацию в машиночитаемом виде, без повторного ввода. Основа — открытые стандарты обмена (IFC от buildingSMART) и платформы цифровых двойников вроде Bentley iTwin, которые синхронизируют данные из разных систем в их исходных форматах. Разбор рассчитан на владельца небольшой строительной компании, который сейчас находится на этапе замысла и технико-экономического обоснования — то есть в единственной точке, где эту проблему ещё можно решить дёшево.

Что именно ломается при передаче объекта в эксплуатацию

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

Причина поломки почти всегда одна: требования к данным для эксплуатации никто не сформулировал в начале проекта. Проектировщик делал модель под свои задачи, подрядчик вёл документацию под акты, а что из этого нужно тому, кто будет менять фильтры и обслуживать лифты, — не обсуждали. В момент сдачи собрать это задним числом уже невозможно: люди, которые знали ответы, ушли на другие объекты.

Вывод для этапа ТЭО простой: требования к передаче данных — это часть проектного задания, а не пожелание на финишной прямой. Если их нет в контракте с проектировщиком и генподрядчиком, их не будет и в результате.

На чём строится передача без повторного ввода

Рабочая схема опирается на два публично доступных элемента.

Первый — открытые стандарты обмена. Организация buildingSMART International развивает набор стандартов для строительной отрасли, ключевой из которых — IFC (Industry Foundation Classes, стандарт ISO 16739). Это стандартизированное цифровое описание здания: не картинка и не чертёж, а структурированные данные, где у каждой стены, трубы и вентиляционной установки есть атрибуты. buildingSMART также поддерживает бесплатный онлайн-сервис валидации IFC-файлов — то есть корректность файла можно проверить формально, а не на глаз. Практический смысл: если вы в контракте требуете передачу модели в IFC с заданным набором атрибутов, у вас появляется проверяемый критерий приёмки, а не «пришлите всё, что есть».

Второй элемент — платформы цифровых двойников. Пример — Bentley iTwin Platform: открытая платформа на API и библиотеках, которая берёт на себя интеграцию данных, визуализацию, отслеживание изменений и безопасность. Ключевое свойство, заявленное разработчиком: цифровой двойник непрерывно синхронизируется и объединяет данные из разных репозиториев в их исходных форматах. То есть модель проектировщика, данные подрядчика и эксплуатационные системы не нужно сводить в один «единственно правильный» файл — платформа связывает их как есть. Важная оговорка самого производителя: клиент владеет своими данными, а платформа построена на открытых технологиях. Это прямой ответ на главный страх владельца — попасть в зависимость от закрытого формата одного вендора.

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

Что меняется Почему важно бизнесу Что проверить
Требования к данным прописываются на этапе ТЭО Эксплуатация не платит за повторный сбор информации Есть ли в проектном задании раздел о передаче данных
Обмен идёт в IFC (ISO 16739) Формат открытый, приёмку можно проверить валидатором Умеют ли проектировщик и подрядчик выгружать корректный IFC
Данные связываются через платформу двойника Не нужен ручной перенос между системами Кто владеет данными и как их выгрузить при уходе от вендора
Эксплуатация подключается до сдачи объекта Атрибуты оборудования собираются по ходу стройки Заполнены ли паспорта оборудования в модели, а не в Excel

Как выстроить процесс: от замысла к передаче

Метод не требует покупки дорогой платформы на старте. Он требует дисциплины в четырёх точках.

Шаг первый — на этапе ТЭО сформулировать, какие данные нужны эксплуатации. Не «BIM-модель», а конкретно: перечень систем и оборудования, обязательные атрибуты (производитель, модель, серийный номер, гарантия, регламент ТО), формат передачи. У buildingSMART есть понятие требований к обмену данными — по сути, формализованного списка того, что должно быть в модели. Это и есть основа раздела контракта.

Шаг второй — закрепить требования в договорах с проектировщиком и генподрядчиком. Пункт о передаче модели в IFC с заполненными атрибутами должен быть условием приёмки, как и комплект исполнительной документации. Без договорного закрепления требование останется пожеланием.

Шаг третий — собирать данные по ходу строительства, а не в конце. Когда подрядчик смонтировал насосную, атрибуты оборудования вносятся в модель сразу, с актов и паспортов. Здесь и работает логика платформ вроде iTwin: изменения отслеживаются, данные из разных источников синхронизируются, и к моменту сдачи двойник уже содержит фактическое состояние объекта.

Шаг четвёртый — приёмка данных как отдельная процедура. IFC-файл прогоняется через валидатор, полнота атрибутов сверяется с требованиями из контракта, эксплуатационная служба подтверждает, что может работать с полученным. Только после этого объект считается переданным.

Где ограничения и риски

Честная картина включает несколько слабых мест.

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

Второе — стоимость и доступность. Bentley — иностранный вендор, и для российской компании в 2026 году вопросы оплаты, поддержки и устойчивости доступа к зарубежным SaaS-платформам остаются открытыми. Это не аргумент против метода, но аргумент за то, чтобы требования к данным строились на открытых стандартах (IFC), а не на конкретной платформе. Стандарт переживёт любого вендора; закрытый формат — нет. Отдельно отметим: материалы Bentley — это описание производителя, а не независимая оценка, и обещания вроде «мы берём на себя тяжёлую работу» стоит проверять на пилоте.

Третье — компетенция команды. Корректная выгрузка IFC с нужными атрибутами — навык, которым владеют не все проектировщики. Проверить это нужно до подписания договора, запросив тестовый файл с прошлого объекта и прогнав его через бесплатный валидатор buildingSMART.

Четвёртое — объём работ не должен раздуваться. Собирать «всё обо всём» — путь к провалу. Начинать стоит с инженерных систем и оборудования, где цена ошибки в эксплуатации максимальна.

Что сделать на этой неделе

Если у вас объект на этапе замысла или ТЭО, безопасный первый шаг выглядит так:

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

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

Источники

Что почитать дальше