Почему BIM-требования написаны по-русски, но всё равно непонятно

Давно хочу поговорить, как писать требования без противоречий, неоднозначностей и избыточности, а если просто говорить, что понял Проектировщик и мог выполнить без мата и слёз. Ну а помимо этого большая часть требований к ЦИМ сегодня плохо поддается автоматизации, противоречит сама себе или зависит от конкретного САПР. Последнее - может и хорошо одним, но плохо - другим. Где-то точно плачет красный кирпичик, смотря на ваши "вендорнонезависимые" стандарты.

В результате:

• проектировщик не понимает, что именно требуется, делает, как делает и получает неаргументированный отказ (и не всегда важно, что говорит буква закона, если её не вспоминать);
• автоматические проверки не совпадают с текстом требований, IDS начинает жить отдельно от требований;
• IFC проходит через «костыли»;
• регулятор, заказчик и BIM-менеджер интерпретируют требования по-разному

Картина маслом "Лебедь, рак да щука"

Проблема обычно не в IFC и не в проектировщиках. Проблема — в архитектуре самих требований. Дам свой взгляд, как писать требования к ЦИМ, которые:

• можно реализовать;
• можно проверить;
• можно автоматизировать;
• можно интерпретировать однозначно независимо от ПО.

1. Почему BIM-требования перестают работать

Главная ошибка — требования пишутся не от сценариев использования

Часто документ начинается с копирования чужих BIM-стандартов. И только потом кто-то пытается понять, а зачастую именно Проектировщики, кому это непосредственно выполнять:

а зачем вообще нужны эти данные?

В зрелом подходе последовательность должна быть обратной:

• Определить сценарий использования модели (bim-uses)
• Определить проверки
• Определить алгоритмы получения данных и расчеты (объемов, материалов)
• Определить минимально необходимый состав модели
• Определить обязательные параметры
• Подготовить IDS-правила (если мы про тех, кто работает в мульти-вендорной среде) или шаблон проверки в другом формате
• Подготовить МК
• Выполнить пилотную проверку, уточнить допущения и обновить требования
• Только после этого масштабировать требования

BIM-модель должна быть не "на всякий случай"

Очень частая ошибка — смешение разных типов моделей в одном:

• модели для ТЭП;
• модели для ПД/РД;
• аналитической модели;
• цифровой двойник;
• модели для визуализации (ВПМ, НПМ);
• модели для метавселенной :)

У них: разные цели; разный уровень детализации; разный набор данных; разные правила проверки.

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

Избыточность — это тоже ошибка

Если данные:

• нигде не используются;
• не участвуют в проверках;
• не участвуют в расчетах;
• не участвуют на последующих этапах жизненного цикла (проекта)

то их обязательность ставится под вопрос. Когда вы пишите требования, считайте в уме трудозатраты проектировщика, которые повлияют на ваши сроки получения согласований и РНС, он всё-таки не волшебник:

Данное требование стоит увеличения сроков? Например, я уверен, что нужно заполнять минимальный набор параметров для элементов, которые не влияют на мои BIM-uses?

Примеры этапов

Чтобы требования к BIM-модели были качественными, они обязаны учитывать, как модель будет жить «дальше по течению». Вот парочка классических классические сценариев:

1. Согласование АГК, АГР: НПМ требуются для размещения на общей 3D-карте Москвы, а ВПМ требуются для архивирования и загрузки в Метавселенную Москвы - цифровой двойник города в виртуальной среде, существующей на базе Unreal Engine. А ЦИМ АГР в IFC идеологически нужна для автоматических проверок ТЭП.
2. Сметный расчет (5D): Сметчик берет готовую модель, чтобы автоматически выгрузить объёмы материалов. Если проектировщик не заполнил нужные коды или некорректно задал объёмы, этот сценарий «сломается». Именно на этом этапе и появляется потребность в классификации элементов, чтобы однозначно идентифицировать элементы - унификация на все проекты.
3. Планирование строительства (4D): На основе элементов модели строится график производства работ, элементы привязываются ко времени, появляются "захватки".
4. Закупки и логистика: В идеальной картине мира отдел снабжения использует ту же ВОР на основе данных из модели, чтобы заказать точное количество арматуры, бетона или воздуховодов и доставить их на строительную площадку.
5. Эксплуатация здания (6D): Когда объект сдан, служба эксплуатации использует цифровой двойник для обслуживания (например, кликает на насос в системе, чтобы увидеть дату его последней проверки и марку фильтра). Это самый редкий в целом, но популярный в промышленности сценарий использования ЦИМ (слышала на курсе ПСС "BIM-менеджер 2.0" от экспертов, но сама не щупала).

2. Принципы хороших BIM-требований

2.1. Требования должны быть проверяемыми

Формулировки вроде: "качественная модель"; "полноценный экспорт в IFC"; "без избыточной детализации"; "модель должна быть проработана"; список параметров без примеров и перечня допустимых значений не имеют смысла. Любое требование должно содержать: объект проверки; критерий; допуск; метод проверки.

Проектировщик зашьётся реализовывать абсолютно бесполезное требование:

Не допускаются коллизии

Чтобы был смысл, рекомендуется указывать конкретные детализированные проверки и прикладывать матрицу, с допусками:

Не допускается пересечение IfcSpace между собой.
Допустимое пересечение фасадной геометрии — не более 80 мм.

Но матрица тоже не является гарантией, её создавать нужно осознанно. Пример универсальной МК (для гражданских зданий) для IFC и RVT в виде шаблона Larix могу направить (напишите в сообщения сообщества https://t.me/letsmanagebim)

2.2. Требования должны быть минимально достаточными

Модель должна содержать ровно столько информации, сколько необходимо для сценариев использования.

Если задача модели: расчет СПП; подсчёта квартир; получение общей площади, то бессмысленно требовать:

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

Минимально достаточная модель должна обеспечивать:

• получение требуемых данных;
• автоматические проверки

А, значит, однозначную идентификацию элементов (но для данной задачи для большинства элементов достаточно IfcClass).

2.3. Требования должны быть независимы от ПО

Неправильно использовать терминологию конкретного САПР как нормативную. "Базовая точка проекта"; "внутреннее началом"; "семейства"; "общие координаты" - это термины конкретного ПО.

Правильно использовать:

• IFC/openBIM-терминологию;
• либо нейтральные инженерные формулировки.

Например вместо:

модель должна иметь базовую точку проекта

лучше писать:

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

Ну и подумать, а вы правда будете проверять эти координаты в модели, если у вас небольшой объект с одним зданием. Про ЛО сейчас не говорим)

2.4. Требования не должны противоречить реализации

Очень часто требования пишутся без учета ограничений IFC экспортеров или САПР.

В итоге появляются требования, которые:

• невозможно реализовать вообще;
• невозможно стабильно экспортировать (раз на раз не приходится).

Это, пожалуй, самое сложное. Те, кто состоят в чатиках по IFC и те, кто непосредственно практикует экспорт - знают эту боль не по наслышке. Поэтому написать понятные проектировщику и выполнимые им требования - настоящее искусство, нелегче, чем писать Войну и мир)))

Зачем требовать тип IfcReal, если при экспорте из одного САПР получаем футы по умолчанию? и выдумываем костыль, выгружаю в тип данных Area, а потом пишем плагины как в структуре IFC поправить тип данных с Area на Real..

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

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

Правильные требования должны учитывать реальные возможности САПР, а не абстрактную "идеальную BIM-модель".

2.5. Свои требования на каждое назначение зданий и сооружений

ПГС тоже нужно разделять на гражданские и промышленные. ЛО, инфраструктура - отдельная песня.

Пример ТЭП для промки на АГК.

3. Архитектура BIM-требований

3.1. Компоновка

Зрелые BIM-требования — это не один PDF-документ, а система связанных компонентов:

Должен существовать единый источник истины, поэтому важно явно определить:

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

Хоть в данной статье и ведется упоминание IDS, но важно понимать, что не покрывает всё и это только для работы по стандарту IFC:

• не решает геометрические проверки;
• не заменяет нормативный текст.

3.2. Системные ограничения требований

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

3.3. Плавная передача данных, автоматическое внесение изменений и уход от ручных данных

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

Но на практике, к примеру, модель из САПР невозможно экспортировать в FBX (НПМ, ВПМ) нужного качества (получается избыточная триангуляция и нужно «подчищать вручную модели»), поэтому ЦИМ АГР в .IFC и ВПМ/НПМ в .FBX делаются с нуля и это отдельные модели (переделывать после экспорта искажение meshей, изменение текстур зачастую сложнее, чем сделать с нуля).

Но даже если получилось из САПР выгрузить в .fbx с минимальными корректировками, возникает проблема внесения изменений. Отсутствует динамическая связь между САПР, ВПМ и НПМ. Снова выгружать, править ВПМ и создавать НПМ.

А что насчет машиночитаемых документов XML? В моей картине мира, если нужно сверить АГК (буклет) и АГР (модель), то данные с АГК уже должны быть уже в информационной системе и вручную их не нужно вносить Проектировщику. ЦИМ - должна быть единым источником данных без всяких XML. Бесшовная передача данных - головная боль Заказчика, а не Проектировщика.

4. Как правильно писать требования к данным

4.1. Каждый параметр должен иметь паспорт

А именно: назначение; тип данных; единицы измерения; допустимые значения; источник заполнения; сопоставление параметров IFC с параметрами САПР (маппинг); правило проверки; связь со сценарием использования.

Паспорт параметра Высота для такого-то сценария

Чем подробнее требования (не избыточны, а подробны), тем меньше вопросов по реализации.

4.2. Не нужно дублировать данные

Очень частая проблема "Имя" и "Наименование" - несколько параметров с одинаковым смыслом. У каждого значения должен быть один источник хранения и одно правило заполнения.

5. Методика расчета должна быть описана явно

5.1. Как правильно определять ТЭП

Недостаточно написать:

модель должна обеспечивать получение ТЭП.

Необходимо определить:

• какие элементы участвуют;
• какие IFC-классы допустимы;
• какие фильтры применяются;
• какие параметры учитываются;
• какие исключения существуют;
• как обрабатываются особые случаи;
• какие коллизии важны.

5.2. BIM-логика не равна нормативной логике

Например: модель может строиться по рельефу; а площадь по СП считается в проекции.

При этом:

• геометрическое ядро САПР считает площадь по поверхности с учётом уклонов;
• норматив требует другую методику.

Требования должны учитывать:

• особенности IFC;
• алгоритмы расчета в САПР;
• нормативную методику.

В таком случае, надо либо менять подход к ТЭП, практико-ориентированный наконец на современный САПР (ту же вопрос с округлением, может хватить вначале округлять, потом складывать?). Либо упрощать модель, никакие рельефы не заставлять моделировать

5.3. Методика должна ссылаться на актуальные СП

Для каждого расчета должны быть указаны:

• нормативный источник;
• пункт СП;
• редакция документа.

Очень частая ошибка — использование:

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

Например, рассмотрим выкопировку из методологии определения ТЭП. Значение высоты 1,8 м не соответствует актуальным нормативам. Термин «засыпка пространства» применён некорректно. Правило с порогом высоты применяется только к внутриквартирным лестницам.

Для жилых зданий (СП 54):
п. А.1.3 СП 54.13330.2022: «В площадь многоквартирного жилого здания включаются площади ниш высотой 2 м и более, арочных проемов шириной 2 м и более, пола под маршем внутриквартирной лестницы при высоте от пола до низа выступающих конструкций марша 1,6 м и более» .

Для общественных зданий (СП 118):
п. А.4 СП 118.13330.2022: «Площадь общественного помещения определяют по его размерам, измеряемым между отделанными поверхностями стен и перегородок на уровне пола (без учета плинтусов). В площадь общественного помещения включают: площадь лестничных площадок и ступеней, расположенных в пределах такого помещения» .

п. А.2.2 СП 54.13330.2022: «Площадь под маршем внутриквартирной лестницы на участке с высотой от пола до низа выступающих конструкций лестницы 1,6 м и менее не включается в площадь помещения, в котором размещена лестница» .

Для лестниц общего пользования:
п. А.1.3 СП 54.13330.2022: «В площадь этажа включают... лестничные площадки и ступени с учетом их площади в уровне данного этажа» .

п. А.1 СП 118.13330.2022: «Не включают площади: засыпанных землей пространств между строительными конструкциями» .

В СП 54 аналогичное понятие отсутствует - используется «подполье», «техническое подполье», «проветриваемое подполье» . Понятие «засыпка» относится к пространствам между конструкциями, заполненным грунтом (техническое подполье, обратная засыпка), а не к пустующему пространству под лестницей в эксплуатируемом этаже.

Спасибо Сергею Драгомирову за экспертные комментарии.

6. Как правильно писать требования к IFC

6.1. IFC-классы должны быть определены однозначно

Проверяйте требование на:

• запрет класса в одном разделе;
• разрешение его в другом.

Что может быть в Proxy? И может ли быть вообще? Недавно была дискуссия, нужен или нет. Я считаю, что оставляем, а вы?

6.2. Пользовательские наборы параметров

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

1. минимизировать количество кастомных pset;
2. использовать стандартные (buildingSMART) системные свойства классов IFC (наборы "Pset", "Qto");
3. При описывании маппинга тестировать интероперабельность между системами на пилотных моделях.

6.3. Лучшие практики Open BIM

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

• возможна выгрузка не листов, а видов с координатной привязкой. Это классный рывок, но пока недостаточный, чтобы перевернуть парадигму. Кто сделает это первым, тот молодец :)
• ну и важно учитывать весь зоопарк САПР

Если отечественный САПР позволяет выгружать в IFC без костылей, то у вас есть все шансы, как минимум на АГК, АГР занять нишу, даже у самых ярых ревитчиков (на истину не претендую, но чувствую, что это настолько сильная боль). И это надо популяризировать! Готова потестировать ваши решения, напишите мне (в сообщения канала https://t.me/letsmanagebim)

Ну и для справки. BIM Collaboration Format (BCF) — это открытый XML-формат файлов, всё остальное - нет. Листы с аннотациями и условными обозначениями (в привычном нам понимании) в IFC не выгружаются. Но можно выгрузить вид с планом первого этажа, сохранив секущий диапазон, оси.

7. Как писать требования к автоматическим проверкам

7.1. Проверки должны быть значимыми

Нет смысла проверять:

• названия уровней;
• субъективный LOD;
• коллизии без влияния на сценарий использования.

Имеет смысл проверять:

• пересечения помещений;
• корректность классификации на этапе получения ВОР;
• атрибуты для текущих BIM-uses;
• ошибки расчета площадей, дельту между чертежом и ЦИМ.

7.2. Проблема скрытых проверок

Проектировщик может написать:

• «СПП в ГНС»;
• «СПП ГНС»;
• «СПП ГНС 1 этаж»;
• «Жилая СПП».

IDS/шаблоны проверок не должны содержать "скрытых требований"

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

Например, в IDS параметр должен быть равен СПП в ГНС, тогда СПП ГНС или СПП ГНС 1-го этажа будут ошибкой и это надо четко зафиксировать в требованиях.

Если данные участвуют в автоматизации, необходимо использовать:

• классификаторы;
• фиксированные значения;
• диапазоны.

8. Чек-лист зрелых BIM-требования

• основаны на сценариях использования;
• машиночитаемы (но на 100% таких пока не существует, но хотя бы требования к параметрам и МК в Excel);
• пункты требований автоматически проверяемы;
• независимы от ПО;
• минимально!!! достаточны;
• совместимы с openBIM;
• не содержат скрытых проверок: согласованы между текстом, IDS|шаблонами;
• учитывают реальные ограничения интероперабельности;
• не лишены здравого смысла;
• уважают труд проектировщиков

Самое главное — они должны быть реализуемыми без ручных «костылей», минимально достаточны и однозначны для всех ролей. Не нужно из ЦИМ делать коробку (хотя на ЦИМ АГР очень даже можно ИМХО), но и замок Дисней тоже никому не нужен.