Структура BIM-модели: как организовать проектную информацию с первого этапа

Правильная структура BIM-модели — это не бюрократия, а фундамент, который определяет, сможет ли команда эффективно работать вместе, передавать данные подрядчикам и эксплуатировать объект. Ошибки, допущенные на этапе создания пустого проекта, всплывают поздно: при сборке федеративной модели, проверке коллизий, передаче в GIS или Facility Management. Исправить их тогда стоит в десятки раз дороже, чем заложить правильные правила в начале.

Главный принцип: структура должна служить задачам проекта, а не формальным требованиям стандарта. Стандарты (ISO 19650, ГОСТ Р ИСО 19650, ПОДС) задают рамки, но внутри них нужно принимать решения под конкретный объект, состав команды, программное обеспечение и этапы жизненного цикла. Ниже — пошаговый разбор того, что нужно определить до первой моделируемой стены.

011. Координатная система и базовые точки: общая система отсчёта

Первое, что должно быть зафиксировано в BIM-стандарте проекта (BEP) — это координатная система. Без единой системы отсчёта модели архитекторов, конструкторов и инженеров не сцепятся без ручного подгонки, а привязка к кадастру и GIS станет проблемой.

Что определить обязательно

• Проектная система координат (Project Coordinate System). Локальная система проекта. В Revit — Internal Origin, в ArchiCAD — Project Origin, в Tekla — базовая точка. Все моделирующие должны работать в одной системе.
• Геодезическая привязка (Survey Point / Geolocation). Точка с известными геодезическими координатами (МСК, местная система, WGS84). Фиксируется в BEP с указанием метода получения (ГНСС, каталог точек ГГС).
• Угол поворота относительно севера (True North / Project North). Разница между проектным севером (удобным для компоновки листов) и истинным севером (необходимым для инсоляции, ветровой нагрузки, GIS).
• Отметка нуля проекта (Level 0 / Ground Floor). Единая отметка ±0,000, от которой отсчитываются все уровни. Допускается ли отрицательная отметка для подвалов — решается здесь.

Практическое правило: базовую точку и поворот устанавливает BIM-менеджер или ведущий архитектор до начала моделирования. Все связанные файлы (Revit, IFC, DWG подложки) загружаются с привязкой к этой точке «по общему началам координат» (Origin-to-Origin), а не «по центру» или «по последней точке».

022. Файловая структура: федерация или монолит

Выбор стратегии разделения модели на файлы зависит от размера объекта, количества участников, программного обеспечения и этапа проектирования. Нет универсального «правильного» варианта — есть подходящий под условия.

Основные подходы

Подход	Когда уместен	Основные риски
Один файл на дисциплину (AR, KR, OV, VK, EOM)	Малые объекты (до 5–7 тыс. м²), команда 2–4 человека, один этап П/Р	Конфликты доступа, большой вес файла, сложно разделять права
Разделение по зонам/секциям/этажам внутри дисциплины	Крупные объекты, поэтажная сдача, разные подрядчики на секции	Сложность координации на стыках зон, дублирование осевой сетки
Федеративная модель: отдельные файлы загрузки (linked models)	Стандарт для Revit-проектов любого размера, работа в CDE (ACC, BIM 360, ProjectWise)	Требует дисциплины обновления связей, версионирования
Гибрид: мастер-файл координации + рабочие файлы дисциплин	Сложные объекты с поэтапной сдачей, необходимость изоляции изменений	Наибольшие накладные расходы на управление

Рекомендации по выбору

• Начинайте с федеративной структуры (отдельные файлы AR, KR, OV и т.д., собранные в координационном файле), даже если проект мал. Это закладывает правильную гигиену работы с связями.
• Не разбивайте файл по этажам внутри одной дисциплины, если нет строгой необходимости (поэтажная сдача, разные ответственные). Вертикальные элементы (колонны, шахты, трубопроводы) рвутся на границе файлов.
• Выделяйте общие координационные элементы (оси, уровни, границы участка, рельеф) в отдельный файл-базу (Shared Coordinates / Site Model), на который ссылаются все дисциплины.
• Именование файлов должно включать: дисциплину, этап, версию/дату, статус (WIP / Shared / Published). Пример: AR_P_20241215_v12_Shared.rvt.

033. Система именования: читаемость и машинная обработка

Именование — это интерфейс между людьми и скриптами. Плохие имена ломают автоматизацию (Dynamo, PyRevit, Solibri, Power BI отчёты) и заставляют людей гадать.

Что должно иметь единое правило

• Уровни (Levels): префикс дисциплины + отметка + назначение. Пример: AR_01_+3000_1_Этаж, KR_00_-3000_Подвал. Нумерация уровней должна совпадать у всех дисциплин.
• Рабочие наборы (Worksets): по функционалу, а не по автору. AR_Конструктив, AR_Перегородки, AR_Мебель, OV_Вентиляция, VK_Отопление. Один рабочий набор — одна область ответственности / один тип элементов.
• Семейства и типоразмеры: используйте классификатор (Uniclass, OmniClass, локальный) в префиксе. Пример: Pr_20_51_21_Стена_Наслоенная_200 (Uniclass Pr_20_51_21 — стены несущие).
• Зоны и помещения: номер по номенклатуре ПОДС / классификатору + имя. 01.01.01_Лобби.
• Виды и спецификации: префикс назначения + дисциплина + содержание. PL_AR_План_1_Этаж, SCH_KR_Ведомость_Колонн, 3D_COORD_Координация_Общая.

Проверка: откройте браузер проекта (Project Browser). Если вы не можете за 5 секунд найти нужный вид или рабочий набор — система именования не работает.

044. Уровень детализации и информационная насыщенность (LOD / LOIN)

LOD (Level of Development) в понимании BIM Forum / ISO 19650 — это не просто «детализация геометрии», а степень достоверности геометрии и информации для принятия решений на конкретном этапе. В российской практике часто смешивают LOD (геометрия) и LOI (информация). Разделяйте их в BEP.

Практическая таблица соответствия этапов и LOD (ориентировочно)

Этап (РУ)	Этап (ISO 19650)	LOD геометрия	LOI (информация)	Кто принимает решение по данным
Техно-экономическое обоснование (ТЭО)	Concept / 1	100–200 (объёмные блоки, зонирование)	Минимум: тип объекта, площадь, этажность	Инвестор, заказчик
Предпроектные работы / П (Концепция)	Concept / 2	200 (обобщённые системы, габариты)	Основные материалы, класс ответственности, грузоподъёмность	Архитектор, ГИП, экспертиза
Проектная документация (П)	Design / 3	300 (точная геометрия, узлы стыковки)	Марки стали/бетона, бренд оборудования (или равноценные), ПОЖ класс	Экспертиза, ГИП, подрядчик (для ППР)
Рабочая документация (Р) / Проект производства работ (ППР)	Construction / 4	350–400 (сборки, арматура, префабрикаты, отверстия)	Партии материалов, серийные номера оборудования, даты поставки	Подрядчик, ТПР, СМР
Эксплуатация / As-Built	Operation / 5	500 (фактическая геометрия после монтажа)	Паспорта оборудования, гарантии, QR-коды, история ТО	Эксплуататор, Facility Management

Важно: LOD 300 на стадии П не означает, что смоделирована каждая гайка. Это значит: геометрия достаточно точна для коллизий, расчёта объёмов и координации отверстий. Не требуйте LOD 400 на стадии П — это перерасход ресурсов и ложная точность.

055. Классификация и свойства: язык обмена данными

Модель без классификации — просто набор 3D-объектов. Классификация превращает её в базу данных для смет, закупок, эксплуатации и анализа.

• Выберите классификатор на старте. В России чаще всего: Uniclass 2015 (международный, гибкий), Омникласс (для экспорта), локальные классификаторы заказчика (Газпром, Роснефть, Мосметро и др.), ГОСТ/КС по видам работ (для смет в ГРАНД-Смете/Сметчете).
• Зафиксируйте набор обязательных параметров (COBie / IFC Pset / заказнические). Минимум для каждого элемента: Classification Code, Type Name, Manufacturer, ModelNumber, SerialNumber (для оборудования), InstallationDate, WarrantyDate, AssetID.
• Разделяйте типовые параметры (Type) и экземплярные (Instance). Материал, бренд, модель — на типе. Номер партии, дата монтажа, ответственный — на экземпляре.
• Не создавайте «свой» параметр, если есть стандартный IFC Pset. Проверьте IFC4 Property Sets (Pset_WallCommon, Pset_DoorCommon и др.) перед изобретением велосипеда.

066. Работа в команде: рабочие наборы, права и процесс синхронизации

Файловая структура и именование бесполезны, если не регламентирован процесс ежедневной работы.

Ключевые правила для worksharing (Revit) / Teamwork (ArchiCAD) / Multi-user (Tekla)

1. Один рабочий набор — один владелец в момент работы. Нельзя двум людям одновременно владеть Workset «AR_Перегородки». Планируйте забор задач по наборам.
2. Синхронизация (Sync / Send Changes) — минимум каждые 30–60 минут. Не накапливайте изменения до вечера. Конфликты разрешаются проще на малых порциях.
3. Работа с центральным файлом только через локальные копии. Никто не открывает центральный файл напрямую. Это жесткое правило.
4. Ежедневная публикация (Publish / Save As Central) в CDE. Версия для координации (Shared) обновляется по расписанию (например, каждый день в 18:00), а не хаотично.
5. Журнал изменений (Revision History / Issue Log). Каждая опубликованная версия должна иметь описание: что изменилось, по чьей инициативе, связанный тикет в трекере (BIM 360 Issues, Jira, Redmine).

Права доступа: разделите роли: BIM-менеджер (администрирование, настройка шаблонов), ведущий проектировщик (владение ключевыми наборами, принятие решений), проектировщик (работы в своих наборах), координатор (только чтение + проверка коллизий). Не давайте права администратора проектировщикам.

077. Координационные пространства и проверка коллизий

Коллизии ищут не в момент сдачи, а постоянно. Для этого нужны выделенные координационные виды и автоматизированные проверки.

• Создайте набор 3D-видов для координации: по этажам, по зонам, по системам (OV+VK, EOM+NS). Настройте фильтры видимости: показывать только элементы текущей дисциплины + полупрозрачные элементы смежных дисциплин.
• Настройте автоматические проверки в Solibri / Navisworks / BIMcollab / Revit Model Checker. Базовый набор: жесткие коллизии (пересечение геометрии), клиренсы (проходы, доступ к обслуживанию), проверка отверстий в перекрытиях/стенах, дубликаты элементов.
• Регламент BCF-процесса: коллизия → создание Issue в BCF → назначение ответственного → срок исправления → верификация → закрытие. Без трекера процесс теряется в чатах и почте.
• Зоны ответственности за отверстия: кто моделирует проемы под инженерку — архитектор или инженер? Зафиксируйте в BEP. Обычно: инженер размещает семейство отверстия (Opening), архитектор утверждает геометрию.

088. Обмен данными: IFC, COBie, нативные форматы

Модель не заканчивается в авторской программе. Она уходит в экспертизу, к подрядчику, в СМР, в FM-систему. Подготовьте экспорт заранее.

• IFC 4.3 (или IFC 4.2×3 CV2.0) — основной формат обмена. Настройте MVD (Model View Definition): Reference View для координации, Design Transfer View для передачи проекту, Quantity Takeoff для смет.
• Property Mapping / IFC Mapping: проверьте, как ваши внутренние параметры маппятся в IFC Psets. Потеря классификации и свойств при экспорте — типичная проблема.
• COBie (если требует заказчик/эксплуататор): формируется не в конце, а настраивается параллельно с моделированием. Требует строгой иерархии: Facility → Floor → Space → Zone → Component → Type → System.
• Проверка качества IFC: используйте валидаторы (buildingSMART IFC Validator, Solibri, BIMvision) перед каждой передачей. Не считайте, что «экспортировалось — значит нормально».

099. Типичные ошибки на старте и как их избежать

Подключить классификатор в шаблоне, сделать обязательные поля в семействах

Ошибка	Последствие	Правильная альтернатива
Начали моделировать без согласованной системы координат и отметки ±0,000	Модели не стыкуются, рельеф «плывёт», привязка к кадастру ломается	Зафиксировать Survey Point, Project Base Point, True North в BEP до первого моделирования
Все моделируют в одном файле без рабочих наборов	Конфликты сохранения, невозможно изолировать изменения, файл «раздувается»	Внедрить worksharing / Teamwork с первого дня, даже если команда из 2 человек
Именование «как удобно»: «Стена 1», «Copy of Стена», «New Level»	Невозможно автоматизировать спецификации, экспорт IFC, поиск элементов	Утвердить Naming Convention в BEP, внедрить в шаблон проекта (Template)
LOD не определён, все моделируют «по максимуму» или «по минимуму»	Переработки на ранних этапах или недоделки на стадии П/Р	Таблица LOD/LOIN по этапам и категориям элементов в BEP
Классификация и параметры «добавим потом»	Ретрофит параметров стоит в 10–20 раз дороже, чем закладка на старте
Нет процедуры обновления связанных файлов (Reload Latest)	Координируются со вчерашней версией, коллизии пропускаются	Ежедневное обновление связей по расписанию, ответственный за публикацию
Отверстия под инженерку не моделируются или моделируются «на глаз»	Проемы не совпадают с трассами, арматура режется на стройке	Семейство отверстия с параметрами системы, владение инженером, утверждение архитектором

1010. Чек-лист запуска BIM-проекта (Zero Stage)

Перед тем как отдать шаблон команде, пройдитесь по этому списку. Если хотя бы один пункт «нет» — проект стартует с риском.

1. Утверждён BEP (BIM Execution Plan) с разделом «Структура модели и стандарты».
2. Создан файл-база координат (Shared Coordinates / Site Model) с зафиксированными Survey Point, Project Base Point, True North, уровнем ±0,000.
3. Подготовлены шаблоны проектов (.rte, .tpl, .tsc) для каждой дисциплины с загруженными: рабочими наборами, системами именования уровней, видами-образцами, таблицами параметров, классификаторами.
4. Настроена файловая структура в CDE (папки WIP / Shared / Published / Archive) с правами доступа по ролям.
5. Определена таблица LOD/LOIN по этапам и категориям элементов (стены, перекрытия, колонны, оборудование, сети).
6. Подключён классификатор (Uniclass / локальный) и созданы общие параметры (Shared Parameters) для COBie / заказнических требований.
7. Настроен экспорт IFC (MVD, Property Mapping) и пройдена тестовая валидация на пустой модели.
8. Созданы координационные 3D-виды и настроены правила проверки коллизий (Clash Detection Matrix: какие дисциплины проверяются друг против друга).
9. Регламентирован BCF-процесс: инструмент, статусы, сроки, ответственные.
10. Проведено вводное обучение команды по шаблону, именованию, процессу синхронизации и публикации.

1111. Сценарии: как адаптировать структуру под условия

Сценарий А: Малый объект (до 3000 м²), команда 3–5 человек, один этап П+Р

• Файлы: AR.rvt, KR.rvt, OV_VK.rvt, EOM.rvt + Coord.rvt (связи).
• Рабочие наборы: по 3–5 на дисциплину (Конструктив, Ограждения, Отделка, Мебель/Оборудование).
• LOD: единый для всего проекта (300/350), без поэтапного деления.
• Классификация: упрощённая (Uniclass Table Pr_Products только для оборудования).
• Координация: еженедельные совместные совещания в Navisworks / BIMcollab, без сложного BCF-трекера.

Сценарий Б: Крупный объект (от 50 000 м²), много подрядчиков, поэтапная сдача, требование FM

• Файлы: разделение по секциям/этажам внутри дисциплин + мастер-файл координации. Отдельные файлы для рельефа, ограждения участка, внешних сетей.
• Рабочие наборы: гранулярные (по системным семействам: AR_Стены_Наружные, AR_Стены_Внутренние, OV_Вент_Приточные, OV_Вент_Вытяжные).
• LOD: поэтапная таблица с переходом 300 → 350 → 400 → 500.
• Классификация: полная Uniclass 2015 (Pr, Ss, EF, Z) + маппинг на заказничный классификатор для FM (например, COBie + CAFM ID).
• Координация: автоматические ночные проверки в Solibri, BCF в BIM 360 Issues / BIMcollab, еженедельный Clash Report.
• Данные для FM: выделенный этап As-Built моделирования с полем AssetID на каждом экземпляре оборудования.

Сценарий В: Реконструкция / реновация с лазерным сканированием

• Файл-база: облако точек (RCP/RCS) + модель существующего здания (Existing) как отдельная дисциплина.
• Фазирование (Phasing): обязательно. Демолируемые, существующие, новые элементы — разные фазы, разные фильтры видов.
• Точность LOD для Existing: 200–300 (геометрия по облаку), для New — по стандартной таблице.
• Координация: проверка коллизий новых систем с существующими конструкциями (балки, колонны, фундаменты) — приоритет №1.

1212. Следующие шаги после настройки структуры

Структура заложена — это 20% работы. Остальные 80% — это дисциплина исполнения.

1. Еженедельный аудит модели (Model Health Check): размер файла, количество предупреждений (Warnings), неиспользуемые семейства, дубликаты типоразмеров, потерянные связи. Назначьте ответственного (BIM-координатор).
2. Контроль именования: скрипт (Dynamo / PyRevit / C# Add-in), который раз в неделю сканирует проект и выдаёт отчёт по нарушениям Naming Convention.
3. Обновление BEP: BEP — живой документ. Любое изменение структуры (новый рабочий набор, изменение классификатора, новый LOD) фиксируется в BEP с версией и датой.
4. Передача этапа (Data Drop): за 2 недели до сдачи формируйте пакет: нативные файлы + IFC (проверенные) + COBie (если нужно) + отчёт по коллизиям + матрица LOD/LOIN + выписка из BEP. Не собирайте это за ночь.

13Резюме: главное, что нужно запомнить

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

Начните с BEP и шаблона. Не моделируйте в пустом файле. Задайте правила до первой стены — и вся дальнейшая работа пойдёт по рельсам, а не в огнеметную переделку.

Материал носит информационный характер и отражает общие инженерные практики управления BIM-проектами. Конкретные требования к структуре модели, классификаторам, форматам обмена и этапам детализации определяются БИМ-планом проекта (BEP), техническим заданием заказчика, условиями контракта и применимыми стандартами (ISO 19650, ГОСТ Р ИСО 19650, ПОДС). Перед применением рекомендаций на реальном проекте согласуйте их с BIM-менеджером проекта, ГИП и заказчиком.