Вопрос. Как организовать передачу модели через среду общих данных (СОД) так, чтобы зафиксировать не только файл, но и состав атрибутов, версию и статус (проект/РД/изменение)...

Вопрос

Как организовать передачу модели через среду общих данных (СОД) так, чтобы зафиксировать не только файл, но и состав атрибутов, версию и статус (проект/РД/изменение), и как это потом использовать при экспертизе?

Ответ

Чтобы организовать передачу BIM‑модели через среду общих данных (СОД) с фиксацией не только файла, но и атрибутов, версии, статуса, а затем использовать это при экспертизе, нужно выстроить процесс на стыке регламентов, структуры СОД и форматов данных.

Нормативная база, на которую стоит опираться

*** 19650 (и его адаптация в российских документах) — задаёт принципы управления информацией, включая зоны WIP/Shared/Published/Archive, версионность и статусы.
СП 333.1325800.2020 — требования к структуре и составу цифровой информационной модели (ЦИМ), в том числе к атрибутам и передаче данных.
СП 48.13330.2019 — организация строительства и документооборот, включая статусы документации.
Требования экспертных организаций (в т. ч. госэкспертизы) — часто публикуются в виде чек‑листов и требований к пакету выдачи.

Как технически зафиксировать файл + атрибуты + версию + статус

1. Структура зон СОД по ISO 19650

WIP (Work in Progress) — рабочие файлы, черновые версии. Здесь хранятся промежуточные наработки без официального статуса.
Shared — общие данные для междисциплинарной координации. Сюда выгружают модели после внутреннего контроля, но до утверждения.
Published — «официальные» версии, прошедшие проверку и согласованные. Именно отсюда берут данные для передачи на экспертизу.
Archive — долгосрочное хранение всех версий, истории изменений, замечаний и решений.

Статус (проект/РД/изменение) и версия фиксируются не только в имени файла, но прежде всего в карточке объекта в СОД.

2. Карточка объекта в СОД

В большинстве платформ СОД (Pilot‑BIM, CADLib, Autodesk *** 360/ACC и др.) у каждого файла/контейнера есть карточка с обязательными полями:

Идентификатор (уникальный ID, не зависящий от имени файла).
Версия (V1, V2, V3… или дата/время).
Статус (черновик/на проверке/утверждён/отклонён; стадия: П/РД; тип: изменение/новое).
Атрибуты (дисциплина, раздел, LOD/LOI, стадия, ответственный, дата выпуска).
Связи (с исходным заданием, замечаниями, смежными моделями).

Именно карточка, а не имя файла, является источником истины для экспертизы.

3. Атрибуты внутри модели

Помимо карточки в СОД, атрибуты должны быть внутри самой модели:

IFC‑свойства (IfcPropertySet) — универсальный способ хранить атрибуты в модели для интероперабельности.
Нативные свойства (***** parameters, Renga properties и т. п.) — удобны для работы в нативной среде, но менее пригодны для внешней экспертизы без выгрузки.
Единый классификатор (КСИ, Uniclass, ********* и др.) — позволяет однозначно сопоставлять элементы модели с видами работ и расценками.

Для экспертизы критично, чтобы ключевые атрибуты (наименование элемента, марка, материал, габариты, привязка к осям/уровням, стадия, LOD) были заполнены и не противоречили документации.

4. Форматы передачи

Нативная модель (RVT, RNP и т. д.) — для детальной проверки и внутренних доработок.
IFC (рекомендуется IFC4 Reference View или ****** Transfer View) — для передачи атрибутов и геометрии между разными средами и для экспертизы.
NWD/NWC — для визуализации, проверки коллизий и наглядной демонстрации статусов.
Комплект документации (PDF, DWG) — как сопровождающий материал с привязкой к версии модели.

Важно: версия модели в IFC должна соответствовать версии и статусу в карточке СОД.

Процесс передачи и фиксации

Подготовка модели: проверка заполнения атрибутов, соответствие LOD/*** требованиям стадии, удаление лишней информации.
Выгрузка обменных форматов (IFC, NWD) с привязкой к ** и версии.
Размещение в зоне Shared для координации и первичной проверки.
Внутренний контроль (BIM‑координатор, ГИП): проверка атрибутов, коллизий, соответствия требованиям.
Перевод в зону Published с присвоением статуса «Утверждено», фиксацией версии и даты.
Формирование пакета выдачи для экспертизы: модель (IFC/нативная), ведомость изменений, BEP, требования к атрибутам, классификатор.
Фиксация в СОД: карточка объекта, журнал изменений, список замечаний и их статусов, электронная подпись (при необходимости).

Как это используют при экспертизе

При проверке эксперт действует по следующему алгоритму:

Проверка источника данных: убеждается, что модель взята из зоны Published, имеет корректный статус (например, РД), зафиксированную версию и атрибуты в карточке.
Сопоставление модели и документации: проверяет, что атрибуты элементов (наименование, марка, материал) соответствуют спецификации и чертежам.
Проверка полноты атрибутов: наличие данных для сметного расчёта (объёмы, площади, длины, массы), соответствие классификатору, достаточность LOD для заявленных целей.
Анализ изменений: по журналу изменений и ведомости корректировок эксперт видит, какие элементы были изменены, когда и по какой причине. Это помогает быстро локализовать зоны риска.
Верификация геометрии и коллизий: при необходимости использует NWD/IFC для проверки пересечений и соответствия проектных решений нормативам.
Проверка интероперабельности: если модель передаётся для сметных расчётов или дальнейшей эксплуатации, эксперт проверяет, что ключевые атрибуты корректно выгружаются в *** и могут быть использованы в сметных программах.

Практические рекомендации для сметчиков и проектировщиков

Единые правила именования и версионирования — исключают путаницу и ускоряют поиск нужной версии.
Шаблоны карточек объектов в СОД — заранее пропишите обязательные поля (статус, версия, LOD, дисциплина и т. д.).
Контрольные чек‑листы перед публикацией модели — проверка атрибутов, геометрии, коллизий, комплектности.
Журнал изменений — фиксируйте не только факт изменения, но и его влияние (на объёмы, стоимость, сроки).
Интеграция СОД с СЭД — для юридически значимого документооборота и регистрации официальных выпусков.

Пример связки «СОД → экспертиза»

Допустим, вы передаёте модель на экспертизу:

В СОД в зоне Published лежит IFC‑файл Project_B1_IFC_V3.ifc со статусом «РД, утверждено», версия V3, дата 2026‑07‑01.
В карточке указаны: стадия — РД, LOD — 400, ответственный — Иванов И. И., есть ссылка на ведомость изменений.
Внутри *** у каждого элемента заполнены свойства: наименование, марка, материал, габариты, классификация по КСИ.
Эксперт загружает IFC в свою систему, проверяет атрибуты, сопоставляет с ведомостями и спецификациями, анализирует изменения по журналу и делает выводы о соответствии проекта нормативам.

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

Ответ дан по состоянию на 01.07.2026

Все права на информационный материал принадлежат редакции сайта «Дайджест-Визард». Копирование и публикация материала допускается только с обязательной прямой ссылкой на страницу, с которой материал был взят, любое другое использование — только с письменного разрешения редакции.

Вопрос

Ваше сообщение