Состав IFC-модели для АГР: какие элементы и свойства подготовить до технической проверки

Для московского АГР, когда требуется представление IFC, необходимо подготовить связанный комплект моделей территории и архитектурных решений. В нём должны читаться элементы, помещения, расчётные зоны и их свойства, а геометрия и показатели — описывать ту же версию проекта, что и чертежи.

Для заказчика основной вопрос — можно ли по переданной модели установить, что именно запроектировано, как распределены площади и откуда получены итоговые значения. Красивое трёхмерное изображение само по себе этого не подтверждает.
~

Что определяет состав IFC для АГР

IFC — Industry Foundation Classes, открытая схема обмена информацией об объектах строительства. Она описывает геометрию, характеристики и связи объектов. Файл IFC является результатом обмена; содержание выгрузки зависит от задачи и настроек исходной модели.
Специальные требования утверждены совместным распоряжением Департамента градостроительной политики (ДГП) и Департамента информационных технологий (ДИТ) Москвы от 16.01.2026 № ДГП-Р-1/26/64-16-6/26, действующим со 2 апреля 2026 года. Именно его приложение задаёт состав, классы и атрибуты ЦИМ АГР — цифровой информационной модели архитектурно-градостроительного решения. Пункты 4.1.1–4.1.2 устанавливают модельный вид IFC4 Reference View и формат IFC STEP Physical File.

В Москве действует Постановление Правительства Москвы от 22.05.2026 № 1423-ПП, в редакции от 13.08.2026, вступившее в силу 30 сентября 2026 года. Пункт 2.2 приложения 1 предусматривает IFC в составе проектных материалов с установленными исключениями. Для заявлений, поданных до вступления постановления в силу, действует переходное правило пункта 9.1.

Перед подготовкой задания следует установить применимость IFC к объекту и этапу рассмотрения. Общая связь форматов разобрана в материале «Цифровые модели для АГР».
Актуально на 12 октября 2026 года.
Обсудить маршрут согласования

Из каких частей состоит цифровой комплект

Дисциплинарная модель объединяет данные определённой части проекта. Раздел 5 требований выделяет проектную ситуацию, благоустройство и озеленение, архитектурные решения. При наличии нескольких корпусов пункт 5.1.2 требует их разделения и запрещает моделировать несколько корпусов в одном файле.

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

Задание на IFC полезно дополнить реестром файлов: содержание каждого, ответственный, исходная версия и связанные листы. Если подземная часть обслуживает несколько зданий, её распределение следует объяснить заранее, чтобы площади и элементы можно было проверить без догадок.
Структура IFC-модели для АГР: участок, здание, этажи, помещения и свойства элементов.

Из каких частей состоит цифровой комплект

  • Элементы и принадлежность

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

    Классы задаются требованиями: например, помещения и зоны — IfcSpace, стены и перегородки — IfcWall, перекрытия — IfcSlab. Классификацию других элементов следует брать из таблицы 5.1, включая различия по этапам.

    Рекомендацию удалить внутреннюю геометрию из презентационной модели нельзя автоматически применять к IFC: внутренние стены и помещения входят в состав АР.

  • Свойства и их расположение

    Для АГР используются пользовательские наборы RusSet_ и параметры RUS_; стандартные Pset_ и Qto_ не заменяют их — пункты 5.3.12–5.3.16 требований.

    Заказчику стоит запросить матрицу передачи данных, где для каждого применимого класса указаны:
    • набор и точное имя свойства;
    • источник значения в исходной модели;
    • тип данных и единица измерения;
    • правило заполнения и ответственный;
    • способ проверки после экспорта.
    Примеры данных: RUS_FNO — назначение здания («Жилое здание» или «Нежилое здание» по пункту 5.3.5); RUS_Name — наименование; RUS_Area — площадь; RUS_Object и RUS_Object_Sub — принадлежность корпусу и секции. Это ориентиры для чтения модели; полный перечень определяется применимыми таблицами требований.

    Название «Площадь» в интерфейсе программы ещё не объясняет, какое значение попадёт в IFC. Следует проверить выбранный источник, единицу, тип и место записи. Число, текст и логическое значение нельзя произвольно подменять друг другом.

    В официальных материалах «СтроимПросто» опубликованы примеры, маппинг — сопоставление параметров исходной программы и IFC — и файлы IDS (Information Delivery Specification), задающие машиночитаемые требования к данным. Там отдельно приведены корректировки атрибутов АР, которые планируется включить в обновлённые требования. Рабочее разъяснение портала следует отличать от изменения правового акта; исключение проверки параметра в IDS само по себе не отменяет нормативное требование.

  • Помещения и расчётные зоны

    Помещения и зоны для расчёта площадных показателей решают разные задачи. По пункту 5.3.6 требований зоны IfcSpace обеспечивают определение суммарной поэтажной площади в габаритах наружных стен — СПП в ГНС — и общей площади. Для их идентификации используется RUS_Name.

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

    Для жилого объекта особенно важно проверить группировку помещений по квартирам. Официальные разъяснения связывают её с RUS_Group_Type, RUS_Group_Number, RUS_Number и принадлежностью корпусу и секции. Практику сопоставления технико-экономических показателей (ТЭП) раскрывает проверка ТЭП в материалах АГР.

Какую детализацию не стоит добавлять автоматически

По пунктам 5.2.5–5.2.7 требований в ЦИМ ПС и БиО не моделируют малые архитектурные формы, переносные изделия, деревья и кустарники; газоны учитываются как покрытия. Это правило нельзя переносить на все графические и презентационные материалы проекта.
Tetriz Architects рекомендует начинать с архитектурной задачи: какие объёмы, планировки, фасадные решения и показатели должны быть проверяемы. Дополнительная детализация оправдана, когда помогает оценить решение или предусмотрена заданием. Она должна сохранять согласованность с конструкциями, инженерией и возможностью реализации.

Как подготовить комплект до технической проверки

  1. Зафиксировать исходную версию. Собрать актуальные планы, фасады, разрезы, схему территории, ведомость показателей и сведения об участках. Обозначить нерешённые проектные вопросы.
  2. Согласовать состав. Подготовить реестр дисциплинарных файлов и матрицу элементов. Определить, где отражены общие части и как исключается повторный учёт.
  3. Проверить передачу свойств. Сделать пробную выгрузку и просмотреть примеры здания, помещения, расчётной зоны, стены и покрытия. Сверить их с матрицей данных.
  4. Сопоставить геометрию и показатели. Проверить планы и разрезы по контрольным уровням, затем расчётные зоны и итоговую ведомость. Отдельно проверить совмещение территории и зданий.
  5. Проверить окончательную выгрузку. Сохранить перечень файлов и редакций, выполнить автоматическую и профессиональную проверку. Работа с сервисом описана в статье «Техническая проверка ЦИМ АГР».
Эта последовательность — рекомендация по организации работы. Она помогает определить, требуется ли настройка экспорта, дополнение данных или корректировка самого архитектурного решения.

Ошибки, которые следует исключить заранее

  • Состав определён только по внешнему виду модели

    Предлагаем проверять его по матрице элементов: видимый фасад не показывает полноту помещений и зон.

  • Свойство есть в исходной программе, но его передачу не проверили

    Предлагаем принимать результат по IFC-выгрузке, а не по скриншоту исходного интерфейса.

  • Файлы относятся к разным редакциям

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

  • Положительный автоматический результат принят за окончательную готовность

    Рекомендуем отдельно сверять архитектуру, содержание и методику показателей. Разбор технических причин приведён в статье «Ошибки цифровых моделей АГР».

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

Её можно рассматривать как исходную основу. Сначала следует сопоставить состав, классификацию, свойства и расчётные зоны с задачей московского АГР. Само происхождение модели не подтверждает соответствия нужному обменному комплекту.