IFC и качество данных: приёмка модели до передачи

Протокол приёмки IFC: восемь проверок с порогами, скрипт для подсчёта proxy и пустых свойств, требования в задание и разбор симптомов негодного файла.

Подрядчик прислал IFC и попросил принять модель. Внутри 62 тысячи элементов, из них 19 тысяч с типом IfcBuildingElementProxy: для программы это «объект без определённого класса». Стены, двери и оборудование лежали в общей куче. Посчитать по такому файлу нельзя ничего.

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

Про галочки экспортёра есть отдельный разбор: настройки экспорта IFC из Revit. Здесь про приёмку: как за час понять, годен файл или его надо возвращать.

Что значит «качественная модель» на практике

Красота тут ни при чём. Проверяемых признака четыре.

• Классификация. Каждый элемент попал в свой класс. Стена это IfcWall, а не безымянный объект.
• Свойства. У элементов есть поля, по которым можно фильтровать и считать: марка, тип системы, этаж, материал.
• Структура. Элементы разложены по этажам и зданиям, а не свалены в один узел дерева.
• Координаты. Файл встаёт на своё место рядом с остальными разделами без ручного сдвига.

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

Протокол приёмки: восемь проверок

Мы прогоняем один и тот же список независимо от того, кто прислал файл. Занимает 40-60 минут на раздел.

Проверки 1, 2 и 7 закрывают большую часть проблем. С них и начинаем, а если хотя бы одна провалилась, дальше файл не смотрим, а возвращаем автору.

Отдельно отмечу шестую строку. Пустые оболочки не видны глазом: элемент отображается, а объёма у него нет. Такие приходят при экспорте моделей на месте и при сложных вырезаниях. Замечают их обычно сметчики, когда объём стен выходит вдвое меньше ожидаемого.

Чем проверять

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

Мы держим маленький скрипт на IfcOpenShell, он гоняется по любому присланному файлу за пару минут:

import ifcopenshell
from collections import Counter

f = ifcopenshell.open("AR_2026-08-01.ifc")
vse = f.by_type("IfcProduct")

# 1. Сколько элементов не получили нормальный класс
klassy = Counter(e.is_a() for e in vse)
proxy = klassy.get("IfcBuildingElementProxy", 0)
print(f"всего {len(vse)}, proxy {proxy} ({proxy / len(vse):.1%})")

# 2. Топ-10 классов: сразу видно перекос
for k, n in klassy.most_common(10):
    print(f"  {k:<32} {n}")

# 3. Элементы без единого набора свойств
bez_svoystv = [e for e in vse if not getattr(e, "IsDefinedBy", None)]
print(f"без свойств: {len(bez_svoystv)}")

# 4. Проверка привязки к этажу
bez_etazha = [e for e in f.by_type("IfcBuildingElement")
              if not any(r.is_a("IfcRelContainedInSpatialStructure")
                         for r in getattr(e, "ContainedInStructure", []) or [])]
print(f"вне этажей: {len(bez_etazha)}")

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

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

Требования пишут заранее

Половина споров про качество возникает из-за того, что требований не было. Автор сделал как умеет, приёмщик ждал другого, оба правы.

В задание или в план работ по проекту стоит внести четыре вещи.

Версию схемы. IFC 2x3 Coordination View 2.0 либо IFC4 Reference View. Одна на весь проект, без смены посередине.

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

Координаты. Точка привязки и способ (общие координаты). Одна строка в задании экономит недели.

Ритм и формат публикации. Когда, куда и под каким именем. Про то, как это связано со сборкой, есть разбор по сводной модели.

Пять симптомов негодного файла

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

Фильтры не работают. Симптом: пробуете отобрать все двери, попадает мебель. Классификация формально есть, но её проставили вручную и невнимательно.

Модель на километр в стороне. Симптом: сборка разъезжается, координатор двигает файл руками. Опасно тем, что при следующей публикации сдвиг придётся повторять, и однажды его забудут.

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

Файл разбух втрое. Симптом: было 180 МБ, стало 600 МБ без изменений в проекте. Обычно внутрь попали связи, подложки или экспорт пошёл со всех видов вместо одного подготовленного.

Кто отвечает за качество

Отвечает передающая сторона, и это стоит зафиксировать письменно. Приёмщик проверяет по протоколу и возвращает, а не чинит чужой файл.

Как только координатор начинает править присланные модели, происходят две вещи. Автор перестаёт следить за качеством, потому что «там поправят». И через месяц никто не знает, какая версия правильная: исходная или подправленная.

Возврат файла это не конфликт, а нормальная процедура. Формулировка короткая: номер проверки, что не прошло, что сделать. Три строки без эмоций.

Как выглядит ответ автору

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

Сверху одна строка про решение: принято или возвращено. Дальше версия файла, дата и число элементов, чтобы потом не было спора о том, какую публикацию обсуждали. Потом пункты протокола, которые не прошли, с цифрами: доля proxy 31% при пороге 5%, марка пустая у 1 480 элементов из 4 100.

В конце срок, к которому ждём исправленную публикацию. Без срока файл вернётся через месяц.

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

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

Где проверка данных не поможет

Она не оценивает проектные решения. Модель может быть безупречной по структуре и содержать неверно подобранное оборудование. Классификация и нормоконтроль это разные вещи.

Она не восстановит того, чего в исходнике нет. Если марку не заполняли в рабочей модели, в IFC ей взяться неоткуда. Проверка честно покажет пустоту, но чинить придётся у автора.

Она не спасает при обмене между разными версиями схемы. Половина команды отдаёт IFC4, половина 2x3, и часть свойств будет теряться при каждом круге. Это решается договорённостью на старте, а не приёмкой на выходе.

И она не заменяет прямой обмен исходниками внутри одной среды. Когда все работают в Revit, ставить IFC посередине смысла нет: вы добавите потери там, где их могло не быть.

Частые вопросы

Обязательно ли принимать IFC, если все работают в Revit? Нет. IFC нужен для внешних участников, заказчика и долгого хранения. Внутри команды удобнее родной формат.

Сколько времени занимает приёмка? Первый раз 1-2 часа с настройкой скрипта. Дальше 15-20 минут на раздел, большая часть автоматом.

Что делать, если подрядчик не может дать нормальный IFC? Разобрать вместе настройки экспорта, обычно проблема в двух галочках. Если не помогает, принимать исходный формат и конвертировать самим.

Нужен ли для проверки платный инструмент? Полезен, но не обязателен. Бесплатный просмотрщик плюс скрипт на IfcOpenShell закрывают весь протокол, который я описал выше.

Кто должен писать требования к моделям? BIM-менеджер заказчика или технический заказчик. Если такой роли нет, требования пишет тот, кто потом будет считать по модели.

С чего начать

Возьмите последний присланный IFC и посчитайте долю proxy-элементов и пустых свойств. Двадцать минут вместе с установкой библиотеки. Два числа сразу покажут, можно ли этому файлу верить.

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

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