Основные правила обмена данными

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

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

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

Связанные данные должны быть доступны для обмена.

Данные должны быть проверены и очищены от информации, не требуемой для обмена.

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

Рекомендации по организации структуры проекта

Принципы разделения модели

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

При организации структуры данных в составе моделей следует учитывать:

- структуру разделов проектной документации или комплектов марок чертежей рабочей документации;

- вид объекта строительства;

- географическую удаленность, количество и состав проектных групп;

- особенности реализации конкретного программного обеспечения по обеспечению коллективного доступа к данным модели(ей);

- производительность компьютеров;

- требования информационной безопасности.

Базовый принцип разделения: при разработке BIM-моделей рекомендуется соблюдать структуру проекта, ориентированную на системы и специальности.

Структура проекта должна учитывать все разрабатываемые в BIM разделы проекта, например, как в таблице 5-3.

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

Например, для поиска коллизий в Navisworks будет необходимо указать, между какими системами искать коллизии, и если они все будут находиться в одном файле, то потребуется дополнительное время на поиск слоев этих систем внутри подгруженного файла.

Таблица 5‑3. Пример разделения модели

Дисциплина (раздел проекта)	Принципы разделения
Автомобильные дороги	Разделение по участкам (километражу, пикетам) и отдельно переходы/развязки
Инженерные сети	Разделение по системам (типам сетей)
Искусственные сооружения	Разделение по конструктивным элементам или для комплексных объектов (мостовых переходов), на составные части (эстакады, русловая часть моста и т. п.)
Генеральный план	Разделение на зоны, типы покрытий в виде отдельных поверхностей

 

Главным инструментом управления разделения моделей в Civil 3D является инструмент быстрых ссылок на данные.

Разделение моделей ИССО и вспомогательных объектов в Revit рекомендуется на основе принципов, описанных в «BIM-СТАНДАРТ ОРГАНИЗАЦИИ для площадных объектов (Revit и Civil 3D). ШАБЛОН. Версия 2.0» разделы 5.1 и 5.8.4.

Файл модели должен содержать данные только одной дисциплины. В одном файле не должно быть больше одной проектной дисциплины, но допускается наличие других дисциплин через быстрые ссылки на данные.

В зависимости от размеров объекта может потребоваться дальнейшее разделение геометрии, чтобы файлы модели оставались работоспособными на используемых аппаратных средствах. В частности, коридоры Civil 3D требуют разделения из-за своей ресурсоемкости.

В ходе выполнения проекта владение элементами может передаваться между участниками через быстрые ссылки на данные. Процедура передачи элементов должна быть четко определена в Плане реализации BIM-проекта.

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

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

Модели могут создаваться как объекты, передаваемые другим участникам проекта через инструменты быстрых ссылок на данные Civil 3D, которые впоследствии будут разделены на ссылки между участниками проекта.

Все модели и их части необходимо именовать согласно правилам именования.

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

Процедура синхронизации должна быть описана в Плане реализации BIM-проекта.

Рекомендации по организации структуры папок проекта

Для организации структуры папок в рабочей области среды общих данных необходимо учитывать рекомендации раздела 5.8.2.

Работа в среде общих данных подразумевается в виде структуры папок.

В случае если количество символов в длине адреса расположения файла будет превышать максимально допустимое в операционной системе, то рекомендуется использовать только цифровое именование папок.

Таблица 5-4. Пример общей структуры папок

010_Общие	Папка с регламентами и стандартами работы над проектом
020_Исходные данные	Исходные данные для работы по проекту
021_Библиотеки	Библиотеки используемых элементов
022_Шаблоны	Шаблоны используемых документов
023_ТУ	Технические условия
030_В работе	Папка, в которой находятся рабочие файлы, не предназначенные для общего доступа (варианты проектных решений, незавершенные документы)
040_Общий доступ	В данной папке размещаются документы, проверенные ведущими специалистами по направлениям и предназначенные для совместного использования в проекте
050_Опубликовано	Официально переданная заказчику проектная документация
060_Архив	Проектная продукция, прошедшая экспертизу и предназначенная для передачи на следующий этап (для разработки РД или эксплуатации)

 

Правила именования файлов

Именование файлов, содержащих элементы модели, должны однозначно идентифицировать принадлежность модели/чертежа/документа к части раздела проекта. Использование кодов для обозначения документов и файлов систематизирует процесс управления, контроля, отчетности в рамках всего BIM-проекта.

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

Требования к символам

От названия зависит упорядоченность содержания папки проекта, возможность быстрого поиска, унификация структуры проекта. Название файла должно содержать своеобразные «теги», функциональные блоки, несущие определенную информацию о файле - имя проекта, версию, наименование раздела, статус документа.

В качестве знака-разделителя между полями рекомендуется использовать знак «подчеркивание» («_»).

Все поля в имени файла начинаются с заглавной (прописной) буквы, за которой следуют строчные. Если поле состоит из двух и более слов, то каждое слово начинается с заглавной буквы и все слова пишутся слитно.

Аббревиатуры и коды следует писать заглавными буквами.

Запрещается использовать в названиях следующие знаки и символы:

,.! “ £ $ % ^ & * () { }[ ] + = < >? | \ / @ ’ ~ # ` ‘

 

Именование файлов проекта

Состав полей имени файла:

<Поле1> _<Поле2> _<Поле3> _<Поле4> _<Поле5> _<Поле6> (Статус)

Поле 1: Шифр проекта. 

Поле 2: Раздел проекта

Поле 3: Подраздел проекта.

Поле 4: Описание.

Поле, описывающее тип данных, представленных в файле,

Поле 5: Версия программного обеспечения. Применить согласно Таблица 5-5.

Таблица 5-5. Аббревиатуры программного обеспечения

Код	Описание
RY	Revit 202Y
N2Y	Navisworks 202Y
IF3	IFC формата 2х3
IF4	IFC формата IFC4
AC2Y	ArchiCAD 2Y
AA2Y	AutoCAD 202Y
T2Y	Tekla 202Y
RG	Renga
C2Y	Civil 3D 202Y

Примечание: вместо буквы Y следует вводить цифру, соответствующую году

версии программного обеспечения. Например, код R0 соответствует Autodesk

Revit 2020. Предпочтение следует отдавать актуальным версиям

программного обеспечения.

Примеры именования файлов модели:

1234_ТКР_ГП_Генплан_С21;

1234_ТКР_АД_Основной ход_С21

1234_ТКР_ПЖ_Путь железнодорожный_С21.

6. Документ «Информационные требования заказчика»

На этапе формирования конкурсной документации заказчик формирует техническое задание (ТЗ) на проектирование или разработку рабочей документации (в зависимости от этапа/фазы проекта). Помимо стандартных требований к проектируемому объекту (ТЗ), заказчик разрабатывает Информационные требования заказчика (Employer’s Information Requirements – EIR [2.28]). Информационные требования, с одной стороны, будут дополнять ТЗ, отвечая за информационное моделирование проектируемого объекта, а с другой, будут описывать требования к процессам информационного моделирования и взаимодействия как внутри команды проекта, так и с заказчиком. Информационные требования заказчика особенно актуальны при наличии внешних субподрядчиков при работе над проектом, в противном случае может быть достаточно требований BIM стандарта компании.

6.1 Состав и содержание требований заказчика

Ниже приводится рекомендуемый список разделов Информационных требований заказчика:

· цели, задачи и способы использования BIM-моделей на различных стадиях жизненного цикла;

· этапы работ и контрольные точки выдачи информации;

· требования к применяемым нормативным документам по информационному моделированию;

· требования к составу BIM-моделей и объемам моделирования;

· требования к обеспечению единого координатного пространства;

· требования к уровням проработки элементов BIM-моделей;

· требования к составу и форматам выдачи результатов проекта;

· требования к именованию файлов;

· требования к качеству BIM-моделей;

· требования к среде общих данных;

· требования к предоставлению ключевых метрик проекта;

· требования к квалификации исполнителей и наличию лицензионного ПО;

· прочие требования.