СП 328.1325800.2017. Свод правил. Информационное моделирование в строительстве. Правила описания компонентов информационной модели

(утв. Приказом Минстроя России от 15.12.2017 № 1674/пр)

ИСТОРИЯ ИЗМЕНЕНИЙ НОРМАТИВНО-ТЕХНИЧЕСКИХ АКТОВ

flowchart LR
  n0["СП 328.1325800.2017"]:::rst
  click n0 "https://bukva.ai/docs/sp-svod-pravil-sp-328-1325800-2017" "СП 328.1325800.2017. Свод правил. Информационное моделирование в строительстве. Правила описания компонентов информационной модели (утв. Приказом Минстроя России от 15.12.2017 N 16"
  n1["СП 328.1325800.2020"]:::doc
  click n1 "https://bukva.ai/docs/sp-svod-pravil-sp-328-1325800-2020" "СП 328.1325800.2020. Свод правил. Информационное моделирование в строительстве. Правила описания компонентов информационной модели (утв. и введен в действие Приказом Минстроя Росси"
  n0 --> n1
classDef rst fill:#FFEBEB,stroke:#8B0000,color:#000;
classDef doc fill:#EBFFEB,stroke:#006400,color:#000;
classDef notEnt fill:#FFFFEB,stroke:#FF8C00,color:#000;

СВОД ПРАВИЛ

ИНФОРМАЦИОННОЕ МОДЕЛИРОВАНИЕ В СТРОИТЕЛЬСТВЕ. ПРАВИЛА ОПИСАНИЯ КОМПОНЕНТОВ ИНФОРМАЦИОННОЙ МОДЕЛИ

Building information modeling. Components. Guidelines and requirements

СП 328.1325800.2017

Дата введения 16 июня 2018 года

Предисловие

Сведения о своде правил

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 465 «Строительство»

3 ПОДГОТОВЛЕН к утверждению Департаментом градостроительной деятельности и архитектуры Министерства строительства и жилищно-коммунального хозяйства Российской Федерации (Минстрой России)

4 УТВЕРЖДЕН Приказом Министерства строительства и жилищно-коммунального хозяйства Российской Федерации от 15 декабря 2017 г. № 1674/пр и введен в действие с 16 июня 2018 г.

5 ЗАРЕГИСТРИРОВАН Федеральным агентством по техническому регулированию и метрологии (Росстандарт)

6 ВВЕДЕН ВПЕРВЫЕ

В случае пересмотра (замены) или отмены настоящего свода правил соответствующее уведомление будет опубликовано в установленном порядке. Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте разработчика (Минстрой России) в сети Интернет.

Введение

Настоящий свод правил разработан в соответствии с Федеральным законом от 30 декабря 2009 г. № 384-ФЗ «Технический регламент о безопасности зданий и сооружений» в целях выработки единых требований, правил и рекомендаций по созданию компонентов, используемых для формирования информационных моделей объекта строительства.

Свод правил подготовлен авторским коллективом АО «НИЦ „Строительство“ — ЦНИИСК им. В.А. Кучеренко (руководитель работы — д-р техн. наук И.И. Ведяков; канд. техн. наук Ю.Н. Жук, А.В. Ананьев) и ООО „КОНКУРАТОР“ (М.Г. Король, С.Э. Бенклян).»

1. Область применения

1.1 Настоящий свод правил распространяется на процессы информационного моделирования зданий и сооружений и устанавливает требования к компонентам их информационных моделей.

1.2 Настоящий свод правил не устанавливает требований к способам размещения, ведения, структуре, форме и содержанию цифровых библиотек (каталогов/баз) компонентов.

2. Нормативные ссылки

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

ГОСТ 2.303-68 Единая система конструкторской документации. Линии

ГОСТ 2.306-68 Единая система конструкторской документации. Обозначения графические материалов и правила их нанесения на чертежах

Примечание - При использовании настоящим сводом правил целесообразно проверить действие ссылочных документов в информационной системе общего пользования — на официальном сайте федерального органа исполнительной власти в сфере стандартизации в сети Интернет или по ежегодному информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя «Национальные стандарты» за текущий год. Если заменен ссылочный документ, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого документа с учетом всех внесенных в данную версию изменений. Если заменен ссылочный документ, на который дана датированная ссылка, то рекомендуется использовать версию этого документа с указанным выше годом утверждения (принятия). Если после утверждения настоящего свода правил в ссылочный документ, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный документ отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку. Сведения о действии сводов правил целесообразно проверить в Федеральном информационном фонде стандартов.

3. Термины и определения

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

3.1 атрибуты компонента: Существенные свойства компонента, необходимые для определения его геометрии или характеристик и имеющие имя и значение.

3.2 геометрические параметры компонента: Атрибуты, которые определяют размер, форму и пространственное положение компонента.

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

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

3.5 компонент: Цифровое представление физических и функциональных характеристик отдельного элемента объекта строительства, предназначенное для многократного использования.

Примечание - Компонент, примененный в модели, становится элементом модели.

3.6 метаданные компонента: Структурированные данные, представляющие собой характеристики описываемого компонента для идентификации, поиска, оценки и управления им.

3.7 открытые форматы обмена данными: Форматы данных с открытой спецификацией.

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

3.8 сборка: Именованный набор компонентов, предназначенный для многократного использования.

3.9 уровень проработки; LOD: Набор требований, определяющий полноту проработки элемента цифровой информационной модели. Уровень проработки задает минимальный объем геометрических, пространственных, количественных, а также любых атрибутивных данных, необходимых для решения задач информационного моделирования на конкретной стадии жизненного цикла объекта.

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

3.11 цифровая информационная модель: Объектно-ориентированная параметрическая трехмерная модель, представляющая в цифровом виде физические, функциональные и прочие характеристики объекта (или его отдельных частей) в виде совокупности информационно насыщенных элементов.

3.12 элемент модели: Часть цифровой информационной модели, представляющая элемент, систему или сборку в пределах объекта строительства или строительной площадки.

4. Общие положения

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

4.2 Компоненты следует разделять:

По типам:

• точечные — компоненты с заданными геометрическими формами, добавляемыми в модель с привязкой к своей точке вставки.

Примечание - Такие компоненты как окно, дверь, балка, колонна, насос, мебель и т.п.;

• линейные — получаемые посредством соединения направленного замкнутого профиля и линии привязки как образующей.

Примечание - Такие компоненты как стены, трубы, воздуховоды, кабельные короба и т.п.;

• площадные — объемные компоненты, значительно меньшей высоты, создаваемые путем отрисовки контура ограниченной площади.

Примечание - Такие компоненты как перекрытия, крыши, потолки и т.п.;

По привязке к производителю:

• обобщенный — компонент является цифровым представлением продукции, конкретный производитель которой неизвестен;
• продукт — компонент является цифровым представлением продукции конкретного производителя.

По уровню параметризации:

• параметрические компоненты — компоненты, размещаемые экземпляры которых можно конфигурировать изменением значений атрибутов в интерфейсе программного обеспечения (без необходимости непосредственного редактирования компонента);
• непараметрические компоненты — компоненты, которые созданы без возможности их конфигурации.

По сфере применения:

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

5. Общие требования к компонентам

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

5.2 При разработке компонентов следует:

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

6. Требования к геометрическим параметрам, уровням геометрической проработки и графическому отображению компонентов

6.1 Требования к геометрическим параметрам и графическому отображению компонента включают в себя требования к:

• геометрическим параметрам;
• отображению графических обозначений;
• уровню геометрической проработки;
• резервированию пространства, занимаемого компонентом;
• графическому отображению материалов.

6.2 Требования к геометрическим параметрам

6.2.1 При разработке компонента следует:

• моделировать геометрию в масштабе 1:1;
• определять точку вставки (базовую точку) для компонента типа «точечный»;
• использовать минимальное число вспомогательных элементов (например, вспомогательных плоскостей и линий);
• использовать геометрические параметры, выраженные в метрической системе единиц.

6.2.2 Компоненты типа «обобщенный» должны включать в себя значения параметров, определяющие номинальные размеры, если фактические размеры неизвестны.

6.2.3 Компоненты типа «продукт» должны включать в себя значения параметров, определяющие точные размеры.

6.2.4 Требование к отображению графических обозначений:

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

6.3 Требования к уровню геометрической проработки

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

6.3.2 Рекомендации по назначению уровня геометрической проработки компонентов приведены в А.5 - А.8 (приложение А).

6.4 Требования к графическому отображению материалов

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

6.4.2 Требования к файлу с изображением материала:

• размер изображений квадратной формы — не менее 512 x 512 пикселей;
• размер изображений прямоугольной формы — не менее 512 пикселей по самой длинной стороне;
• разрешение изображения — не менее 150 точек на дюйм.

7. Требования к уровню атрибутивной проработки и значениям атрибутов

7.1 При разработке компонентов число, состав атрибутов и уровень атрибутивной проработки следует определять с учетом:

• целей и задач применения цифровых информационных моделей;
• требований к LOD;
• требований к составу и содержанию технической документации.

7.2 Все созданные атрибуты компонента должны быть заполнены.

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

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

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

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

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

7.6 Значение текстового атрибута компонента не должно заканчиваться точкой.

8. Функциональные требования к компонентам

8.1 Компонент должен «вести себя» таким образом, чтобы отражались его функциональное назначение и взаимосвязи с другими компонентами.

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

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

9. Правила именования компонентов и их атрибутов

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

9.2 Система именования должна состоять из:

• общих правил именований;
• схем именований.

Примечание — Пример системы именования файлов компонентов приведен в А.15 - А.16 (приложение А).

9.3 У компонента должно быть уникальное имя и описание.

9.4 Правила именования атрибутов

9.4.1 Единицы измерения в названии атрибута не указываются.

9.4.2 Атрибуты со значениями, предполагающими логические типы данных (Да/Нет), должны именоваться так, чтобы значение обязательно было присвоено (например, «Наличие Подоконника» — Да/Нет).

Примечание — Пример правил именования атрибутов приведен в А.17 (приложение А).

9.5 Правила именования материалов

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

9.5.2 Файлу с изображением материала имя присваивается таким же образом, как и материалу, с расширением, соответствующим формату применяемого графического файла.

Примечание — Пример правил именования материалов приведен в А.18 (приложение А).

10. Требования к форматам компонентов

10.1 По форматам файлов компоненты могут быть представлены:

• в открытом формате IFC (версии 2 x 3 и выше);
• в исходных форматах (форматы файлов компонентов и файлов проекта применяемого программного обеспечения).

11. Требования к метаданным компонентов

11.1 При организации баз/каталогов/библиотек компонентов, например, в виде интернет-хранилищ, необходимо обеспечивать удобный поиск необходимого контента. Как правило, такой поиск осуществляется по метаданным. Поиск по метаданным — поиск по атрибутам компонента, поддерживаемым конкретной поисковой системой.

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

Приложение А

РЕКОМЕНДАЦИИ ПО РАЗРАБОТКЕ КОМПОНЕНТОВ

А.1 Компоненты могут объединяться в сборки (например, «сантехкабина», «тепловой узел», «трансформаторная подстанция»), которые рекомендуется применять для формирования тематических каталогов/баз/библиотек повторного применения.

А.2 Компонент должен быть однозначно идентифицирован. Для этого рекомендуется использовать:

• глобальный уникальный идентификатор, который применяется для идентификации ресурсов;

А.3 Для минимизации числа разрабатываемых компонентов и их унификации рекомендуется создавать параметрические компоненты.

А.4 Рекомендации к отображению графических обозначений:

• для соответствия требованиям стандартов ЕСКД и СПДС (например, ГОСТ 2.303 и ГОСТ 2.306), предъявляемым к оформлению проектной и рабочей документации, при разработке компонента рекомендуется включать в его состав условные графические обозначения.

А.5 Для разработки компонентов рекомендуется применять три уровня геометрической проработки:

• LOD 200;
• LOD 300;
• LOD 400.

Примечание - Компоненты на уровне проработки LOD 100 представляют собой концептуальные формообразующие элементы и как таковые не нуждаются в предварительной подготовке соответствующих компонентов, а на уровне LOD 500 — полностью определенные компоненты, которые отличаются от уровня LOD 400 только размерами, которые соответствуют фактическому исполнению проектных решений. По этим причинам для разработки баз/библиотек/каталогов компонентов рекомендуются уровни проработки LOD 200, 300 и 400.

А.6 Компоненты типа «обобщенный» рекомендуется представлять на уровнях проработки LOD 200 и LOD 300.

А.7 Компоненты типа «продукт» рекомендуется представлять на уровне проработки LOD 400.

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

А.8 Компоненты инженерного/технологического оборудования рекомендуется разрабатывать с учетом резервирования пространства для обслуживания, которое рекомендуется включать как часть компонента.

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

А.10 В компонентах типа «продукт» рекомендуется применять материалы с определенными свойствами.

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

А.12 Значение атрибута компонента может быть выражено в виде формулы — в случае, если его значение зависит от других атрибутов.

А.13 Если компонент может представлять различные варианты элемента объекта строительства, рекомендуется представлять их с помощью атрибута со значением, выраженным одним из следующих способов:

• единственное значение — если для значения существует единственный вариант выбора;
• списочное значение — если в упорядоченном списке есть несколько уникальных значений одного типа, порядок которых важен (например, 200, 400, 600, 800);
• диапазонное значение — если существуют верхняя и нижняя границы этого значения (предел). Сначала указывается нижний предел, а затем верхний (например, 175 — 200 кВт). В случае, если в диапазон значений входят положительные и отрицательные значения, они разделяются с помощью слов «от» и «до» (например, от минус 10 °C до плюс 20 °C). Если значение не указано, это означает неограниченный предел (например, 175 кВт — <ноль>, т.е. все значения выше или равны нижнему предельному значению 175 кВт);
• нумерованное значение — если для значения предусмотрен выбор фиксированных значений из установленного перечня. Отдельные элементы должны отделяться друг от друга запятой и пробелом (например, a, b, c, d).

Примечание - Данные способы выражения различных вариантов элементов объекта строительства, как правило, применяются в компонентах типа «обобщенный».

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

А.15 При именовании файлов компонентов рекомендуется применять следующие общие правила:

• имя файла состоит из полей;
• в качестве знака-разделителя между полями рекомендуется использовать знак подчеркивания «_»;
• в имени файла не рекомендуется применять пробелы;
• все поля в имени файла начинаются с заглавной буквы, за которой следуют строчные. Если поле состоит из двух и более слов, то каждое слово начинается с заглавной буквы и все слова пишутся слитно;
• аббревиатуры и коды следует писать заглавными буквами;
• не рекомендуется применять в названиях файлов следующие знаки и символы: , ! $ % & ( ) { }[ ] + = @ ~ # '

А.16 Структура имен файлов компонентов

• Для именования файлов компонентов рекомендуется применять следующую схему:

<Поле1><Поле2><Поле3><Поле4><Поле5>_<Поле6>

где поля имеют приведенные в таблице А.1 значения.

Таблица А.1

Если компонент не содержит трехмерной геометрии, в конце «Поля2» (функциональный тип), следует добавить «-2D».

Примечания

1 Число полей в имени файла может варьироваться от четырех до шести в зависимости от типа компонента (тип «обобщенный» или «продукт»), а также наличия дополнительных идентификационных признаков.

2 Пример именования компонентов типа «обобщенный»:

АБВ_Дверь_Двупольная_Алюминиевая_ГОСТ23747-2015

3 Пример именования компонентов типа «продукт»:

АБВ_Умывальник_Керамический_Завод1_ИсполнениеА

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

А.17 Правила именования атрибутов

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

<Поле1>_<Поле2>

Таблица А.2

Примечание - Примеры именования атрибутов:

Длина

ПрофильШирина

А.18 Для именования материалов рекомендуется использовать следующую схему:

где поля имеют следующие значения, приведенные в таблице А.3

Таблица А.3