Bonsai - еще не САПР, но больше, чем САПР

В то время, как бесплатный ИИ-помощник DeepSeek уложил на лопатки IT-гигантов, вернемся в более приземленное русло.

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

У нас нет завышенных ожиданий по поводу Bonsai, однако считаем, что этот инструмент заслуживает в IFC Клубе отдельной ветки Bonsai | BlenderBIM.

➖Конечно, надстройку Bonsai на базе мощного бесплатного ПО Blender нельзя назвать полноценным САПР.

✅Вместе с тем его возможности выходят за рамки обычного IFC-вьюера и традиционных САПР.

Что в нем стоит обсудить:

🔹 Обнаружение коллизий и работа по их устранению на базе BCF
🔹 Создание новых IFC-моделей с нуля и редактирование существующих
🔹 Создание 2D-документации
🔹 Исправление некорректной координационной привязки файлов IFC
🔹 Создание календарных графиков и их визуализации
🔹 Интеграция c bSDD для подключения альтернативной классификации
🔹 Перевод моделей между различными версиями IFC (например, IFC4 в IFC4x3)
🔹 Использование библиотек IFC для повторного применения
🔹 Валидация моделей на соответствие цифровым требованиям IDS
🔹 Извлечение необходимых данных
🔹 Назначение наборов свойств (Psets) для объектов
🔹 и многое другое.

Ежемесячный подкаст "BIM-среда" в IFC Клубе!

Помните крутой доклад на BIM-форуме про BIM-менеджмент и IDS? В эту среду мы поговорим подробнее, что к чему и почему.

🗓️ Среда, 5 февраля, в 16-00 МСК

🔊 Тема: "OpenSource, IFC и IDS в управлении проектами"

Гость:
👤 Антон Мотовилов, Руководитель отдела цифровизации и технологий информационного моделирования, ООО «Желдорпроект»

Поговорим о:
🛑управлении процессами по информационному моделированию с помощью инструментов на открытом исходном коде;
🛑управлении требованиями к IFC-моделям с использованием OpenSource-решений;
🛑разработках в части автоматизации проверок моделей;
🛑и перспективах применения такого подхода.

Присоединяйтесь!
Встреча будет проходить в группе в формате видео-чата.

👥 @IFC_ru
👥 @IFC_club

✈️ Запись эфира "OpenSource, IFC и IDS в управлении проектами"

✈️ Гость: Антон Мотовилов, руководитель отдела цифровизации и технологий информационного моделирования, ООО «Желдорпроект»

📹Youtube | 📺Rutube | ✈️Презентация

👥 @IFC_ru
👥 @IFC_club

DeepSeek и IFC. Пример запроса

Запрос:

Сопоставь работу со схемой данных стандарта IFC.
Используй только данные с ресурса https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/

Устройство железобетонных колонн в деревянной опалубке высотой:до 6 м, периметром более 4 м

Ответ:
Для сопоставления работы "Устройство железобетонных колонн в деревянной опалубке высотой: до 6 м, периметром более 4 м" со схемой данных стандарта IFC (Industry Foundation Classes) версии IFC4_3, необходимо определить соответствующие классы и атрибуты, которые описывают процесс строительства железобетонных колонн с использованием деревянной опалубки.

Шаги для сопоставления:
Описание колонны:

Железобетонная колонна может быть описана с использованием класса IfcColumn, который представляет собой вертикальный строительный элемент.

Атрибуты:

Name: "Железобетонная колонна".

PredefinedType: COLUMN.

Height: 6 м (может быть указано в IfcPropertySingleValue).

Perimeter: более 4 м (также может быть указано в IfcPropertySingleValue).

Материал колонны:

Железобетон может быть описан с использованием класса IfcMaterial с атрибутом Name = "Железобетон".

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

Опалубка:

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

Атрибуты:

Name: "Деревянная опалубка".

PredefinedType: FORMWORK.

Процесс устройства колонн:

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

Атрибуты:

Name: "Устройство железобетонных колонн в деревянной опалубке".

OperatesOn: ссылки на колонну (IfcColumn) и опалубку (IfcConstructionMaterialResource).

➕
В схеме IFC нет стандартного «периметра» для колонны, поэтому DeepSeek предложил пользовательское свойство Perimeter.

В случае с высотой DeepSeek не определил стандартный количественный показатель (quantity) Length как высоту колонны и также предложил ввести свойство Height.

Как подружить элементы и документы в IFC

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

Ранее мы публиковали новость о том, что в BIM Vision появилась эта возможность.

Создавать такие ссылки можно с помощью инструментов от That Open. Пара видео 🎞тут.

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

🔍То есть стандарт IFC позволяет формировать "скелет" для интеграции геометрических данных, буквенно-цифровой информации и документации (в соответствии с ISO 19650 и ISO 7817).

👥 @IFC_ru
👥 @IFC_club

Проверка IFC моделей по требованиям IDS

На Хабре вышла хорошая обзорная статья от Ильи Савельева по работе с IDS-требованиями, с полезными ссылками и практическими кейсами на Python и библиотеки ifcopenshell.

Добавляем в закладки.

👥 @IFC_ru
👥 @IFC_club

Связи BIM-стандартов ISO

Комитет по моделированию и стандартам EC3 связал воедино все ISO-стандарты по информационным технологиям в строительстве.

Стандарты отбираются фильтрами. А при нажатии на кнопку Relationships отображаются все связи между этими стандартами.

Полезный и нужный труд.

https://ec-3.org/BIM-Standards-Landscape-Explorer.html

👥 @IFC_ru
👥 @IFC_club

Обзор библиотек для просмотра IFC в веб-приложениях

Если вы планируете создавать веб-приложения для работы с моделями, важно не ошибиться с подходящей библиотекой для отображения IFC-файлов.

Коллеги из MARKS DIGITAL сделали подробный разбор популярных решений:

🔹Ifc.js (в настоящий момент развивается как That Open Company);
🔹Xbim;
🔹Xeokit.

Каждая библиотека имеет свои особенности, выбор зависит от задач проекта.

Подробнее в статье: читать

👥 @IFC_ru
👥 @IFC_club

Машинно-интерпретируемые требования: иллюзия или реальность?

Рассмотрим схему:

1. Определили цифровые требования в IDS.
2. Создали модель в IFC.
3. Сформировали отчет об ошибках в BCF.
4. Отправили данные через openCDE.

Мы часто слышим о машинно-интерпретируемых требованиях, открытых стандартах и цифровой трансформации. Но что, если это лишь верхушка айсберга? Что, если за красивыми слайдами скрывается проблема, которую предпочитают игнорировать?

На этой картинке нас смущает пункт 3 и отсутствие еще одного важного шага между 2 и 3.

🔍 Отчет в BCF - это не проверка, а лишь отчет о проверке.

Это не check, а report. И в этом кроется ключевая ошибка. Где же сам механизм проверки? Где открытые алгоритмы, которые должны лежать в основе этой системы?

Что мы имеем на текущий момент:

🛑 IDS-стандарт и его дальнейшее развитие призвано формализовать требования к информации в машинном виде.
При этом алгоритмы проверки файла на соответствие IDS находится вне файла требований, а на стороне вьюверов и чекеров.

Вопрос "подкапотной обработки" модели на соответствие требованиям решают OpenSource-проекты, наиболее известный из них - IfcOpenShell.

🛑 В России формируется реестр требований, который к 2026 году планируют перевести в машинно-интерпретируемую форму, использовав для этого разметку на базе КСИ.
При этом мы не видим ни активного движения в сторону апробации формируемых требований, ни верификационных примеров, ни открытых алгоритмов, которые бы помогли другим разработчикам ЕДИНООБРАЗНО интерпретировать и проводить проверку.

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

🔍Реестр цифровых нормативных требований - это только начало.
Следующий шаг - это создание алгоритмов проверки. Ведь мы собираемся передать машине функции, которые раньше выполнял человек. А значит, должны быть на 100% уверены в корректности этих алгоритмов.

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

🔍 Подытожим:
Без открытых алгоритмов проверки вся система машинно-интерпретируемых требований останется неполной, а значит - нерабочей.

✈️ Ну и вопрос "на засыпку", готовы ли мы к такому уровню цифровизации? Или нам еще рано говорить о полной автоматизации проверок?

📢 @IFC_ru
👥 @IFC_club

Интероперабельность. Роль заказчика и разработчика ПО

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

Важность открытых форматов большинство заказчиков осознало несколько лет назад, когда Autodesk ушел

Это осознали только те, кто давно работает с BIM. Сегодня заказчики, особенно государственные - это наиболее "просевшее" звено. И связано это с тем, что они до сих пор не могут сформулировать свои потребности, исходя из которых формулировались бы требования.

Заказчик должен играть ключевую роль в установлении требований к данным. Однако сегодня мы имеем немного другую ситуацию:

- BIM-стандарты и ТЗ на модель зачастую пишут сами проектировщики;
- требования к форматам и классификации - в постановлениях Правительства;
- а проверки на коллизии - дело экспертизы.

Заказчик в этом процессе как-то затерялся.

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

+1.
При этом разработчики ПО, не развивая интероперабельность на базе OpenBIM-стандартов, делают хуже не только пользователю, но и себе, так как потребность в стандартизации данных будет расти и дальше. А плохая поддержка открытых стандартов уже давно воспринимается как большой недостаток такого ПО.

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

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

👥 @IFC_ru
👥 @IFC_club

Альтернативная классификация

Не хватает классов IFC?

🔍 Использование инструментов That Open Engine и JavaScript (для красоты) позволяет добавлять, редактировать и сохранять дополнительную классификацию к элементам, будь то КСИ, МССК, Uniformat, OmniClass или любую другую.

Классификационных систем в одном IFC-файле может быть несколько, в зависимости от задач.

Для кода и наименования классификатора предназначены специальные сущности IfcClassificationReference и IfcClassification. Это важно, чтобы классификатор всегда находился в одном месте, а не в произвольном параметре вроде "код по КСИ".

✈️ Напомним, что в редакторе IDS от ИСП РАН можно создавать требования с использованием альтернативной классификации (КСИ, РЖД, МССК).

👥 @IFC_ru
👥 @IFC_club

Провели встречу с замечательным человеком, BIM-лидером отрасли в части инфраструктуры Аллой Землянской (Tangl).
Обсудили перспективы открытых стандартов передачи данных в отечественных ПО.

🔹 В части цифровых требований пришли к общему мнению, что это молодое направление еще предстоит освоить как вендорам, так и заказчикам. И начинать здесь надо с малого, с IDS :) то есть с цифровизации требований заказчика.

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

🔹Также поговорили о передаче отчетов о коллизиях в BCF. Востребованность формата пока по большей части ограничивается госсектором и органами экспертиз. Но при обмене замечаниями через BCF-сервер, популярность его будет только расти. И такие разработки в России уже ведутся.

🔹И затронули перспективу перехода к IFC4x3, как более проработанному и развитому в части описания инфраструктурных объектов.

👥 @IFC_ru
👥 @IFC_club