Как проверить IFC-модель перед подачей: 8 групп ошибок

IFC-модель принимают по содержимому готового файла и комплекту выдачи. То, что файл открылся и здание выглядит правильно, не подтверждает наличие нужных классов, атрибутов и координат. До подачи проверяют именно ту редакцию, которую получит город. Разбираем восемь групп технических ошибок, из-за которых ЦИМ для АГР в Москве не проходит проверку, и порядок внутренней приёмки.

Модель IFCЭкспертный разбор · ПЦ «Архрешения»

Коротко

Перед подачей IFC для АГР проверяют восемь вещей: формат и модельный вид (IFC4 Reference View, IFC SPF), комплект файлов с именами по шаблону и ведомостью XML, классы элементов, наборы атрибутов RusSet_ и RUS_, детальные атрибуты по приложению 2, координаты и уровни, согласованность с буклетом и ТЭП, и то, что проверена именно финальная выгрузка. Это рабочий чек-лист по распоряжению ДГП и ДИТ от 16.01.2026, а не официальный перечень оснований отказа.

Что вы узнаете?

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

На какие требования опираться

Техническая основа — распоряжение ДГП и ДИТ Москвы от 16.01.2026 № ДГП-Р-1/26/64-16-6/26, которое применяется со 2 апреля 2026 года. В нём определены формат выдачи, имена файлов, подпись, координаты, классы элементов и состав атрибутов. Состав модели и нормативная база разобраны в статьях «ЦИМ для АГР в формате IFC» и «Требования к ЦИМ и IFC для АГР»; настройка выгрузки — в статье «Экспорт IFC из Revit и Archicad». Здесь — приёмка результата.

Непрохождение технической проверки, замечание к материалам и отказ в приёме заявления — разные события. Основания отказа и отклонения материалов установлены постановлением № 1423-ПП (приложение 3, п. 3.1 и 5.2), и IFC — лишь часть проверяемого комплекта. Поэтому ниже — технический чек-лист, а не юридический перечень.

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

1. Неподходящий формат или модельный вид

Требования задают формат IFC SPF (*.ifc), модельный вид IFC4 Reference View и схему IFC 4.0.2.1 по ГОСТ Р 10.0.02-2019 или более позднюю (п. 4.1.1, 4.1.2, 4.1.5). Расширение .ifc само по себе ничего не доказывает: файл могли выгрузить с другой схемой или модельным видом.

Что проверить. Заголовок файла: схема и модельный вид записаны в его первых строках. Затем открыть файл в отдельном просмотрщике, а не в программе, из которой он выгружен. Если просмотрщик не показывает модельный вид, запросите сохранённый профиль экспорта и версию программы. Переименование файла проверкой не является.

2. Комплект не совпадает с ведомостью

К IFC прилагают ведомость ЦИМ АГР в формате XML (п. 4.1.6). Модель делится на дисциплинарные файлы — ПС, БиО и АР; несколько корпусов в одном файле не допускаются (п. 5.1.1–5.1.2). Каждый файл называют по шаблону из пяти полей, например НН_К01_С01_АР_АГР (п. 4.3), подписывают усиленной квалифицированной электронной подписью с отдельным файлом подписи того же имени (п. 4.2) и держат в пределах рекомендуемых 500 МБ (п. 4.4.1).

Что проверить. Сверить перечень файлов в ведомости с фактическим архивом: нет ли потерянных частей и старых редакций, читается ли XML, совпадают ли имена файлов и файлов подписи. Для каждого требуемого материала записать имя файла и редакцию. Если какая-то часть неприменима — установить основание, а не оставлять молчаливый пропуск. Отдельный файл АР комплектность не подтверждает.

3. Элементы выгружены не в те классы

Классы элементов задают приложения 1 и 2 и таблица 5.1 (п. 4.1.3): стена — IfcWall, перекрытие — IfcSlab, помещение и зона — IfcSpace, окно — IfcWindow, дверь — IfcDoor, фасад — IfcCurtainWall. Класс IfcBuildingElementProxy допускается только в предусмотренных случаях (п. 4.1.4) — например, для вспомогательного 3D-тела по приложению 2. Поэтому одинаково ошибочны и выгрузка всех элементов в Proxy, и требование удалить любой Proxy без разбора.

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

4. Атрибуты есть, но не в тех наборах

При рассмотрении учитываются только значения в пользовательских наборах с префиксом RusSet_ и атрибутах с префиксом RUS_, имена — без пробелов (п. 5.3.12–5.3.16). Значения в стандартных наборах Pset_ и Qto_ не засчитываются.

Что проверить. Открыть свойства уже выгруженного элемента, найти точное имя набора и атрибута, сверить тип данных и значение. Поле с похожим русским названием в исходной программе не доказывает, что оно попало в нужное место IFC. Учитывать регистр и написание из таблиц требований: RusSet_Quantities, а не «RusSet Quantities».

5. Общий минимум вместо детальных требований

Для элементов, у которых есть своя таблица в приложении 2, атрибуты берут из неё. Общий минимум RusSet_Common из трёх текстовых атрибутов (таблица 5.2, п. 5.3.11) — для элементов, для которых детальных требований нет. Нельзя проверить три общих поля и объявить все элементы готовыми. У стены, например, по Б.4 нужны RUS_Length, RUS_Thickness, RUS_Height в мм и RUS_Volume в м³; у зоны «СПП в ГНС» по Б.3.1 — RUS_Area в м² и RUS_Height в мм.

Что проверить. Построить матрицу «тип элемента — таблица приложения 2 — атрибуты — результат». Смотреть не только наличие поля, но и единицы, округление (мм без дробной части, площадь 0,00 м², объём 0,000 м³ — п. 4.6) и осмысленность значения. Заполнитель «нет данных» достоверным значением не становится.

6. Части модели не скоординированы

Базовая точка модели — пересечение осей 1 и А на отметке чистого пола первого этажа, 0,000 (п. 4.5.3). Все дисциплинарные файлы выполняют в местной системе координат и Балтийской системе высот с указанием угла к истинному северу (п. 4.5.4), в масштабе 1:1 и метрической системе (п. 4.6). Уровни ставят по чистому полу и называют по шаблону (п. 4.7). Видимое совпадение одной пары объектов в исходной программе не доказывает положение всей выдачи.

Что проверить. Собрать итоговые файлы в одной сцене просмотрщика, сопоставить контрольные точки, уровни и ориентацию. Расхождение не исправляют перемещением одного файла в просмотрщике — ищут причину в настройках координат. Для объектов с ограниченным доступом действует исключение п. 4.5.5; их координаты в открытые сервисы не передают.

7. Модель, ТЭП и буклет противоречат друг другу

Технико-экономические показатели формируются из атрибутов модели (раздел 7), а IFC прилагается к планам, фасадам и разрезам буклета. До экспорта требования предписывают сверить модель с двумерной документацией, оставить только публикуемые элементы, проверить коллизии по матрице приложения 4 и примыкания — элементов, «висящих в воздухе», быть не должно (п. 6.2.2). Автоматическая проверка структуры файла не подтверждает, что все материалы описывают один вариант проекта.

Что проверить. Этажность, габариты, характерные отметки, состав объёмов и ключевые ТЭП — в модели, ведомости и буклете. При расхождении установить первопричину вместе с ответственным проектировщиком. Править только XML, чтобы скрыть противоречие с геометрией, нельзя. После согласования изменений все затронутые материалы обновляют одной редакцией. Замечания к модели удобно вести в формате BCF (п. 6.1) — они привязаны к конкретным элементам.

8. Проверена прежняя выгрузка, а подаётся новая

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

Что проверить. Связать итоговый файл, дату проверки и отчёт; для прослеживаемости сохранять контрольную сумму и журнал изменений. После повторного экспорта заново проверяют изменённые данные и связанные части. Результат городской предварительной проверки ЦИМ на портале «СтроимПросто» относится к конкретной выгрузке — ссылку на него прилагают к материалам АГР (п. 5.3.3 и 6.3 Требований ДГП к составу проектных материалов), и получать её нужно по финальной версии файлов.

Порядок приёмки перед подачей

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

Что передать проверяющему	Для чего
IFC, файлы подписи и ведомости одной редакции	проверить фактическую выдачу
Актуальный буклет и ТЭП	сопоставить модель с проектом
Матрицу требований и прошлые замечания	отделить новые проблемы от закрытых
Профиль экспорта и версию программы	найти источник повторяющегося сбоя

Такой порядок не даёт повторять одну и ту же настройку экспорта вместо исправления исходных данных. Что входит в буклет и как сверять ТЭП — в статье «Что входит в буклет АГР».

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

Если IFC открывается в просмотрщике, он готов к подаче?

Нет. Отдельно проверяют комплектность и имена файлов, классы, наборы RusSet_ и атрибуты RUS_, координаты и уровни, согласованность с буклетом и ТЭП.

Можно ли все элементы выгрузить как IfcBuildingElementProxy?

Нет. По п. 4.1.4 требований этот класс допускается только в предусмотренных случаях, например для вспомогательного 3D-тела. Класс каждого типа элемента сверяют с таблицей 5.1 и приложениями 1 и 2.

Достаточно ли стандартных наборов Pset_ и Qto_?

Нет. При рассмотрении учитываются только пользовательские наборы RusSet_ и атрибуты RUS_ (п. 5.3.12–5.3.16). Стандартные наборы требуемые данные не заменяют.

Можно ли выгрузить все корпуса одним файлом?

Нет. Несколько корпусов в одном файле не допускаются (п. 5.1.2). Каждый корпус выгружают отдельно по каждой дисциплине и называют по шаблону п. 4.3.

Нужно ли повторять проверку после нового экспорта?

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

Эти восемь групп — официальный перечень оснований отказа?

Нет. Это технический чек-лист по распоряжению ДГП и ДИТ. Основания отказа в приёме и отклонения материалов установлены постановлением № 1423-ПП, и техническое замечание не равно отказу.

Доработаете ли вы чужую IFC-модель, которая не прошла проверку?

Чужие файлы IFC мы не дорабатываем: за исходную модель и её данные отвечает автор. Мы разрабатываем ЦИМ для АГР с нуля по вашим чертежам и буклету — с проверкой по требованиям Москвы перед подачей.

Разработаем ЦИМ по вашему проекту

Если проверка показывает, что исходная модель не содержит нужных данных — нет базовой точки, корпуса в одном файле, атрибуты только на чертежах, — настройками экспорта это не исправить. Передайте согласованные проектные материалы и показатели: разработаем ЦИМ для АГР с нуля, с дисциплинарными файлами, атрибутами по требованиям, ведомостями и проверкой перед подачей. Результат технической проверки не является гарантией утверждения АГР.

Нормативная оговорка

Материал подготовлен 28 октября 2026 года по тексту распоряжения ДГП и ДИТ Москвы от 16.01.2026 № ДГП-Р-1/26/64-16-6/26 и постановления № 1423-ПП в редакции от 13.08.2026. Чек-лист — рекомендация по организации приёмки, он не заменяет требования к конкретному объекту. Сверяйте действующую редакцию на дату подачи.

Основные источники

Распоряжение ДГП и ДИТ Москвы от 16.01.2026 № ДГП-Р-1/26/64-16-6/26 — требования к материалам в формате IFC; применяется со 02.04.2026: п. 4.1–4.7, 5.1, 5.3.10–5.3.16, 6.1, 6.2.2, раздел 7, табл. 5.1, 5.2, приложения 1, 2 (Б.1, Б.3.1, Б.4), 4.
Постановление Правительства Москвы от 22.05.2026 № 1423-ПП (в редакции от 13.08.2026; действует с 30.09.2026): приложение 3, п. 3.1, 5.2.
«Требования к составу, содержанию и форматам представления проектных материалов» (приказ ДГП города Москвы от 02.04.2026 № ДГП-ПР-64/26 в редакции от 22.06.2026 № ДГП-ПР-132/26): п. 5.3.3, 6.3.