3.4 Структура файлов проекта

Требования к среде общих данных (CDE)

Перед началом моделирования необходимо организовать и согласовать с Заказчиком среду общих данных (CDE) для совместной работы и обмена информацией.

Пример организации CDE, применяемой в Development Systems, представлена в разделе «Среда общих данных (CDE)».

Настройка файлов проекта

Предварительную настройку файла проекта производит BIM-отдел в лице BPM, координирующего разработку раздела.

До начала работ по оформлению документации в обязательном порядке должны быть утверждены (для рабочей и проектной документации) основная надпись (штамп), включая шифр, адрес и название объекта, позиции разработчиков, проверяющего, нормконтроллера и т.д.

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

Структура файлов проекта

В настоящем разделе представлены принципы разделения модели с целью обеспечения:

• многопользовательского доступа;
• оперативной эффективности;
• взаимодействия.

Условный перечень файлов проекта и взаимодействие с ними представлены на рисунке ниже (уточняется под каждый проект более детально).

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

Базовые принципы разделения моделей для архитектурных и объёмно-планировочных решений

• рекомендуемый принцип разделения – «1 секция = 1 модель». Объединение здания с несколькими секциями в единую модель определяется, исходя из прогноза конечного веса файлов (после разработки РД и ДП МОП). Укрупнение сборки возможно по согласованию с Заказчиком и исходя из опыта применения BIM-технологий в компании;
• рекомендуемая площадь корпуса не более 1000 м², объем корпуса не более 10800 м³, вес файла не более 400 мб.
• встроенно-пристроенный паркинг выделяется в отдельную модель при площади более 3000 м2;
• при разделении крупных зданий на модели, а также разделении зданий с примыкающим подземным паркингом, рекомендуется выполнить разделение по деформационному шву;
• в случае более мелкого разделения в рамках одного раздела требуется создать сводную модель;
• фактический перечень моделей определяется в BEP.

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

Для объектов паркинга или других нежилых сооружений принять следующие рекомендательные характеристики:

• площадь корпуса не более 2000 м2;
• объем корпуса не более 500 м3;
• вес файла не более 400 мб;

Базовые принципы разделения моделей в рамках разделов Генерального Плана

• рекомендуемый принцип разделения – по типу объектов (рельеф, МАФ, озеленение);
• рекомендуемый принцип работы – использование быстрых и внешних ссылок;
• доступна совместная работа и передача информации другим разделам;
• фактический перечень моделей определяется в BEP.

Базовые принципы разделения моделей в рамках разделов, содержащих сведения об инженерном оборудовании и сетях инженерно-технического обеспечения

• основной принцип разделения – «1 раздел (подраздел / дисциплина) = 1 модель». Решение о разделении единой модели на несколько секций определяется, исходя из прогноза конечного веса файлов (после разработки РД). Рекомендуемый вес файлов – не более 300 Мб; укрупнение сборки возможно по согласованию с Заказчиком;
• в целях координации для инженерных разделов следует создавать отдельную сводную модель, содержащую ссылки на все дочерние модели. При этом рекомендуемый тип связи внешних ссылок – прикрепление;
• фактический перечень моделей определяется в BEP.

Базовые принципы сборки

• В файле-сборке следует создавать количество рабочих наборов, равное количеству подгруженных ссылок для возможности гибкого управления внешними файлами. Допускается объединять модели одного раздела в один рабочий набор.
• При количестве моделей более четырёх в каждом разделе необходимо создавать сборки отдельно для каждого раздела, а затем формировать общий файл-сборку.
• Следует избегать вложенных сборок и создавать общую с типом связи внешних ссылок – наложение.

Дублирование элементов в различных разделах документации

Дублирование элементов в различных разделах документации не допускается, кроме следующих случаев:

• на старте проекта – при выдаче задания конструкторам из архитектурной модели – дублирование несущих конструкций (несущие стены, колонны, перекрытия), а также лестниц и некоторых других в архитектурном и конструктивном разделах. В ВЕР подробно описывается логика взаимосвязи моделей разных разделов. В конструктивном разделе элементы указываются как несущие, в архитектурном – как архитектурные. Все дублирующиеся элементы модели разделяются по соответствующим рабочим наборам. Например, если элементы конструкции находятся в модели архитектуры, то в этом случае все элементы конструкции объединяются в рабочие наборы по функциональному назначению. После согласования несущих конструкций, дублирующиеся элементы в модели АР удаляются. Подробнее о Рабочих наборах – смотри раздел «Рабочие наборы»;
• на начальных этапах проектирования допускается дублирование оконечного инженерного оборудования в разделах АР и АИ. Дублирующиеся элементы модели разделяются по соответствующим рабочим наборам;
• также допускается дублирование оборудования ОВ/ВК в моделях разделов ЭОМ/СС (при моделировании разделов ЭОМ/СС). При этом необходимо проконтролировать исключение данного оборудования из спецификаций моделей ЭОМ/CC;
• в моделях назначаются кодификаторы элементов. Если элементы дублируются в моделях различных разделов, то их «вспомогательному» дубликату присваивается значение кодификатора «999»;
• иные отступления выполняются по согласованию с Заказчиком и фиксируются в BEP.

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