graphisoft · 2019-12-15 · Önorm, statsbygg bim manual, singapore bim guide, опыт...
TRANSCRIPT
GRAPHISOFT
ТИМ (BIM) стандарт
версия 1.0
2
СОДЕРЖАНИЕ
ПРЕДИСЛОВИЕ .................................................................................................................................... 5
1. ВВЕДЕНИЕ ........................................................................................................................................ 6
1.01. СФЕРА ПРИМЕНЕНИЯ ............................................................................................................ 6 1.01.1 Основные цели стандарта ......................................................................................... 7
1.02. ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ ............................................................................................ 8 1.03. ПРОЦЕДУРА ОБНОВЛЕНИЯ .................................................................................................. 9 1.04. ПОЛЕЗНЫЕ ССЫЛКИ............................................................................................................. 10 1.05. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ ............................................................................................... 11
1.05.1 Основные термины и определения .......................................................................... 11 1.05.2 Общие технические термины .................................................................................. 13 1.05.3 Термины и определения среды ARCHICAD ............................................................. 14
1.06. РАСПРОСТРАНЕНИЕ ............................................................................................................ 16
2. ОБЩИЕ СВЕДЕНИЯ ....................................................................................................................... 17
2.01. УРОВНИ «ЗРЕЛОСТИ» BIM................................................................................................... 17 2.02.1 Диаграмма Бью-Ричардса .......................................................................................... 17 2.02.2 Возможности BIM-модели на Уровне 2 ................................................................... 18
2.03. РОЛЬ BIM-МЕНЕДЖМЕНТА .................................................................................................. 20
3. ВНЕДРЕНИЕ BIM ............................................................................................................................ 21
3.01. ПЛАНИРОВАНИЕ ВНЕДРЕНИЯ ............................................................................................ 21 3.02. РЕГЛАМЕНТАЦИОННЫЕ И ИСПОЛНИТЕЛЬНЫЕ ДОКУМЕНТЫ ...................................... 22 3.03. РОЛИ И ОБЯЗАННОСТИ ...................................................................................................... 23
3.03.1 BIM-менеджер (стратегия)............................................................................................ 25 3.03.2 BIM-координатор (тактика/управление) ..................................................................... 25 3.03.3 BIM-моделлер (исполнение) ............................................................................................ 26
3.04. КОММУНИКАЦИЯ ................................................................................................................... 26 3.04.1 Запуск BIM ........................................................................................................................ 26 3.04.2 BIM-совещания ................................................................................................................. 27 3.04.3 Проектные совещания ................................................................................................... 27
3.05. BIM НА ЭТАПАХ ЖИЗНЕННОГО ЦИКЛА ОБЪЕКТА ............................................................ 27
4. СОВМЕСТНАЯ BIM-РАБОТА ........................................................................................................ 29
4.01. СРЕДА ОБЩИХ ДАННЫХ (CDE) ........................................................................................... 29 4.01.1 Рабочий Процесс (WIP – Work In Progress) ................................................................... 30 4.01.2 Общие (SHARED) ............................................................................................................. 30 4.01.3 Опубликованные (PUBLISHED) ...................................................................................... 31 4.01.4 Архив (ARCHIVE) .............................................................................................................. 32
4.02. БЕЗОПАСНОСТЬ И СОХРАННОСТЬ ДАННЫХ ................................................................... 33 4.03. ДОСТУП ДЛЯ НЕ-РАЗРАБОТЧИКОВ ................................................................................... 34
5. ИНТЕРОПЕРАБЕЛЬНОСТЬ .......................................................................................................... 35
5.01. ОБЩИЕ ПРИНЦИПЫ .............................................................................................................. 35 5.02. ЦЕЛЕВОЕ НАЗНАЧЕНИЕ МОДЕЛИ ...................................................................................... 36 5.03. ОБМЕН CAD-ДАННЫМИ ........................................................................................................ 37 5.04. ОБМЕН BIM-ДАННЫМИ ......................................................................................................... 37 5.05. ОБМЕН МЕЖДУ ПРОГРАММНЫМИ ПЛАТФОРМАМИ ....................................................... 38
6. СТРУКТУРА МОДЕЛИ .................................................................................................................... 39
3
6.01. ОБЩИЕ ПРИНЦИПЫ .............................................................................................................. 39 6.01.1 2D- и 3D-разделение ........................................................................................................ 40 6.01.2 Функциональное разделение .......................................................................................... 40
6.02. ВНУТРЕННЕЕ РАЗДЕЛЕНИЕ ................................................................................................ 40 6.03. ВНЕШНИЕ ССЫЛКИ ..................................................................................................................... 41
6.03.1 Двумерные данные – DWG ............................................................................................. 41 6.03.2 Трехмерные данные – IFC .............................................................................................. 42
7. МЕТОДОЛОГИЯ МОДЕЛИРОВАНИЯ........................................................................................... 44
7.01 БАЗОВЫЕ ТРЕБОВАНИЯ ................................................................................................... 44 7.02. УРОВНИ ПРОРАБОТКИ ......................................................................................................... 44 7.03. СОЗДАНИЕ И ДЕТАЛИЗАЦИЯ КОМПОНЕНТОВ ................................................................. 45 7.04. ПРОСТРАНСТВЕННОЕ РАСПОЛОЖЕНИЕ И КООРДИНАЦИЯ ........................................ 46 7.04.1 ОБЩИЕ ПРИНЦИПЫ ПРОСТРАНСТВЕННОЙ КООРДИНАЦИИ.......................................................... 47 7.04.2 СИСТЕМА КООРДИНАТ ЗДАНИЯ (СКЗ) ...................................................................................... 48 7.04.3 ЕДИНАЯ СИСТЕМА КООРДИНАТ ПРОЕКТА (ЕСК) ....................................................................... 49 7.04.4 КОМПЛЕКС СИСТЕМ КООРДИНАТ ПРОЕКТА (КСК) ..................................................................... 50 7.04.5 ДРУГИЕ РЕШЕНИЯ .................................................................................................................... 54 7.04.6 СПЕЦИФИКА ARCHICAD ......................................................................................................... 54 7.05. ЕДИНИЦЫ ИЗМЕРЕНИЯ ....................................................................................................... 54 7.06. ДВУМЕРНАЯ ДЕТАЛИЗАЦИЯ МОДЕЛЕЙ ............................................................................ 55
8. СРЕДА МОДЕЛИРОВАНИЯ .......................................................................................................... 55
8.01. ОБЩАЯ СТРУКТУРА СРЕДЫ ................................................................................................ 55 8.02. СВОЙСТВА ПРОЕКТА ............................................................................................................ 57
Информация о проекте ............................................................................................................. 57 Расположение проекта .............................................................................................................. 58 Настройки проекта (правила расчетов) ................................................................................ 58
8.03. СТРУКТУРА ПРОЕКТА ........................................................................................................... 58 Карта проекта ........................................................................................................................... 58 Карта видов ................................................................................................................................ 58 Книга макетов ............................................................................................................................ 59 Публикатор ................................................................................................................................. 60
8.04. РАБОЧИЕ ИНСТРУМЕНТЫ ................................................................................................... 61 Инструменты ............................................................................................................................. 61 Избранное .................................................................................................................................... 61
8.05. РЕКВИЗИТНАЯ СРЕДА .......................................................................................................... 61 Слои .............................................................................................................................................. 63 Строительные материалы ...................................................................................................... 67 Сложные профили ...................................................................................................................... 68 Композиты .................................................................................................................................. 68 Зоны .............................................................................................................................................. 69 Перья ............................................................................................................................................ 70 Инструменты разметки ........................................................................................................... 70 Графическая среда – наборы слоев, наборы перьев .............................................................. 71
8.06. КОНТЕНТНАЯ СРЕДА ............................................................................................................ 71 Системы классификации .......................................................................................................... 71 Наборы свойств .......................................................................................................................... 73 Предопределенные правила ...................................................................................................... 73
8.07. БИБЛИОТЕКИ И КОМПОНЕНТЫ .......................................................................................... 73 8.08. ГРАФИЧЕСКИЕ НАСТРОЙКИ................................................................................................ 74
Модельные виды ......................................................................................................................... 74 Масштаб...................................................................................................................................... 75 Статусы реконструкции .......................................................................................................... 75
4
Графическая замена ................................................................................................................... 75 Текст и Аннотирование ............................................................................................................ 75
8.09. ИНТЕРОПЕРАБЕЛЬНОСТЬ И ВЗАИМОДЕЙСТВИЕ ........................................................... 76 Фильтры модели ........................................................................................................................ 76 IFC Схема проекта ..................................................................................................................... 77
9. ОБЕСПЕЧЕНИЕ КАЧЕСТВА ......................................................................................................... 78
9.01. КОНТРОЛЬ И ОБЕСПЕЧЕНИЕ КАЧЕСТВА .......................................................................... 78 9.02. КОНТРОЛЬНЫЕ СПИСКИ ПРОВЕРКИ ................................................................................. 80
10. ПРИЛОЖЕНИЯ .............................................................................................................................. 83
10.01. ПРИМЕР НАИМЕНОВАНИЯ ФАЙЛОВ ................................................................................ 83 10.02. ПРИМЕР ГЛОБАЛЬНЫХ ЗОН ДАННЫХ ............................................................................. 84 10.03. КОДЫ ОБОЗНАЧЕНИЯ РОЛЕЙ ........................................................................................... 84 10.04. КОДЫ СТАДИЙ РАЗРАБОТКИ ............................................................................................ 85 10.05. КОДЫ СИСТЕМ/ПОДСИСТЕМ ............................................................................................ 86 10.06. КОДЫ ОБОЗНАЧЕНИЯ ТИПОВ ДАННЫХ .......................................................................... 87
5
ПРЕДИСЛОВИЕ
На сегодняшний момент ключевой для коренных трансформаций проектирования и
строительной отрасли в целом является технология BIM (Building Information Modelling)/ТИМ
(Технология информационного моделирования зданий и сооружений). Хотелось бы сделать
акцент именно на слове технология, поскольку ТИМ не является каким-либо программным
продуктом или решением, конкретной методикой или способом проектирования. Это
комплексный подход, использующий передовое программное обеспечение и решения в
области проектирования, управления информацией, коммуникации и взаимодействия, это
новые методы в принципах формирования проектных команд и во внутренних процессах
организаций на протяжении всего жизненного цикла объекта.
Несмотря на то что информационное моделирование все чаще становится неотъемлемой
частью проектирования/строительства, многие организации и компании все еще
сталкиваются со значительными трудностями при переходе на новые методологии при
внедрении ТИМ. Связано это прежде всего с тем, что до сих пор существует значительная
нехватка информации о правильном построении стратегии внедрения и применения ТИМ –
от решения глобальных задач до технических нюансов моделирования.
Сегодня ситуация коренным образом меняется: по прошествии более чем двадцати лет
использования CAD/BIM многие передовые компании и профессиональные сообщества
опубликовали на основе своего опыта и практики основополагающие стандарты в этой
относительно новой для строительного сектора области, регламентирующие основные
процессы, деятельность, методики и лучшие практики в рамках информационного
моделирования (BIM). Многие из этих стандартов уже получили мировое признание и
являются прототипами для последующих локализованных версий.
Компания GRAPHISOFT подготовила на базе ключевых международных и национальных
стандартов собственный BIM-стандарт, формализующий и регламентирующий специфику
работы в рамках информационного моделирования. Несмотря на то что основной акцент
сделан на платформе GRAPHISOFT ARCHICAD, в стандарте также описаны общие принципы
и требования при внедрении BIM в рамках компании, принципы междисциплинарной
координации (OPEN BIM), организации единой информационной среды, общая специфика и
логика новых технологических процессов.
6
1. ВВЕДЕНИЕ
1.01. СФЕРА ПРИМЕНЕНИЯ
Данный стандарт в значительной своей части базируется на принципах и основах,
определенных британскими, российскими и международными стандартами, в том числе:
• AEC (UK) BIM Technology Protocol v2.1
• ISO 19650-1
• ISO 19650-2
• ISO/TS 12911
• ISO 13567-1:2017
• ISO 13567-2:2017
• ГОСТ Р 10.0.02-2019/ИСО 16739-1:2018
• ГОСТ Р 10.0.03-2019/ИСО 29481-1:2016
• ГОСТ Р 10.0.04-2019/ИСО 29481-2:2012
• ГОСТ Р 10.0.05-2019/ИСО 12006-2:2015
• ГОСТ Р 10.0.06-2019/ИСО 12006-3:2007
• ГОСТ Р 58439-1-2019
• ГОСТ Р 58439-2-2019
Учтена специфика опубликованных национальных СП. При составлении стандарта также
принимались во внимание другие национальные BIM-стандарты и протоколы: COBIM,
ÖNORM, Statsbygg BIM Manual, Singapore BIM Guide, опыт крупных компаний и др.
Стандарт регламентирует применение BIM-технологий и практик на базе GRAPHISOFT
ARCHICAD, не ограничивая использование других программных продуктов, применяемых в
рамках междисциплинарного взаимодействия, основой которого является концепция OPEN
BIM.
7
1.01.1 Основные цели стандарта
● Сформировать понимание основополагающих стандартов в рамках их применения на
практике.
● Повысить производительность путем применения скоординированного
и согласованного подхода к работе в BIM.
● Обозначить доступные и понятные «правила игры» в рамках
организации/отдела/группы, позволяющие выстраивать эффективное
взаимодействие между всеми участниками процесса.
● Обеспечить правильное структурирование файлов, информации, контента в рамках
единой среды данных для эффективного управления, хранения и обмена данными
между всеми участниками проекта, в ходе совместной работы в
мультидисциплинарных группах как во внутренней, так и во внешней BIM-среде.
● Изложить основные требования к построению моделей, их качеству, контенту,
а также основные критерии эффективного междисциплинарного обмена (в том числе
с помощью открытых стандартов, включая формат IFC).
● Акцентировать внимание на ключевых технических нюансах программного продукта
GRAPHISOFT ARCHICAD, позволяющих сформировать корректную и полноценную
BIM-модель.
● Определить лучшие практики и подходы.
Предполагается, что перед внедрением данный стандарт будет изучен компетентными
специалистами, понимающими логику представленных положений. В то же время стандарт
рекомендуется для изучения всеми участниками проекта.
8
1.02. ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ
Все положения данного стандарта носят рекомендательный характер и должны быть
тщательно проанализированы перед их применением в работе. Авторы не несут
ответственности за использование данного стандарта и всех вышеизложенных
рекомендаций.
Стандарт не описывает детально специфику и пошаговую последовательность работ в
программном продукте ARCHICAD или конкретной дисциплине проекта, а содержит рамочные
рекомендации и методологии для правильного построения процессов информационного
моделирования и его производных (моделей, чертежей, расчетов и др.), а также может быть
использован как основа для написания собственного BIM-стандарта компании.
9
1.03. ПРОЦЕДУРА ОБНОВЛЕНИЯ
Предложения по внесению изменений и дополнений в данный стандарт принимаются
разработчиками в письменной форме с приложением примеров, обсуждений, других
сопроводительных материалов (например, файлов моделей) по электронному адресу:
[email protected]. Все предложения будут рассмотрены и вынесены на обсуждение.
Предложения, принятые разработчиками как уместные, будут добавлены в пакеты
изменений стандарта с указанием авторов этих предложений.
Разработчики рассчитывают на участие сообщества проектировщиков и других специалистов
архитектурно-строительной отрасли в совершенствовании данного стандарта. Ожидается,
что стандарт пройдет процесс эволюции, так как сама отрасль адаптируется к требованиям и
достижениям методологии BIM.
10
1.04. ПОЛЕЗНЫЕ ССЫЛКИ
• Сайт компании GRAPHISOFT - https://www.graphisoft.ru
• Центр Поддержки GRAPHISOFT - https://helpcenter.graphisoft.ru/
• Сайт ассоциации buildingSMART -
• Российское отделение buildingSMART - https://buildingsmart.su/
• Документация по формату IFC - https://technical.buildingsmart.org/standards/ifc/ifc-schema-
specifications/
• Подготовка шаблона в ARCHICAD - https://helpcenter.graphisoft.ru/knowledgebase/62656/
• МИНСТРОЙ РОССИИ (поиск опубликованных документов) - http://www.minstroyrf.ru/docs/
• СП 333.1311500.2017 «Информационное моделирование в
строительстве. Правила формирования информационной модели объектов на
различных стадиях жизненного цикла». - http://www.minstroyrf.ru/docs/16405/
• СП 328.1311500.2017 «Информационное моделирование в
строительстве. Правила описания компонентов информационной модели».
http://www.minstroyrf.ru/docs/16400/
• СП 331.1311500.2017 «Информационное моделирование в
строительстве. Правила обмена между информационными моделями
объектов и моделями, используемыми в программных комплексах».
http://www.minstroyrf.ru/docs/16403/
• СП 301.1325800.2017 «Информационное моделирование в
строительстве. Правила организации работ производственно-техническими
отделами». - http://www.minstroyrf.ru/docs/15631/
• Стандарт ISO 19650-1:2018 - https://www.iso.org/standard/68078.html
• Стандарт ISO 19650-2:2018 - https://www.iso.org/standard/68080.html
• Singapore BIM Guide - https://www.corenet.gov.sg/media/586132/Singapore-BIM-
Guide_V2.pdf
• Руководство Statsbygg BIM Manual -
https://www.statsbygg.no/files/publikasjoner/manualer/StatsbyggBIM-manual-ver1-2-1eng-
2013-12-17.pdf
• AEC (UK) BIM Technology Protocol -
https://aecuk.files.wordpress.com/2015/06/aecukbimtechnologyprotocol-v2-1-1-201506022.pdf
• CIC Building Information Modelling Standarts -
http://www.cic.hk/files/page/51/CIC%20BIM%20Standards_FINAL_ENG_v1.pdf
• AEC (UK) BIM Technology Protocol for GRAPHISOFT ARCHICAD –
https://aecuk.files.wordpress.com/2016/01/aecukbimtechnologyprotocolforarchicad-v2-0.pdf
• Руководство NATSEC National BIM Guide - https://bim.natspec.org/documents/natspec-
national-bim-guide
11
1.05. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ
В стандарте используются следующие термины с соответствующими определениями:
1.05.1 Основные термины и определения
● ТИМ / Технология информационного моделирования зданий и сооружений
(англ. BIM – Building Information Modelling)
Комплексный подход к процессу проектирования, строительства, эксплуатации здания,
основанный на создании и внесении данных об объекте в целостную информационную
систему, представленную в виде интегральной модели, наполненной всей
необходимой информацией и содержащей все ключевые геометрические,
параметрические, физические и другие данные о проекте/объекте.
● ИМ / Информационная модель
Результат/производная информационного моделирования, объектно-
ориентированное цифровое представление геометрических, физических
и функциональных свойств здания или сооружения в виде совокупности
информационно насыщенных элементов/компонентов, согласованных и
упорядоченных в рамках этого представления.
● Ссылочная ИМ
Модель, загруженная как отдельный экземпляр в другую модель.
● Сводная ИМ
Две и более ссылочных модели.
● Компонент модели
Отдельный элемент (двери, лестничные марши, мебель, фасадные панели, колонны,
блоки инженерных коммуникаций и т.д.).
● CDE / Среда общих данных (СОД)
Комплекс технических, программных и методологических средств, предоставляющий
совместный доступ ко всей доступной проектной информации, организованной и
систематизированной на основе принятых стандартов для обеспечения
эффективного обмена данными между всеми участниками проекта.
● Класс ЭИМ / класс
Определяет степень проработки отдельного элемента в зависимости от
поставленных задач/требований на каждом из этапов жизненного цикла проекта.
Обычно оперирует степенью детализации геометрии объекта (LOD/LOG) и степенью
проработки его атрибутивной части (LOI – Level of Information).
● ROI / Возврат инвестиций
Коэффициент, определяющий уровень окупаемости финансовых вложений. В данном
контексте – кумулятивный эффект от применения/внедрения BIM в конкретной
организации.
12
● Валидация
Процесс приведения данных в соответствие с четко описанными требованиями
(критериями) для определенных целей. Как правило, состоит из трех ключевых этапов:
подготовка, проверка и коррекция.
● Верификация
Процесс подтверждения данных в соответствии с четко описанными требованиями
(критериями) для определенных целей.
13
1.05.2 Общие технические термины
● IFC / Industry Foundation Classes
Универсальный объектно-ориентированный формат данных с открытой
спецификацией, который не контролируется ни одной компанией или группой
компаний. Формат был разработан и поддерживается международным альянсом
buildingSMART для упрощения взаимодействия в строительной индустрии. Наиболее
часто использующиеся спецификации для передачи информации – IFC2x3 (реже
ifcXML2x3) и IFC4.
● XML / eXtensible Markup Language
Расширяемый язык разметки – то есть язык с простым формальным синтаксисом,
удобный для создания и обработки документов программами и одновременно
удобный для создания и чтения документов человеком. Наиболее часто используется
для описания настроек поведения различных программ и их компонентов, реже для
передачи структурированных массивов данных.
● COBie / Construction Operations Building Information Exchange
Непроприетарный формат данных для передачи информации, полученной на основе
информационной модели здания для обслуживания и эксплуатации зданий и
сооружений.
● BCF / BIM Collaboration Format
Открытый универсальный формат для межплатформенной и междисциплинарной
коммуникации, обычно содержащий снимок вида (текущего вида), координаты
позиционирования камеры, данные об элементе/группе элементов (External IFCID) и
ключевую информацию о самой записи (автор, дата, фаза проекта, метки, описание и
т.п.). Поддерживается большинством ПО, в том числе и облачными платформами.
● API / Программный интерфейс приложения
Описание способов (набор классов, процедур, функций, структур или констант),
которыми одна компьютерная программа может взаимодействовать с другой
программой. Например, с помощью ARCHICAD API могут быть написаны
дополнительные расширения для платформы.
14
1.05.3 Термины и определения среды ARCHICAD
● PLN – основной формат хранения всех проектных данных (модельных, атрибутивных
и т.п.) в ARCHICAD.
● PLA – архивный формат хранения проектных данных, содержащий вложенные
библиотечные элементы.
● BPN – временная резервная копия последнего состояния рабочего файла.
● LCK – блокирующий файл для ограничения возможности параллельной перезаписи
открытого файла другим пользователем.
● MOD – модуль (hotlink), формат файла, предназначенного для последующей (часто
многоразовой) вставки в другой файл. Хранит в себе только модельные данные,
вследствие чего опирается на текущую среду, загруженную с помощью шаблона или
последнего проекта/файла.
● TPL – формат шаблона ARCHICAD.
● BIMx – формат гипермодели BIMx, обеспечивает одновременную навигацию по 2D-
документам и 3D-модели, доступ к информации. Используется для презентаций,
осуществления архитектурного надзора и контроля строительства.
● PMK – собственный формат чертежей ARCHICAD, отличающийся меньшим
размером и лучшей производительностью.
● GSM – формат файлов библиотечных элементов.
● GDL – формат частей кода библиотечных элементов.
● LCF – файл-контейнер, содержащий определенный перечень упакованных
библиотечных объектов.
● Библиотечный элемент – типовой элемент, характеризирующийся общим набором
свойств и графическим представлением.
● Вид – сгенерированное представление информации из/о модели в графической
форме (планы, разрезы, фасады, таблицы и пр.) с определенным перечнем
применяемых графических настроек.
● Модуль – вставленная отдельным файлом определенная часть текущей или другой
модели.
● Сопоставление (анл. Mapping) – настройка соответствия/преобразования между
исходными данными и необходимым конечным результатом (например,
пользовательское преобразование определенных типов элементов).
● Обнаружение Коллизий – процесс обнаружения ошибок различного характера
в проекте (геометрические пересечения, отсутствие необходимой информации об
элементах, нарушение логических связей и т.п.).
15
● Реквизиты (атрибуты) – структурированные пользовательские свойства различных
типов элементов: слои, строительные материалы, сложные профили, категории зон и
др.
● Шаблон – предварительно подготовленный и настроенный файл для создания новых
проектов.
● Транслятор – набор настроек для операций экспорта/импорта дву- и трехмерных
данных.
● Teamwork – способ организации одновременной коллективной работы в среде
ARCHICAD, базирующийся на серверном решении BIMcloud.
● Xref – способ размещения в проекте сторонних чертежей (DWG/DXF) смежных
дисциплин.
16
1.06. РАСПРОСТРАНЕНИЕ
Эффективность и широта применения данного стандарта напрямую зависят от количества
компаний, которые будут его использовать. Ввиду этого он может свободно распространяться
и использоваться в любом необходимом формате при единственном условии ссылки на
разработчиков и первоисточник.
17
2. ОБЩИЕ СВЕДЕНИЯ
2.01. УРОВНИ «ЗРЕЛОСТИ» BIM
2.02.1 Диаграмма Бью-Ричардса
Важно отметить, что BIM – это не просто программный продукт, это одновременно и процесс,
и методология, и продукт, опирающиеся на кадрово-ресурсные возможности организации.
При внедрении BIM необходимо изучить реальное положение вещей, понимать стартовую
диспозицию, адекватно оценивая возможности специалистов, качество и эффективность
существующих процессов и взаимодействия, а также методологически-технический уровень
BIM.
Для таких целей можно использовать диаграмму Бью-Ричардса. Она описывает уровни
зрелости BIM, исходя из способности строительного процесса оперировать информацией и
обмениваться ею. Модель применима ко всему проектному сценарию в целом: одна и та же
компания может осваивать второй уровень зрелости (3D-моделирование, использование
таблиц COBie, 2D рецензируемые PDF) и в то же время вести ряд проектов на первом уровне.
Такое положение дел нормально и во многих случаях ожидаемо, поскольку различные
организации «дозревают» на протяжении разного времени, и это зависит от множества
факторов.
Рис. 1: Диаграмма Бью-Ричардса
Модель зрелости также используется для определения вспомогательной инфраструктуры,
необходимой на каждом уровне производительности. Предполагается, что она будет
применяться стратегической группой BIM-проекта в процессе определения приоритетов
развития BIM-инфраструктуры. Второй уровень зрелости BIM по Бью-Ричардсу включает:
● Уровень 0 – CAD (САПР); практически плоский CAD без трехмерных данных,
в котором можно создать только традиционные чертежи.
18
● Уровень 1 – управляемый CAD в 2D- или 3D-формате с инструментом
взаимодействия, обеспечивающим общую среду данных, возможно некоторые
стандартные структуры данных и форматы. Коммерческая сторона проекта ведется
финансистами независимо, пакеты управления стоимостью проекта не
интегрированы в процесс.
● Уровень 2 – управляемое 3D-окружение, содержащееся в отдельных
дисциплинарных инструментах BIM со вложенными данными.
Уровень 1 содержит только нулевой и первый уровни.
Есть надежда, что в будущем все профессиональные и строительные группы будут
инвестировать в совместимые технологии, обучать персонал, насыщать проектной, ценовой
и технической информацией централизованно управляемую модель. Тем не менее,
вероятно, что пройдет некоторое время, прежде чем BIM будет использоваться в такой
высокой степени сложности.
2.02.2 Возможности BIM-модели на Уровне 2
Есть две концепции использования BIM: «одинокая» и «совместная» BIM. Понятие
«одинокая BIM» (введено Робертом Клашка из Studio Klaschka) используется
применительно к ранним проектам Уровня 2, в которых BIM-технологии применяет только
одна сторона. Совместная BIM, также называемая социальной или интегрированной,
возникает, когда BIM-технологии моделирования начинают использовать все стороны
проекта. Сейчас нет общепринятой договоренности, какой Уровень 2 следует считать по-
настоящему совместным, но если все стороны создают 3D-модели и работают вместе – нет
никаких оснований отказывать в этом статусе.
Модель-ориентированное управление проектом улучшает концепцию и подачу проектов
любых масштабов и сложности. Общие возможности модели в соответствии с Уровнем 2
кратко описаны ниже.
● 2D – Черчение
Плоские чертежи – изображения или CAD-визуализация, описывающая элементы в
линиях и определяющая геометрию конструкции.
● 3D – Модель
«Прогулка» по модели служит инструментом визуализации, позволяет
разработчикам и подрядчикам совместно работать, удаленно выявлять и решать
проблемы.
Обнаружение коллизий. Чертежи проекта должны быть сверены, гарантируя, что
различные строительные системы не конфликтуют и действительно могут быть
построены в отведенном пространстве. 3D-модель позволяет идентифицировать
потенциальные проблемы еще на стадии проектирования и решить их до начала
строительства.
19
Визуализация проекта – простая схематичная симуляция может показать
владельцу, как будет выглядеть здание в процессе строительства на участке;
предоставить всем участникам проекта полезный и наглядный инструмент.
Виртуальный макет модели – часто на больших проектах заказчик запрашивает
физические макеты модели. BIM-моделирование позволяет создать и протестировать
виртуальную модель с куда меньшими затратами.
● 4D – Время
Добавляя параметр времени к информации в модели проекта, можно рассматривать
процесс строительства здания по мере его продвижения. Для больших и сложных
проектов или проектов, расположенных на сложных участках, это особенно полезно,
поскольку может быть использовано для изучения путей сообщения, решения
логистических задач, таких как доставка и размещение кранов, и вообще для
обсуждения и определения, как именно будет построено здание. По мере
совершенствования совместимости должен появиться более простой способ
рассмотрения различных вариантов, позволяющий быстро обрабатывать их и
транслировать непосредственно в 3D-модель процесса строительства.
Если модель обновляется, чтобы отразить деятельность на площадке, может быть
полезным инструмент анализа достигнутого результата и выяснения, где процесс
отстает от графика. Также он может использоваться и в меньшем масштабе, чтобы
моделировать возможные коллизии с кранами и временными работами. Вполне
вероятно, что 4D-модель будет разработана основным подрядчиком, исходя из
информации, предоставленной специалистом подрядчика, и может помочь в
следующем:
• планирование и управление строительством. BIM-модели
обеспечивают средства проверки логистики участка и операций,
задействуя инструменты, визуально отображающие использование
участка на протяжении всего этапа строительства. Модель может
включать в себя временные компоненты, такие как краны, грузовики,
ограждения и пути сообщения с площадкой. В дальнейшем инструменты
BIM-модели можно по мере развития проекта использовать для
углубленного планирования, мониторинга состояния и безопасности.
• визуализация графика работ. Отслеживая визуализацию графика,
участники проектной группы получат возможность принимать верные
решения, основанные на многочисленных источниках точной
информации, в режиме реального времени. Продвинутые BIM-модели
смогут автоматически определять изменения, влияющие на критические
участки, указывать соответствующие последствия реализации проекта.
● 5D – Стоимость
Способность BIM-моделей поддерживать информацию о затратах и количественные
ведомости/спецификации позволят вычислять стоимость текущего проекта на
порядок быстрее. Появится возможность более точно оценивать стоимость еще на
20
стадии концепции, ускоряя итерационный процесс проектирования и приводя его в
соответствие с бюджетом заказчика.
• Оценка стоимости в реальном времени – данные о стоимости могут
быть добавлены к каждому объекту, что позволяет модели
автоматически подсчитать примерные расходы в целом и по частям,
определить стоимость материалов. Это обеспечивает проектировщиков
ценным инструментом оптимизации затрат, но он, конечно, не
подскажет, как избавиться от издержек.
● 6D – Эксплуатация
Полностью собранная, насыщенная всей необходимой информацией модель,
соответствующая состоянию «as built» («как построено»), открывает значительные
возможности в области управления и эксплуатации построенного здания, позволяя
эффективно осуществлять управление недвижимостью, включая мониторинг
безопасности, текущий и плановый ремонт, реконструкцию.
2.03. РОЛЬ BIM-МЕНЕДЖМЕНТА
Для успешного перехода к новой методологической и технологической парадигме
необходимы качественные изменения в кадровой структуре компании. Практически в каждом
проекте, где планируется использование BIM, необходимы определенная техническая
поддержка и управление со стороны компетентных специалистов. Обычно таких
специалистов называют BIM-менеджерами. Они играют ключевую роль при внедрении,
организации и использовании BIM не только на уровне проекта, но и в масштабах всей
организации. Это принципиально новая роль, которая появилась с развитием
информатизации и цифровизации проектно-строительной отрасли. Задачи и зоны
ответственности этой роли должны быть четко сформулированы и зафиксированы на уровне
организации, о чем будет сказано в отдельном разделе.
21
3. ВНЕДРЕНИЕ BIM
3.01. ПЛАНИРОВАНИЕ ВНЕДРЕНИЯ
Для получения эффекта от BIM необходимы, с одной стороны, грамотная интеграция его
применения в рабочие процессы компании, а с другой – продуманная стратегия внедрения
BIM и детальное планирование каждого отдельно взятого проекта.
Достижение стратегических целей BIM реализуется последовательным планированием
конкретных проектов, конкретных фаз их разработки в рамках BIM стратегического
планирования.
BIM-планирование:
● Каждый проект должен прорабатываться с точки зрения BIM индивидуально.
Применение всех ранее наработанных методов, приемов и материалов должно
подвергаться критическому анализу для поиска новых BIM-возможностей и во
избежание тиражирования некогда успешных, но утративших актуальность практик.
● Согласованные и регулярные BIM-проверки проекта необходимы для соответствия
BIM-процесса намеченному плану и получения ожидаемого результата.
● Документирование порядка совместной работы внутри проекта и с внешними
участниками позволит избежать недопонимания и не допустить нарушения BIM-
процесса.
● Требуется четкое распределение ответственности (индивидуальное или групповое)
по каждому сегменту данных на протяжении всего времени выполнения проекта.
● Разделение моделей между дисциплинами и внутри одной дисциплины необходимо
для оптимизации объемов данных (размеров файлов) и поддержания нужных темпов
работы.
● Необходимо понимание всеми разработчиками моделей назначения этих моделей и
поддержание минимально необходимого, но достаточного уровня моделирования.
● Очень важна настройка и поддержка в рабочем состоянии максимально
автоматизированной технологической цепочки от информационной модели
к выводимым данным.
● Внесение изменений в конечные данные (чертежи) должно производиться путем
внесения изменений в исходные модели. Декомпозиция интерактивных видов
(«взрыв» в 2D), апплицирование изображений («этикетки» на чертежах) являются
экстраординарными мерами.
● Все спорные вопросы должны решаться путем обсуждения.
22
3.02. РЕГЛАМЕНТАЦИОННЫЕ И ИСПОЛНИТЕЛЬНЫЕ ДОКУМЕНТЫ
Ниже перечислены основные документы, которые регламентируют процесс
информационного моделирования и другие ключевые технические аспекты проекта.
● BEP / BxP / BIM Исполнительный план проекта
Основной регламентирующий документ, который определяет ключевые задачи
проекта, методы и средства их достижения (моделирование, обмен информацией,
организация модели и данных и пр.). С точки зрения BIM-методов и средств в BEP
должны быть проработаны следующие пункты:
• Цели и применение. Определение BIM-целей, применения BIM, направлений
развития (с учетом требований рабочих процессов, необходимых для их
достижения) для конкретной используемой технологии.
• BIM-совещания по проекту. Определение периодичности проведения BIM-
совещаний и состава участников.
• ПО и инфраструктура. Определение и уточнение используемой BIM-
технологии и стратегии совместимости. Каталогизация обмена информацией и
проблем совместимости, определение путей решения несоответствий.
• Позиционирование и СК. Определяется координатная среда проекта (единая
система координат или иерархия систем координат) для всех BIM-данных, при
необходимости описываются методы совмещения моделей и определяются
границы моделирования.
• Разделение данных. Основано на организационной структуре модели, если
это уместно для обеспечения междисциплинарного и многопользовательского
доступа и поэтапной разработки проекта, а также распределенного владения
информацией.
• Обмен информацией. Определение протоколов коммуникации, а также
периодичности и формы обмена информацией между официальными точками
принятия решений.
• Проверка/валидация. Определение процесса проверки/валидации
информации.
При разработке BEP могут применяться ранее разработанные шаблоны, но они
должны быть пересмотрены и приведены в соответствие специфике конкретного
проекта. Также для повышения эффективности необходимо формирование
библиотеки шаблонов из BEP наиболее успешных проектов.
По окончании работы над проектом необходимо сформировать отчет, фиксирующий
фактическое выполнение BEP проекта, а также сопряженные с ним трудности и
прочие факты, которые могут быть полезны для анализа и повторного применения.
● EIR / Информационные требования заказчика
Основополагающий документ – техническое задание, описывающее требования к
созданию информационной модели проекта для всех его участников. Требования,
перечисленные в EIR, являются основой для разработки BIM-плана выполнения
проекта (BEP).
23
Перечень и характер требований зависят от технической компетенции заказчика. В
некоторых случаях EIR может быть предложен для утверждения со стороны
проектировщика.
В документе должны быть определены следующие положения:
• назначение модели/моделей, а также конечный предоставляемый формат;
• разделение моделей (дисциплины, отдельные участки/части и т.п.);
• требования к программному обеспечению;
• требования к степени проработки элементов модели (LOD);
• требования к системе классификации (при необходимости);
• требования, определяющие процессы контроля качества модели
и документации;
• этапы работ и время выдачи промежуточных/финальных результатов;
• определение ключевых стандартов;
• прочие технические требования.
● MIDP / Основной план реализации информационных задач
(англ. Master Information Delivery Plan)
Документ, определяющий, какая информация должна быть подготовлена, кем, когда
и с какими ключевыми требованиями. В нем также должны быть описаны ключевые
форматы предоставления информации и временные рамки.
● Протоколы валидации
Документы, содержащие контрольный список пунктов проверки моделей, данных,
информации и иного проектного контента на соответствие требованиям и принятым
нормам/стандартам.
Примечание. Не стоит воспринимать эту работу исключительно как совокупность
бюрократических процедур. Перечисленные документы представляют собой
инструмент, позволяющий избежать вербальных искажений передачи информации и
появления различного рода неточностей, особенно при работе с удаленными
проектными командами или с большим количеством команд/специалистов в рамках
крупного и сложного объекта.
3.03. РОЛИ И ОБЯЗАННОСТИ
Совместную работу необходимо усовершенствовать путем практичного, универсального,
доступного для понимания и гибкого распределения должностей, должностных
обязанностей и зон ответственности. Для четкости понимания должностные обязанности
должны быть согласованы по ключевым компонентам BIM и по тому, под чью
ответственность они попадают.
24
Для успешного внедрения BIM в компании определяются BIM-роли с иерархией
и распределением обязанностей, основанными на трех основных функциях:
● Стратегия: BIM-менеджер
● Управление: BIM-координатор
● Исполнение: BIM-моделлер
Эти функции распределены между тремя BIM-ролями параллельно со служебными
обязанностями специалистов в своем профиле.
Рис. 2: Роли и обязанности
25
3.03.1 BIM-менеджер (стратегия)
Необходимо понимать, насколько существенной является роль BIM-менеджера. Это не
просто ребрендинг CAD-менеджера и не его замена. Речь идет о понимании того, чего
можно достичь при помощи BIM: видение, вовлечение заинтересованных сторон извне,
сотрудничающих партнеров и внутренних команд. За стратегию BIM, изменения процессов и
мировоззренческое воздействие должен отвечать надежный человек. Успешные модели в
компании и за ее пределами не могут быть построены без стратегического менеджера.
Структура команды BIM определяется бюджетом и масштабами проекта. В небольших
проектах BIM-менеджер может выполнять все функции, но вне зависимости от размеров
проекта должен быть только один человек, отвечающий за стратегическую функцию.
BIM-менеджер – технологический лидер компании, большей частью освобожденный от
непосредственного процесса проектирования и сосредоточенный на следующих
обязанностях:
● определение (предоставление программ высшему руководству) корпоративных BIM-
целей, стратегии BIM-развития компании;
● изучение лучших практик, исследования, мониторинг предложений на рынке BIM-
технологий, другая изыскательская деятельность, ориентированная на поиск
инструментов и механизмов достижения целей BIM;
● изыскания с целью оптимизации рабочих процессов проектирования посредством
BIM-технологий на основе мониторинга и анализа данных внутренних процессов
компании на предмет чрезмерных ресурсозатрат;
● создание процессов и рабочей среды компании;
● создание стандартов, протоколов и других регулирующих документов;
● разработка и внедрение BIM-проектов;
● формирование обучающей стратегии компании, организация и проведение тренингов
персонала;
● руководство технологией процесса проектирования (в частности, регламентация
взаимодействия дисциплин);
● управление проектными данными в целом, мониторинг их состояния и динамики.
3.03.2 BIM-координатор (тактика/управление)
BIM-координатор – технологический лидер группы, в совершенстве владеющий ее
основными программными средствами. Частично освобожден от непосредственного
процесса проектирования и выполняет следующие обязанности:
● функции BIM-менеджера в масштабе и в рамках группы, постоянное повышение
уровня своей технической квалификации;
26
● реализация в группе целей и задач, определенных BIM-менеджером, их
ретрансляция группе;
● создание и реализация BIM Исполнительного плана проекта;
● аудит моделей, производимых и принимаемых группой;
● междисциплинарная BIM-координация, взаимодействие с другими группами на
уровне BIM-координаторов, отладка правил и принципов такого взаимодействия;
● определение BIM-технологии процесса проектирования в группе, создание шаблонов
для работы группы;
● управление проектными данными и библиотеками группы, мониторинг их состояния и
динамики, разработка библиотек.
3.03.3 BIM-моделлер (исполнение)
BIM-моделлер – проектировщик, непосредственно участвующий в процессе проектирования.
В число его обязанностей также входят:
● выполнение функций координатора в рамках своего участка работ;
● постоянное совершенствование навыков владения специализированным
профильным ПО;
● анализ своего рабочего процесса на предмет наличия рутинных и трудоемких
участков с целью предоставления этой информации координатору и формирования
предложений по оптимизации;
● создание информационных моделей зданий в соответствии с BIM-требованиями,
определенными координаторами и менеджером;
● формирование проектной документации средствами и методами, соответствующими
BIM-требованиям группы и компании;
● управление своими проектными данными в соответствии с BIM-правилами,
установленными в компании.
Роли и обязанности могут корректироваться ситуативно.
3.04. КОММУНИКАЦИЯ
3.04.1 Запуск BIM
При запуске проекта необходимо инициировать стартовое BIM-совещание.
Цель совещания – сбор существующих и определение дополнительных информационных
требований к проекту, форм и способов их реализации, создание BIM Исполнительного
плана для всего проекта.
27
На совещании по запуску BIM должны присутствовать все ключевые участники, необходимо
как можно раньше определить информационные требования для всего жизненного цикла
проекта.
Повестка стартового совещания может формироваться на основании пунктов BIM
Исполнительного плана проекта, которые принимаются как отправные точки в работе.
3.04.2 BIM-совещания
Для выполнения проекта на основе BIM необходима эффективная коммуникация,
осуществляемая на регулярной основе. По мере продвижения работы над проектом
периодичность совещаний может варьироваться.
Цель совещаний – постоянный мониторинг проекта, выполнения проектных BIM-требований
и следования BEP, при необходимости – коррекция требований и BEP.
Особое внимание на совещаниях необходимо уделять влиянию BIM на выполнение проекта
в целом. В частности, следует заблаговременно избегать ситуаций, когда преимущества BIM
достигаются за счет ресурсов, не предусмотренных в проекте, что может нивелировать эти
преимущества и подвергнуть дополнительным рискам успех всего проекта.
Контроль выполнения BEP необходим для достижения BIM-целей, но при этом в процессе
реализации проекта важно критически пересматривать сам BEP. К примеру, структура
моделей (разделение данных), эффективная на ранних стадиях разработки при невысоком
LOD, на более поздних стадиях с повышением LOD зачастую оказывается нецелесообразно
трудоемкой в использовании.
3.04.3 Проектные совещания
При необходимости на проектных совещаниях должен присутствовать специалист,
обладающий достаточными навыками в соответствующей технологии – для навигации по
модели и ее демонстрации.
Также при рассмотрении проектных вопросов и принятии решений необходимо учитывать
технологические особенности рабочего процесса – во избежание непредвиденного
изменения качества и сроков выполнения работ, вызванного влиянием проектных решений
на технологию.
3.05. BIM НА ЭТАПАХ ЖИЗНЕННОГО ЦИКЛА ОБЪЕКТА
Чтобы BIM полноценно раскрыла свой потенциал, важно, чтобы она использовалась
в течение всего процесса реализации проекта, на всех этапах его жизненного цикла –
комплексно, системно и с максимально бесшовными переходами между этапами. Это
требует серьезной и вдумчивой разработки стратегии использования BIM для каждого
проекта.
Следует отметить, что каждый из этапов жизненного цикла объекта имеет свою специфику,
характеристики, сложности, требования и прежде всего служит для достижения конкретных
целей. Важно понимать, что это самым непосредственным образом влияет на
28
использование BIM в ходе каждого из этапов, и четко планировать «прогрессию»
использования BIM, уделяя особенное внимание фазам перехода.
Ясно, что использование BIM только на ранних этапах жизненного цикла существенно
ограничивает ее эффективность и не обеспечивает возврата инвестиций (ROI). На каждом
из этапов кумулятивный эффект от использования BIM возрастает.
В рамках наилучшей практики использование BIM должно начинаться на этапе сбора
информации, эскизного проекта. Модели, разработанные на данном этапе, впоследствии
должны преобразовываться в полномасштабную информационную модель объекта –
параллельно с развитием и разработкой самого проекта. Наличие модели, насыщенной
информацией и необходимым спектром данных, позволяет проектным группам
осуществлять комплексный анализ, прорабатывая огромное количество вариантов и
оптимизируя проектные решения. Та же модель, доработанная и детализированная,
скоординированная в рамках всех дисциплин (разделов проекта), позволяет предоставить
всю необходимую информацию для строительства объекта, управлять ею, эффективно и
прозрачно вносить изменения. На этапе строительства такая модель, расширенная и
дополненная, может использоваться для визуализации последовательности процессов
логистики, строительства, выполнения работ и др. После получения исполнительной модели
(англ. as build model) по факту завершения строительства модель можно использовать как
базу данных для оперативного использования объекта и его эксплуатации – вплоть до
финального демонтажа.
Исключительно важно понимать, что на протяжении жизненного цикла объекта, его модель
постоянно насыщается информацией (геометрической, физической, параметрической и пр.),
объемы которой возрастают по мере развития проекта.
29
4. СОВМЕСТНАЯ BIM-РАБОТА
4.01. СРЕДА ОБЩИХ ДАННЫХ (CDE)
В основу описываемой здесь совместной BIM-работы положены принципы,
формализованные в документах ISO 19650-1 и ISO 19650-2, которые определяют процесс
совместной работы над проектом и эффективного совместного использования данных.
Важной составляющей среды коллективной работы является возможность обмениваться
информацией, повторно использовать данные без их потери или неверного толкования.
Среда общих данных (Common Data Environment, CDE, СОД) предоставляет доступ
к информации всем участникам проекта, в том числе и за пределами ИТ-инфраструктуры
компании. Доступ к данным за пределами компании обеспечивается посредством
регламентированной и защищенной, но прямой доступности этих данных из сети интернет
(доступ в инфраструктуру компании и/или репликация с облачными хранилищами).
Существуют четыре принципиальные зоны, относящиеся к CDE:
Рис. 3: Области Среды Общих Данных
● WIP (Work In Progress) – Рабочий Процесс;
● SHARED – Общие;
● PUBLISHED – Опубликованные;
● ARCHIVE – Архив.
30
4.01.1 Рабочий Процесс (WIP – Work In Progress)
Ключевое определение для размещаемых данных – Рабочий Материал, Генерация
Контента.
В этой зоне хранятся данные, которые на данный момент используются в работе и еще не
проверены и не утверждены как пригодные для использования за пределами авторской
команды.
● Структура хранения и разделение на рабочие файлы определяются рабочей группой-
владельцем.
● Результирующие данные разработок должны находиться по иерархии папок выше,
чем составляющие их подключенные подмодели, варианты и эскизы разработок.
● Доступ к WIP-данным для их использования в работе другим участникам процесса не
запрещается, однако при этом авторская команда не несет ответственности за
содержание данных.
4.01.2 Общие (SHARED)
Ключевое определение для размещаемых данных – Информация для Общего
Пользования.
В этой зоне хранятся данные процессов обмена информацией внутри организации
и исходящих к внешним участникам (заказчик, субпроектировщики и пр.), она является
накопительным репозиторием всех передаваемых данных и упорядочена по характеру
процессов, которые описаны ниже.
● Export – Экспорт:
• данные, экспортированные из зоны WIP (как правило, из BIM-моделей);
• данные, имеющие универсального получателя.
С целью оперативного донесения информации обновляются как можно чаще при
изменениях в исходных моделях.
Ответственность авторов ограничена, так как источником является WIP-модель, а
требования к ее проверке перед экспортом не критичны.
● Approval – Согласование:
• материалы, отражающие процессы согласований проектных решений между
участниками процесса.
Как правило, представлены файлами запросов разнообразного формата
и файлами подтверждений с легитимными подписями.
Являются историей принятия решений и могут выступать подтверждениями при
разбирательствах.
● Assignments – Задания
• проверенные и утвержденные данные, передаваемые другим участникам
процесса как основание для разработок.
31
Как правило, данные, скопированные из Экспорта и переименованные
в соответствии с установленными процедурами.
Получатель данных копирует их в свою зону Ресурсов.
Автор несет полную ответственность за содержание.
● Delivery – Выпуск/выдача (предоставление определенного результата/продукта)
• файлы выпускаемой документации и другие файлы, передаваемые заказчику.
По сути, история формирования конечного продукта.
Из этих файлов формируются данные в зоне Published.
Автор несет полную ответственность за их содержание.
Доступ к этим данным может быть предоставлен заказчику.
● Другие процессы, требующие обособленного управления данными.
По всем процессам ведутся реестры передачи данных в соответствии с регламентами,
установленными в организации.
4.01.3 Опубликованные (PUBLISHED)
В этой зоне сохраняются данные, представляющие собой предмет обязательств проектной
организации перед заказчиком (электронную версию): конечный результат работы,
проверенный, согласованный и утвержденный в соответствии с установленными
процедурами. Может быть представлен как электронными 2D-чертежами, полученными из
BIM, так и исходными и/или экспортированными BIM-моделями. Основная и единственная
функция зоны Published – предоставление данных заказчику.
● В зоне Published сохраняются только последние версии выдаваемых заказчику
материалов.
● Все данные, относящиеся к процессу выпуска и в целом к формированию данного
конечного продукта, сохраняются в зоне Shared.
● Опубликованные данные должны быть упорядочены наиболее простым и понятным
для заказчика образом, но с соблюдением требований к именованию этого
Протокола.
● Формат и состав данных, размещаемых в этой зоне, определяется договорными
отношениями с заказчиком и описывается в BIM Исполнительном плане проекта.
● Состав публикуемой документации должен быть изложен в начале процесса
публикации для формирования целостного представления о ней. Описание состава
создается в Реестре Актуальной Документации (Actual Documentation Registry) и
актуализируется в процессе выпуска документации.
● Проектная документация (электронная версия) передается заказчику посредством
однократного предоставления доступа к Реестру Актуальной Документации и
создания в нем интерактивных ссылок на соответствующие файлы.
32
4.01.4 Архив (ARCHIVE)
Ключевое определение для размещаемых данных – Завершенные Проекты и Утратившие
Актуальность Данные.
В этой зоне сохраняются все данные из всех рабочих зон (кроме временных и удаленных) по
окончании работ с ними. Хранение осуществляется так долго, как это установлено
требованиями компании к архивным материалам.
● Структура данных в этой зоне полностью идентична структуре архивируемых зон
данных.
● Данные перемещаются в архив и ни в коем случае не копируются во избежание
дублирования информации.
● Общий доступ к архивным данным ограничен только чтением.
● При необходимости возобновления работы с заархивированными данными эти
данные перемещаются в соответствующие рабочие зоны.
● Проектные данные могут перемещаться в архив постепенно, папками стадий
проектирования, папками рабочих групп, отдельными файлами версий рабочих
данных.
● Перед архивированием данные должны пройти проверку на полноту,
упорядоченность и отсутствие посторонней информации.
● Архивные данные очищаются от папок, оказавшихся пустыми, а также от
создаваемых программным обеспечением файлов резервных копий, блокировки,
предпросмотра и прочих технических файлов, сопутствующих работе.
33
Рис. 4: Обмен данными между разными дисциплинами
4.02. БЕЗОПАСНОСТЬ И СОХРАННОСТЬ ДАННЫХ
Все данные BIM-проекта находятся на сетевых серверах, которые подвергаются
регулярному резервному копированию и репликации, а также обладают высоким уровнем
отказоустойчивости.
Доступ персонала к данным BIM-проекта, находящимся в сети серверов, регламентируется
правами доступа.
По умолчанию ко всем данным предоставлен доступ для чтения.
Права на запись предоставляются рабочим группам на уровне соответствующих папок в
структуре папок проекта.
Для наглядности зона SHARED
изображена здесь как одна
заштрихованная область.
В действительности это могут
быть синхронизированные
размещения для каждого
участника.
34
4.03. ДОСТУП ДЛЯ НЕ-РАЗРАБОТЧИКОВ
Участники процесса, в задачи которых не входит редактирование информации, должны
использовать ПО для просмотра и нередактируемые форматы данных. Доступ таких
участников к данным должен быть ограничен только чтением на уровне IT-инфраструктуры.
ПО и сервисы, необходимые для безопасного просмотра данных (без возможности
несанкционированного редактирования), определяются в BIM Исполнительном Плане.
35
5. ИНТЕРОПЕРАБЕЛЬНОСТЬ
5.01. ОБЩИЕ ПРИНЦИПЫ
Интероперабельность (англ. interoperability – способность к взаимодействию) – это
способность продукта или системы, интерфейсы которых полностью открыты,
взаимодействовать и функционировать с другими продуктами или системами без каких-либо
ограничений доступа и реализации.
Взаимодействие между программными продуктами является одной из важнейших
составляющих успешной BIM-работы, поскольку оно существенно влияет на
взаимодействие между специалистами и рабочими группами и дает возможность получать
сводные и взаимно совместимые BIM-модели. Методы создания и подготовка BIM-
моделей в конечном счете определяют успешное применение данных в других программных
пакетах и технологиях, как при представлении в 2D, 3D (4D-6D), так и при обмене
информацией.
Взаимодействие с другими платформами и дисциплинами должно следовать концепции
OPEN BIM, позволяя смежным специалистам эффективно работать с предоставляемыми
моделями, данными и иным генерируемым BIM-контентом.
Обмен BIM-данными также должен соответствовать рекомендациям, изложенным в ISO
19650-1 и ISO 19650-2. Данный документ содержит ряд необходимых положений,
позволяющих привести среду, данные и рабочие процессы в рамках GRAPHISOFT
ARCHICAD к вышеупомянутым стандартам.
Примечание. Следует принять во внимание недавно выпущенный стандарт ISO 19650
Information management using building information modelling.
36
5.02. ЦЕЛЕВОЕ НАЗНАЧЕНИЕ МОДЕЛИ
Ключевой целью специалиста/группы специалистов в процессе моделирования является
предоставление заказчику чертежей требуемого состава и детализации, а также моделей,
соответствующих требованиям заказчика к информации (если такие имеются) в рамках
данной дисциплины. Исходя из этого, BIM-данные должны формироваться в соответствии с
основной целью – выполнением обязательств перед заказчиком.
Подготовку, проверку и обмен BIM-данными необходимо осуществлять с учетом требований
принимающих программных приложений; для обмена использовать надежные данные, не
содержащие ошибок и существенных недоработок. При этом задача предоставления
CAD/BIM-данных другим группам проектировщиков является сопутствующей, и подготовка
данных для смежных групп не должна существенно влиять на исходную модель.
Предоставление данных обмена следует строить на принципе единства источника (модели)
посредством создания видов (представлений) исходной модели, а создание дубликатов
исходной модели с последующей адресной доработкой под получателя рассматривать как
исключение и согласовывать с ответственным BIM-специалистом.
В подготовке видов модели для обмена надо ориентироваться на универсальное
и управляемое представление, удовлетворяющее большинство реальных и потенциальных
получателей, а процесс предоставления такой универсальной информации максимально
автоматизировать.
При адресной подготовке данных для специфических получателей изначально необходимо
попытаться включить требуемые данные в универсальное представление; при
невозможности или усложнении универсального представления создать отдельное
представление единой модели, и только при невозможности последнего создавать
дублирующую модель (2D-чертеж) и дорабатывать ее до требуемого получателем
состояния и/или ориентироваться на доработку модели получателем.
В процессе моделирования на этапах подготовки данных к передаче, при отсутствии
окончательных решений, необходимо придавать модели законченное состояние для
данного этапа.
37
5.03. ОБМЕН CAD-ДАННЫМИ
Все входящие/исходящие CAD-данные должны быть размещены в соответствии с принятой
структурой CDE и BIM-стандартом компании.
Входящие данные должны размещаться в отдельной директории, в том виде, названии и
формате, в которых они были получены. Впоследствии их следует скопировать в рабочие
папки проекта и подвергнуть проверке/валидации перед использованием.
Модификации входящих CAD/BIM-данных должны быть санкционированы ответственным
BIM-специалистом, а их количество сведено к минимально необходимому для приведения
данных в состояние, пригодное для применения в проектировании.
Чтобы обеспечить корректный и эффективный обмен CAD-данными, следует тщательно
подготовить трансляторы для каждой из платформ, участвующих в обмене.
CAD-данные должны быть выполнены в принятой системе координат. Подробности см. в п.
7.04.
5.04. ОБМЕН BIM-ДАННЫМИ
Основным форматом для обмена BIM-данными является формат IFC (зарегистрированный
и описанный в ГОСТ Р 10.0.02-2019/ИСО 16739-1:2018). Спецификация IFC2x3
поддерживается большинством программных продуктов, задействованных в BIM;
спецификация IFC4 поддерживается в меньшей мере.
Необходимо регулярно отслеживать в программном обеспечении изменения,
затрагивающие процессы обмена с помощью IFC-формата. В некоторых случаях
рекомендуется использовать дополнительные расширения для более точного обмена со
смежными платформами.
Так же, как и в случае CAD-обмена, все входящие данные должны быть приняты в исходном
виде и впоследствии перемещены в рабочие директории.
Чтобы обеспечить корректный и эффективный обмен BIM-данными, необходимо тщательно
подготовить трансляторы для каждой из платформ, участвующих в обмене.
В отличие от CAD-специфики, полноценный обмен BIM-данными значительно сложнее и
требует более тщательного подхода. Для успешного обмена следует придерживаться
следующего:
● понимание целевого назначения модели/моделей и их предполагаемого
использования;
● понимание специфики работы и экспорта/импорта каждой платформы, участвующей
в обмене;
● максимально корректное и тщательное моделирование, в особенности с точки зрения
геометрического представления. Крайне важно придерживаться требуемого уровня
детализации (LOD);
38
● проверка правильности настроек каждой из платформ, в особенности настроек
трансляции;
● своевременная реакция на возникающие проблемы, учет опыта предыдущих
решений.
5.05. ОБМЕН МЕЖДУ ПРОГРАММНЫМИ ПЛАТФОРМАМИ
Для правильной подготовки данных обмена необходимо изучить и описать в BEP проекта
требования и ограничения целевых программных/аппаратных систем.
Регламент обмена данными между различными программными/аппаратными системами
перед утверждением должен быть протестирован для обеспечения целостности данных.
Независимо от формата вывода данных обмена из BIM (2D, 3D и т.д.) эти данные должны
быть применимыми в команде, разумно соответствовать действующим стандартам проекта
и позволять легко манипулировать контентом файла (например слоями).
Для упрощения обмена данными и всей командной работы необходимо разрабатывать
единую стандартизированную контентную среду (в рамках проекта, дисциплины, компании),
основанную на международных классификаторах, таких как, например, Uniclass, Uniformat,
CCS и др., и применять таблицы экспорта контента.
При экспорте данных необходимо отдавать предпочтение платформонезависимым
форматам передачи данных в 3D (например IFC) и широко распространенным 2D (DWG,
PDF).
39
6. СТРУКТУРА МОДЕЛИ
6.01. ОБЩИЕ ПРИНЦИПЫ
Для разделения модели проекта в ARCHICAD существует множество различных причин – от
необходимости решать вопросы производительности в рамках крупных и сложных проектов
до организации эффективной коллективной работы или междисциплинарного обмена. Ниже
перечислены наиболее часто встречающиеся типы разделений:
● Организация коллективной работы – позволяет более гибко переформатировать
рабочий процесс, распределив отдельные части модели между функциональными
командами и минимизируя временные затраты на авторизацию внесения изменений
в модель.
● Функциональная логика – некоторые объекты представляют собой комплексные
системы, подсистемы которых могут по-разному применяться в других локациях
проекта, что делает целесообразным их выделение в отдельные файлы. Хорошим
примером служат жилые комплексы: их фасады, планировки, кровля могут
варьироваться в различных секциях, где проектировщики используют их как
«конструктор».
Также может пересекаться по назначению с предыдущим и следующим пунктом.
● Повторяющиеся, типовые элементы – элементы/группы элементов, которые без
каких-либо изменений повторяются в целом ряде локаций либо являются
определенным «типообразующим» элементом модели.
● Проектная логика – проект может иметь различные стадии, очереди, в которых
должна существовать лишь определенная часть модели. Кроме того, это может быть
оговорено в специфических условиях MIDP.
● Внешние ссылки – модели других дисциплин, ПО или проектных команд могут быть
включены как отдельные файлы для обеспечения лучшей координации
и согласованности проектных решений.
Следует понимать, что, разделяя модель на части, мы получаем потенциальные
проблемные точки в местах стыковки, поэтому необходимо заранее проработать
и согласовать структуру разделения модели со всеми ключевыми участниками проекта и
внести необходимую информацию в BEP.
Кроме того, при разделении/сведении моделей следует уделять максимальное внимание
пространственной координации (п. 7.04) для предотвращения возможных коллизий.
Логика разделения моделей также должна быть отражена на уровне файлов системы, папок,
наименований файлов моделей и других данных в соответствии и с принятым регламентом
компании.
40
6.01.1 2D- и 3D-разделение
При необходимости могут быть разделены модель и генерируемые из нее двумерные
данные. Как правило, отделяется структура документации, в которую подключаются либо
внешние чертежи, либо конкретные виды из файла модели. Такой подход зачастую
обусловлен:
● размером модели/файла;
● производительностью модели/файла;
● специфической структурой выпуска;
● доступом к данным (в том числе по соображениям безопасности).
В то же время при отделении двумерной части нарушается прямая связь между самой
моделью и ее производной в виде документации. Также это ведет к частичной потере
функциональности системы выпуска, поэтому, где это возможно, такого разделения
следует избегать.
6.01.2 Функциональное разделение
Как уже сказано, в ряде случаев необходимо обеспечить коллективную работу нескольких
функциональных команд или специалистов. Там, где это возможно и рационально, следует
использовать Teamwork (рациональность заключается во взвешенном подходе к выбору
файлов для коллективной работы. Не имеет смысла загружать в Teamwork файл,
состоящий, например, из небольшой группы элементов – обычно для таких целей
выбираются более комплексные логические объекты уровня секций, блоков, домов, в
крайнем случае отдельных крупных частей модели).
В Teamwork данные модели можно гибко перераспределить между различными
пользователями/группами, основываясь на резервировании элементов и используя заранее
предустановленные роли пользователей.
Если использование Teamwork не представляется возможным, производится разделение
модели на модули/внешние файлы (Hotlinked Sources), интегрированные с конечной хост-
моделью (файлом, в который они подключаются).
6.02. ВНУТРЕННЕЕ РАЗДЕЛЕНИЕ
Под внутренним разделением подразумевается комплекс действий по разбивке модели на
определенные части с применением штатного функционала ARCHICAD. В данном случае
это система Связанных Модулей (Hotlinks).
Несмотря на то что для разделения может быть применен достаточно большой перечень
расширений, рекомендуется использовать модули (файлы с расширением .mod), если
необходимо разбить непосредственно модельную часть – эти файлы содержат только
41
размещенный объектный контент и значительно эффективнее с точки зрения
производительности.
Необходимо убедиться, что при подключении внешних Связанных Модулей используется
корректный этаж (уровень) и правильная СК (система координат) для размещения. Слой
также должен быть заранее создан и определен для размещения модулей конкретного типа
(например, слои для моделей конструктива, инженерии и т.п.).
Несмотря на то что подключаемый внешний файл может наследовать структуру этажей
хост-файла, его структура должна быть максимально идентичной структуре последнего,
особенно в общих логических пространствах.
Все элементы должны принадлежать корректному (своему) этажу, независимо от сложности
модульной структуры.
Примечание. Следует понимать, что все реквизиты передаются по иерархии «снизу
вверх», то есть от модуля нижнего уровня и до конечного хост-файла. Это может
оказаться серьезной проблемой в крупных проектах со сложной модульной структурой,
поэтому необходимо поддерживать реквизитную среду в надлежащем состоянии – в
соответствии с пунктами, изложенными в разделе 8.05.
6.03. Внешние данные
Обмен данными со смежными дисциплинами или другими платформами
с непосредственным подключением их файлов можно рассматривать как часть процессов
разделения (и сведения) моделей.
6.03.1 Двумерные данные – DWG
Внешние DWG-файлы могут быть подключены тремя разными способами:
● Внешний чертеж – позволяет контролировать слои и наборы перьев размещенного
чертежа на уровне его персональных настроек.
● Прикрепленный Xref – позволяет более комплексно управлять входящей
информацией с помощью транслятора (в настройках Xref) и слоями на уровне
Менеджера Реквизитов. Поддерживает обновление размещенных чертежей, при
выгрузке автоматически удаляет все использовавшиеся реквизиты.
● Промежуточный PLN – DWG-файл импортируется во внешний PLN-файл, где
подвергается очистке и обработке, после чего подключается как стандартный
Связанный Модуль (Hotlink).
Рекомендуется использовать Xref-метод как оптимальное сочетание контроля
и оперативности. Для размещения DWG-файлов рекомендуется использовать Рабочие
Листы (worksheets).
42
6.03.2 Трехмерные данные – IFC
Внешние IFC-файлы рекомендуется подключать с помощью Менеджера Связанных
Модулей (Hotlink Module Manager) – такой способ обеспечивает удобство регулярного
обновления с уже заранее настроенными параметрами импорта.
Для более точной настройки желательно использовать отдельный транслятор импорта для
каждой дисциплины или платформы (например, транслятор для импорта сетей ОВ, для
импорта конструкций и т.п.).
При необходимости жестко выделить конкретные типы элементов при импорте следует
использовать фильтр модели в настройках трансляции.
Для каждого раздела импорта следует предусмотреть в соответствующих настройках
процессы конвертации геометрии, типов элементов, наборов свойств, слоев и материалов.
Поскольку модель является ссылочной и не используется для последующего
редактирования, рекомендуется «свернуть» все потенциальные слои внешней модели в
один, который заранее определен реквизитной средой. При
невозможности/нецелесообразности такого подхода необходимо использовать конвертацию
слоев, задав каждому входящему слою новое соответствие, согласованное с текущей
системой реквизитов проекта.
Рис. 5: Пример настройки IFC-транслятора
43
Все внешние ссылки должны быть корректно размещены относительно структуры проекта в
среде общих данных и следовать установленным правилам наименования.
Примечание. Зачастую в рабочие файлы архитектурной модели посредством IFC-ссылок
подключаются внешние ссылки смежных дисциплин. Наиболее часто это конструктив
(бетонные и металлические конструкции). На практике конструктив все чаще
подключается целиком не только для пространственной координации – впоследствии он
становится частью модели, из которой формируется проектная документация
(например, КБ), без непосредственного редактирования исходной модели.
Рис. 6: Пример IFC-ссылки металлоконструкций
Однако при выдаче трехмерной модели раздела (в данном случае АР) в качестве задания
для смежников необходимо исключить все внешние ссылки на модели других разделов,
поскольку в противном случае при публикации они каждый раз будут дважды
конвертироваться (сначала преобразовываясь в элементы среды ARCHICAD, а затем из
этих элементов в среду иной программы), что критически негативно скажется на их
итоговом качестве.
Вместо этого смежные специалисты должны параллельно подгрузить раздел АР и
прочие необходимые дисциплины (например, АР + КБ и КМ) как отдельные внешние
ссылки.
44
7. МЕТОДОЛОГИЯ МОДЕЛИРОВАНИЯ
Следует понимать, что модель может иметь различное предназначение (BEM – BIM Energy
Model, BAM – BIM Asset Management и т.п.), принадлежать различным фазам и этапам
проекта, что в каждом конкретном случае диктует определенные требования к
моделированию. Такие требования должны быть заранее формализованы и описаны в BEP
проекта.
7.01 БАЗОВЫЕ ТРЕБОВАНИЯ
● Все модельные элементы должны быть созданы с помощью нативных инструментов
и компонентов: стены смоделированы инструментом «Стена», балки – инструментом
«Балка» и т.д. Если специфический элемент не может быть смоделирован с
использованием штатного инструмента, необходимо подобрать максимально
удобный в использовании другой нативный элемент (например, для свай могут
использоваться различные типы колонн) при согласовании данного решения BIM-
специалистом.
● Все использующиеся элементы проекта рекомендуется привести в строгое
соответствие стандартным IFC-типам: IfcBeam, IfcColumn, IfcSlab и т.д. Это может
потребовать проверки принятой системы классификации элементов и их
последующей трансляции в типы.
● Каждый элемент должен принадлежать конкретному слою, классификации, иметь
соответствующий набор свойств, статус реконструкции и корректно отображаться с
учетом всех примененных графических настроек (модельных видов, графической
замены и т.д.).
● Как правило, модель вертикально разделяется на определенные этажи (уровни),
отражающие реальное положение вещей. Все элементы должны быть поэтажно
разделены, принадлежать корректному Собственному Этажу. Следует принять во
внимание специфику моделирования этажей (уровней) в различных дисциплинах –
например, для архитектурных и конструктивных моделей.
7.02. УРОВНИ ПРОРАБОТКИ
Требования к контенту модели зависят от ее целевого назначения и конкретного этапа/фазы
проекта. Проработку модели можно условно разделить на три ключевых уровня/степени:
Уровень 1. Целевое назначение модели – базовое взаимодействие и коммуникация
между основными разработчиками. Расположение и упрощенная геометрия модели
соответствуют требованиям, все элементы здания содержат лишь минимальную
описательную часть.
(Например для ранних стадий проекта: концепция, эскиз).
Уровень 2. Целевое назначение модели – предварительный проект и/или проект с
осуществлением анализа энергоэффективности, проработкой проектных решений,
предварительных подсчетов, базовой координации дисциплин. Расположение и
45
геометрия модели соответствуют требованиям, все элементы здания корректно
наименованы и смоделированы таким образом, чтобы обеспечить возможность
получения необходимых и достаточных расчетов и других данных непосредственно
из модели.
(Например для стадий ПП, П).
Уровень 3. Целевое назначение модели – выдача строительной документации,
обеспечение планирования строительства и необходимых закупок подрядчиком,
сопровождение строительства и др. Расположение и геометрия модели
соответствуют требованиям, необходимая и достаточная для подрядчика
информация прикреплена к элементам модели таким образом, который обеспечивает
возможность получения всех необходимых спецификаций, ведомостей таких
элементов (типы окон, заводские размеры, шумозащита и др.).
(Например для стадий Р, РП, РД).
Уровень проработки должен быть заранее согласован и утвержден в начале проекта
с последующим описанием в BEP-документе.
7.03. СОЗДАНИЕ И ДЕТАЛИЗАЦИЯ КОМПОНЕНТОВ
Все созданные или полученные иным путем компоненты необходимо рассортировать,
назвать и сохранить, соответственно, в проекте или в центральной структуре папок. Как
правило, это библиотечные элементы, общие требования к которым сформулированы в
разделе 8.07.
Элементы должны быть рассортированы следующим образом:
Рис. 7: Уровни детализации компонентов
● Компонент степени LOD100 – Схематический
Символический элемент, представляющий объект, который может быть
46
внемасштабным и безразмерным. В частности, это применимо к электрическим
символам, которые зачастую не представляют в виде 3D-объектов.
● Компонент степени LOD200 – Концептуальный
Простой элемент с самым низким уровнем детализации – например, стул любого
типа. Приблизительные размерные данные. Создан из условного материала.
● Компонент степени LOD300 – Обобщенный
Условная модель, минимально необходимая для определения типа, а также
материала. Обычно содержит двумерное отображение для предпочтительного
масштаба. Размеры могут быть неточными.
● Компонент степени LOD400 – Определенный
Содержит релевантные метаданные и техническую информацию. Смоделирован на
таком уровне, чтобы можно было определить тип и материалы компонентов.
● Компонент степени LOD500 – Реалистичный / для строительства
Детальный, точный, соответствующий строительным требованиям элемент модели,
содержащий все необходимые подрядчику геометрические и контентные данные.
Используется, если 3D-вид при определенном масштабе требует, чтобы
отображались детали, необходимые в связи с близким расположением объекта к
камере.
7.04. ПРОСТРАНСТВЕННОЕ РАСПОЛОЖЕНИЕ И КООРДИНАЦИЯ
Как указано в BS1192:2007+A1:2015, все BIM-проекты должны:
● использовать применяющиеся в мировой/местной практике системы координат;
● размещаться на реальной высотной отметке;
● все BIM-файлы и данные должны быть скоординированы относительно принятой СК
(системы координат).
Как показывает практика, традиционно используемые для пространственной координации
инструменты и предметы (такие как координационные оси в чертежах и реперы на
местности) не являются гарантированно статичными и, как следствие, менее надежны, чем
абстрактно принятая, но связанная с системой высшего порядка система координат.
При этом наличие систем координат с неизменным началом практически во всех
программных решениях для моделирования делает координатное взаимодействие очевидно
логичным.
Учитывая тот факт, что зачастую именно архитекторы первыми создают свои эскизные
модели и предоставляют экспортные данные смежным дисциплинам, на них лежит
ответственность за инициацию корректной и согласованной системы координат проекта.
47
7.04.1 Общие принципы пространственной координации
Ключевым условием для непротиворечивого и согласованного совмещения моделей,
пространственной координации проекта (необходимых для успешного BIM-взаимодействия
всей проектной команды) является оперирование системами координат как единственным
механизмом пространственной координации.
● Пространственная координация всех моделей в проекте осуществляется
исключительно посредством совмещения систем координат моделей.
● Совмещение моделей осуществляется методом подключения ссылок, единственной
точкой совмещения которых является точка начала координат. Таким образом
совмещение моделей по сути является совмещением файлов, их систем координат.
● Слияние моделей, копирование/вставка элементов также осуществляются
относительно начала координат моделей.
● Совмещение моделей по точкам начала их систем координат понимается как
совмещение без изменений расположения (в случае, когда в совмещаемых моделях
применена одна и та же система координат), так и со смещением X, Y, Z и поворотом
α, четко, осознанно и регламентированно задаваемыми пользователем (если
системы координат разные).
● Некорректное совмещение элементов моделей при корректном совмещении их
систем координат свидетельствует о нарушении единства систем координат моделей
или ошибках моделирования, которые необходимо устранить, модифицируя
элементы моделей относительно систем координат, а не совмещая модели, опираясь
на элементы или каким-либо другим способом.
● Система координат всех моделей проекта должна быть определена/задана
однозначно и исчерпывающе.
● Единожды установленная система координат модели должна быть неизменной на
протяжении всего жизненного цикла проекта.
● Система координат модели может быть изменена только если была задана ошибочно
(произвольно) или существенно изменились исходные факторы, и это изменение
должно быть строго регламентировано.
● Установка и изменение систем координат моделей осуществляются методом
смещения элементов модели в файле модели относительно точки начала координат
файла – и никаким другим способом. То есть началом координат модели является
предопределенное и неизменное начало координат файла, а его определение и
изменение для модели является по сути модификацией модели относительно начала
координат.
● Системы координат разделяются на два основных типа:
• исходные – определяются из исходных данных по проекту;
• проектные – задаются проектной командой.
● Проектные системы координат могут быть:
48
• едиными для всего проекта;
• комплексными, многоуровневыми, масштабно-иерархическими;
• комбинированными.
● Исходная система координат и тип проектной системы координат определяются и
описываются в BIM исполнительном плане проекта (BEP) в начале проекта, а в
случае их изменения производятся дополнительные записи с обоснованием причин
и сохраняется вся история таких изменений.
7.04.2 Система Координат Здания (СКЗ)
Здания являются ключевыми объектами проектирования, и, независимо от того, какой тип
системы координат будет принят в целом по проекту, к системам координат моделей зданий
предъявляются неизменные требования.
Рис. 8: Пример начала СКЗ
● СКЗ определяется BIM-специалистами совместно с рабочей группой, первой
начинающей работу над моделью здания (как правило архитектурной).
● Начало СКЗ принимается наиболее удобным и приближенным к сооружению. При
этом следует избегать совпадения (наложения) с элементами здания, так как при
совмещении моделей объектная привязка к элементам модели может затруднить
точную привязку точек начала СКЗ.
● X и Y точки начала СКЗ принимаются обусловленными геометрией сооружения в
плане. Следует выявить наиболее статичную точку, опираясь на которую будет
логично и удобно модифицировать модель. Как правило, под такое определение
подходят точки пересечения композиционных осей здания, осей симметрии, центры
композиционного вращения.
49
● Z начала СКЗ должен соответствовать отметке 0,000 сооружения.
● Ориентация модели в СКЗ принимается горизонтальной по длинному габариту
сооружения.
● В случаях, когда в сооружении заложено несколько композиционных (структурных)
сеток, в том числе повернутых, веерных, радиальных, начало координат всех сеток
должен совпадать с СКЗ, как и точка поворота (если таковая есть).
● Точка начала СКЗ является единственной точкой совмещения моделей разделенных
частей и систем здания, выполненных в различных файлах.
Также не исключено, что СКЗ может быть принята как проектная система координат в случае
разработки, например, типового или концептуального сооружения без привязки к конкретной
местности.
7.04.3 Единая Система Координат Проекта (ЕСК)
Для проектов, представленных одним сооружением (возможно с несколькими
незначительными сопутствующими), принимается Единая Система Координат Проекта
(ЕСК), которая распространяется на все модели проекта.
● ЕСК определяется BIM-специалистами совместно с рабочей группой, первой
начинающей работу над моделью объекта (как правило архитектурной).
● ЕСК является системой координат (СКЗ) основного сооружения, расширенной на
весь участок проектирования, и на нее распространяются соответствующие
требования (см. раздел Система Координат Здания).
● Смещение и поворот ЕСК относительно Исходной системы координат (и высот)
должны быть округлены до наибольшего возможного порядка – для упрощения
совмещения моделей и конвертации систем координат в обоих направлениях.
● Точка начала ЕСК должна быть графически/объемно зафиксирована во всех моделях
уровня участка и сборок здания (крупных блоков здания) как минимум в координатах
X и Y.
● Смещение и поворот ЕСК (ее начальной точки и поворота) относительно Исходной
системы координат должны быть задокументированы в BIM исполнительном плане
проекта в виде таких позиций:
• 0,0 по X, Y ЕСК в координатах Исходной системы;
• 0 по Z в системе высот Исходной системы;
• угол поворота ЕСК (оси X) относительно Исходной системы (оси,
тождественной X в ЕСК) против часовой стрелки, в градусах с десятичными
долями (0,00° ⩽α < 360,00°).
50
=er 7.04.4 Комплекс Систем Координат Проекта (КСК)
Крупные и сложные проекты характеризуются такими особенностями, усложняющими
пространственную координацию:
● два и более отдельных равнозначных объекта;
● две и более зоны участка застройки с различными (как правило в повороте)
базисными сетками, определяющими размещение сооружений, инженерных сетей,
благоустройства и пр.;
● объекты и их модули, многократно применяемые в проекте, при этом как масштабов
здания и групп зданий, так и масштабов оборудования и мебели.
В контексте представленных особенностей крупных и сложных проектов использование ЕСК
для всего проекта нецелесообразно, так как логичное ее применение в одном случае делает
нелогичным все остальные применения.
Комплекс систем координат проекта (КСК) является строго упорядоченной по уровням
(обусловленным масштабом) иерархией систем координат. Благодаря сложной структуре
КСК возможно применение принципа координатного взаимодействия на проектах любых
размеров и уровня сложности.
В КСК строго определены пять уровней систем координат и их иерархия (Исходная система
координат (ИСК) считается уровнем 0). Уровни КСК:
1. Участка;
2. Базиса;
3. Здания (сооружения);
4. Модуля (секции);
5. Элемента.
Рис. 9: Пример системы координат Участка
51
● СК Участка является приведением (смещением) ИСК к значениям, более удобным
для работы над проектом. К ней предъявляются такие требования:
• СК Участка определяется BIM-специалистами совместно с рабочей группой,
первой начинающей работу над моделью по участку;
• СК Участка фиксируется в BIM Исполнительном плане проекта и графически
отображается в модели участка;
• СК Участка задается смещением относительно ИСК по X, Y, Z с округлением
до наибольшего возможного порядка;
• СК Участка задается без поворота относительно ИСК;
• X и Y точки начала СК Участка устанавливаются ниже и левее за пределами
участка для получения преимущественно положительных значений координат
в пределах участка;
• Z точка начала СК Участка устанавливается соответствующей отметке 0,000
ключевого здания, или приближенной к низшей точке участка, или
соответствующей другой отметке, обоснованной спецификой проекта.
Рис. 10: Пример определения СК Базиса на участке
● СК Базиса – система координат Базисной зоны на участке. Обеспечивает
ортогональность расположения и наиболее целые значения координат элементов
внутри Базисной зоны, точек начала СК размещаемых зданий. При этом:
• СК Базиса определяется BIM-специалистами совместно с рабочей группой,
ведущей детальную разработку по участку, рассматривается комплексно
для всех зон проекта и должна подчиняться единой логике для всех зон;
52
• начало координат и направление осей СК Базиса графически
отображаются в модели участка;
• СК Базиса задается смещением относительно СК Участка по X, Y;
• СК Базиса задается без смещения по Z;
• СК Базиса задается с поворотом относительно СК Участка, при этом
исключая визуальный переворот СК (-90° ⩽α⩽ +90°);
• начало координат и поворот СК Базиса определяются проектными
(композиционными) решениями по участку и, как правило, привязываются к
существующим элементам (границам участка, осям дорог,
ограничительным линиям и т.д.).
Рис. 11: Пример системы координат здания
● СК Здания – система координат уровня здания, на которую распространяются
требования, изложенные в разделе Система Координат Здания, и в контексте КСК
предъявляются дополнительные:
• СК Здания рассматривается и определяется комплексно для всех зданий
проекта и должна подчиняться единой логике;
• СК Здания является внутренней, ее определение не должно зависеть от
систем высшего порядка;
• начало координат и направление осей СК Здания графически отображаются в
модели здания;
• точка начала СК Здания является единственной точкой размещения здания в
СК Базиса.
53
Рис. 12: Пример систем координат модулей в здании
● СК Модуля (Hotlink) – система координат модулей, блоков, секций, составляющих
здание (как правило, повторяющихся или подобных в рамках одного проекта либо
четко выделяющихся из единого объема здания и при этом представляющих собой
во многом автономное завершенное целое в рамках здания), на которую
распространяются требования, изложенные в разделе Система Координат Здания, и
в контексте КСК предъявляются дополнительные:
• СК Модуля рассматривается и определяется комплексно для всех модулей
проекта и должна подчиняться единой логике;
• СК Модуля является внутренней, но ее определение не должно учитывать
системы высшего порядка, логику СК Зданий, в которые включаются модули;
• начало координат и направление осей СК Модуля графически отображаются в
модели;
• точка начала СК Модуля является единственной точкой размещения модуля в
СК Здания.
● СК Элемента – система координат небольших частей зданий, как правило
размещаемых в различных местах:
• СК Элемента обычно определяется разработчиком элемента;
• СК Элемента является внутренней и практически не зависит от систем
высшего порядка;
• в СК Элемента начало координат принимается, как правило, по осям
и характерным точкам установки/монтажа элементов;
• точка начала СК Элемента не обязательно является единственной точкой
размещения модуля в СК Здания или Модуля.
54
7.04.5 Другие решения
На практике применение описанных выше систем координат проекта в чистом виде зачастую
оказывается невозможным и/или нецелесообразным. Характерным примером может
служить здание или участок с решениями, геометрически основанными на иррегулярных
сетках. Поэтому каждый проект должен рассматриваться индивидуально, а описанные выше
принципы пространственной координации применяться оправданно и гибко, в том числе в
комбинированных сочетаниях, что должно быть отражено в BIM Исполнительном плане
проекта (BEP).
7.04.6 Специфика ARCHICAD
Для определения точки начала координат (НК) в проекте ARCHICAD крайне не
рекомендуется использовать смещение с помощью пользовательского НК, поскольку это
может привести к внутренним нарушениям координатной системы. Возвращение точки в
исходное положение не всегда может устранить проблему, особенно в разрезе IFC-обмена
со смежными дисциплинами и платформами.
Примечание. Ситуацию со сбившимся НК в некоторых случаях может исправить
размещение IFC Survey Point с последующим изменением настроек трансляции, при
котором «якорь» привязки должен быть изменен с ARCHICAD НК на Точку Привязки (IFC
Survey Point).
7.05. ЕДИНИЦЫ ИЗМЕРЕНИЯ
● Единицы измерения должны быть согласованы в рамках всего проекта, что может
оказаться остро актуальным при работе с зарубежными партнерами.
● Единицы измерения подразделяются на рабочие и выводимые:
• рабочие – используются при разработке моделей и другого контента проекта;
• выводимые – используются в выдаваемой документации.
● Рабочие единицы измерения по умолчанию устанавливаются с наибольшим
возможным количеством знаков после запятой – во избежание неточностей
в моделировании.
● Для выводимых единиц измерения количество знаков после запятой принимается в
соответствии с нормативными требованиями или требованиями заказчика, что
должно быть задокументировано в BIM Исполнительном плане проекта.
● Для разных масштабов разработки применяются различные единицы измерения
длин и площадей:
• городской – километры и тысячи гектаров;
• участка – метры и гектары;
• объектный и меньший – миллиметры и квадратные метры.
55
● Единицами измерения объемных величин по умолчанию принимаются метры
кубические.
● Единицами измерения угловых величин по умолчанию принимаются градусы
с десятичными долями.
● Любые отступления от данных требований к единицам измерения должны быть
задокументированы в BIM Исполнительном плане проекта.
7.06. ДВУМЕРНАЯ ДЕТАЛИЗАЦИЯ МОДЕЛЕЙ
В определенных ситуациях допускается использование двумерной информации (чертежей)
для дополнительной детализации модели.
● В BIM Исполнительном плане проекта должно быть четко указано, когда
заканчивается 3D-геометрия и начинается детализация в 2D при подготовке
к публикации.
● 2D-черчение должно сопровождать геометрию для достижения требуемого
содержания видов без лишней нагрузки на оборудование. 2D-черчение применимо не
только для детальной/производственной информации.
● Детализацию и повышение степени проработки необходимо применять, не усложняя
модель и при этом не нарушая ее целостность.
8. СРЕДА МОДЕЛИРОВАНИЯ
8.01. ОБЩАЯ СТРУКТУРА СРЕДЫ
Важно понимать, что правильно подготовленная рабочая среда проекта является залогом
качественного и эффективного моделирования и проектирования, значительно упрощая
многие процессы и автоматизируя часть рутинных операций.
В идеале внутренние процессы в рамках такой среды должны напоминать «конвейер», где
отправной точкой является модель, на которую нанизан ряд необходимых параметров и
свойств (реквизиты, наборы свойств, IFC-сопоставления и пр.), в дальнейшем проходящая
графическую обработку с помощью видов, контент которой упорядочен в структуре макетов
документации и подготовлен для пакетной выдачи в Издателе.
Любое изменение в модели должно быть автоматически передано по цепочке вплоть до
уровня публикации.
Обычно выделяют следующие ключевые разделы для настройки среды:
56
● Основные свойства проекта (включая Информацию о Проекте – заметки, авторские
права, изображение предпросмотра, настройки расположения проекта, правила
расчетов и, опционально, рабочее окружение, включающее настраиваемые
пользовательские профили).
● Структура проекта (Навигатор, Виды, Макеты с настройкой системы выдачи,
Издатель).
● Рабочие инструменты (базовые инструменты, ключевые типы элементов,
Избранное).
● Реквизитная среда (Слои, Комбинации Слоев, Типы Линий и Штриховок, Наборы
Перьев, Покрытия, Строительные Материалы, Многослойные Конструкции, Сложные
Профили, Зоны и Профили Эксплуатации, Стили Разметки).
● Контентная среда (управление проектными данными – классификации
и преднастроенные правила, наборы свойств, формулы).
● Библиотеки и компоненты (внешние/внутренние библиотечные элементы,
загружаемые компоненты).
● Графические настройки (настройки отображения, Параметры Модельного Вида,
Графическая Замена, оперативные параметры).
● Настройки интероперабельности/взаимодействия (в большей части – настройки
экспорта/импорта любых форматов, в особенности IFC, настройка IFC-
сопоставлений, настройки для экспорта/импорта данных. Также может включать
специфические настройки для разворачивания модульной среды).
Рис. 13: Структура рабочей среды проекта в ARCHICAD
57
8.02. СВОЙСТВА ПРОЕКТА
Информация о проекте, месторасположение – крайне важные разделы проекта, напрямую
или косвенно участвующие во многих других процессах. Например, с помощью IFC-
трансляции информация о проекте передается в другие программные продукты;
соответственно, она должна быть своевременно внесена и согласована во всех
необходимых разделах.
Информация о Проекте
Учитывая, что информация о проекте передается в IFC-схемах, обязательно должны быть
заполнены следующие поля:
• Project Name – Наименование Проекта;
• Project Description – Описание Проекта;
• Project ID – ID Проекта;
• Project Code – Код Проекта;
• Project Number – Номер Проекта;
• Project Status – Стадия Проекта;
• Site Name – Наименование Участка;
• Site Description – Описание Участка;
• Site ID – ID Участка;
• Building Name – Наименование Здания;
• Building Description – Описание Здания;
• Building ID – ID Здания;
• Contact Email – Электронная почта.
Свойства информации о проекте служат не только для корректного описания объекта в
целом, но и для автоматизации части рутинных операций (например, при оформлении
документации, штампов, аннотировании и пр.).
Все поля, существующие по умолчанию, должны быть заполнены. При необходимости в
каждом из разделов могут быть созданы дополнительные поля.
Следует принять во внимание, что все автотекстовые команды привязываются к внутренним
кодам свойств, автоматически сгенерированных ARCHICAD (например, вида
<![CDATA[PROJECTNUMBER]]>), поэтому их нежелательно изменять в ходе проекта.
Рекомендуется настроить изображение для предпросмотра и в соответствующих разделах
указать авторские права (достаточно большое количество программных продуктов умеет
автоматически считывать эти данные).
В некоторых случаях пользовательские поля информации о проектах могут быть
использованы в специфических целях – например, как временный буфер ввода той или иной
текстовой информации (например, для передачи UID обнаруженных некорректных
элементов в отчете – для последующего их выделения Графической Заменой в целях
облегчения поиска). Такие поля должны быть визуально отделены от общей части
информации о проекте.
58
Расположение Объекта Проектирования
Для каждого проекта необходимо указать направление севера, а также долготу и широту.
Данные могут быть взяты из существующего списка городов в реквизитах проекта либо же
из ГИС-программ или картографических систем (например, Google Maps).
Заполненные данные должны быть тщательно проверены, поскольку могут использоваться
для других аналитических модулей (например, расчета инсоляции) в качестве исходных
данных.
Рабочая Среда Проекта (Единицы и Правила Расчетов)
Для корректных расчетов, отображения необходимых размерных единиц рекомендуется
тщательно настроить каждый из разделов в настройках проекта.
8.03. СТРУКТУРА ПРОЕКТА
Крайне важно выстроить согласованную, понятную и удобную структуру для обеспечения
«конвейеризации» внутренних процессов (модель → конечный результат/документация),
обеспечить максимально автоматическую взаимосвязь на каждом из уровней.
Карта Проекта
Карта Проекта (базовая исходная структура) должна содержать исключительно
необходимые элементы. Все временные, рабочие элементы должны регулярно
подвергаться ревизии и при утрате актуальности удаляться.
Каждый элемент должен иметь свой код, обеспечивая сортировку в рамках своей категории
(например, S01 Разрез 1-1). Код может быть как уникальным, отделяющим необходимый
элемент, так и групповым, делегирующим функцию сортировки непосредственно
наименованию элемента. В особенности это актуально для разрезов, деталей, рабочих
листов и экспликаций, где, как правило, в ходе выполнения проекта создается значительное
количество элементов.
Карта Видов
Карта Видов (структура) должна быть сформирована на базе исходной структуры проекта,
существующей в Карте Проекта, и логически разделена на основе целевого предназначения
видов/групп видов.
Логику разделения рекомендуется согласовать с описанными в PAS 1192-2:2013 и
BS1192:2007 / ISO 19650 зонами данных – в частности, с тремя ключевыми зонами: Рабочей
Зоной (WIP), Зоной Обмена (Shared) и Зоной для Опубликованного (Published). При
необходимости могут быть добавлены пользовательские зоны: Временные (Temporary, для
временного использования. Впоследствии их можно безвозвратно удалить) и Специальные
(для узконаправленных нужд, BIM или другого технического использования, проверки и пр.).
59
Книга Макетов
Верхняя структура Книги Макетов должна придерживаться логики разделения на рабочие
зоны, описанной в PAS 1192-2:2013 и BS1192:2007 / ISO 19650, – то есть WIP, Shared,
Published и другие для обеспечения удобства работы особенно в коллективных проектах или
в проектах со сложной комплектностью выпускаемой документации.
Средний уровень структуры макетов должен соответствовать разделам, представленным
в пп. 4.01.1, 4.01.2, 4.01.3. При необходимости перечень разделов может быть расширен,
если такое расширение не нарушает общую логику структуры. Рекомендуется выстраивать
структуру папок по аналогии с размещением рабочих файлов в среде общих данных, следуя
логике декомпозиции объекта. Например:
Рис. 14: Пример структуры папок
Структура, состав и содержание комплектов определяются действующими официальными
нормативными требованиями.
Каждый макет и Поднабор Макетов должны иметь уникальный и автоматический ID
с наследованием по иерархии наборов/комплектов. Отклонения допускаются только
в обоснованных и исключительных случаях.
60
Рис. 15: Пример структуры книги макетов
Параметры макетов должны быть согласованы и внесены в Схему Выпуска.
Каждый комплект документации должен быть опубликован с использованием Схемы
Выпуска.
Схема Выпуска предоставляет удобный и прозрачный механизм систематизации, выпуска и
хранения информации о выпущенных комплектах в среде ARCHICAD. Следовательно, она
должна быть заранее согласована, настроена и поддерживаться в максимально корректном
состоянии.
ID Редакции Выпуска и листов должны совпадать, рекомендуется использовать трехзначные
числа.
Схема Выпуска должна быть заранее согласована и внесена в систему.
Единожды созданные выпуски не должны корректироваться или удаляться. При
необходимости они могут быть исключены из перечня выпусков в индексах/каталогах
проекта через специальные критерии отбора.
Издатель
Верхняя структура Книги Макетов должна придерживаться логики разделения на рабочие
зоны, описанной в PAS 1192-2:2013 и BS1192:2007 / ISO 19650, – то есть WIP, Shared,
Published и другие, для обеспечения удобства работы особенно в коллективных проектах
или в проектах со сложной комплектностью выпускаемой документации.
Весь нижеследующий контент должен быть автоматической ссылкой из Книги Макетов. При
необходимости допускаются ручные наборы, если они не нарушают структуру и логику
Издателя.
Все свойства каждого набора (метод, пути и т.д.) должны быть заранее определены
и настроены.
61
8.04. РАБОЧИЕ ИНСТРУМЕНТЫ
Все настройки, свойства и характеристики, использующиеся в рабочих инструментах (стена,
окно, балка, линия, размер и т.д.), должны быть заранее определены и настроены. Каждый
инструмент должен содержать необходимый минимальный набор таких настроек.
Инструменты
Настройки по умолчанию для каждого из инструментов должны быть согласованы
с шаблоном и подготовлены для наиболее широко использующегося типа элемента или
оптимального варианта. Следует понимать, что в рабочем процессе типология
инструмента/элемента будет постоянно меняться, поэтому все часто использующиеся
альтернативные версии необходимо поместить в Избранное.
Избранное
Структура избранных элементов должна быть упорядочена и опираться либо на тип
инструмента, его функциональное предназначение, либо на используемую в проекте
систему классификации.
8.05. РЕКВИЗИТНАЯ СРЕДА
Реквизиты проекта – одна из фундаментальных основ всей модели в целом, поскольку они
заключают в себе большую часть всей параметрической информации. Соответственно,
реквизиты требуют особо тщательной настройки и последующей поддержки выработанной
структуры.
Реквизитная среда должна:
● удовлетворять всем необходимым требованиям к параметризации модели, ее
компонентов/частей и отражению их ключевых свойств/характеристик;
● иметь четкую, ясную и логичную структуру, понятную в использовании и поддержке;
● быть максимально унифицированной и стандартизированной, в то же время
предусматривая возможность последующего расширения и добавления новых
реквизитов;
● учитывать специфику ARCHICAD (внутреннюю индексацию реквизитов, логику
поведения при работе с модульной структурой, внешними подключенными IFC-
файлами и др.);
● быть включенной в корпоративный шаблон компании;
● регулярно пересматриваться для актуализации, оптимизации и улучшения с учетом
всех новых данных.
Для эффективной работы с реквизитной средой проекта крайне рекомендуется
придерживаться следующих положений:
62
● при возможности опираться на существующие реквизиты в шаблоне ARCHICAD по
умолчанию (штриховки, линии, покрытия и др.);
● описать структуру реквизитов в сопроводительном документе, при необходимости
содержащем дополнительные поля, описывающие логику построения;
● придерживаться классификационного принципа наименования всех реквизитов,
выделяя условный код реквизита, наименование и, опционально, дополнительное
уточнение. Например:
Z00 Имя Реквизита
Z01 Имя Реквизита, уточнение
Код состоит из одного символа-определения области и двузначного порядкового
номера, обозначающего определенную категорию/подкатегорию конкретного
реквизита. Для кодов реквизитов рекомендуется использовать латинские символы.
Следует проработать систему индексации всех реквизитов, чтобы обеспечить
возможности для расширения и впоследствии упростить контроль над «чистотой»
структуры. Логика индексации может опираться на выбранную кодификацию
реквизитов.
Рис. 16: Пример структуры слоев
Такой подход позволяет логически строить структуру реквизитов, опираясь на
необходимые группы, обеспечивая единые и доступные «правила игры» для всех
участников, позволяя предусмотреть необходимую сортировку реквизитов для
удобства использования, а также условную «глубину» детализации.
При необходимости можно использовать любую из существующих систем
классификации (Uniformat, Uniclass, OmniClass и др.), дополнительно адаптируя ее
под конкретные задачи;
● для создания и редактирования структуры реквизитов удобно использовать
сторонние редакторы, изменяя выгруженный XML-файл реквизитов. Различные
версии/ветки рекомендуется хранить в распределенных системах управления
версиями (git, svn и др.);
● названия и коды/ID реквизитов не должны содержать спецсимволов (это требование
может оказаться критичным при междисциплинарном обмене либо при
взаимодействии с определенными программными продуктами).
Рекомендации для категорий реквизитов:
63
Слои
Несмотря на то что система слоев еще активно используется, необходимо понимать, что их
происхождение относится к плоскостному (2D/CAD) проектированию и интенсивность их
использования будет со временем существенно снижаться, уступая место другим методам,
инструментам и подходам.
В то же время логика задач и процессов подразумевает необходимость использования
слоев, особенно в контексте создания/оформления документации, а также для более тонкой
фильтрации трехмерной модели. К тому же следует учесть, что некоторые программные
продукты умеют определять исходные слои в экспортированных IFC-моделях, что может
оказаться удобным. Слои могут быть затребованы в виде IFC-параметра
(Pset_Draughting/LayerName).
Исходя из вышеизложенного, рекомендуется разделять категории слоев на основные
группы, связанные непосредственно с моделированием,
аннотированием/документированием, аналитикой и прочими задачами, с собственными
кодами категорий, применяющимися ко «вложенным» элементам. Например:
...
A00 === АНАЛИЗ ===
A10 Оценка
A21 Обследование, инсоляция
...
E10 === SUBSTRUCTURE ===
E11 Фундамент
E11 Фундамент, свайное поле
...
Для схожих по логике/контенту слоев рекомендуется использовать одинаковые базовые
названия, с дополнительным уточнением в конце или в виде расширения.
Роли участников проекта, работающих в одном teamwork-файле или модульной структуре,
при необходимости могут быть указаны в расширении слоя. Если файл проекта
ориентирован исключительно на одну дисциплину, такое дополнение не является
обязательным.
Данный стандарт не ставит целью представить конечную структуру слоев,
но рекомендует использовать следующую логическую схему разбивки, учитывая правила
формирования реквизитов слоев. Логика построения базировалась на таких системах
классификации, как Uniclass, Uniformat, а также основывалась на общей логике
структуризации компонентов здания и графических, вспомогательных элементов:
Idx LOD Code Ext Interpretation – RU UFII Ref. U2 Ref.
= = A РАСЧЕТЫ И АНАЛИТИКА N/A N/A
100 - A00 АНАЛИТИКА - -
110 - A10 Расчеты ТЭП - -
64
111 - A1x ... - -
210 - A21 Анализ, инсоляционный - -
220 - A22 Анализ, транспортный - -
2X0 - A2x ... - -
= = E ЭЛЕМЕНТЫ МОДЕЛИ N/A N/A
500 L100 E05 УЧАСТОК И РЕЛЬЕФ G10 & G20 Ee_15
600 L200 E06 Рельеф G1070 Ee_15_70
700 L200 E07 Парковка, внешняя G2020 -
800 L200 E08 Благоустройство G20 -
801 L300 → Дороги, тротуары G2010 -
802 L300 → Мощение G2010 Ee_30_60
803 L300 → Элементы благоустройства G2060 -
804 L300 → Стаффаж G20.. -
1000 L100 E10 ОСНОВАНИЕ A Ee_20_05
1100 L200 E11 Фундаменты A10 Ee_20_05
1101 L300 → Ленточный фундамент A1010 Ee_20_05
1102 L300 → Свайный фундамент A1020.70 Ee_20_06
1103 L300 → Ростверк A1020.XX Ee_20_07
→ ... ... ...
1200 L200 E12 Подвал/Цоколь A40... -
1201 L300 → Стены подвала/подпорные A4040 Ee_25_10
2000 L100 E20 ОСНОВНЫЕ КОНСТРУКЦИИ B & C Ee20/25/30/35
2100 L200 E21 Каркас B10... Ee_20_10
2101 L300 → Каркас, балка B10... Ee_20_20
2102 L300 → Каркас, колонна B10... Ee_20_30
2103 L300 → Каркас, декинг B10... -
2104 L300 → Каркас, перекрытие B10... -
2105 L300 → Каркас, монолитные стены B10... -
2200 L200 E22 Несущие конструктивные элементы B10... -
2201 L300 → Перемычки B10... -
2202 L300 → Капители колонн B10... -
2203 L300 → Специальные конструкции B10... -
2510 L200 E25 Стены, отделка, утепление и пр. - -
2520 L200 E25 Стены, навесные B2010 -
2530 L200 E25 Стены, наружные B2010 Ee_25_20
2540 L200 E25 Стены, внутренние C1010 Ee_25_25
2560 L200 E26 Перегородки C1010 Ee_25_25
2570 L200 E27 Ограждения - Ee_25_40
3100 L200 E31 Полы C2030 Ee_30_40_10
3110 L200 E31 Полы, отделка, покрытие C2030 Ee_30_40_40
3200 L200 E32 Потолки C2050 Ee_30_40_25
3110 L200 E32 Потолки, отделка, покрытие C2050 Ee_30_40_47
3300 L200 E33 Кровля B1020 Ee_30_10_10
65
3310 L200 E33 Кровля, отделка, покрытие B3010 Ee_30_10_25
3320 L200 E33 Кровля, элементы B3020 Ee_30_10_60
3600 L200 E36 Лестницы B1080 Ee_35_15
3601 L300 → Стремянки и пр. B1080.80 Ee_35_16
3700 L200 E37 Рампы - Ee_35_17
4000 L100 E40 ОБОРУДОВАНИЕ И МЕБЕЛЬ E Ee_40
4100 L200 E41 Знаки, указатели E1090 Ee_40_10
4200 L200 E42 Оборудование E1090 Ee_40_15
4220 L300 → Обр., админ.. и коммерческого
назначения E1090.XX Ee_40_06
4225 L300 → Обр., образовательное и научное E1090.XX Ee_40_07
4230 L300 → Обр., промышленное E1090.XX Ee_40_08
4235 L300 → Обр., мед. и здравоохранение E1090.XX Ee_40_09
4240 L300 → Обр., рекреационное, спортивное E1090.XX Ee_40_10
4245 L300 → Обр., для жилья E1090.XX Ee_40_11
4250 L300 → Обр., дренажное E1090.XX Ee_40_12
4255 L300 → Обр., ВК E1090.XX Ee_40_13
4260 L300 → Обр., ОВ E1090.XX Ee_40_14
4270 L300 → Обр., ЭО E1090.XX Ee_40_15
4275 L300 → Обр., СС E1090.XX Ee_40_16
4280 L300 → Обр., жд E1090.XX Ee_40_17
4281 L300 → Обр., транспортное E1090.XX Ee_40_18
4282 L300 → Обр., вод. E1090.XX Ee_40_19
4283 L300 → Обр., тросовое E1090.XX Ee_40_20
4284 L300 → Обр., аэрокосмическое E1090.XX Ee_40_21
4285 L300 → Обр., узкая специализация E1090.XX Ee_40_22
4300 L200 E43 Мебель E20 Ee_40_15
4499 L100 E44 ИНЖЕНЕРНЫЕ СИСТЕМЫ D Ee_5x
4500 L200 E45 Транспортные системы D10 Ee_80_50
4501 L300 → Лифты D1010 Ee_80_50_50
4502 L300 → Эскалаторы D1010 Ee_80_50_40
4503 L300 → Траволаторы D1030 Ee_80_50_70
5000 L200 E50 ДУ (и пр.) D80 Ee_50
5500 L200 E55 ВК D20 Ee_55
6000 L200 E60 ОВ D30 Ee_60 & Ee_65
7000 L200 E70 ЭО D70 Ee_70
7500 L200 E75 СС D40 / D60 / D80 Ee_75
8500 L200 E85 УС (узкая специализация и пр.) D... Ee_85
9000 - E90 СПЕЦ. И ВСПОМОГАТЕЛЬНЫЕ - Zz_85
9100 - E91 WIP Солиды, трехмерные объекты - Zz_85_05
9200 - E92 Отверстия в стенах, перекрытиях - Zz_85_05_85
9300 - E93 WIP Операторы булевых операций - Zz_85_05_60
66
9500 - E95 ДЛЯ BIM И ТЕХ. ИСПОЛЬЗОВАНИЯ - Zz
9600 - E96 Внешние модули - Zz_30_30
9610 - → A Внешние модули, архитектура - Zz_30_30
9620 - → G Внешние модули, генплан - Zz_30_30
9630 - → D Внешние модули, инженерия - Zz_30_30
9631 - → P Внешние модули, ВК - Zz_30_30
9632 - → H Внешние модули, ОВ - Zz_30_30
9633 - → E Внешние модули, ЭО - Zz_30_30
9634 - → L Внешние модули, СС - Zz_30_30
9635 - → Y Внешние модули, Y - Zz_30_30
9640 - → S Внешние модули, конструктив - Zz_30_30
9641 - → SC Внешние модули, конструктив кб - Zz_30_30
9642 - → SS Внешние модули, конструктив км - Zz_30_30
9690 - → X Внешние модули, специальные - Zz_30_30
9700 - E97 Внешние чертежи - Zz_30_30
9800 - E98 BIM Для специальных и тех. целей - -
9810 - → BIM Классификационные схемы - -
9999 - E99 TMP Временные слои - -
- - S ЗОНЫ И ПОМЕЩЕНИЯ N/A N/A
10000 L100 S00 ПРОСТРАНСТВА, ПОМЕЩЕНИЯ, ЗОНЫ - Zz_50
10100 L200 S10 Зоны помещений - Zz_50_95
10101 L200 → Зоны специальные - Zz_50_60
19100 L200 S91 Зоны, ограничения - Zz_50_10
19200 L200 S92 Зоны, общая площадь - Zz_50_60
19300 L200 S93 Зоны, общий объем - Zz_50_90
- T ДВУМЕРНЫЙ И CAD КОНТЕНТ N/A N/A
20000 - T00 ТЕКСТОВЫЙ И 2D-КОНТЕНТ - Zz_10 & Zz_20
20100 - T01 Аннотации - Zz_10_70_05
20101 - → WIP Аннотации, раб. - Zz_10_70_06
20200 - T02 Размеры - Zz_20_20
20201 - → WIP Размеры, раб. - Zz_20_20
20202 - → IA Размеры, инвестиционные альбомы - Zz_20_20
20203 - → S Размеры, конструктив - Zz_20_20
20204 - → ... - Zz_20_20
20300 - T03 WIP Линии и штриховки, всп. - Zz_20_40
20301 - → WIP Линии, всп. - Zz_20_40
20302 - → WIP Штриховки, раб. - Zz_20_40
20400 - T04 Штампы, формы, бланки - Zz_20_90
21000 T10 ОСИ И РАЗМЕТКА - Zz_35
21100 - T11 Оси, основные - Zz_35_40_80
21101 - T11 WIP Оси, раб. - Zz_35_40_81
21200 - T12 Оси, второстепенные (секционные и др.) - Zz_35_40_80
21201 - → ... - ...
67
22000 - T20 МАРКЕРЫ, ВИДЫ, ИНСТРУМЕНТЫ - Zz_70
22100 - T21 Детали и рабочие листы - Zz_70_20
22101 - → Детали - Zz_70_20
22102 - → Листы - Zz_70_20
22200 - T22 Изменения и ревизии - Zz_10_70
22201 - → Изменения - Zz_10_70
22202 - → Ревизии - Zz_10_70
22300 - T23 Фасады - Zz_70_30
22400 - T24 Отметки (планы) - Zz_70_60
22500 - T25 Разрезы - Zz_70_80
22600 - T2x ... - ...
Рис. 17: Пример структуры слоев
Строительные Материалы
Строительные Материалы должны использовать исключительно заранее
подготовленные и согласованные Штриховки и Покрытия. Перья и ориентация
Штриховок наследуются от их реквизитов (если не были переназначены
пользователем).
Приоритет пересечений должен исходить из логики использования материалов либо
их физических свойств. Кроме того, отдельно могут быть созданы материалы для
специфических задач – например, для операций твердотельного моделирования
с максимальным приоритетом пересечения.
Строительные Материалы должны быть идентифицированы согласно общей логике
кодификации реквизитов проекта (см. п. 8.04) и обеспечивать удобную сортировку и
разбивку на категории использования: конструктивные материалы, материалы для
отделки, вспомогательные, специальные и т.п. Например:
...
M15 === Подготовительные работы & Земляные работы ===
M16 Грунт, гравий
...
M20 === Конструкции & Общие материалы ===
M22 Сборный, бетон
M24 Блоки, бетон
M24 Блоки, керамика
...
Названия Строительных Материалов не должны быть слишком длинными, поскольку
ARCHICAD «сжимает» названия в некоторых выпадающих меню и списках, что не
всегда удобно. Кроме того, в некоторых программных продуктах существуют
ограничения на количество символов в названии.
Каждый Строительный Материал должен иметь установленные и валидные
теплофизические характеристики.
68
Каждый Строительный Материал может иметь дополнительную информацию,
занесенную в разделы Производитель и Описание.
Примечание. Следует учесть, что при настройках транслятора по умолчанию
Product Type некоторых типовых элементов (например стен) носит наименование
применяемого строительного материала.
Сложные Профили
Сложные Профили должны использовать только заранее подготовленные
и согласованные реквизиты проекта.
Не рекомендуется использовать один и тот же профиль для различных типов
элементов.
Обычно профили позиционируют следующим образом:
• Стена – привязка находится на базовой линии стены;
• Балка – привязка находится сверху и по центру;
• Колонна – привязка находится в центре колонны.
При создании реквизита в Редакторе Профилей нужно учитывать расположение точки
привязки. Кроме того, правильной практикой считается расположение
дополнительных точек привязки по всему контуру профиля (по линиям изломов), что
помогает при позиционировании или редактировании элемента в разрезах, фасадах,
3D.
Названия модификаторов, применяемых к профилям, должны быть максимально
унифицированы и доступно описывать характер модификации.
Примечание. Следует учесть, что при настройках транслятора по умолчанию
Product Type некоторых типовых элементов (например стен) носит наименование
применяемого профиля.
Многослойные Конструкции
Многослойные Конструкции должны использовать только заранее подготовленные
и согласованные Строительные Материалы, Перья и Типы Линий проекта.
Многослойные Конструкции должны обеспечивать удобную сортировку и разбивку на
категории использования, а также относительно типов элементов (Стена,
Перекрытие, Оболочка, Кровля).
Каждый слой должен иметь собственный конструктивный тип (ядро, отделка, другое)
в зависимости от материала либо логики проекта.
При формировании Многослойных Конструкций следует учесть порядок набора
слоев: сверху наружный слой, снизу – внутренний. Это должно отражаться и в логике
их наименования.
Наименование Многослойной Конструкции должно отображать ее составные части
(слои) и их актуальные толщины. Рекомендуется последовательно перечислять
69
каждый из слоев с указанием его толщины. Учитывая, что количество слоев может
быть значительным, общее название Многослойной Конструкции будет
увеличиваться. Чтобы избежать чрезмерно больших названий, рекомендуется
присваивать каждому Строительному Материалу трехсимвольный тэг (метку); метки
можно указать в описании каждого из материалов – в соответствующем разделе
реквизитов. Для большей ясности можно использовать код типа/формы
Многослойной Конструкции. Такой подход обеспечивает удобную сортировку и поиск
всех кМногослойных Конструкций, представленных в проекте, отражает их реальное
содержание. Например:
...
C26 = Стеновые конструкции =
C26 Б.Бет250 – Бетонные блоки 250mm
C26 Б.Крм250 - О.Штк020 – Керамические блоки,250mm + Отделочная штукатурка 20mm
...
Внимание! Чтобы сделать процесс более удобным, можно использовать формулы
для генерации полных названий Многослойных Конструкций в более понятной
и читаемой форме, записываемых в свойства конкретных элементов.
При создании Многослойных Конструкций важно учитывать расположение
линии/плоскости привязки элемента. Рекомендуется использовать следующее
позиционирование:
• Потолки – плоскость привязки сверху
• Кровля – опорный многоугольник снизу
• Перекрытие – плоскости привязки по ядру (чистый пол)
• Наружные стены – линия привязки внутри ядра
• Внутренние стены – в зависимости от расположения и ситуации
Нежелательно использовать одну и ту же Многослойную Конструкцию для различных
типов элементов.
Примечание. Следует учесть, что при настройках транслятора по умолчанию
Product Type некоторых типовых элементов (например стен) носит наименование
применяемой Многослойной Конструкции.
Зоны
Зоны должны использовать только заранее подготовленные и согласованные
библиотечные элементы, использующиеся как маркеры зон.
Зоны должны обеспечивать удобную сортировку и разбивку на категории
использования, разделяясь в зависимости от функционального типа. Например:
...
S20 === Административное, Коммерческое, Служебное ===
S20 Служебные помещения
S21 Административные помещения
S21 Конферент-залы
S22 Коммерческие помещения
...
70
Следует разделять реквизиты зон на те, что используются исключительно для
отдельных помещений, и те, что служат в качестве зон для подсчета общей площади,
объемов или исключительно для маркировки (отдельные слои, категории и
классификации).
Цвета категорий зон должны быть идентичными для 2D и 3D (имеется в виду
схожесть по цвету между перьями и поверхностями).
Перья
Все перья в различных наборах должны быть согласованы между собой и иметь
схожее назначение, указанное в описании. Это необходимо для обеспечения единой
структуры в различных модельных видах, графических заменах и других графических
средах.
Инструменты Разметки
Инструменты Разметки должны использовать только заранее подготовленные
и согласованные Перья проекта.
Инструменты Разметки должны обеспечивать удобную сортировку и разбивку на
категории в зависимости от их предназначения.
Учитывая активное развитие программных продуктов и расширений, работающих с
форматом BCF, и увеличивающуюся интенсивность междисциплинарного обмена,
рекомендуется добавить/консолидировать инструменты разметки к наиболее
распространенным типам и статусам задач с помощью формата BCF.
Рис. 18: Пример формирования задания в BCF формате
71
Следует принять во внимание, что импорт внешних BCF-файлов приводит к созданию
новых типов инструментов разметки – соответственно, рекомендуется предусмотреть
возможные рабочие варианты при BCF-коммуникации и включить их в реквизитную
среду.
Графическая среда – Комбинации Слоев, Наборы Перьев
Рекомендуется согласовать реквизитную часть графической среды (Комбинации
Слоев, Наборы Перьев) и другие настройки, оказывающие непосредственное
влияние на финальный вид модели (графическая замена, модельные виды,
настройки реконструкции и пр.), для обеспечения единой логики графического
пространства, настраиваемого в оперативных параметрах. Это особенно удобно при
пакетном редактировании структуры видов, обмене со смежными специалистами.
Рис. 19: Выбор параметров для графичечкой среды
8.06. КОНТЕНТНАЯ СРЕДА
В современных процессах проектирования и моделирования значимость данных
и информации, заложенных в проект, стремительно растет, так же как растут их объемы и
количество. В свою очередь это диктует необходимость их правильной организации,
систематизации и упорядочивания для обеспечения доступности извлечения и эффективной
работы.
Системы классификации
Учитывая тот факт, что система трансляции IFC-типов элементов теперь напрямую зависит
от использующейся классификации, она должна быть максимально корректной и
поддерживаться в надлежащем состоянии.
72
Следует понимать, что одна система не может быть абсолютно применима ко всем
требованиям и/или поставленным задачам – например, таким, как подготовка элементов к
последующим операциям для 4D, 5D, 6D и другим, более сложным BIM-задачам.
Соответственно, в проекте может быть несколько систем классификации, причем некоторые
из них будут генерироваться автоматически (например, при использовании Grasshopper
Connector).
Внимание! Тем не менее, в качестве основной, базовой системы классификации
рекомендуется придерживаться той, которая доступна по умолчанию (ARCHICAD
Classification), поскольку она наиболее адаптирована и приспособлена к существующему
набору инструментов и функционала. Также при вынужденной работе с несколькими
версиями программы или для того чтобы избежать регулярной перенастройки в
шаблоне, рекомендуется продублировать ARCHICAD Classification и избавиться от
версионности в названии, чтобы исключить возможные коллизии.
Общие требования к системам классификации:
● структура классификации должна быть заранее продуманной, четкой, обеспечивать базовую
логическую сортировку компонентов. Каждый элемент должен иметь свой уникальный ID и
наименование;
● классификация должна максимально опираться на существующий набор нативных
элементов ARCHICAD, чтобы исключить логические коллизии и избежать проблем
с последующей трансляцией типов элементов. Следует понимать, что в штатном наборе
программы представлены не все физические/строительные элементы или компоненты –
соответственно, для них необходимо подбирать максимально удобный в использовании
нативный элемент (например, для свай могут быть использованы типы колонн);
● внесение изменений в классификацию непосредственно в активной фазе рабочего процесса
нежелательно, поскольку потребует привести в соответствие весь набор файлов проекта.
При использовании комплексной модульной структуры в рамках крупных объектов это может
вызвать значительные сложности;
● файлы не должны содержать конфликтов классификаций (при использовании модульной
структуры);
● каждый элемент классификации должен содержать лишь тот набор свойств (property sets),
который свойственен исключительно ему;
● перед использованием сторонних систем классификации необходимо проверить их на
соответствие требованиям;
● при использовании нестандартных или сторонних систем классификации необходимо
учесть/проверить настройки в IFC-трансляторах: TypeMapping, PropertyMapping,
DataConversion.
Системы классификации, адаптированные для использования в среде ARCHICAD, можно
загрузить здесь: https://www.graphisoft.com/downloads/archicad/BIM_Data.html.
73
Наборы Свойств
Структура наборов свойств (property sets) должна обеспечивать удобную сортировку
и разбивку на категории использования. Рекомендуется разбивать свойства по типам
элементов/группам типов элементов – например, для зон, стен, колонн или же для отделки
полов/помещений и т.д.
Каждое свойство должно принадлежать соответствующему элементу классификации/группе
элементов классификации.
Типы данных должны соответствовать логике самого свойства (то есть если в свойстве
измеряется длина элемента, тип данных должен соответствовать length).
Формулы не должны содержать ошибок, результат на выходе должен соответствовать
правильному типу данных.
Файлы не должны содержать конфликтов наборов свойств (при использовании модульной
структуры).
При использовании нестандартных или сторонних систем классификации необходимо
учесть/проверить настройки в IFC-трансляторах: TypeMapping, PropertyMapping,
DataConversion.
Предопределенные правила
Предопределенные правила обеспечивают быструю классификацию подготовленной
модели. При этом используется заранее предусмотренный формат поля
IfcClassificationReference, позволяющий правильно транслировать классификацию
в сторонние платформы.
Рекомендуется использовать системы классификации по умолчанию либо те, которые
составлены/одобрены BIM-менеджером компании.
8.07. БИБЛИОТЕКИ И КОМПОНЕНТЫ
Как правило, во время работы над проектом используется несколько различных библиотек с
различной специализацией. Целесообразно определить для библиотек три ключевых
раздела:
● Стандартная Библиотека ARCHICAD (по умолчанию);
● библиотека компании (содержит разработанные/одобренные типовые библиотечные
элементы для применения ко всем проектам компании);
● библиотека проекта (специфические библиотечные объекты, использующиеся
исключительно в рамках конкретного проекта).
Не рекомендуется выгружать библиотечные элементы в корень вложенных библиотек. Все
библиотечные элементы перед их использованием должны быть тщательно
протестированы и одобрены.
74
Модули не должны содержать вложенных библиотек. Все использующиеся библиотечные
элементы следует синхронизировать через библиотеку проекта или библиотеку компании.
Не рекомендуется использовать библиотечные объекты, оказывающие влияние на общую
производительность программы (объекты со сложными внутренними вычислениями,
некорректным кодом и т.п.).
Все подгружаемые библиотеки (кроме Стандартной Библиотеки ARCHICAD) не должны
содержать элементов, которые не используются в работе.
Необходимо регулярно проверять состояние и статус использующихся библиотек,
обновлять их для новых версий программы и поддерживать в надлежащем состоянии.
8.08. ГРАФИЧЕСКИЕ НАСТРОЙКИ
Крайне рекомендуется все графические настройки (модельные виды, графическая замена,
масштаб, статусы реконструкции и пр.) согласовать с существующими наборами слоев,
перьев для упрощения рабочего графического пространства и ясности структуры.
То есть, иными словами, названия и кодификация всех модельных видов, графической
замены, наборов реквизитов должны строиться, исходя из единой логики, и использоваться
для схожих/единых по характеру задач.
Параметры Модельных Видов
Комбинации Параметров Модельных Видов должны обеспечивать удобную сортировку и
разбивку на категории в зависимости от их предназначения. В то же время их названия не
должны быть чрезмерно большими, чтобы не усложнять навигацию в оперативных
параметрах проекта.
Для схожих по логике/контенту комбинаций Параметров Модельных Видов рекомендуется
использовать одинаковые базовые названия с дополнительным уточнением в конце.
Отображение модельного контента должно исходить из потребностей текущей стадии
проектирования. Например, детальные отображения дверей и окон, необязательные на
ранних этапах, могут потребоваться позже. Следует также принять во внимание, что
уровень детализации напрямую влияет на производительность программы, поэтому
комбинации Параметров Модельных Видов нужно разделять, обособляя, к примеру,
детальные модельные виды, предназначенные для оформления документации, и работая в
более простом по отображению режиме. Особое внимание стоит уделять Лестницам и
Ограждениям как композитным структурам, содержащим множество подэлементов.
Параметры Модельных Видов влияют на конечный вид большинства объектов, в том числе
и в 3D, что важно при междисциплинарном взаимодействии.
Внимание! В диалог Параметров Модельных Видов может встраиваться функционал от
сторонних разработчиков, написанный на языке GDL. Перед использованием комбинации
Параметров Модельных Видов желательно заранее проверить и протестировать.
75
Масштаб
Единым масштабом разработки как моделей, так и текстово-табличных данных (таблицы,
рамки, штампы и т.д.) принимается масштаб 1:1.
Масштаб вывода чертежей должен соответствовать нормативным требованиям или
требованиям заказчика.
Масштаб вывода текстово-табличных данных – 1:1.
Масштаб разработки и вывода схем, эскизов, аналитических картограмм и пр. допускается
принимать произвольно.
Следует учитывать тот факт, что значительное количество библиотечных объектов
ARCHICAD использует различные уровни детализации, основываясь на текущем масштабе.
Фильтры Реконструкции
Фильтры Реконструкции используются для настройки отображения различных элементов в
зависимости от их статуса (Существующий, Для Сноса, Новый).
В некоторых случаях Фильтры Реконструкции могут использоваться как вариации, при их
надлежащем упорядочении.
Графическая Замена
Комбинации Графической Замены должны обеспечивать удобную сортировку и разбивку на
категории в зависимости от их предназначения.
Каждая Комбинация Графической Замены должна использовать только заранее
подготовленные и согласованные Правила Графической Замены. Количество правил для
одной комбинации не ограничено, но должно иметь разумные пределы, обусловленные
практической необходимостью.
Каждое правило должно быть названо согласно соответствующей комбинации, быть
удобным для сортировки и упорядочения.
Каждое правило должно быть синтаксически корректно описано и опираться на
необходимую логику выборки.
Стили перезаписи в каждом правиле должны использовать только заранее подготовленные
и согласованные Штриховки, Перья, Типы Линий и Покрытия проекта.
Текст и Аннотирование
Для текстовых и аннотационных данных рекомендуется использовать следующие размеры:
2.0 Обычный текст, размерные цепочки;
2.5 Важная аннотация, маркеры осей;
3.5 Подзаголовки, подразделы;
76
5.0 Заголовки титульных листов.
8.09. ИНТЕРОПЕРАБЕЛЬНОСТЬ И ВЗАИМОДЕЙСТВИЕ
Трансляция входящих/исходящих моделей посредством формата IFC – наиболее
востребованный и в то же время комплексный метод взаимодействия со смежными
дисциплинами и ПО, требующий правильной настройки и надлежащей поддержки.
Все необходимые трансляторы для экспорта/импорта IFC-моделей должны быть заранее
настроены и внесены в шаблон. Рекомендуется исключить трансляторы, встроенные по
умолчанию, и оперировать только теми, которые созданы или одобрены BIM-менеджером
компании или ответственным лицом. При необходимости все основные трансляторы могут
быть загружены из базового шаблона ARCHICAD.
Рекомендуется использовать схему IFC4, но с предварительной оценкой способности
стороннего ПО считывать такую схему.
Целесообразно использовать следующие типы MVD (Определение Модельного Вида):
● Coordination View (IFC2x3) или Reference View (IFC4) – для передачи наиболее
точной геометрии модели. В таком виде модель представляет собой подобие
«трехмерной подложки», но диапазон ее применения в стороннем ПО существенно
сужается;
● Coordination View 2.0 (IFC2x3) или Design Transfer View (IFC4) – для более
«интерактивной» передачи модели стороннему ПО. К примеру, в таком случае
последнее будет способно преобразовать большинство элементов в свои нативные
типы.
Следует понимать, что типы MVD служат скорее ориентирами, которые позволяют
определить конечное использование транслируемой модели, а также проверяют все
разделы настроек на соответствие выбранному типу.
Фильтры модели
Фильтры модели позволяют избегать включения лишних элементов в хост-файл модели на
основе ключевых IFC-типов. С другой стороны, необходимо заранее проверить контент
подгружаемого файла на соответствие требованиям (все элементы модели должны
принадлежать правильному типу).
В некоторых случаях фильтры модели позволяют избежать проблем импорта, связанных с
преобразованием стандартных типов элементов (стена, колонна, балка и т.п.) в объекты или
морфы при их взаимном пересечении. Для этого используется мультизагрузка одного и того
же внешнего файла, но с жесткой фильтрацией по конкретному типу элемента за один этап
импорта: импорт только балок, импорт только плит перекрытия и т.д. Такой метод должен
быть формализован в виде заранее настроенных трансляторов.
77
IFC-схема проекта
В большинстве случаев все существующие в стандартной схеме Pset_* не используются в
основном рабочем процессе, поэтому рекомендуется исключить их из трансляции для
облегчения выгружаемых IFC-моделей. При необходимости все стандартные схемы и
наборы IFC- свойств могут быть подгружены из стандартного шаблона.
78
9. ОБЕСПЕЧЕНИЕ КАЧЕСТВА
9.01. КОНТРОЛЬ И ОБЕСПЕЧЕНИЕ КАЧЕСТВА
В данном контексте обеспечение качества моделирования (QA – Quality Assurance, QC –
Quality Check, проверка качества) сфокусировано на регулярной проверке разрабатываемых
моделей каждой из дисциплин, участвующих в проекте. Несмотря на то что такая процедура
в основном не ориентирована на проверку непосредственно проектных решений в полном
объеме, она может помочь в поиске и устранении модельных и технических ошибок,
отклонений от норм и стандартов, несогласованности дисциплин между собой, в итоге
оказывая существенное влияние на качество и точность проекта, выпускаемой
документации и итогового результата в виде построенного объекта.
Общий процесс контроля и обеспечения качества должен состоять из нескольких этапов:
• техническая проверка модели каждой из дисциплин согласно определенной
логике моделирования, присущей конкретному программному обеспечению и
на основе принятых BIM-стандартов;
• дисциплинарная проверка конкретного раздела, то есть проверка
непосредственно проектных решений на соответствие основным нормам,
стандартам, требованиям и т.п.;
• федеративная проверка всех дисциплин проекта в сводной модели,
включающая поиск коллизий и конфликтов, модельных ошибок и прочих
отклонений от основных требований.
Исключение из общей схемы (см. рис. «Основные этапы проверки…» на с. 79) хотя бы
одного из этапов крайне нежелательно, поскольку полностью ломает логику процесса и
негативно сказывается на конечном результате. То есть без предварительной технической
(модельной) проверки невозможно точно осуществить проверку дисциплины проекта на
соответствие нормам и стандартам, поскольку исходные данные могут быть неверными
(неточно «заполненные» зоны, неправильные строительные материалы, дублирующиеся
элементы и пр.). В свою очередь без предварительной дисциплинарной проверки каждого из
разделов результаты общей федеративной проверки могут быть существенно искажены
и потерять смысл.
Процессы QA требуют регулярного исполнения и в сумме могут оказаться очень затратными
по времени, поэтому одна из основных целей – максимально оптимизировать
(и автоматизировать) осуществление проверки. Что, в свою очередь, требует прохождения
определенных этапов (см. рис. «Этапы оптимизации проверки» на с. 79).
79
Основные этапы проверки моделей (на текущий момент формализованы требования только для
базовой технической проверки отдельного ПО в ручном режиме)
Проверка раздела не осуществляется, в то же время существуют базовые процедуры поиска
коллизий и конфликтов в сводных моделях.
Этапы оптимизации проверки
На сегодня формализованы основные критерии только для технической проверки модели
в среде GRAPHISOFT ARCHICAD, перечисленные ниже в контрольном списке. После
отработки процесса проверки и на основе полученных результатов следующим этапом
будет автоматизация таких процедур.
80
9.02. КОНТРОЛЬНЫЕ СПИСКИ ПРОВЕРКИ
Этот раздел представляет контрольные списки ключевых пунктов для проверки
дисциплинарных моделей на корректность их структуры и свойств, целостность,
соответствие принятым стандартам и пригодность для использования. Перечень ключевых
пунктов может быть расширен/изменен в зависимости от конкретной стадии проектирования.
1. Общие свойства
1.1 Файл модели поименован и размещен согласно стандартам.
1.2 Все внешние модели правильно расположены, поименованы и корректно
подключены.
1.3 Все подключенные внешние элементы, ссылки и чертежи обновлены, последние
изменения получены.
1.4 Модель не содержит уведомлений об ошибках при загрузке.
1.5 Размер файла модели не превышает установленных размеров.
1.6 Модель размещена корректно относительно принятой системы координат.
1.7 Точка привязки (анг. Survey point) (при наличии и необходимости) соответствует
принятой системе координат.
2. Библиотеки проекта
2.1 Подключены только все необходимые и корректные библиотеки
соответствующих версий.
2.2 Модель не содержит несанкционированных вложенных библиотечных объектов,
в том числе из внешних файлов (модулей).
2.3 Нет «отсутствующих» библиотечных объектов.
2.4 Размер библиотек не превышает установленных размеров.
3. Модельная среда
3.1 Параметры расположения проекта соответствуют действительности.
3.2 Все реквизиты соответствуют принятому шаблону проекта.
3.3 Все классификаторы соответствуют принятому шаблону.
81
3.4 Все наборы свойств соответствуют принятому шаблону.
3.5 Информация о Проекте заполнена и соответствует принятому шаблону.
3.6 Фильтры реконструкции стандартны либо соответствуют принятому шаблону.
3.7 Параметры Модельных Видов соответствуют принятому шаблону.
3.8 Комбинации Графической Замены, их состав и свойства правил соответствуют
принятому шаблону.
3.9 Параметры расчетов и модельные единицы соответствуют шаблону или
требованиям проекта.
3.10 Трансляторы DWG и IFC соответствуют принятому шаблону.
3.11 Пользовательский профиль соответствует текущей версии программы.
3.12 Пользовательская среда не содержит несанкционированных расширений и
дополнений (анг. Add-on).
4. Модельный контент
4.1 Оси определены и построены корректно, соответствуют принятой системе
наименования.
4.2 Ключевые конструктивные элементы размещены корректно.
4.3 Модель не содержит некорректно пересекающихся или дублирующихся
элементов.
4.4 Модель не содержит пересекающихся зон.
4.5 Классификация элементов моделей и зон определена и соответствует принятым
типам.
4.6 Каждый элемент либо зона принадлежит корректному и единственному этажу.
4.7 Все зоны помещений автоматически заполняют доступный объем.
4.8 Модель не содержит лишних, временных или вспомогательных элементов
в открытых рабочих слоях.
5. Документация
5.1 Файл модели не содержит неиспользуемых или «отсутствующих» чертежей.
82
5.2 Ручное обновление чертежей обосновано (в случае файла teamwork).
5.3 Структура документации соответствует принятому шаблону проекта.
5.4 Структура выдачи настроена и соответствует принятому шаблону.
83
10. ПРИЛОЖЕНИЯ
10.01. ПРИМЕР НАИМЕНОВАНИЯ ФАЙЛОВ
Схема именования состоит из пяти обязательных и пяти опциональных полей. Конечное
название имеет вид PRJ-S00-000-R-SYS-des-ver-ath-dt-dat, где:
● PRJ – шифр проекта (площадки)
● S00 – фаза проектирования (стадия + очередь)
● 000 – номер здания по ГП
● R – роль в процессе (дисциплина, комплект)
● SYS – система/подсистема
● des – кумулятивное описание, дополнение, может включать в себя все последующие
части в разумных пределах и видах
● ver – версия/выпуск/вариант
● ath – код владельца и при необходимости код контрагента через тип взаимодействия
с ним
● dt – тип данных
● dat – дата в формате YYMMDD
Типы данных, коды дисциплин смотрите ниже.
Примеры наименования:
• Рабочий архитектурный файл-контейнер всех этажей, стадия Проект,
версия 002: OBL-D00-001-A-LZF-002.
• Экспортированный файл IFC для внутреннего использования по зданиям от
001 до 003, с указанием даты выдачи: OBL-D00-001t003-A-ZZ-180907.
84
10.02. ПРИМЕР ГЛОБАЛЬНЫХ ЗОН ДАННЫХ
Рабочая зона CDE Сетевой ресурс Сетевой диск Подпапка проекта
Incoming \00-Incoming N:\ 00-Inc
Resources \00-Resources R:\ 00-Res
Work in Progress \01-Work (WIP) W:\ 01-WiP
Shared \02-Shared S:\ 02-Sha
Published \03-Published P:\ 03-Pub
Archive \04-Archive X:\ 04-Arc
Temporary \99-Temporary T:\ 99-Tmp
Deleted \99-Deleted Y:\ 99-Del
10.03. КОДЫ ОБОЗНАЧЕНИЯ РОЛЕЙ
За основу кодификации Ролей участников процесса приняты положения документов-
источников. Однако структурно-организационные региональные отличия процессов
проектирования не позволяют принять их как есть.
Группа Код Роль / Дисциплина Соответствие BS1192:2007
K заказчик client
T власти, эксперты –
R генеральный план города –
G G генеральный план –
A A архитектурные решения Architecture
A AI архитектурные интерьеры
A AC концептуальные решения (креатив)
A AD архитектурные решения, детали
S S конструктивные решения Structural engineering
S SC конструкции бетонные
S SS конструкции металлические
S SA конструктивные расчеты
D D инженерные решения сводные –
D E электротехнические решения Electrical engineering systems
D P водоснабжение и канализация Public health
D H отопление, вентиляция Heating and Ventilation
D F пожарная безопасность –
D L слаботочные системы –
D U автоматизация –
85
D C системы связи (сети связи) –
D O охранные системы Security systems
Q сметы, ведомости Quantity surveying
Y узкая специализация Specialist designers
B надзор за строительством –
V изыскатели –
W строители (монтажники) Contractors
1 управление, администрация –
X никто, не определено –
Z все General (non-specific)
10.04. КОДЫ СТАДИЙ РАЗРАБОТКИ
Коды Стадий Разработки взяты из наименований, принятых в международной практике,
сопоставлены с BIM-категорией LOD (Level of Detail – уровень детализации), ассоциированы
с региональными обозначениями и дополнены специфическими стадиями из местных
практик.
## Код Значение (англ.) LOD Соответствующая стадия
## Z All – Все стадии
00 P Pre-design 100 ПП, Предпроект, в статусе «Стартующий»
01 S Schematic Design 200 ПП, Предпроект, в статусе «В Работе»; ЭП,
Эскизный Проект
02 D Design Development 300 П, Проект
03 C Construction Design 400 Р, Рабочая Документация
04 U Procurements – –, закупки
05 A Author's Supervision 500 АН, Авторский Надзор
06 F Post-project – Постпроектное Сопровождение
07 V Investment Albums – ИА, Инвестиционные Альбомы
08 T BTI, Technical Passports – БТИ, Технические Паспорта
86
10.05. КОДЫ СИСТЕМ/ПОДСИСТЕМ
Код Значение (англ.) Значение
ZZ All Все
XX Nothing, not Ничего, не определено
L... Levels Этажи
LZF All Types of Floors Все типы этажей (группа)
L01, L02… Floors 01, 02… Этаж 01, этаж 02 ... другие соответственно
LR0 Roof Крыша
LR1 First Under Roof Первый под крышей
LR2 Second Under Roof Второй под крышей
LRF Roofing Floors Верхние этажи (группа)
LTF Typical Floor Типовой этаж
LT1 Typical Floor 1 Type Типовой этаж 1-го типа
LT2 Typical Floor 2 Type Типовой этаж 2-го типа
LDF Technical Floor Технический этаж
LGF Ground Floors Нижние этажи (группа)
LP1 Parking -1 floor Паркинг – 1 этаж
LВ0 Basement Подвал
S... Sections Разрезы
S01, S02… Sections 01, 02… Разрез 01, Разрез 02 ... другие соответственно
E... Elevations Фасады
E01, E02… Elevations 01, 02… Фасад 01, Фасад 02 ... другие соответственно
87
10.06. КОДЫ ОБОЗНАЧЕНИЯ ТИПОВ ДАННЫХ
Код Значение (англ.) Значение
V... Visualizations Визуализации
V3 Virtual 3D Model 3D-модель обзорная
VV Virtual Video Видеоролик
M... Models Модель
MR Model Rendering Модель для визуализации
M3 3D Model 3D-модель
M2 2D Model 2D-модель
M...С 3D/2D Model – Component 3D/2D-модель – компонент
M...A 3D/2D Model – Assembly 3D/2D-модель – сборка
M...Z 3D/2D Model – Container 3D/2D-модель – контейнер
M...E 3D/2D Exported Model 3D/2D экспортированная модель
M...P 3D/2D Processed Model 3D/2D очищенная модель
D... Drawings Чертежи
DR Drawing Чертеж
DB Binders Подшивка (том, комплект)
DV Volumes Тома (для стадии «П»)
DA Albums Альбомы (презентационные комплекты)
DS Drawing Scanned Чертеж отсканированный
S... Schedulers Таблицы
ST Scheduler or Table Таблица
SQ Bill of Quantities Ведомость
SP Specification Спецификация
T... Text Documents Текстовые документы
TM Text Management Руководящий документ
TS Text Standard Стандарт
TN Text Notes Записи
TB Text Bill Накладная
TD Text Document Текстовый документ
A... Analytics Расчеты
AM Analytics Model Расчетная модель
AT Analytics Text or Table Расчет (текст, таблица)